The potential mistake exists in the EU-TIMES

[[email protected]]

Hi Amit and Antti,

I noticed the capacity unit for ESTCAESS101 (in the EU-TIMES model opened by Amit) is PJ/A and ACT unit is PJ, however, the CAP2ACT is set as 0.0036. Is that correct?

Best,
Xiao

[Antti-L]

Sure, obviously there exists a mistake to some degree.
However, I think it is most likely that the string "PJ/A" is the mistake, and the value 0.0036 is correct (corresponding to GWh being the capacity unit).  Only that PRC_CAPACT value affects the TIMES model, while the string "PJ/A" has no impact on anything in TIMES; you could write whatever you like into that unit documentation string, and the model solution would remain the same. That also explains why users may indeed have written random stuff into that documentation string, without worrying about it being considered a mistake by someone.

Nonetheless, it is conceivable that the string "PJ/A" might actually have some impact on VEDA reporting tables when the user requests unit conversions to be employed in the report tables. Amit should be able to tell whether that is the case or not.

[[email protected]]

Sure, obviously there exists a mistake to some degree.
However, I think it is most likely that the string "PJ/A" is the mistake, and the value 0.0036 is correct (corresponding to GWh being the capacity unit).  Only that PRC_CAPACT value affects the TIMES model, while the string "PJ/A" has no impact on anything in TIMES; you could write whatever you like into that unit documentation string, and the model solution would remain the same. That also explains why users may indeed have written random stuff into that documentation string, without worrying about it being considered a mistake by someone.

Nonetheless, it is conceivable that the string "PJ/A" might actually have some impact on VEDA reporting tables when the user requests unit conversions to be employed in the report tables. Amit should be able to tell whether that is the case or not.

Thank you, if so, the NCAP_COST for the power storage denotes the number with the unit of M$/GWh rather than M$/GW. 

Then, there should be very slight difference for the NCAP_COST of battery with 2hour and 10 hour capacities? (the 10-hour capacity is 5-times expensive represent in M$/GW). 

However, from your response to Kristina, it can be implied that the NCAP_COST for the battery with different capacities is very different (the higher NCAP_AFC drives higher NCAP_COST for the storage with 10-hour-capacities).

Best,
Xiao

Your response to Kristina of 05-12-2023, 10:58 PM:
I am not quite able to follow your thinking.


> The daynite storage is working proparly by converting the investment cost from energy to capacity through: invcost * NCAP_AFC * (24/8760).

If you use NCAP_AFC(ELCC,DAYNITE), where ELCC is the output electricity, then the capacity represents the max. output level of ELCC.  Typically such output capacity is in the unit of GW, and PRC_CAPACT would typically be 31.536 (where the flow unit is PJ).

Let's say you want to model a battery storage with an energy capacity of 6 GWh per GW, i.e. 6 hours' capacity. Therefore, if we denote the investment cost per GWh by ICE, then the investment cost per GW is ICP = 6 × ICE.  These specs can be modeled by defining:

  ●  PRC_CAPACT(r,p) = 31.536;
  ●  NCAP_AFC(r,y,p,ELCC,DAYNITE) = 1;
  ●  NCAP_AFC(r,y,p,ACT,DAYNITE) = 0.25;
  ●  NCAP_COST(r,y,p,cur) = ICP;

The availability factor NCAP_AFC(ACT,DAYNITE)=0.25 is due to the fact that the NCAP_AFC(ACT,DAYNITE)=1 corresponds to storage energy availability equivalent to a nominal full-load power output over the full DAYNITE cycle, i.e. 24 hours, and 6 / 24 = 0.25. For a seasonal storage, NCAP_AFC(ACT,SEASON)=1 would correspond to storage energy availability equivalent to full power output over the full year, i.e. 8760 hours. Therefore, if you would like to model a seasonal storage with 100 hours' energy capacity, you should define NCAP_AFC(ACT,SEASON) = 100/8760 = 0.0114155.  I just verified that these should indeed work as expected.

For example, if you have a DAYNITE storage with investment costs of 100 €/kWh, and energy capacity of 6 GWh/GW, one could define NCAP_COST = 600 (assuming the capacity unit is GW, and the currency unit is M€). Similarly, if you have a SEASON storage with investment costs of 100 €/kWh, and energy capacity of 100 GWh/GW, you should define NCAP_COST = 10,000 (assuming the same units as above). Using NCAP_AFC as a multiplier, we get:

  ●  NCAP_COST(r,y,p,cur) = NCAP_AFC(ACT,DAYNITE) × 24 × ICE (DAYNITE case)
  ●  NCAP_COST(r,y,p,cur) = NCAP_AFC(ACT,SEASON) × 8760 × ICE (SEASON case)

Consequently, I am not directly able to see why you say that the investment cost from energy to capacity would be converted through: invcost * NCAP_AFC * (24/8760).  But I can see it might be so if using some different combination for the units of the output capacity and ICE. Could you therefore mention also your assumptions on the units, or otherwise explain why in your case that expression would seem to result in a correct conversion? But anyway, the difference between the DAYNITE and SEASON cases should remain as described above.

[Antti-L]

Sorry, I am not able to follow you at all here, and do not even see what your question is.
The ESTCAESS101 process of the JRC model does not have any NCAP_AFC, which means that the capacity represents the max. amount of energy that can be stored. So, it is a case quite different from Kristina's case.

On the other hand, in Kristina's case the capacity was representing the nominal maximum output level (in power terms), because she wanted to use NCAP_AFC, and she just wanted to be sure how to define the investment cost consistently for that case, when the original data is in terms of energy capacity.

[AKanudia]

Hi Amit and Antti,

I noticed the capacity unit for ESTCAESS101 (in the EU-TIMES model opened by Amit) is PJ/A and ACT unit is PJ, however, the CAP2ACT is set as 0.0036. Is that correct?

Best,
Xiao

I have only migrated the model to Veda2.0 and deployed it on Veda online. Wouter remains the ultimate owner of this model. I will tell him to look at this post.

[[email protected]]

Sorry, I am not able to follow you at all here, and do not even see what your question is.
The ESTCAESS101 process of the JRC model does not have any NCAP_AFC, which means that the capacity represents the max. amount of energy that can be stored. So, it is a case quite different from Kristina's case.

On the other hand, in Kristina's case the capacity was representing the nominal maximum output level (in power terms), because she wanted to use NCAP_AFC, and she just wanted to be sure how to define the investment cost consistently for that case, when the original data is in terms of energy capacity.

Sorry for the confusion. My question is, should the unit for NCAP_COST for power storage options be M$/GWh or M$/GW?

Because for the power storage with high capacity (10-hour or 24-hour), the different unit drives huge difference.

Best,
Xia0

[Antti-L]

I am sorry but I still do not follow.
The whole point of Kristina's question was how to define the investment cost consistently, such that when modeling the capacity in terms of output power and the investment cost accordingly per GW, the investment cost per GWh will remain consistent with the original data.  In other words, if defined consistently, there will be no difference in the investment cost per GWh (energy capacity), even if the capacity unit is changed to GW (output power capacity).

[[email protected]]

I am sorry but I still do not follow.
The whole point of Kristina's question was how to define the investment cost consistently, such that when modeling the capacity in terms of output power and the investment cost accordingly per GW, the investment cost per GWh will remain consistent with the original data.  In other words, if defined consistently, there will be no difference in the investment cost per GWh (energy capacity), even if the capacity unit is changed to GW (output power capacity).

Hi,

I am wondering if I use the right table to define NCAP_AFC attribute (as attached), because it seems like the projections for power storage options disappear after I introduce the NCAP_AFC here.

Best,
Xiao

[Antti-L]

> it seems like the projections for power storage options disappear after I introduce the NCAP_AFC here.

What are the "projections for power storage options", which disappear  after introducing NCAP_AFC?  Do you mean model results?

Anyway, if you define NCAP_AFC, you should also change your capacity unit to power units, i.e. probably GW, and define PRC_CAPACT accordingly. And because of that, you should also change your investment costs (NCAP_COST) and fixed O&M costs (NCAP_FOM) accordingly (as discussed earlier).  If your storage results have disappeared, you have probably forgotten to do these.

Alternatively, if you are an expert user, it is also possible to retain the capacity unit as GWh even when using NCAP_AFC, but in that case you would still need to redefine your PRC_CAPACT, and define the NCAP_AFCs differently. But as said, this option requires some expert understanding, and so would not suggest it to you.

Moreover, you do also have some problems in those tables: ACT is a commodity group and should be put into Other_indexes. Note also that there is no reason to define NCAP_AFC for each timeslice, as you can just use DAYNITE, and there is no reason to define any IE option for your NCAP_AFC, and NCAP_AFC does not have a LimType index.

[[email protected]]

> it seems like the projections for power storage options disappear after I introduce the NCAP_AFC here.

What are the "projections for power storage options", which disappear  after introducing NCAP_AFC?  Do you mean model results?

Anyway, if you define NCAP_AFC, you should also change your capacity unit to power units, i.e. probably GW, and define PRC_CAPACT accordingly. And because of that, you should also change your investment costs (NCAP_COST) and fixed O&M costs (NCAP_FOM) accordingly (as discussed earlier).  If your storage results have disappeared, you have probably forgotten to do these.

Alternatively, if you are an expert user, it is also possible to retain the capacity unit as GWh even when using NCAP_AFC, but in that case you would still need to redefine your PRC_CAPACT, and define the NCAP_AFCs differently. But as said, this option requires some expert understanding, and so would not suggest it to you.

Moreover, you do also have some problems in those tables: ACT is a commodity group and should be put into Other_indexes. Note also that there is no reason to define NCAP_AFC for each timeslice, as you can just use DAYNITE, and there is no reason to define any IE option for your NCAP_AFC, and NCAP_AFC does not have a LimType index.

Hi Antti,

Many thanks for addressing it. one quick question:

I set the NCAP_AFC for a battery with 2-hour capacity as 2/24/STG_EFF (~0.1), and the PRC_CAPACT as 31.54 (activity unit is PJ while the capacity unit as GW), and the NCAP_COST as ~2000 M$/GW. Are these set at a normal level (roughly)?

Besides, should I set the tslvl for the pump-hydropower (with seasonal regulation) as SEASON, because I am confused by the open EU-TIMES where that for ESTHYDPS201 (seasonal pump-hydropower) is DAYNITE (same as ESTHYDPS101).

  
 
Best,
Xiao

[[email protected]]

> it seems like the projections for power storage options disappear after I introduce the NCAP_AFC here.

What are the "projections for power storage options", which disappear  after introducing NCAP_AFC?  Do you mean model results?

Anyway, if you define NCAP_AFC, you should also change your capacity unit to power units, i.e. probably GW, and define PRC_CAPACT accordingly. And because of that, you should also change your investment costs (NCAP_COST) and fixed O&M costs (NCAP_FOM) accordingly (as discussed earlier).  If your storage results have disappeared, you have probably forgotten to do these.

Alternatively, if you are an expert user, it is also possible to retain the capacity unit as GWh even when using NCAP_AFC, but in that case you would still need to redefine your PRC_CAPACT, and define the NCAP_AFCs differently. But as said, this option requires some expert understanding, and so would not suggest it to you.

Moreover, you do also have some problems in those tables: ACT is a commodity group and should be put into Other_indexes. Note also that there is no reason to define NCAP_AFC for each timeslice, as you can just use DAYNITE, and there is no reason to define any IE option for your NCAP_AFC, and NCAP_AFC does not have a LimType index.

Hi Antti,

Many thanks for addressing it. one quick question:

I set the NCAP_AFC for a battery with 2-hour capacity as 2/24/STG_EFF (~0.1), and the PRC_CAPACT as 31.54 (activity unit is PJ while the capacity unit as GW), and the NCAP_COST as ~2000 M$/GW. Are these set at a normal level (roughly)?

Besides, should I set the tslvl for the pump-hydropower (with seasonal regulation) as SEASON, because I am confused by the open EU-TIMES where that for ESTHYDPS201 (seasonal pump-hydropower) is DAYNITE (same as ESTHYDPS101).

  
 
Best,
Xiao

Sorry I am afraid I have set the wrong CAP2ACT from the results I derived (I set the CAP2ACT for both of P_ESTCAESS and ESTCAESS as 31.54, I guess it's too large). I am not sure about it, because it will decide my next step. Can you take a look on it (have attached)?

Best,
Xiao

[wnijs]

Dear Xiao,

It is nice meeting you, and thank you for your questions.

I was indeed responsible for storage in JRC-EU-TIMES.

Antti is correct: there's a mistake in the "PJ/A" string, although the value of 0.0036 is accurate. The storage capacity for a DAYNITE-level timeslice represents daily storage capacity. PRC_CAPACT=0.0036 was chosen to avoid scaling issues arising from having excessively high CAPEX for storage capacity. The unit of capacity refers to energy storage capacity and corresponds to GWh. This was correctly indicated in Table 42 of our 2013 report: https://op.europa.eu/en/publication-deta...anguage-en.

Therefore, the unit for NCAP_COST for those storage technologies is MEUR/GWh or EUR/kWh.

To give you more context, there’s additional information in the _README folder on how we manage variable renewable sources. The key point is that in a 12-timeslice model, without additional equations, PV or wind electricity is considered dispatchable within a timeslice. However, in practice, production is often "peaky" and doesn't always align with demand. In several papers, we explain how we parameterize different combinations of wind, solar, and storage capacities based on a country-specific analysis with an hourly model outside JRC-EU-TIMES.

Unfortunately, the information on how we model storage is somewhat limited and scattered. Our initial approach was to add storage technologies directly into the model with EST and P_EST technologies, representing energy storage and the "charging power" of storage options. Although a 12-timeslice TIMES model can handle day/night variations well, this representation proved inadequate.

In the latest version, we integrated storage into our parameterization. We observed that there's a threshold size for batteries; beyond 12/24 hours of "average power demand", additional storage offers only marginal short-term flexibility. Thus, we assumed a fixed storage capacity per country, equal to 5 hours of "average power demand." We made exogenous assumptions for the energy storage capacity of batteries and short-term pumped hydro, and disabled DAYNITE storage technologies in TIMES. We used two modes to parametrize negative residual load:
1. Without any storage, using the scenario file Sepdb-ziet_var, followed by SepDb-ZIET_VAR_Nostor.
2. With storage capacity equal to 5 hours of average power demand, using the scenario file Sepdb-ziet_var, followed by SepDb-ZIET_VAR_Stor.

This approach works well because, despite having only 12 timeslices, information on variable relationships is condensed in simplified equations. Additionally, the model can still invest in longer-term storage options.

I hope this is helpful for you.

Kind regards,
Wouter