Hello!
I added a UC constraint to put an emission cap on CO2 of all sectors. For some scenarios, say I impose an 80% CO2 reduction for a future year, and the program was terminated with an optimal solution, but the emission sum from the result is actually greater than the imposed cap value. I was wondering whether there is any other modification I need to make to make the new CO2 Cap constraint I added binding.
Thank you!
The two statements sound logically contradictory to me:
1) I impose an 80% CO2 reduction for a future year.
2) The emission sum from the result is actually greater than the imposed cap value.
Therefore, I suspect that your constraint is not imposing the emission cap correctly. Because if it were correctly modelled, the emissions would be bounded by the cap value. However, as I have no access to your model, it is not possible for me to see which flaws your constraint may have. One frequent beginner's error is forgetting to use an interpolation option for the RHS, if it is not specified as a full time-series, just to mention one out of numerous possibilities.
(05-08-2020, 07:12 AM)Antti-L Wrote: [ -> ]If using VEDA as your user shell, you can find working examples of CO2 constraints in the Demo models:
https://iea-etsap.org/index.php/etsap-demos-models
Thank you! I used option 5 of Interpolation as follows. For this example, I simply just impose a cap of the electric sector CO2 emission to be zero (which is 100% reduction compared to the emission in the base year). However, the electric sector CO2 emission in the result shows that it is 93.2, which is greater than the cap. I am not sure why this constraint is not binding.
Ok, so you are bounding the sum of the VAR_COMNET levels of ELCCO2 over all regions. Could you thus post a picture from the VEDA-BÉ results showing the VAR_Comnet levels for ELCCO2, with all dimensions expanded (Attribute, Region, Commodity and Year indexes shown)?
(05-08-2020, 07:05 PM)Antti-L Wrote: [ -> ]Ok, so you are bounding the sum of the VAR_COMNET levels of ELCCO2 over all regions. Could you thus post a picture from the VEDA-BÉ results showing the VAR_Comnet levels for ELCCO2, with all dimensions expanded (Attribute, Region, Commodity and Year indexes shown)?
Thanks! I am attaching the table here.
I asked to show all dimensions expanded (Attribute, Region, Commodity and Year indexes shown). Your picture shows neither Attribute nor Commodity. And could you please show the Scenario index as well.
(05-08-2020, 07:21 PM)Antti-L Wrote: [ -> ]I asked to show all dimensions expanded (Attribute, Region, Commodity and Year indexes shown). Your picture shows neither Attribute nor Commodity. And could you please show the Scenario index as well.
The table I showed earlier takes VAR_COMNET as Attribute and ELCCO2 as Commodity. Should I send a picture include all the Attributes and Commodity in my model. Would you clarify which attributes and commodities I should include? Will it be ok that I share the database and another database without this CO2 cap constraint since I generate the table from each model run? Thanks!
I don't understand. Your picture shows only Region and Year (=Period). What I asked was to show all the dimensions in that table. You can do that by dragging the Attribute, Commodity and Scenario buttons (shown at the top in your picture) down to the left side of the Table area, so that we can clearly see the Attribute, Commodity and Scenario indexes for this table.
It would take only one minute of your time to do that, and would make things clear.
(05-08-2020, 08:14 PM)Antti-L Wrote: [ -> ]I don't understand. Your picture shows only Region and Year (=Period). What I asked was to show all the dimensions in that table. You can do that by dragging the Attribute, Commodity and Scenario buttons (shown at the top in your picture) down to the left side of the Table area, so that we can clearly see the Attribute, Commodity and Scenario indexes for this table.
It would take only one minute of your time to do that, and would make things clear.
Sorry for the confusion. I created this table only to include the ELCCO2 as commodity and VAR_Comnet as attribute, that's why when I expand the dimensions as you asked, the table is the same. Would it be helpful to show a table summarizes the electric sector instead (as the second picture I included here)? Thanks!
Ok, thanks for the expanded picture!
That does make things much clearer, but unfortunately I still have no answer to the basic question.
If you wish me to find out the reason for the apparent inconsistency between the constraint and the results, I am willing to do that, if you provide me with the full set of model input files and the listing file for this scenario: The *.DD, *.RUN files and the *.LST file (for the ELCO2_100_0804_single case). If you can do that, please pack these files in a ZIP file, upload the ZIP e.g. on Dropbox or Google drive, and send me the download link (in a private message using the Forum message tool). Then I will find out the reason for the issue.
Thanks, I received the link you provided. But the ZIP file did not include the files I was asking for. It included only a single *.DD file: elco2_100_0804_single_ts.dd
However, by looking at the RUN file, I can see that your model input files consist of the following 20 *.DD files:
elco2_100_0804_single_ts.dd
base.dd
tradeparams.dd
syssettings.dd
coalplants-ret-and_lifeext.dd
storage.dd
baseextra-offeps.dd
growth.dd
refemi-ts.dd
uc-biofuelssimple.dd
uc-elc18.dd
uc-rps18.dd
uc-rescom18co.dd
uc-ind18x.dd
uc_trnhdv18.dd
uc_trnldv18.dd
aqreg.dd
uc_aqreg.dd
csapr-mats.dd
uc-csapr-mats.dd
Unfortunately I cannot test the model without having the model input files, sorry.
There is one thing you could confirm, though: Please check that you have NOT enabled dummy imports for user constraints. Because if you have enabled them, then you of course cannot expect any of your user constraints to be binding in the way you have modelled them.
Ok, thanks again, I received the full set of DD files now.
I tested the model, and I can now confirm that you have modelled the CO2 cap incorrectly, just as I suspected. If you want to model a binding CO2 cap, you should of course not enable dummy imports for user constraints, because the whole point of those dummy imports is to make the user constraints non-binding, to avoid infeasibility. Nonetheless, the model shows that you have indeed enabled those dummy imports.
My test revealed in the model results that the level of the dummy import flows was 93.2 for the zero CO2 cap constraint in 2050, which is of course exactly the sum of the VAR_COMNET levels over regions. In summary, it seems that you have deliberately modelled the CO2 cap in a non-binding way, by allowing dummy imports to intervene.
I hope that helps.
(05-08-2020, 11:19 PM)Antti-L Wrote: [ -> ]Ok, thanks again, I received the full set of DD files now.
I tested the model, and I can now confirm that you have modelled the CO2 cap incorrectly, just as I suspected. If you want to model a binding CO2 cap, you should of course not enable dummy imports for user constraints, because the whole point of those dummy imports is to make the user constraints non-binding, to avoid infeasibility. Nonetheless, the model shows that you have indeed enabled those dummy imports.
My test revealed in the model results that the level of the dummy import flows was 93.2 for the zero CO2 cap constraint in 2050, which is of course exactly the sum of the VAR_COMNET levels over regions. In summary, it seems that you have deliberately modelled the CO2 cap in a non-binding way, by allowing dummy imports to intervene.
I hope that helps.
Thank you very much! Does it mean to change the value of the attached file (highlighted "created dummy...") to be both zero? in the SysSettings workbook. I am testing it now.
I think editing that section in SysSettings by yourself is not recommended. Instead, in VEDA-FE, go to Tools --> User Options and disable the dummy imports for user constraint there.