Unnormal results

[AKanudia]

They have improved, but still appear far from being in a state to serve any useful purpose. The techs I pointed out in (https://forum.kanors-emr.org/showthread.php?tid=1341&pid=7168#pid7168) still play a dominant role.

This forum is meant to help Veda-TIMES modelers with *HOW* to do things when they have a reasonably clear idea of *WHAT* they want to do. But your questions are on *what* you need to do to make the model produce sensible results. We could answer that too, if there are one or a few mysteries to solve. But your model is just not at that point. What exactly are you trying to do with this model?

[[email protected]]

They have improved, but still appear far from being in a state to serve any useful purpose. The techs I pointed out in (https://forum.kanors-emr.org/showthread.php?tid=1341&pid=7168#pid7168) still play a dominant role.

This forum is meant to help Veda-TIMES modelers with *HOW* to do things when they have a reasonably clear idea of *WHAT* they want to do. But your questions are on *what* you need to do to make the model produce sensible results. We could answer that too, if there are one or a few mysteries to solve. But your model is just not at that point. What exactly are you trying to do with this model?

Hi Dr. Antti,

We are trying to understand the economic difference for varied sector under different CO2 scenarios. Now I have revised the model a bit, some views are normal, yet 
(1) dummy imports are unnormal high, where the base-year 2020 is normal (except for TRA-truck) while the dummy imports increase with time.. Why? Because the RESID shrinks with time while there is no NCAP_INV defined for these base-year technologies ( it means there is no complementary stock)? 
(2) the oil price is so high (more than 1000), although I set the min-oil and import-oil both lower than 10. I guess this is because there are dummy imports for OIL which is unnormal high?

These are main questions. Thank you if you could address a bit.

[AKanudia]

Xiao, as a free academic user of VO you need to use public repos and make public models. Can you please make your repo public?

[[email protected]]

Xiao, as a free academic user of VO you need to use public repos and make public models. Can you please make your repo public?

Hi!

I have made it open although it's still useless. The point is, the TRA_tru for one region (AL) always need to import dummy demand, which means that IMPDEMZ always high for TRA_TRU of AL no matter what approach I try... The stock(000units)*actflow(passenger/tonne per vehicle)*cap2act(0.001)*afa(000km) was checked to be equal to demand (bp/btkm). Would you help take a quick look on it?

Best,
Xiao

[Antti-L]

Ok, I had a quick look, due to your private request.

First of all, the model instance did not include any new technologies for transport, and because your existing capacities were defined to decrease linearly, that already explains some dummy imports occurring in 2021. However, below I will focus on the 2020 (base year) dummy imports issue for TRA_TRU.

The 2020 dummy imports for TRA_TRU are caused by the CO2 constraint. You are limiting the total historical CO2 emissions in 2020 to 645,400, although the model has been calibrated to produce total emissions of 818,130. I checked that by removing the CO2 constraint, and then no dummy imports occurred for TRA_TRU. Obviously, historical emissions cannot actually be reduced retroactively, but you are nonetheless trying to reduce them by over 21% from the base year value your model produces without the constraint. Your model is thus basically infeasible because of the CO2 constraint, and in the model the dummy imports appears to be the only a way of circumventing the infeasibility. Shutting down some of the truck operations in Canada (with the dummy imports satisfying the demand) thus appeared to be an effective way of reducing the total historical emissions in Canada. The imposed marginal cost of emissions reduction was about 15, i.e. I guess that is 15,000 CAD/tonne.

I also had a quick look at the CO2 emissions, and I found out that the total TRACO2N emissions were as high as 616,000 in 2020, i.e. about 75% of the total base year emissions in Canada. And, I guess the truck transports are indeed the major cause. As a curiosity, I also found out that the DUMDCAES process produced about 86,000 kt of CO2 emissions in 2020 (over all CAN regions), and they accounted for 100% of the total ELCCO2N emissions. I find that strange if all ELCCO2N emissions in 2020 were produced by CAES storage alone in Canada.

If you think that the base year emissions are too high, as a first priority, you should correct your model calibration in such a way that it produces correct amounts of emissions. Modeling emission reduction policies does not make much sense if your model does not produce reasonable emissions balances, and I think you should not try to reduce historical emissions in the model.

[[email protected]]

Ok, I had a quick look, due to your private request.

First of all, the model instance did not include any new technologies for transport, and because your existing capacities were defined to decrease linearly, that already explains some dummy imports occurring in 2021. However, below I will focus on the 2020 (base year) dummy imports issue for TRA_TRU.

The 2020 dummy imports for TRA_TRU are caused by the CO2 constraint. You are limiting the total historical CO2 emissions in 2020 to 645,400, although the model has been calibrated to produce total emissions of 818,130. I checked that by removing the CO2 constraint, and then no dummy imports occurred for TRA_TRU. Obviously, historical emissions cannot actually be reduced retroactively, but you are nonetheless trying to reduce them by over 21% from the base year value your model produces without the constraint. Your model is thus basically infeasible because of the CO2 constraint, and in the model the dummy imports appears to be the only a way of circumventing the infeasibility. Shutting down some of the truck operations in Canada (with the dummy imports satisfying the demand) thus appeared to be an effective way of reducing the total historical emissions in Canada. The imposed marginal cost of emissions reduction was about 15, i.e. I guess that is 15,000 CAD/tonne.

I also had a quick look at the CO2 emissions, and I found out that the total TRACO2N emissions were as high as 616,000 in 2020, i.e. about 75% of the total base year emissions in Canada. And, I guess the truck transports are indeed the major cause. As a curiosity, I also found out that the DUMDCAES process produced about 86,000 kt of CO2 emissions in 2020 (over all CAN regions), and they accounted for 100% of the total ELCCO2N emissions. I find that strange if all ELCCO2N emissions in 2020 were produced by CAES storage alone in Canada.

If you think that the base year emissions are too high, as a first priority, you should correct your model calibration in such a way that it produces correct amounts of emissions. Modeling emission reduction policies does not make much sense if your model does not produce reasonable emissions balances, and I think you should not try to reduce historical emissions in the model.

Hi Antti,

Sorry for the late reply. Many thanks for your address here. You helped a lot on this bug. 

Best,
Xiao

[[email protected]]

Ok, I had a quick look, due to your private request.

First of all, the model instance did not include any new technologies for transport, and because your existing capacities were defined to decrease linearly, that already explains some dummy imports occurring in 2021. However, below I will focus on the 2020 (base year) dummy imports issue for TRA_TRU.

The 2020 dummy imports for TRA_TRU are caused by the CO2 constraint. You are limiting the total historical CO2 emissions in 2020 to 645,400, although the model has been calibrated to produce total emissions of 818,130. I checked that by removing the CO2 constraint, and then no dummy imports occurred for TRA_TRU. Obviously, historical emissions cannot actually be reduced retroactively, but you are nonetheless trying to reduce them by over 21% from the base year value your model produces without the constraint. Your model is thus basically infeasible because of the CO2 constraint, and in the model the dummy imports appears to be the only a way of circumventing the infeasibility. Shutting down some of the truck operations in Canada (with the dummy imports satisfying the demand) thus appeared to be an effective way of reducing the total historical emissions in Canada. The imposed marginal cost of emissions reduction was about 15, i.e. I guess that is 15,000 CAD/tonne.

I also had a quick look at the CO2 emissions, and I found out that the total TRACO2N emissions were as high as 616,000 in 2020, i.e. about 75% of the total base year emissions in Canada. And, I guess the truck transports are indeed the major cause. As a curiosity, I also found out that the DUMDCAES process produced about 86,000 kt of CO2 emissions in 2020 (over all CAN regions), and they accounted for 100% of the total ELCCO2N emissions. I find that strange if all ELCCO2N emissions in 2020 were produced by CAES storage alone in Canada.

If you think that the base year emissions are too high, as a first priority, you should correct your model calibration in such a way that it produces correct amounts of emissions. Modeling emission reduction policies does not make much sense if your model does not produce reasonable emissions balances, and I think you should not try to reduce historical emissions in the model.

Hi Antti,

Sorry for the late reply. Many thanks for your address here. You helped a lot on this bug. 

Best,
Xiao

Hi!

Here comes the new bug... the dummy imports for NRG is unnormally high for these processes consuming electricity (COMELC, RSDELC...), I have checked the stock for these processes and confiming the capacity for electricity sector, and there is no problem. What would be the potential trouble shooter?

Best,
Xiao

[Antti-L]

> I have checked the stock for these processes and confiming the capacity for electricity sector, and there is no problem.

I find that a confusing statement, if the model is about Canada.

Looking at some capacity statistics available, I found there about 147 GW of electricity generating capacity in Canada in 2020, of which conventional thermal (incl. biomass) about 35 GW, nuclear 13.6 GW, hydro 81.8 GW, wind about 13.6 GW and solar about 3.4 GW.  But looking at your model, I can see you have only about 47 GW of electricity generating capacity in your model for 2020, consisting of only wind onshore (14 GW), hydro run-of-river (29 GW) and solar PV (about 3.6 GW).  So, I could not see in your model any thermal generation capacity, no nuclear, and no hydro dam capacity. Am I missing something?

I also see that your availability factors for electricity generation capacities are strangely defined. For example, I see your EEPP_PV technology (solar PV) being defined with a 1% annual utilization factor in all regions. So you have checked and confirm that there is no problem?

[[email protected]]

> I have checked the stock for these processes and confiming the capacity for electricity sector, and there is no problem.

I find that a confusing statement, if the model is about Canada.

Looking at some capacity statistics available, I found there about 147 GW of electricity generating capacity in Canada in 2020, of which conventional thermal (incl. biomass) about 35 GW, nuclear 13.6 GW, hydro 81.8 GW, wind about 13.6 GW and solar about 3.4 GW.  But looking at your model, I can see you have only about 47 GW of electricity generating capacity in your model for 2020, consisting of only wind onshore (14 GW), hydro run-of-river (29 GW) and solar PV (about 3.6 GW).  So, I could not see in your model any thermal generation capacity, no nuclear, and no hydro dam capacity. Am I missing something?

I also see that your availability factors for electricity generation capacities are strangely defined. For example, I see your EEPP_PV technology (solar PV) being defined with a 1% annual utilization factor in all regions. So you have checked and confirm that there is no problem?

Hi Antti,

Thank you for help checking them. Actually I have defined them in By-trans. Taking AFA for EEPP_PV as an example, I have defined the AFA of different time slice for it, however, the VEDA only input the last line into the model (why?). I have defined it as follows.

~TFM_INS
TimeSlice LimType Attribute Year AT QU ON MA SA AL BC Pset_PN
FD FX AFA 2020,2100 0.34 0.34 0.34 0.34 0.34 0.34 0.34 EEPP_PV
FN FX AFA 2020,2100 0 0 0 0 0 0 0 EEPP_PV
FP FX AFA 2020,2100 0.1 0.1 0.1 0.1 0.1 0.1 0.1 EEPP_PV
RD FX AFA 2020,2100 0.37 0.37 0.37 0.37 0.37 0.37 0.37 EEPP_PV
RN FX AFA 2020,2100 0 0 0 0 0 0 0 EEPP_PV
RP FX AFA 2020,2100 0.1 0.1 0.1 0.1 0.1 0.1 0.1 EEPP_PV
SD FX AFA 2020,2100 0.45 0.45 0.45 0.45 0.45 0.45 0.45 EEPP_PV
SN FX AFA 2020,2100 0 0 0 0 0 0 0 EEPP_PV
SP FX AFA 2020,2100 0.23 0.23 0.23 0.23 0.23 0.23 0.23 EEPP_PV
WD FX AFA 2020,2100 0.2 0.2 0.2 0.2 0.2 0.2 0.2 EEPP_PV
WN FX AFA 2020,2100 0 0 0 0 0 0 0 EEPP_PV
WP FX AFA 2020,2100 0.01 0.01 0.01 0.01 0.01 0.01 0.01 EEPP_PV

Best,
Xiao

[[email protected]]

> I have checked the stock for these processes and confiming the capacity for electricity sector, and there is no problem.

I find that a confusing statement, if the model is about Canada.

Looking at some capacity statistics available, I found there about 147 GW of electricity generating capacity in Canada in 2020, of which conventional thermal (incl. biomass) about 35 GW, nuclear 13.6 GW, hydro 81.8 GW, wind about 13.6 GW and solar about 3.4 GW.  But looking at your model, I can see you have only about 47 GW of electricity generating capacity in your model for 2020, consisting of only wind onshore (14 GW), hydro run-of-river (29 GW) and solar PV (about 3.6 GW).  So, I could not see in your model any thermal generation capacity, no nuclear, and no hydro dam capacity. Am I missing something?

I also see that your availability factors for electricity generation capacities are strangely defined. For example, I see your EEPP_PV technology (solar PV) being defined with a 1% annual utilization factor in all regions. So you have checked and confirm that there is no problem?

Hi Antti,

Thank you for help checking them. Actually I have defined them in By-trans. Taking AFA for EEPP_PV as an example, I have defined the AFA of different time slice for it, however, the VEDA only input the last line into the model (why?). I have defined it as follows.

~TFM_INS
TimeSlice LimType Attribute Year AT QU ON MA SA AL BC Pset_PN
FD FX AFA 2020,2100 0.34 0.34 0.34 0.34 0.34 0.34 0.34 EEPP_PV
FN FX AFA 2020,2100 0 0 0 0 0 0 0 EEPP_PV
FP FX AFA 2020,2100 0.1 0.1 0.1 0.1 0.1 0.1 0.1 EEPP_PV
RD FX AFA 2020,2100 0.37 0.37 0.37 0.37 0.37 0.37 0.37 EEPP_PV
RN FX AFA 2020,2100 0 0 0 0 0 0 0 EEPP_PV
RP FX AFA 2020,2100 0.1 0.1 0.1 0.1 0.1 0.1 0.1 EEPP_PV
SD FX AFA 2020,2100 0.45 0.45 0.45 0.45 0.45 0.45 0.45 EEPP_PV
SN FX AFA 2020,2100 0 0 0 0 0 0 0 EEPP_PV
SP FX AFA 2020,2100 0.23 0.23 0.23 0.23 0.23 0.23 0.23 EEPP_PV
WD FX AFA 2020,2100 0.2 0.2 0.2 0.2 0.2 0.2 0.2 EEPP_PV
WN FX AFA 2020,2100 0 0 0 0 0 0 0 EEPP_PV
WP FX AFA 2020,2100 0.01 0.01 0.01 0.01 0.01 0.01 0.01 EEPP_PV

Best,
Xiao

Hi!

Sorry for another question, if I wanna put the up-limit on a specific out-commodity (summarize from four different types of techs), taking the SNKCO2N as an example, does it work effectively if I format the constraint as the following?

~TFM_INS
TimeSlice LimType Attribute           Year   Region1 Pset_Set Pset_PN Pset_PD Pset_CI Pset_CO Cset_Set Cset_CN Cset_CD
              UP         COM_BNDNET   2021      0                                                                                    SNKCO2N

Best,
Xiao

[Antti-L]

If you are asking about what COM_BNDNET does, please read the documentation.
However, I see you have:

~FI_Comm
Csets CommName CommDesc      Unit LimType
ENV   SNKCO2N  Captured CO2   kt    FX

I believe there is a good reason for the LimType FX. But if you use COM_BNDNET with positive bound values, it would open up the commodity balance, and would thereby likely result in a notable modeling flaw related to CCS. But of course a zero bound for it is ok, but should normally not be needed because the LimType is already FX.

[[email protected]]

If you are asking about what COM_BNDNET does, please read the documentation.
However, I see you have:

~FI_Comm
Csets CommName CommDesc      Unit LimType
ENV   SNKCO2N  Captured CO2   kt    FX

I believe there is a good reason for the LimType FX. But if you use COM_BNDNET with positive bound values, it would open up the commodity balance, and would thereby likely result in a notable modeling flaw related to CCS.  But of course a zero bound for it is ok, but should normally not be needed because the LimType is already FX.

Hi Antti,

Thank you for addressing it.  SNKCO2N is the output commodity of four technologies (SNK_DAC, SNK_DAC_GAS, SNK_DAC_GAS_LowAF, and SNK_DAC_LowAF).

I am trying to put a constraint (up-limit) on the total captured co2 quantity by using these four technologies. So i described it by COM_BNDNET as follows, but it seems that there is no captured CO2 in the future (all results are zero), do you know the possible reason?

~TFM_INS
TimeSlice LimType Attribute Year AL AT BC MA ON QU SA Pset_Set Pset_PN Pset_PD Pset_CI Pset_CO Cset_Set Cset_CN Cset_CD
UP COM_BNDNET 2021 0 0 0 0 0 0 0 SNKCO2N
UP COM_BNDNET 2022 0 0 0 0 0 0 0 SNKCO2N
UP COM_BNDNET 2023 1.33457E-10 1.89686E-11 3.09542E-11 1.07871E-11 7.84798E-11 4.03863E-11 3.49668E-11 SNKCO2N
UP COM_BNDNET 2024 8.78211E-08 1.24822E-08 2.03693E-08 7.09838E-09 5.16433E-08 2.65761E-08 2.30097E-08 SNKCO2N
UP COM_BNDNET 2025 6.94131E-06 9.86583E-07 1.60997E-06 5.61051E-07 4.08185E-06 2.10055E-06 1.81867E-06 SNKCO2N
UP COM_BNDNET 2026 0.000161069 2.28931E-05 3.73585E-05 1.30189E-05 9.4717E-05 4.87421E-05 4.22013E-05 SNKCO2N
UP COM_BNDNET 2027 0.001767926 0.000251279 0.000410054 0.000142898 0.001039632 0.000535003 0.000463209 SNKCO2N
UP COM_BNDNET 2028 0.01181174 0.001678826 0.002739623 0.000954717 0.006945912 0.003574423 0.003094759 SNKCO2N
UP COM_BNDNET 2029 0.055944313 0.007951476 0.01297576 0.004521856 0.032898139 0.016929653 0.014657803 SNKCO2N
UP COM_BNDNET 2030 0.207106973 0.029436524 0.048036526 0.016740001 0.121789575 0.062673918 0.054263483 SNKCO2N
UP COM_BNDNET 2031 0.956854871 0.135999677 0.221933539 0.077340476 0.562679983 0.289559752 0.250702702 SNKCO2N
UP COM_BNDNET 2032 3.73791104 0.531276696 0.866973509 0.302127132 2.198084352 1.131152306 0.979358964 SNKCO2N
UP COM_BNDNET 2033 12.02680959 1.709394256 2.789506011 0.97210058 7.072383926 3.639507001 3.151108642 SNKCO2N
UP COM_BNDNET 2034 32.87824494 4.673050042 7.625801442 2.65747626 19.33410265 9.949488413 8.614331259 SNKCO2N
UP COM_BNDNET 2035 78.70004772 11.18579358 18.25374008 6.361151846 46.27968445 23.81590667 20.61996565 SNKCO2N
UP COM_BNDNET 2036 166.9510535 23.72908374 38.72273556 13.49428663 98.1758245 50.52208764 43.74234943 SNKCO2N
UP COM_BNDNET 2037 322.2990301 45.80899921 74.75424596 26.05072208 189.5284418 97.53289666 84.44461118 SNKCO2N
UP COM_BNDNET 2038 575.4025769 81.78310738 133.4592467 46.50852535 338.3663728 174.1261215 150.7595194 SNKCO2N
UP COM_BNDNET 2039 960.7453617 136.5526402 222.8359019 77.65493552 564.9677918 290.7370774 251.7220374 SNKCO2N
UP COM_BNDNET 2040 1513.177143 215.070863 350.9672875 122.306782 889.8261531 457.911865 396.463047 SNKCO2N
UP COM_BNDNET 2041 2233.445758 317.4440672 518.0268569 180.5245107 1313.381223 675.8767914 585.1784865 SNKCO2N
UP COM_BNDNET 2042 3141.132459 446.4553748 728.5562985 253.8908313 1847.147787 950.5574601 822.9987816 SNKCO2N
UP COM_BNDNET 2043 4250.164012 604.0842251 985.7857959 343.5314137 2499.315503 1286.168336 1113.572844 SNKCO2N
UP COM_BNDNET 2044 5568.008033 791.3920047 1291.447392 450.0498488 3274.275712 1684.969241 1458.857239 SNKCO2N
UP COM_BNDNET 2045 7095.701168 1008.526054 1645.781528 573.5299265 4172.638016 2147.273879 1859.123578 SNKCO2N
UP COM_BNDNET 2046 8828.577101 1254.823141 2047.705895 713.5944787 5191.658381 2671.67015 2313.149252 SNKCO2N
UP COM_BNDNET 2047 10757.4392 1528.976131 2495.087422 869.5001622 6325.928716 3255.375003 2818.52468 SNKCO2N
UP COM_BNDNET 2048 12869.90025 1829.224402 2985.053007 1040.245745 7568.164694 3894.639866 3372.004323 SNKCO2N
UP COM_BNDNET 2049 15151.66453 2153.536075 3514.286892 1224.675735 8909.959696 4585.138622 3969.8426 SNKCO2N
UP COM_BNDNET 2050 17587.6132 2499.762282 4079.282405 1421.568111 10342.42307 5322.296067 4608.078272 SNKCO2N

Best,
Xiao

[Antti-L]

As I already tried to explain, your COM_BNDNET bounds for SNKCO2N make no sense. The VAR_COMNET for SNKCO2N should be zero, but you are opening up the balances. Apparently you did not read the documentation?

[[email protected]]

As I already tried to explain, your COM_BNDNET bounds for SNKCO2N make no sense. The VAR_COMNET for SNKCO2N should be zero, but you are opening up the balances.  Apparently you did not read the documentation?

Hi Antti,

Thank you! and yes, I understand that COM_BNDNET doesn't work for it, then what function could limit the total quantity of SNKCO2? (WHICH IS OUTPUT BY 4 TECHS), ACTBND?

Best,
Xiao

[[email protected]]

Hi~

Why the veda could only read the last line for this table? (I mean, AFA of all timeslice are 0.38)

~TFM_INS
TimeSlice LimType Attribute Year AT QU ON MA SA AL BC Pset_CI
FD FX AFA 2020,2100 0.42 0.42 0.42 0.42 0.42 0.42 0.42 ELCWIN
FN FX AFA 2020,2100 0.44 0.44 0.44 0.44 0.44 0.44 0.44 ELCWIN
FP FX AFA 2020,2100 0.4 0.4 0.4 0.4 0.4 0.4 0.4 ELCWIN
RD FX AFA 2020,2100 0.33 0.33 0.33 0.33 0.33 0.33 0.33 ELCWIN
RN FX AFA 2020,2100 0.36 0.36 0.36 0.36 0.36 0.36 0.36 ELCWIN
RP FX AFA 2020,2100 0.36 0.36 0.36 0.36 0.36 0.36 0.36 ELCWIN
SD FX AFA 2020,2100 0.31 0.31 0.31 0.31 0.31 0.31 0.31 ELCWIN
SN FX AFA 2020,2100 0.36 0.36 0.36 0.36 0.36 0.36 0.36 ELCWIN
SP FX AFA 2020,2100 0.35 0.35 0.35 0.35 0.35 0.35 0.35 ELCWIN
WD FX AFA 2020,2100 0.39 0.39 0.39 0.39 0.39 0.39 0.39 ELCWIN
WN FX AFA 2020,2100 0.41 0.41 0.41 0.41 0.41 0.41 0.41 ELCWIN
WP FX AFA 2020,2100 0.38 0.38 0.38 0.38 0.38 0.38 0.38 ELCWIN


Best,
Xiao