Interpreting NCAP_AFC for long duration energy storage

[O.Broad]

Hello Antti, 

I'm writing to ask about how to interpret / use NCAP_AFC to represent long duration energy storage technology options in TIMES models . I am aware that many have asked about this parameter, and have reviewed other posts without finding what I'm after. If the information is already out there please feel free to point me to it!  

In the case of short duration electricity storage batteries, the following example and interpretation would, as I understand it, be typical:

• STG technology SET membership, Same ELC input / output to BESS system with xhrs storage (x<24), BESS declared at the DAYNITE tslvl, storage efficiency EFF, CAP2ACT 31.536 linking capacity in GW to output in PJ. 
  


• NCAP_AFC( r, y, BESS, ACT, DAYNITE) = (x/24) / EFF -- defines the power to energy ratio, that is, it ensures that e.g. 1GW installed capacity can only output xGWh over a 24h period.
  


• NCAP_AFC( r, y, BESS, NRG, DAYNITE) =y -- y<1 - if defined - describes inflow and outflow availability factors - describing that y% of the nominal capacity is available to charge and sdischarge over the t.s. duration.
  


• NCAP_AFC( r, y, BESS, ELC, DAYNITE) = z -- z<1 - if defined - overwrites the 'NRG' declaration and redefines the outflow availability factor - describing that z% of the nominal capacity is available to discharge over the t.s. duration.
  

In the case of long duration electricity storage, I would like to make sure I understand how the storage parameters work in the following cases.


A] Battery storage system as above but with a storage duration x > 24hrs 


I assume the appropriate representation for this would be as above: 

• DAYNITE t.s. technology definition, STG technology SET membership, CAP2ACT 31.536, storage efficiency EFF
  


• NCAP_AFC( r, y, BESS, ACT, DAYNITE) = (x/24) / EFF -- higher than 1. 
  


• with this approach the BESS technology can store energy within the DAYNITE t.s. and its immediate parent t.s. - but no higher. 
  

B] Hydrogen storage in e.g. salt caverns for durations of days / weeks / months

The approach above no longer applies. Instead one should consider something like the following: 

• Same input / output commodity HYG. 
  


• STS technology SET membership would allow the technology to store energy across all t.s. levels (DAYNITE, WEEKLY, SEASON) - not just to immediate parent. 
  


• CAP2ACT =1, capacity defined in PJ_a and output defined in PJ. 
  


• Tslvl = ? unclear to me whether this sort of option should be defined on a DAYNITE or e.g. a SEASON level? 
  


• NCAP_AFC( r, y, HYGSTG, ACT, DAYNITE) = ? unclear to me how to define this parameter and what it means in this context? 
  

Other posts have described systems storing H2 representing e.g. 1000 hrs storage. In that context, I understand that one would likely define the technology as DAYNITE, and the NCAP_AFC(...ACT..)=(1000/24)/EFF. However in this example I don't understand how the TIMES system interprets this in relation to the PJ_a / PJ units of the technology - i.e. with an electrical system, a 1GW storage with 1000hrs of storage means 1000 GWh of electricity can be released. Does the 1000hrs in the context of the hydrogen system defined in PJ_a/PJ translate as 1000/8760 = 0.114 PJ of stored energy? And how should one interpret the Installed Capacity results for this system? 

(I note that the NCAP_AFC(...ACT, SEASON) calculation would differ from the DAYNITE definition of the storage caverns and be 1000/8760 = 0.114 - assuming EFF=1)

In essence, I am struggling to decide how to use NCAP_AFC in the context of long-duration "energy" (not electricity) storage systems. It is not clear to me how to use NCAP_AFC to parameterise a "generic" supply chain for storing H2 which links a cavern system to H2 turbines. 

(I have similar thoughts about compressed air storage) 

Happy to review any previous posts or model file examples that highlight how this works. 
Thanks for the help!

[Antti-L]

> A] Battery storage system as above but with a storage duration x > 24hrs
I assume the appropriate representation for this would be as above:
DAYNITE t.s. technology definition, STG technology SET membership, CAP2ACT 31.536, storage efficiency EFF
NCAP_AFC( r, y, BESS, ACT, DAYNITE) = (x/24) / EFF -- higher than 1.
with this approach the BESS technology can store energy within the DAYNITE t.s. and its immediate parent t.s. - but no higher.

Hmm... no, an STG storage process operating on the DAYNITE level (PRC_TSL=DAYNITE) cannot store energy on any higher level.  I am not sure why you said so, but maybe it was just a cosmetic misinterpretation?

> Other posts have described systems storing H2 representing e.g. 1000 hrs storage. In that context, I understand that one would likely define the technology as DAYNITE, and the NCAP_AFC(...ACT..)=(1000/24)/EFF.

Yes, NCAP_AFC(...ACT,DAYNITE)=(1000/24)/STG_EFF for a DAYNITE storage would define a storage energy capacity equivalent to 1000 hours output at full discharge power, where the capacity as such is thereby assumed to be representing the nominal maximum output level. Hence, the energy capacity is proportional to that output capacity, the proportionality factor being defined with the availability factor NCAP_AFC(...ACT,DAYNITE).

> However in this example I don't understand how the TIMES system interprets this in relation to the PJ_a / PJ units of the technology - i.e. with an electrical system, a 1GW storage with 1000hrs of storage means 1000 GWh of electricity can be released. Does the 1000hrs in the context of the hydrogen system defined in PJ_a/PJ translate as 1000/8760 = 0.114 PJ of stored energy? And how should one interpret the Installed Capacity results for this system?

The documentation is supposed to give a sufficient description about NCAP_AFC(ACT), and it says the following:
NCAP_AFC(r,y,p,'ACT',tsl) can additionally be used for bounding the activity (the amount stored); in this case one must bear in mind that any capacity expressed in power units (e.g. MW/GW) is assumed to represent a gross storage capacity equivalent to the amount produced by full power during one full year/week/day for SEASON/WEEKLY/DAYNITE level storage processes, respectively, assuming STG_EFF=1. Knowing this, the availability factor can be adjusted to correspond to the assumed real storage capacity. For example, a capacity of 1 GW is assumed to represent a storage capacity of 24 GWh for a DAYNITE storage, and if the real daily storage capacity is, say 8 GWh / GW, the maximum availability factor should be 0.333 / STG_EFF, on the DAYNITE level.

As described in that documentation, for a DAYNITE storage the reference energy output is 24 hours’ output at full nominal power level. And for a SEASON storage it is one year’s output at full nominal power level.  The 24 hours' output at full nominal power level can be obtained simply by  MaxNomOUT = VAR_CAP × PRC_CAPACT × 1/365.  As you can see, the character strings used for identifying units (e.g. GW/GWh/PJa/PJ) need not be considered here at all, because that expression is correct for all units (recalling that the capacity as such is assumed to be representing the nominal maximum output level).  Those unit strings are in fact not used for anything in TIMES, they are just for model documentation.

> In essence, I am struggling to decide how to use NCAP_AFC in the context of long-duration "energy" (not electricity) storage systems. It is not clear to me how to use NCAP_AFC to parameterise a "generic" supply chain for storing H2 which links a cavern system to H2 turbines.

DAYNITE storage with a mere STG qualification will not work for long-duration storage. You would need to define it as an STS storage for being able to function as a seasonal storage as well.  Of course, an STG storage defined at SEASON level would work fine for a purely seasonal storage.

The installed capacity results give the amounts of capacity in the capacity unit (the "string" unit, assuming that unit is indeed consistent with PRC_CAPACT, as it should be).

I hope the above can clarify at least some parts of your doubts?

[Antti-L]

Alright, I spotted a few question marks without having given an explicit answer.

> Tslvl = ? unclear to me whether this sort of option should be defined on a DAYNITE or e.g. a SEASON level?

You mean PRC_TSL? DAYNITE or SEASON are both fine for PRC_TSL, but you need to use STS for DAYNITE if you want to enable seasonal storage capability.

> NCAP_AFC( r, y, HYGSTG, ACT, DAYNITE) = ? unclear to me how to define this parameter and what it means in this context?

That would imply that it is a DAYNITE storage.
You should thus define NCAP_AFC(...ACT,DAYNITE) to represent the energy storage capacity in proportion to the maximum nominal output in one day's time. For example, for a 20 days' storage (gross), define NCAP_AFC(...ACT,DAYNITE)=20. Or, if you want to define it in NET terms (20 days even after EFF losses), divide it by STG_EFF.