(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).
As I am a beginner with VEDA2, I am still myself wondering whether I am just not finding a way to refresh the Browse data sets, as I have understood that such may be needed from time to time.
Anyway, UC_ATTR is an important attribute needed in various types of user constraints, and it would be very useful if one would be able to see it being read correctly into the model database...
I am trying to follow the instructions put forth in this thread regarding limiting investment subsidies per year to a certain amount. It seems to be working correctly, in regards that lumpix is reaching the exact allocated yearly investment subsidy set in the constraint. Thus the constraint is doing what I want it to do with regards to limiting investments subsidies, but creates another problem:
It seems that the constraint is limiting the model to not being able to buy more of the subsidized technologies (in this example energy savings) when the the limit set in the investment subsidy constraint is reached. This makes sense, but is unfortunate, since we might have reason to believe that it is cost-efficient to invest in more of the subsidized processes, even when the maximum subsidy amount is reached - thus buying technologies now un-subsidized.
So, my question is: am I using the wrong constraint when my goal is to both limit yearly investment subsidies, and at the same time allow the model to buy more of the same processes that are limited, though now un-subsidized. And if yes, is there a way to create a more flexible constraint allowing this? Or would the way to proceed be to make some technologies subsidies and some not?
>am I using the wrong constraint when my goal is to both limit yearly investment subsidies, and at the same time allow the model to buy more of the same processes that are limited, though now un-subsidized.
It seems what you want is to have kind of two new capacity variables: The normal capacity of the process, and then a subsidized portion of that capacity. But in TIMES a process can only have a single new capacity variable for each vintage, not two. There is no automated way of creating such new variables, and so it is left to the user to model these "manually".
Similar issues have been discussed here on the Forum before. I have earlier suggested simply including a non-subsidized technology option as well. But of course, that may increase model size, and might seem clumsy when subsidies are modeled on a scenario basis. One can of course use also different approaches, based on dummy processes/commodities. For example, one could define a new commodity which is produced by the subsidized processes when installed (via NCAP_ICOM), and then a dummy process that consumes it when installed. Then define a subsidy on that dummy process, and define the constraint for its total subsidies. In that way one would only need to add one new dummy process, and it would be easier to include/exclude this subsidy process on a scenario basis. But it is all up to the modeller...
(03-11-2022, 01:18 AM)Antti-L Wrote: >am I using the wrong constraint when my goal is to both limit yearly investment subsidies, and at the same time allow the model to buy more of the same processes that are limited, though now un-subsidized.
It seems what you want is to have kind of two new capacity variables: The normal capacity of the process, and then a subsidized portion of that capacity. But in TIMES a process can only have a single new capacity variable for each vintage, not two. There is no automated way of creating such new variables, and so it is left to the user to model these "manually".
Similar issues have been discussed here on the Forum before. I have earlier suggested simply including a non-subsidized technology option as well. But of course, that may increase model size, and might seem clumsy when subsidies are modeled on a scenario basis. One can of course use also different approaches, based on dummy processes/commodities. For example, one could define a new commodity which is produced by the subsidized processes when installed (via NCAP_ICOM), and then a dummy process that consumes it when installed. Then define a subsidy on that dummy process, and define the constraint for its total subsidies. In that way one would only need to add one new dummy process, and it would be easier to include/exclude this subsidy process on a scenario basis. But it is all up to the modeller...
Thank you, Antti. We'll look into it using what you have suggested.
