Battery/Storage, NCAP_AFCS for individual timeslices

[anik]

Hi,

In a DEMO model of ours, we would like to have storage ('STS') for BEV, where we can specify 'min battery state of charge' and 'max battery state of charge'.

According to TIMES-Documentation, it can be done with NCAP_AFCS and by bounding it to output (discharge activity or output activity). But not sure if it can have both UP and LO bound. According to this thread NCAP_AFC can only have UP and FX bound. I assume NCAP_AFC and NCAP_AFCS are quite similar in function.

It would be highly appreciated, if someone could help on the implementation of 'min battery state of charge' and 'max battery state of charge'.
For example- the data of min and max state of storage are given in percentage- max (0.81) and min (0.21) for a individual timeslice. For each timelslice, the max and min values are different.

How can we do it in a efficient and clean way, when there are lots of time slices? Is there any DEMO model that shows how to implement such features with lots of timeslicess?

Attached you will find the demo model along with SysSettings.

Thanks in advance.

Best regards,
Anik

[Antti-L]

> In a DEMO model of ours, we would like to have storage ('STS') for BEV, where we can specify 'min battery state of charge' and 'max battery state of charge'. According to TIMES-Documentation, it can be done with NCAP_AFCS and by bounding it to output (discharge activity or output activity).

That is not at all strictly correct. As explained in the documentation, the capacity of a storage process represents by default the maximum amount of energy stored (or material).  And so, capacity availability directly corresponds to the “state of charge”.  Therefore, when that is the case you can just use the following:

   NCAP_AF(r,y,p,ANNUAL,UP) = 0.81;  and
   NCAP_AF(r,y,p,ANNUAL,LO) = 0.21;

That is quite easy, isn’t it?  The NCAP_AF values are automatically levelized to the process timeslices. But of course, if the usable range is different in each timeslice, then the specification inevitably becomes more tedious. But if many timeslices have the same range, you could use utilize the levelization for defining default values and define exceptions with NCAP_AFS.

Only in the case where you would want the capacity to represent the maximum nominal output flow level instead of the maximum amount that can be stored, you would need to use NCAP_AFC/NCAP_AFCS, for the output commodity, and when doing so, then you would also need to use NCAP_AFC(ACT) if you also want to define the maximum “state of charge”.  But looking at your Excel file, I can see you are not using NCAP_AFC at all, and therefore you can just use those NCAP_AF(UP/LO) parameters.

Notwithstanding, if the usable storage capacity is only 60% of the nominal storage capacity, I think that battery providers/sellers would need to state the capacity and unit costs in terms of the maximum usable capacity, otherwise they would be giving quite misleading information. And if so, I think one could well model the battery in terms of the maximum usable capacity in the first place, no?

> How can we do it in a efficient and clean way, when there are lots of time slices?

Well, if the range and its bounds are different for each timeslice, I don't see much other option than to define the NCAP_AF(UP/LO) for all the DAYNITE timeslices individually. It might thus take quite a few rows in an Excel  table, but the specification is otherwise trivial, and with a DINS table also fast to process. However, if either of the AF bounds might be constant over most or all timeslices, then you could consider utilizing the automatic levelization. But as it seems that you have only 12 DAYNITE timeslices, I cannot see much issue either about cleanliness or efficiency.

[anik]

Hi Antti,

I can't thank you enough for such a clarification!

Yes, you are right, that's quite easy. I had the impression that for Storage process I need to use NCAP_AFC/NCAP_AFCS to define min/max SOC (which is not the case).

> Well, if the range and its bounds are different for each timeslice, I don't see much other option than to define the NCAP_AF(UP/LO) for all the DAYNITE timeslices individually. It might thus take quite a few rows in an Excel table, but the specification is otherwise trivial, and with a DINS table also fast to process. However, if either of the AF bounds might be constant over most or all timeslices, then you could consider utilizing the automatic levelization. But as it seems that you have only 12 DAYNITE timeslices, I cannot see much issue either about cleanliness or efficiency.

A constant AF bounds could be also an option. But right now I would try to implement NCAP_AF(UP/LO) for all DAYNITE timeslice individually to see how it works.