07-11-2020, 08:53 PM (This post was last modified: 07-11-2020, 08:56 PM by SAO.)
Dear all, Could you please help to figure out how to limit the maximum amount of subsidies available for specific period and for different technologies?
I have diferent wind and solar technologies for which subsidies are available (see in attached file)
Total amount of subsidies for wind and solar technolgies is 750 000 in TOTAL.
Period for subsidies is 2025 – 2030. Theres is no limit to the amount of each years subsidies (all amount could be spend in one year or split between years).
The amount of the subsidy per technology is not limited (it could be 50% of investment cost, 100% of investment cost etc.).
Please see attached file. This way does not seem to be very appropriate.
There are several different ways of limiting the maximum amount of subsidies available for specific period and for different technologies, depending on what is exactly the desired formulation of the constraint. 1) One can use REG_BNDCST for limiting the total amount of annual subsidy payments in a any given region and period. 2) One can use REG_CUMCST (as in your scenario file) for limiting the cumulative amount of annual subsidy payments in a given region within a range of years. 3) One can use the user constraint modifier SUB for referring to the lump-sum investment subsidies in any period, and thus bound the amount of the lump-sum investment subsidies in a flexible way by/over regions, technologies and periods. Moreover, 4) one can use the user constraint modifier INVSUB for referring to the amount of annualized investment payments in a given period, and so you can bound the amount of annualized investment subsidies in a flexible way by/over regions, technologies and periods:
• by region, period and technology, or
• by region and technology but over some periods, or
• by technology and period but over some regions, or
• by region and period but over some technologies, or
• by region but over some technologies and periods, or
• by technology but over some regions and some periods, or
• by period but over some regions and technologies, or
• over some regions, some technologies and some periods.
If, for example, the limit for the amount of subsidies for wind and solar technologies is 750,000 in TOTAL, the question remains whether this bound should be for the total amount of the lump-sum subsidies for those technologies (and if so, over which range of commissioning years), or for the total amount of annualized subsidy payments (and if so, over which range of operating years).
If you say that the "Period for subsidies is 2025 – 2030", the question remains whether this means that the subsidy is supposed to be granted only for plants commissioned in 2025 – 2030, or if it means that the amount of annual subsidy payments in 2025 – 2030 is to be limited. In your scenario file, NCAP_ISUB is defined for 2025–2030, which implies that the subsidy is granted for plants commissioned in 2025–2030, while REG_CUMCST is defined for 2023–2030, which implies that only the amount of annual subsidy payments in 2023–2030 is to be limited. However, depending on model milestone years, if you want that no subsidies are to be granted for plants commissioned in 2024 or before, you should additionally define a zero value for the subsidies in 2024.
You state that "There is no limit to the amount of each years subsidies (all amount could be spend in one year or split between years)." Note that if you want the model to be able to optimize the amount of subsidies granted in individual years, you would need to use one-year periods.
You state that "The amount of the subsidy per technology is not limited (it could be 50% of investment cost, 100% of investment cost etc.)." It is not quite clear what this implies: do you mean that the subsidy can be 50%, 100%, 150%, 200%, 250%, … ∞%? Or do you mean it can be anything between X% and 100%? If the latter, I think you should include in the model the options of having either an X% or a 100% subsidy for each of the subsidized technologies in the model during 2025–2030, so that the model can then choose any linear combination between those extremes X% and 100%.
You say that the way in the scenario file does not seem to be very appropriate. Can you elaborate a bit why it would not be appropriate? In your scenario file, NCAP_ISUB=630 is defined for certain technologies between 2025 and 2030, which implies that such a subsidy is granted for any new plants commissioned in 2025–2030 (and possibly also to a lesser extent in a few years before, due to the interpolation of NCAP_ISUB), while REG_CUMCST is defined for 2023–2030, which implies that the total amount of all annual subsidy payments in the year range 2023–2030 is limited to 750,000.
(10-11-2020, 04:02 PM)Antti-L Wrote: There are several different ways of limiting the maximum amount of subsidies available for specific period and for different technologies, depending on what is exactly the desired formulation of the constraint. 1) One can use REG_BNDCST for limiting the total amount of annual subsidy payments in a any given region and period. 2) One can use REG_CUMCST (as in your scenario file) for limiting the cumulative amount of annual subsidy payments in a given region within a range of years. 3) One can use the user constraint modifier SUB for referring to the lump-sum investment subsidies in any period, and thus bound the amount of the lump-sum investment subsidies in a flexible way by/over regions, technologies and periods. Moreover, 4) one can use the user constraint modifier INVSUB for referring to the amount of annualized investment payments in a given period, and so you can bound the amount of annualized investment subsidies in a flexible way by/over regions, technologies and periods:
• by region, period and technology, or
• by region and technology but over some periods, or
• by technology and period but over some regions, or
• by region and period but over some technologies, or
• by region but over some technologies and periods, or
• by technology but over some regions and some periods, or
• by period but over some regions and technologies, or
• over some regions, some technologies and some periods.
If, for example, the limit for the amount of subsidies for wind and solar technologies is 750,000 in TOTAL, the question remains whether this bound should be for the total amount of the lump-sum subsidies for those technologies (and if so, over which range of commissioning years), or for the total amount of annualized subsidy payments (and if so, over which range of operating years).
If you say that the "Period for subsidies is 2025 – 2030", the question remains whether this means that the subsidy is supposed to be granted only for plants commissioned in 2025 – 2030, or if it means that the amount of annual subsidy payments in 2025 – 2030 is to be limited. In your scenario file, NCAP_ISUB is defined for 2025–2030, which implies that the subsidy is granted for plants commissioned in 2025–2030, while REG_CUMCST is defined for 2023–2030, which implies that only the amount of annual subsidy payments in 2023–2030 is to be limited. However, depending on model milestone years, if you want that no subsidies are to be granted for plants commissioned in 2024 or before, you should additionally define a zero value for the subsidies in 2024.
You state that "There is no limit to the amount of each years subsidies (all amount could be spend in one year or split between years)." Note that if you want the model to be able to optimize the amount of subsidies granted in individual years, you would need to use one-year periods.
You state that "The amount of the subsidy per technology is not limited (it could be 50% of investment cost, 100% of investment cost etc.)." It is not quite clear what this implies: do you mean that the subsidy can be 50%, 100%, 150%, 200%, 250%, … ∞%? Or do you mean it can be anything between X% and 100%? If the latter, I think you should include in the model the options of having either an X% or a 100% subsidy for each of the subsidized technologies in the model during 2025–2030, so that the model can then choose any linear combination between those extremes X% and 100%.
You say that the way in the scenario file does not seem to be very appropriate. Can you elaborate a bit why it would not be appropriate? In your scenario file, NCAP_ISUB=630 is defined for certain technologies between 2025 and 2030, which implies that such a subsidy is granted for any new plants commissioned in 2025–2030 (and possibly also to a lesser extent in a few years before, due to the interpolation of NCAP_ISUB), while REG_CUMCST is defined for 2023–2030, which implies that the total amount of all annual subsidy payments in the year range 2023–2030 is limited to 750,000.
Dear Antii,
Thank you so much for the detailed answer! And sorry for my late reply.
I had now time to study it and I guess the problem was that the total subsidy amount I mentioned (750,000) was only for those specific RNW technologies but there are available even more subsidy for other processes/technologies. Therefore the attribute REG_CUMCST (ALLSUB) is not appropriate as other subsidies are not allowed as I understand it.
The total amount of subsidies 750,000 is for the total amount of lump-sum subsidies for wind and solar technologies in period 2023-2030 and I tried to implement it using UC SUB (please see attachment) and seems it works well.
(10-11-2020, 04:02 PM)Antti-L Wrote: There are several different ways of limiting the maximum amount of subsidies available for specific period and for different technologies, depending on what is exactly the desired formulation of the constraint. 1) One can use REG_BNDCST for limiting the total amount of annual subsidy payments in a any given region and period. 2) One can use REG_CUMCST (as in your scenario file) for limiting the cumulative amount of annual subsidy payments in a given region within a range of years. 3) One can use the user constraint modifier SUB for referring to the lump-sum investment subsidies in any period, and thus bound the amount of the lump-sum investment subsidies in a flexible way by/over regions, technologies and periods. Moreover, 4) one can use the user constraint modifier INVSUB for referring to the amount of annualized investment payments in a given period, and so you can bound the amount of annualized investment subsidies in a flexible way by/over regions, technologies and periods:
• by region, period and technology, or
• by region and technology but over some periods, or
• by technology and period but over some regions, or
• by region and period but over some technologies, or
• by region but over some technologies and periods, or
• by technology but over some regions and some periods, or
• by period but over some regions and technologies, or
• over some regions, some technologies and some periods.
If, for example, the limit for the amount of subsidies for wind and solar technologies is 750,000 in TOTAL, the question remains whether this bound should be for the total amount of the lump-sum subsidies for those technologies (and if so, over which range of commissioning years), or for the total amount of annualized subsidy payments (and if so, over which range of operating years).
If you say that the "Period for subsidies is 2025 – 2030", the question remains whether this means that the subsidy is supposed to be granted only for plants commissioned in 2025 – 2030, or if it means that the amount of annual subsidy payments in 2025 – 2030 is to be limited. In your scenario file, NCAP_ISUB is defined for 2025–2030, which implies that the subsidy is granted for plants commissioned in 2025–2030, while REG_CUMCST is defined for 2023–2030, which implies that only the amount of annual subsidy payments in 2023–2030 is to be limited. However, depending on model milestone years, if you want that no subsidies are to be granted for plants commissioned in 2024 or before, you should additionally define a zero value for the subsidies in 2024.
You state that "There is no limit to the amount of each years subsidies (all amount could be spend in one year or split between years)." Note that if you want the model to be able to optimize the amount of subsidies granted in individual years, you would need to use one-year periods.
You state that "The amount of the subsidy per technology is not limited (it could be 50% of investment cost, 100% of investment cost etc.)." It is not quite clear what this implies: do you mean that the subsidy can be 50%, 100%, 150%, 200%, 250%, … ∞%? Or do you mean it can be anything between X% and 100%? If the latter, I think you should include in the model the options of having either an X% or a 100% subsidy for each of the subsidized technologies in the model during 2025–2030, so that the model can then choose any linear combination between those extremes X% and 100%.
You say that the way in the scenario file does not seem to be very appropriate. Can you elaborate a bit why it would not be appropriate? In your scenario file, NCAP_ISUB=630 is defined for certain technologies between 2025 and 2030, which implies that such a subsidy is granted for any new plants commissioned in 2025–2030 (and possibly also to a lesser extent in a few years before, due to the interpolation of NCAP_ISUB), while REG_CUMCST is defined for 2023–2030, which implies that the total amount of all annual subsidy payments in the year range 2023–2030 is limited to 750,000.
Dear Antti,
I have a similar issue as SAO. I would like to set a limit on the sum of lump-sum investment subsidy over 2025-2030. Unfortunately, my UC does not work properly - see the attachment, please.
Could you advise me please, how to define this UC correctly? Thank you very much.
You say: "I would like to set a limit on the sum of lump-sum investment subsidy over 2025-2030."
Please first explain what this is exactly implying? I can see that you are defining a constraint for each period, and in such a way that you are bounding the total lump-sum subsidies in 2020 to zero, then in 2025 and 2030 to at most 2547, and in all periods after that to zero again (taking the first set of constraints as an example). But you still say that it is not what you want after all?
In other words, when you say "Unfortunately, my UC does not work properly", what do you mean by saying that? In what sense it is not working properly? Do you mean that there is a bug in TIMES, as you say the constraints are not working properly? How should those constraints work in your view?
(26-04-2021, 04:43 AM)Antti-L Wrote: You say: "I would like to set a limit on the sum of lump-sum investment subsidy over 2025-2030."
Please first explain what this is exactly implying? I can see that you are defining a constraint for each period, and in such a way that you are bounding the total lump-sum subsidies in 2020 to zero, then in 2025 and 2030 to at most 2547, and in all periods after that to zero again (taking the first set of constraints as an example). But you still say that it is not what you want after all?
In other words, when you say "Unfortunately, my UC does not work properly", what do you mean by saying that? In what sense it is not working properly? Do you mean that there is a bug in TIMES, as you say the constraints are not working properly? How should those constraints work in your view?
Thank you for your quick response Antti.
I would like to limit the sum over 2025 and 2030 to 2547 and 764, respectively.
The results show LUMPIX Cap_New for the process -1026 and -2561 for EUPVSOL201 in 2025 and 2030, respectively. This is more than 764 that should be bound for EUPVSOL201 in the second UC.
I conclude, I either interpret the results wrong or the UC does not work as desired.
26-04-2021, 09:43 PM (This post was last modified: 26-04-2021, 10:14 PM by Antti-L.)
Ok, thanks for the clarification.
Looking at the issue in some more detail, I can see that you (and at first me too) forgot that the SUB UC modifier is handled as defining a cost term summed with any other cost modifier terms. From the documentation:
The cost modifiers are applied to the variable terms by multiplying them with the corresponding cost attribute, or with the sum of multiple cost attributes, if several cost modifiers are specified.
SUB: Multiple by subsidy attribute (summing together with other cost attributes requested)
Therefore, recalling that convention, it should be clear that all subsidy terms are negative cost terms. Consequently, when bounding subsidies with UCs using the SUB modifier, you should use a 'LO' bound and a negative RHS constant. Or alternatively, you could also just use −1 as the UC_NCAP coefficient to change the sign of the subsidies. However, you used an UP bound with UC_NCAP=1 and a positive RHS constant, which of course would never become binding for those subsidies.
Another small aspect in play here is the fact that the "cost modifiers are applied to the variable terms by multiplying them with the corresponding cost attribute". This means that, for example, VAR_NCAP(r,'2030',p) will be multiplied by NCAP_ISUB(r,'2030',p,cur). That will accurately reflect the lump-sum investment subsidy when the subsidy is constant over time, but if it is changing over time, the true lump-sum subsidy will in general be slightly different (because in each period the investments are usually spread over many commissioning years, each having a slightly different NCAP_ISUB).
Nonetheless, if you can live with the small inaccuracy caused by the approximate lump-sum coefficients of your UCs, you should have a constraint fully working as documented by changing UP to LO and the RHS constants to have a minus sign, or alternatively, use −1 as the UC_NCAP coefficient to change the sign of the subsidies.
(26-04-2021, 09:43 PM)Antti-L Wrote: Ok, thanks for the clarification.
Looking at the issue in some more detail, I can see that you (and at first me too) forgot that the SUB UC modifier is handled as defining a cost term summed with any other cost modifier terms. From the documentation:
The cost modifiers are applied to the variable terms by multiplying them with the corresponding cost attribute, or with the sum of multiple cost attributes, if several cost modifiers are specified.
SUB: Multiple by subsidy attribute (summing together with other cost attributes requested)
Therefore, recalling that convention, it should be clear that all subsidy terms are negative cost terms. Consequently, when bounding subsidies with UCs using the SUB modifier, you should use a 'LO' bound and a negative RHS constant. Or alternatively, you could also just use −1 as the UC_NCAP coefficient to change the sign of the subsidies. However, you used an UP bound with UC_NCAP=1 and a positive RHS constant, which of course would never become binding for those subsidies.
Another small aspect in play here is the fact that the "cost modifiers are applied to the variable terms by multiplying them with the corresponding cost attribute". This means that, for example, VAR_NCAP(r,'2030',p) will be multiplied by NCAP_ISUB(r,'2030',p,cur). That will accurately reflect the lump-sum investment subsidy when the subsidy is constant over time, but if it is changing over time, the true lump-sum subsidy will in general be slightly different (because in each period the investments are usually spread over many commissioning years, each having a slightly different NCAP_ISUB).
Nonetheless, if you can live with the small inaccuracy caused by the approximate lump-sum coefficients of your UCs, you should have a constraint fully working as documented by changing UP to LO and the RHS constants to have a minus sign, or alternatively, use −1 as the UC_NCAP coefficient to change the sign of the subsidies.
Oh, it is clear now and it works as you described. Thank you very much!
We are currently struggling on setting up a UC on the maximum (cumulative) subsidy budget. These subsidies are set as investment subsidies (NCAP_ISUB).
Please find below the UC.
From results we noticed that it is somehow binding, however from results, checking INVX+ and LUMPIX, the sum is not consistent with the bound imposed
20-05-2021, 04:48 PM (This post was last modified: 20-05-2021, 05:19 PM by Antti-L.)
As described in the documentation (and my previous post above), "cost modifiers are applied to the variable terms by multiplying them with the corresponding cost attribute". This means that, for example, VAR_NCAP(r,'2030',p) will be multiplied by NCAP_ISUB(r,'2030',p,cur). Your constraint defines a bound on the cumulative amount of VAR_NCAP × (−NCAP_ISUB) apparently over two periods 2021 and 2030.
Consequently, if you want to check the constraint, you should calculate the corresponding sum of VAR_NCAP × (−NCAP_ISUB) from the VAR_NCAP results.
However, instead of doing that, you are comparing INVX+ and LUMPIX with the bound imposed. Why is that? Are you expecting that INVX+ and LUMPIX somehow would give you the sum of VAR_NCAP(r,t,p) × (−NCAP_ISUB(r,t,p)) over the two periods 2021 and 2030?
The LUMPIX / INVX+ components of Cap_New give the lump-sum investment taxes and subsidies in the same way as LUMPINV / INV+ gives the lump-sum investment costs. These lump-sums are calculated in such a way that the cost / taxes / subsidies in the objective function are equivalent to a single lump-sum payment in the beginning of the commissioning year. This means that all the annual investment payments are discounted to the beginning of the commissioning year k associated to each payment stream. When neither NCAP_ILED nor NCAP_DRATE is defined, the sum of the LUMPINV & INV+ values will indeed be equal to sum of VAR_NCAP(r,k,p) × NCAP_COST(r,k,p) in each period. But if either of them is defined, the lump sum cost will be higher, because with interest during construction or a higher required rate of return, the present value of the investment payments at the commissioning year will be higher than the sum of VAR_NCAP(r,k,p) × NCAP_COST(r,k,p). Moreover, LUMPINV, LUMPIX, INV+ & INVX+ are based on the detailed objective function formulation, and thus take into account the change in the costs/taxes/subsidies over time. Hence, there can be several differences from the sum of VAR_NCAP(r,t,p) × (−NCAP_ISUB(r,t,p)).
The bottom line is that you can only check the constraint with the same formulation as it uses: Sum of VAR_NCAP(r,t,p) × (−NCAP_ISUB(r,t,p)).
Additional remark: Actually, I think your constraint is over all periods, although for some reason you have put 2021, 2030 in the Year column.
(26-04-2021, 09:43 PM)Antti-L Wrote: Ok, thanks for the clarification.
Looking at the issue in some more detail, I can see that you (and at first me too) forgot that the SUB UC modifier is handled as defining a cost term summed with any other cost modifier terms. From the documentation:
The cost modifiers are applied to the variable terms by multiplying them with the corresponding cost attribute, or with the sum of multiple cost attributes, if several cost modifiers are specified.
SUB: Multiple by subsidy attribute (summing together with other cost attributes requested)
Therefore, recalling that convention, it should be clear that all subsidy terms are negative cost terms. Consequently, when bounding subsidies with UCs using the SUB modifier, you should use a 'LO' bound and a negative RHS constant. Or alternatively, you could also just use −1 as the UC_NCAP coefficient to change the sign of the subsidies. However, you used an UP bound with UC_NCAP=1 and a positive RHS constant, which of course would never become binding for those subsidies.
Another small aspect in play here is the fact that the "cost modifiers are applied to the variable terms by multiplying them with the corresponding cost attribute". This means that, for example, VAR_NCAP(r,'2030',p) will be multiplied by NCAP_ISUB(r,'2030',p,cur). That will accurately reflect the lump-sum investment subsidy when the subsidy is constant over time, but if it is changing over time, the true lump-sum subsidy will in general be slightly different (because in each period the investments are usually spread over many commissioning years, each having a slightly different NCAP_ISUB).
Nonetheless, if you can live with the small inaccuracy caused by the approximate lump-sum coefficients of your UCs, you should have a constraint fully working as documented by changing UP to LO and the RHS constants to have a minus sign, or alternatively, use −1 as the UC_NCAP coefficient to change the sign of the subsidies.
Oh, it is clear now and it works as you described. Thank you very much!
Dear Antti,
I migrated the model to VEDA 2.0. The UC setting maximum lump sum investment subsidy now seems to limit the NCAP itself - the model is infeasible with this UC as it is in conflict with minimal ELC production by wind power plants in 2020 and in the UC the investment subsidies should be zero in 2020.
Does the VEDA 2.0 read the SUB modifier correctly? I cannot see it in browse (attached).
Thank you very much. Lukas
20-08-2021, 11:18 PM (This post was last modified: 20-08-2021, 11:20 PM by Antti-L.)
I tried to use your scenario for the DemoS4 model. The import went well, and when I wrote the DD files, I was able to see the UC_ATTR being defined there as expected. Thus, I cannot confirm your findings about the lump sum investment subsidy being now limiting the NCAP itself. In fact, I am seeing the subsidy being correctly applied as the coefficient for VAR_NCAP.
But yes, like you I was not able to see UC_ATTR in Browse. Maybe this is a VEDA bug? If you think so, please report it to the VEDA developers (I am not one).
(20-08-2021, 11:18 PM)Antti-L Wrote: I tried to use your scenario for the DemoS4 model. The import went well, and when I wrote the DD files, I was able to see the UC_ATTR being defined there as expected. Thus, I cannot confirm your findings about the lump sum investment subsidy being now limiting the NCAP itself. In fact, I am seeing the subsidy being correctly applied as the coefficient for VAR_NCAP.
But yes, like you I was not able to see UC_ATTR in Browse. Maybe this is a VEDA bug? If you think so, please report it to the VEDA developers (I am not one).
