Storage PV

[wnijs]

 

At VITO, we are running a test model with 12 timeslices (R/S/F/W each with D/N/P) with only an electricity demand, photovoltaic supply and some generic storage process (STG-TSS) with a battery function. We made PV unavailable during night (of course) but also play with the availability in other timeslices to simulate possible long periods without sun and to see how storage reacts.
The TIMES manual says a storage process can operate only at one particular time slice level. Now the question: is it possible in some way to model a storage process at timeslice level "daynight" but so that excess from a certain season can be used in another season ? The reason this would be helpful is that it allows absorbing summerday-production, to be used in the winter. In the current model, defining the timeslice level "daynite" does not allow excess from one season to be used in another season. When defining the timeslice level "season", the problem is that it only absorbs energy flows that are "constant" during the season. Defining two storage processes (one "daynite" and one "season"), partially solves the problem, but I wonder if it can be done in one single storage process. Thanks in advance !

[Antti-L]

The original design of TIMES does not include any possibility to have a combined SEASON and DAYNITE storage, and, as yet, none of the ETSAP partners have provided a design for such a generalization.  Therefore, currently the only way is to use several storage processes (DAYNITE, WEEKLY, SEASON) to provide a generalized storage capability over all timeslices. And according to my experience, that also works reasonably well.

The "constant" charging and discharging of a SEASONal storage can be compensated by the DAYNITE storage. The charge and discharge flows of the two processes can always be balanced in such a way that when combined, net charging effectively occurs only during summer daytime.

But you are encouraged to make the design for such a generalized combined storage in TIMES.  If you can write the design for it, with all the detailed storage equations, and submit your proposal to the ETSAP project head, I am sure it can be implemented.

[wnijs]

 

Dear Antti,

Thanks for these clarifications. It seems that indeed the combination of DAYNITE and SEASON is working properly. I forced the capacity of the very cheap "dummy" DAYNITE storage process to be equal to the capacity of the SEASON storage (taking into account the number of days in a season). This way, there is room for a separate DAYNITE processe with its own cost.

What is bothering me more is how to put a cost on the storage process that is linked to the electricity consumed. The reason is that part of the cost of a storage process is assumed to depend on the highest power (some euro/kW, in my case it is charging because solar has very high GWe). Using VAR_SIN in a User Constraint is not possible and using NCAP_AFC is linked to the amount of electricity produced (and not consumed). Is there a way to solve this with the existing Gams code ? 

Many thanks
Wouter

[Antti-L]

Well, your question remains a bit unclear to me.

But because you mentioned that referring to VAR_SIN in a User Constraint is not possible, it seems that you would like to set a cost on the VAR_SIN flow? If so, that is possible directly, by specifying FLO_COST (TIMES v3.3.3). And for VAR_SOUT, FLO_DELIV can be used. You can memorize these two by associating Cost with Charge, and Deliv with Discharge. However, if that is still not what you want, please give some further clarifications.

Note that VAR_SIN / VAR_SOUT can be indirectly used also in User Constraints by defining an auxiliary flow equal to the VAR_SIN / VAR_SOUT flow that you want to include in the constraint, and then refer to the auxiliary flow instead.

[Antti-L]

A small follow-up to the storage issues:

I decided to take a look at the generalized storage concept myself, and arrived at an implementation. I hope to include the new storage type in the next version of TIMES.

When specified at the DAYNITE level, the new storage type automatically combines the DAYNITE, WEEKLY and SEASONal storage capabilities (when the timeslice levels exists in the model). And when specified at the WEEKLY level, it combines the WEEKLY and SEASON capabilities. In addition, if the process is defined to be also of type STK, it will include even the inter-period storage capability.

The new general storage type has the following advantages over using separate processes:

• There is no need to introduce separate processes at each of the timeslice levels;
• There are no spurious efficiency losses (STG_EFF) due to the extra charging and discharging that is required for the transfer between the storage levels when using separate processes;
• The inputs/outputs from/to the outside world (e.g. grid) occur only at the finest timeslice level.
  

Otherwise the new generalized process is basically equivalent to using two separate storage processes (or three, if the WEEKLY level is also present, or four, if also STK). Storage losses (STG_LOSS) can be specified in a flexible way for the different modes of operation. But there is only one capacity variable, and so there is only a single specific investment cost and fixed cost per storage capacity, which is applied to the common storage capacity. This may or may not be a reasonable assumption, but it seemed the most natural way to implement it.

Any comments or suggestions for improving the concept are welcome!

[wnijs]

Dear Antti,

Sorry it took me so long to respond, but we are very interested in this new storage type. Our model is working with two separate storage processes, but it makes it complicated and untransparant. If you look somebody for testing, I am certainly willing to. Is it modeled as a set of two storage processes or is the EQ_STGTSS changed so that the timeslice levels are mixed ? For example that both the last timeslice of the winter and the first timeslice of the spring occur in the same equation? I also struggled with modeling both the storage capacity (now CAP) and some kind of paramter representing the (mainly input) power of the storage because this determines much of the cost. I solved it by putting a -non storage- dummy process in between with a capacity cost, but it is not ideal as well. Maybe including VAR_SIN/VAR_SOUT in the list of possible variables for User Constraints or having two capacity variables can solve this issue ? Thanks for a reaction.

[Antti-L]

It seems that you have a rather huge model where each of the days in each season has their own DAYNITE timeslices. In such a model you can, indeed, talk about the first and last timeslice in each season. However, in general that is not the case, but each season typically consists of only a single or a few representative days. In such a configuration I don't see any meaningful reference e.g. to the last timeslice of the winter and the first timeslice of the spring.

The new generalized storage concept is based on a single process with some additional internal activity and transfer variables. As I mentioned in my earlier post, the new concept is otherwise basically equivalent to the multi-process case, but it has the following advantages: 1) you only need to define a single process; 2) you can avoid spurious efficiency losses from the extra charging and discharging that is required for the transfer between the storage levels in the multi-process approach, caused by making any use of STG_EFF; 3) you have a common storage capacity for the combined storage operation, with a single specific investment cost and fixed cost (this may or may not be considered an advantage).

The latest version of TIMES (v3.3.4) now also allows storage process to be defined "input-normalized", meaning that the capacity is based on the input flow. However, for now, this is only possible for storage processes that have different input and output commodities.

As I also mentioned in an earlier post, you can easily include VAR_SIN/VAR_SOUT variables in User Constraints by introducing auxiliary storage flows, and so I still don't see what the issue is there.

[wnijs]

 

Thank you, Antti. Sorry, I missed your post of 14 March, looking only at the one of 19 March. Regarding VAR_SIN/VAR_SOUT: yes I will try the auxiliary storage flows. My goal is to have two costs for one and the same storage technology: one for the "reservoir capacity" (energy) and one for the maximum capacity based on input flow (power). The charging or discharging cost in energy units was not my first intention. Although good to know, I cannot use FLO related costs because I actually want a cost to be put on a throughput capacity, being the kilowatts. I could use the "input-normalized" storage process for this, but than there is no variable left for putting a cost on the "reservoir capacity". My strategy was to make a "shadow or dummy" process of the storage process that is a classical process with only a capacity (power) cost and use the standard capacity cost of a storage process for the "reservoir capacity".  I will test our model in the code v3.3.4 and create a dummy process that is coupled to the auxiliary storage flow of the storage process.

Regarding the new storage options, yes indeed we have kind of a big model we would like to build. We probably will go for 78 timeslices as a combination of 26 “2weekly periods” WEEKLY and 3 “daynight” periods DAYNITE. The reason is that from the supply side, we think it is important to align the level of detail with the “natural” extremes. Two weeks without sun and wind is possible, but not much longer… 

So indifferently from using deterministic or some stochastic approach, we think this detail is necessary for our study that analyses 100% renewable energy. But now I am wondering if it is not better to directly have 78 "daynight" periods, although my feeling would be that this makes the model even more big ?

I tried to understand the new storage option and looked what has changed based on the verion.log file. But I do not see how I could implement the new generalised storage process. Could you please indicate this ? If you prefer me to call you on this, pl let me know. Thanks ! Wouter

[Antti-L]

You can define a DAYNITE level storage process to be of the new generalized type by specifying the process type to be "STS" instead of "STG".  However, this is not yet supported by the latest VEDA_FE 4.3.45, and so you would have to wait until you see it mentioned in the VEDA-FE Version History (http://forum.kanors-emr.org/showthread.php?tid=77).

[wnijs]

Thanks Antti. This overview of VEDA FE history is very useful. Meanwhile, I did some test runs comparing a 26 seasonal model with a 4 seasonal model, both with 3 DAYNITE levels and both with only PV as supply. The cost of the 26 seasonal model can differ some 30% of the "averaged" 4 seasonal model, although the average AF is exactly the same. Depending on the shape of the AF curve, the capacity of PV and the reservoir of the storage capacity varies (one generic storage type). So, having some more detail in the time could be interesting. On the other hand, I agree with you Antti that trying to link the first day of a season with the last day of the previous is only interesting if you have 365 days. Having directly, for example, 78 DAYNITE timeslices does indeed not make sense from the storage point of view. There is not 14 nights coming after 14 peaking hours coming after 14 days, but there is 14 times a cycle of Day, Peak and Night. I realise now that a parallel system of efficient short term storage for DAYNITE variations in combination with a less costly SEASONAL storage system is often more economical.