~TFM_INS | ||||
TimeSlice | Attribute | Year | REG1 | Cset_CN |
COM_TAXNET | 2010 | 0.00 | TRNLDVCO2,TRNHDVCO2,TRNOHCO2,ENDUSECO2,REFBIOCO2,ELCCO2 | |
COM_TAXNET | 2015 | 39704.56 | TRNLDVCO2,TRNHDVCO2,TRNOHCO2,ENDUSECO2,REFBIOCO2,ELCCO2 | |
COM_TAXNET | 2020 | 43875.20 | TRNLDVCO2,TRNHDVCO2,TRNOHCO2,ENDUSECO2,REFBIOCO2,ELCCO2 | |
COM_TAXNET | 2025 | 49380.46 | TRNLDVCO2,TRNHDVCO2,TRNOHCO2,ENDUSECO2,REFBIOCO2,ELCCO2 | |
COM_TAXNET | 2030 | 54718.89 | TRNLDVCO2,TRNHDVCO2,TRNOHCO2,ENDUSECO2,REFBIOCO2,ELCCO2 | |
COM_TAXNET | 2035 | 60057.31 | TRNLDVCO2,TRNHDVCO2,TRNOHCO2,ENDUSECO2,REFBIOCO2,ELCCO2 | |
COM_TAXNET | 2040 | 65395.74 | TRNLDVCO2,TRNHDVCO2,TRNOHCO2,ENDUSECO2,REFBIOCO2,ELCCO2 | |
COM_TAXNET | 2045 | 70233.69 | TRNLDVCO2,TRNHDVCO2,TRNOHCO2,ENDUSECO2,REFBIOCO2,ELCCO2 | |
COM_TAXNET | 2050 | 74904.82 | TRNLDVCO2,TRNHDVCO2,TRNOHCO2,ENDUSECO2,REFBIOCO2,ELCCO2 |
Veda2.0 Released!
tax on CO2 emission
|
03-02-2014, 12:16 AM
Hello,
I defined a tax on CO2 emissions ($/kton) based on the TIMES Demo for carbon tax and put that in SuppXLS folder of VEDA_FE. The attribute is COM_TAXNET for the net CO2 emissions from each energy sector (transportation, electric, supply, and end-use demand) and every time period (as the table below). I do not have any constraint on CO2 emissions, but I have a lot of dummy technologies (IMPDemz) for transportation demand commodities and IMPNRGZ processes for other intermediate commodities (non-demand). I do not have any limit or constraint on fuel production in the supply sector, because we assumed all fuels/commodities can be imported infinitely. I'm not sure why I have dummy technologies when I include CO2 tax in the model? I think we should not see any dummy technologies when we include CO2 tax, even if we have CO2 constraint because CO2 tax is not a constraint on CO2 emissions and it only imposes some extra cost to the system. So, we should only see some increase in the total cost of the system. Am I right or I'm missing something? Thank you so much for your help, Samaneh
03-02-2014, 02:51 AM
Thanks for this question; gives me the opportunity to expose some “default” assumptions of VEDA FE. In order to not let models go infeasible on account of commodity imbalance, VEDA FE creates three *dummy* exogenous import processes – IMPNRGZ, IMPDEMZ and IMPMATZ. They can produce each commodity of the type that is embedded in their names. These are ANNUAL processes by default. You can INSert attribute PRC_TSL=DAYNITE for IMPNRGZ in SysSettings, if you have electricity shortage in the model. The basic idea is that these processes should be used when all endogenous options are exhausted. The only way to ensure this is to make the cost of producing from these processes more than all other options. VEDA FE internally uses 9999 as the unit cost for NRG/MAT and 999999 for DEM. In one of my many discussions with Antti, I realized that these very high numbers would be creating scaling issues for solvers, especially for large models. Then I started introducing lower values via SysSettings; you will find 2222/8888 in the DEMO model. The general rule is that these numbers should be the smallest possible that would be certainly higher than the highest possible marginal price of any commodity in each of these categories. For example, if you know that none of your DEM commodities can possibly have a marginal more than 100, in any scenario, then 500 would be better than 8888. It is advisable to not cut this too close, to avoid surprises (like the one you are facing). I actually use a simple scenario “KillDummyImp” which makes START for IMP___Z = 2150 with models that don’t have any dummies. You can also turn off their creation via import settings in user options, but they are needed quite often, and always before prior knowledge. In conclusion, your problem is that the costs of dummy
imports are too low. This could either be because you are using units that make
the reference prices already close to the dummy import costs. Or because you
have put the carbon tax in wrong units. Remember that if the currency units are
in m$, then the tax has to be specified in m$/kt. Which means your numbers would
be multiplied by 10-6.
04-02-2014, 04:50 PM
Thank you so much for the comprehensive explanations. I used the conversion unit 10^-6 for carbon tax and there is no dummy technologies in the results.
Samaneh
|
« Next Oldest | Next Newest »
|
Users browsing this thread: 1 Guest(s)