Hi,
we have an issue in our model regarding modelling of storage and time slice resolution. We think that we probably need to define a non-default G_CYCLE parameter, but based on documentation and relevant forum treads, we have not quite understood how the G_CYCLE parameter works in our case.
Timeslice resolution of our model is as follows (full file with YRFR attached):
Each season contains 13 weeks, and each week contains 8 3-hourly periods for a representative weekday, and 8 3-hourly periods for a representative weekend. We have therefore 832 timeslices in total.
We need to define an electric battery that operates on DAYNITE timeslice-level:
Questions:
1)We are not sure what should be the maximum number of storage periods in our case. If we use the formula 365 * G_YRFR, we get less than one storage cycle per daynite timeslice (se also attached file), e.g.:
For a timeslice representing 3 hours in a weekday, like SPW01D01-03, with YRFR = 0,00172 we get 0,00172*365=0,63 storage periods
For a timeslice representing 3 hours in a weekend, like SPW01E01-03, with YRFR =0,00069we get 0,00069*365=0,25 storage periods
But is this correct in our case to multiply by 365 when we have the daynite level actually representing a week?
2)When we ran the model with default G-CYCLE parameters, we got the following solution, but we are not sure if the number of storage periods are right or not for our timeslice definition and so if the charging/discharing flows are right: VAR_Cap = 0,0077 GWh VAR_FIn = 3,26 GWh VAR_FOut = 2,87 GWh N of storage periods used for charging = 426 N of storage periods used for discharing = 375 N of storage periods used, total = 801
We also tried to run the model with non-default G_CYCLE:
First we tried to change only G_CYCLE(DAYNITE)=365/7=52.143. In this case we have divided 365 by 7 because our daynite level is representing one week. With this G_Cycle results were very close to the original run with default G_CYCLE(DAYNITE).
Then we tried to change only G_CYCLE(WEEKLY)=8760/(24*7)/13=4.01. The weekly level is calculated dividing the 52 weeks by 13 that is the number of weeks in our weekly timeslice level. In this case the results became very different: VAR_Cap = 0,0056 GWh VAR_FIn = 20,5 GWh
VAR_FOut = 18,1 GWh
N of storage periods used for charging = 3680
N of storage periods used for discharing = 3238
N of storage periods used, total = 6918
Finally we tried to specify both G_CYCLE(WEEKLY)=4.01 and G_CYCLE(DAYNITE)=52.143 at the same time, and than the results for storage crashed.
When diverging from the default assumptions (WEEKLY cycle represents one week, DAYNITE cycle represents one day), things may indeed become somewhat confusing.
As far as I can see, your weekly cycle represents 13 weeks, not one week, and so your G_CYCLE(WEEKLY) should be set to 4.01. And your DAYNITE cycle appears to be a full week instead of a single day, and so I think your G_CYCLE(DAYNITE) should be set to 365/7=52.143.
Concerning the "maximum number of storage periods", I am not able to follow. In the model generator, the number of storage periods RS_STGPRD(r,s) refers to the number of cycles under the parent timeslice ts. So, it would be exactly 1 for your DAYNITE timeslices, because your DAYNITE cycle represents one week under each WEEKLY timeslice, and each of your WEEKLY timeslices represent a single week. RS_STGPRD(r,s) = G_YRFR(r,ts)*G_CYCLE(DAYNITE)=7/365 * 365/7 = 1.
But then you say that the "results for storage crashed"? What does that mean?
09-05-2019, 03:34 PM (This post was last modified: 09-05-2019, 03:35 PM by alro.)
Thank you for the quick reply!
When we tested both G_CYCLE(WEEKLY)=4.01 and G_CYCLE(DAYNITE)= 52.143, the output became strange. We got only four variables for STG-BATTERY-HV: VAR_FIn, VAR_FOut, VAR_ActM, VAR_NcapN. There were no VAR_CAP or anything else.
In both other cases, when we removed one of the G_CYCLES, the output was normal, with all usuall variables present.
We are sure that we didn't change anything else in these model runs, only G_CYCLE.
Ok, that sounds a bit strange.
As the storage is a DAYNITE storage, changing G_CYCLE(WEEKLY) should not affect its equations. It may of course affect other parts of the model formulation, and that could be the reason for the changed behaviour of your model when defining G_CYCLE(WEEKLY)=4.01 (on top of G_CYCLE(DAYNITE)). But I cannot really tell, as I cannot see your model.
If you have VAR_FIn & VAR_FOut for the storage, and you specify STG_EFF, but you get no VAR_CAP, that signifies a problem somewhere in your model (or possibly in TIMES). Having no VAR_CAP mans that the input and output flows must be in the same timeslice (please confirm), and so there is no storage operation (which would require storage capacity). But if you have STG_EFF=0.88, you will get efficiency losses, although nothing actually gets stored. Such should only happen if you have some constraint, which can be satisfied at the lowest costs by using the storage input/output flows in this strange way.
But again, I am sorry I cannot really tell what the problem is, as I cannot see your model.
09-05-2019, 05:10 PM (This post was last modified: 09-05-2019, 05:23 PM by Antti-L.)
Ahh... but looking at the picture in your email message, it looks like you have actually not defined any STG_EFF, which explains well the input & output flows without capacity. Then you have no efficiency losses, and the storage effectively does nothing (it is equivalent to having zero flows).
(In the picture, ~FI_T is above the column where you define STG_EFF, which won't work).
[EDIT:] But the flows you reported seem to have losses, and so maybe the picture is incorrectly aligned?
Oh no, it is probably just the pricture that looks wrong! STG_EFF is defined and it works in all other model runs.
I have now tested again with both G_CYCLE(WEEKLY)=4.01 and G_CYCLE(DAYNITE)= 52.143, and it is exactly the same, only four variables come out. And yes, the input and output flows are in the same timeslices. I wonder if these parameters can be somehow related to each other in model equations, e.g. something like G_CYCLE(WEEKLY) = G_CYCLE(DAYNITE)/7 = 365/7 = 52? Than it may happen that redefining both of them leads to some strange model behavior, no?
Our model is quite simple, I believe we do not have any other variables using G_CYCLE (like ramping) if it is what you mean by
Quote:It may of course affect other parts of the model formulation, and that could be the reason for the changed behaviour of your model
It seems at least that out logics in defining G_CYCLE(WEEKLY)=4.01 and G_CYCLE(DAYNITE)= 52.143 was correct. But if you say that
Quote:As the storage is a DAYNITE storage, changing G_CYCLE(WEEKLY) should not affect its equations.
maybe we should only define G_CYCLE(DAYNITE)= 52.143? Should the output for our DAYNITE storage in this case be more correct than with a G_CYCLE(DAYNITE) = 365?
Ok, if your model is quite simple, maybe you could consider providing the model input files for me, in order to take a look at it? It would only require that you pack all the *.DD files, and the *.RUN file (from the VEDA work folder) into a ZIP file, and upload it onto some server (e.g. Dropbox, Google Drive), and then send me the download link for the ZIP file in a private message. Including the listing file *.LST would also be of help.
If you can provide these files, I could investigate the issue and get back to you with a concrete suggestion.
10-05-2019, 01:24 PM (This post was last modified: 10-05-2019, 01:25 PM by alro.)
I have sent you the model.
For information, we have now discovered that not all DAYNITE batteries «lose» capacity variables. There was one DAYNITE battery that had all variables defined in the run with non-default G_CYCLE(WEEKLY) and non-default G_CYCLE(DAYNITE). Hope you can help us to figure this out!
Thanks. It will be good to be able to verify what causes the unexpected behaviour.
However, as I am quite busy at the moment with various tasks, it might take a few days until I have the time to look at it in detail. I will let you know then.
11-05-2019, 10:02 PM (This post was last modified: 13-05-2019, 12:06 AM by Antti-L.)
Ok, I have now investigated the differences in the model runs, between the following two cases:
1. Define only G_CYCLE(DAYNITE)=365/7=52.143
2. Define both G_CYCLE(DAYNITE)=365/7=52.143 and G_CYCLE(WEEKLY)=8760/(24*7)/13=4.01
You reported that the results for storage would be different between these two cases. My tests did not confirm your findings: The value of the objective function from these two runs was exactly the same, and so any differences in the results would be of cosmetic nature, due to degeneracy (multiple solutions having same objective value). And concerning the operation of STG-BATTERY-HV, in both cases there were input and output flows, but they were all in the same timeslices. There were thus no VAR_CAP in either case, because there was no storage operation (nothing was ever stored in STG-BATTERY-HV). Despite the efficiency losses, the solution was still optimal, because the price of ELC-HV was zero in all those timeslices where STG-BATTERY-HV had an input & output flow. So the battery worked like a "curtailment device".
I also investigated all the differences in the model equations between these two cases. It turned out that you do also have a WEEKLY level hydrogen storage STG-H2-W, and therefore the EQL_CAPACT equations for that process were different, as expected, and also the activity costs coefficients for this process were different, as expected. However, because this technology was not used in either of the two runs, these differences did not have any impact on the solution. There were no other differences in the model between the two cases.
In summary, my conclusions from the investigation are:
Defining both G_CYCLE(DAYNITE)=365/7=52.143 and G_CYCLE(WEEKLY)=8760/(24*7)/13=4.01 would in my view be the consistent values for your model, and
I cannot confirm your findings about any relevant differences in storage operation between these two cases.
Notwithstanding, if setting G_CYCLE(DAYNITE)=365/7, I think the fact that your DAYNITE timeslices do not actually make up a chronological cycle will tend to cause an overestimation of the DAYNITE storage costs in your model, because you actually have each timeslice representing 5 or 2 days of the week, such that each of the DAYNITE timeslices represent a non-contiguous time interval within the cycle. In the design of TIMES using this kind of timeslice definitions has not really been given consideration, and so you are pretty much on your own with it. The good thing here is that the issue basically only affects DAYNITE storage. However, to eliminate an overestimation of storage costs you might consider defining a larger number of DAYNITE cycles, after all. Perhaps some kind of a compromise between 365 and 52.143?
