Arbitrary flows storage STS process

[Antti-L]

Dear all,
We face arbitrary VAR_SIN and VAR_SOUT flows for a storage STS process.
In other words, we have both an input and output in the same timeslice.
This effect is described in http://www.etsap.org/docs/TIMES-3.1-Information-Note.pdf
To prevent the undesirable impacts of such arbitrary storage flows, it is recommended to define the commodity only as an output or input of the storage process.

However, this did not work so my question is how I should prevent these flows ?

Kind regards,

Wouter

This is a good question, but it is not clear what it implies.  

Do you mean that there is a bug, such that the VAR_COMPRD variables still have arbitrary values, even though you define the commodity only as an output or input of the storage process? In that case, could you please provide details on the process description?

On the other hand, if it is not a bug, but the feature does work as designed, then your problem is not related to the undesired impacts described in the Information note. In that case, it is not clear what the undesired impacts are in your case, but there are several possibilities for remedy, e.g.:

• You could bound the input/output flows by capacity, by using NCAP_AFC;
  
• You could bound the maximum output flow to be limited by the activity at the beginning of each Timeslice (by using FLO_SHAR);
• You could offer a new and better design for storage processes, which eliminates your problem.

It would be interesting to know what the undesired impacts are in your case, if they are not related to arbitrary VAR_COMPRD values. Anyway, TIMES is a joint development effort of the ETSAP partners, and so you are invited to share also your solution to the design of storage processes, if you have one.

[wnijs]

Hi Antti,

Thanks for the response.
I did many tests to see if I am missing something.
However, I fail to prevent both IN and OUT to occur in the same timeslice.

I give you following information:

1. First you have to know that the "arbitrary" flows are not really arbitrary in a sense. We have a constraint in the model that forces in some situations electricity to be stored or curtailed. This is mainly to simulate the possible excess of solar electricity in our model with limited timeslices. In other words, the Auxiliary flow you seen on the picture is playing an important role (I cannot give you all the details now). Because of this constraint, the model we are using has a certain advantage to have both IN and OUT flows in the same timeslice. The reason is that by doing so it transforms possible excess electricity back into useful electricity. Sometimes this is OK (for example you can imagine a battery providing morning and evening demand based on excess electricity of the midday). However for some technologies we do not want it. 

2. The reason we do not want it has nothing to do with VAR_COMPRD. Actually I cannot see any VAR_COMPRD of this commodity DUMECLSTOR.

3. The process is described as follows. SET=STS, timeslicelevel=DAYNITE, PCG=DUMELCSTOR. See also picture.

4. I defined the commodity DUMELCSTOR only as an output and DUMELCSTOR has limtype FX.

Any suggestions are welcome.
Thanks,
Wouter

[Antti-L]

Two quick questions (I'll try giving my suggestion after your answer):

1. Do I understand correctly, that the undesired impact is simply that DUMELCSTOR is not getting stored, but is recycled directly back to the supply at the same timeslice?

2. How is the auxiliary flow defined?  Is it proportional to the input, output, or activity? Is the aux flow itself an input or an output of the process?

[wnijs]

Hi again,

Here are my answers.

1. The undesired impact is that the storage technology has a too high VAR_FIN. You can see the undesired effect for a storage technology in the SD timeslice (different from my previous post it is now ELCHIG but the issue is the same). I know it seems as not a real problem as mathematically the same net amount is withdrawn from ELCHIG in SD. However, in our specific case the AUX_ESTBATSxxx plays an important role in a User Constraint. What I would like to see is VAR_FIN 45.6 and a zero VAR_FOUT. This way, our model will have more curtailment (as explained we force a certain amount to be the sum of curtailment and storage charging).

2. The aux flow is an input of the process (we used Comm-IN-A). It has the attribute "INPUT" defined as 1.

Hope this clarifies a bit more.
Thanks,
Wouter

[Antti-L]

Thanks Wouter.

The undesired impacts appear to be more complicated than I thought.

May I still ask you to show also the VAR_ACT levels by timeslice in the example shown above, to better understand the behaviour of the storage under your constraint.

[wnijs]

Sure.

They are as follows.

The example shown is defined as STG (not STS) but the effect is the same I guess.
Wouter

[Antti-L]

Thanks again.  It looks I am not able to suggest a satisfactory solution, but maybe can give some useful comments:

The storage level at the beginning of SD is 13.6, and therefore the discharge of 5.9 units of ELC in that timeslice can basically be considered a valid storage operation between the previous and current timeslice. And, from that point of view, the input of 51.5 in the SD timeslice is not getting directly converted to the output flow, but it can be viewed as being fully stored, to be discharged later. As you can see, the storage level at the beginning of SN is 58.1, which can thus be interpreted as fully including the input flow in the previous timeslice (SD).

As far as I can see, preventing simultaneous input and output flows from occurring is not possible in such cases, where all the flows can be interpreted to represent genuine storage operation, because that would violate the convexity requirement.

However, if it can be assumed that the storage capacity would be constraining the charging in this case (i.e. if 13.6 + 51.5 > CAP), that might offer a solution in such special cases. You could thus make another user constraint saying that (VAR_ACT(s)+ VAR_SIN(s)) < CAP × RS_STGPRD(s)). Unfortunately, you would also need to embed the RS_STGPRD(s) numbers as coefficients in the constraint. But if you think that this condition would be a generally valid constraint (when the capacity represents the max. amount that can be stored), perhaps one might even consider changing the TIMES EQ_CAPACT for storage in this respect?

Let me know what you think, or if I can be of any further help.

And if you come up yourself with some solution that could be implemented in TIMES, please let me know.