Storage representation

[MohammedAbiAfthab]

Attached is the excel file showing flow out, flow in, activity, capacity and YRFR.

[Antti-L]

Ok, you say the capacity is 64.99 PJ, fine. But I have serious doubts about the length of the seasons. If one season would represent only 30.3 hours (using that value as an example), altogether you would need 8760/30.3 seasons to cover the full year i.e. about 289 seasons. I thought you had only 20 seasons, no? So, the average length of a single season would be 8760/20=438 hours. Could you post the G_YRFR to see whether you have made a mistake here, while claiming that your seasons would really have lengths 16.12, 21.8, 30.3, 31.3 hours of a year?

[MohammedAbiAfthab]

Ok, you say the capacity is 64.99 PJ, fine.  But I have serious doubts about the length of the seasons. If one season would represent only 30.3 hours (using that value as an example), altogether you would need 8760/30.3 seasons to cover the full year i.e. about 289 seasons. I though you had only 20 seasons, no?  So, the average length of a single season would be 8760/20=438 hours. Could you post the G_YRFR to see whether you have made a mistake here, while claiming that your seasons would really have lengths 16.12, 21.8, 30.3, 31.3 hours of a year?

Sorry it was a mistake. I had edited the previous post. Those hours represent each time slice of those seasons. Hope you have got my previous post with excel file containing the details.

[Antti-L]

Ok, it looks like, for example, season S09 has 30.345 days.  As the capacity is 64.99 PJ, the maximum nominal daily output is 0.178055 PJ.  With NCAP_AF=0.57, the storage level could be at most 0.178055×0.57=0.10149 PJ. And therefore, VAR_ACT could be at most 0.10149×30.345 = 3.0797 PJ in that season. Which season were you talking about?

[MohammedAbiAfthab]

Ok, it looks like, for example, season S09 has 30.345 days.  As the capacity is 64.99 PJ, the maximum nominal daily output is 0.178055 PJ.  With NCAP_AF=0.57, the storage level could be at most 0.178055×0.57=0.10149 PJ. And therefore, VAR_ACT could be at most 0.10149×30.345 = 3.0797 PJ in that season. Which season were you talking about?

Ok. Now I think I got it. As you told, The Var_Act doesn't represent the storage level and it represents the storage level multiplied by the number of days in that season. At S09Q13 my Var_Act was 1.07 PJ. This means I should interpret this as mystorage level at this time slice (represents 30.345 hours~1.26 days) is 1.07/30.345=0.035 PJ, right? Which means my max storage level of day is approx 0.035/1.26=0.0278 PJ, right? This is also less than the maximum permissible level of 0.10149 PJ.

I was thinking Var_Act for storage represents the storage level during that time slice.

[Antti-L]

No, sorry, I don't understand your calculation.

As I already said in my previous post, the storage level is limited to at most 0.178055×0.57=0.10149 PJ, by your NCAP_AF=0.57. According to your results, your actual max. VAR_ACT is 1.852 in season S09, and so your actual max. storage level is 0.061 in that season, because VAR_ACT is aggregated over 30.345 days in season S09.

Now you say that "I was thinking Var_Act for storage represents the storage level during that time slice."
But earlier, you understood that if we take two consecutive time slices T1 and T2, Var_Act (T1)+Var_FIn(T1)–Var_FOut(T1)= Var_Act(T2).  Clearly, you should immediately see that VAR_Act cannot represent the storage level if that relation holds! So, how could you think that VAR_Act represents the storage level during the time slice?

[MohammedAbiAfthab]

No, sorry, I don't understand your calculation.

As I already said in my previous post, the storage level is limited to at most 0.178055×0.57=0.10149 PJ, by your NCAP_AF=0.57. According to your results, your actual max. VAR_ACT is 1.852 in season S09, and so your actual max. storage level is 0.061 in that season, because VAR_ACT is aggregated over 30.345 days in season S09.

Now you say that "I was thinking Var_Act for storage represents the storage level during that time slice."
But earlier, you understood that if we take two consecutive time slices T1 and T2, Var_Act (T1)+Var_FIn(T1)–Var_FOut(T1)= Var_Act(T2).  Clearly, you should immediately see that VAR_Act cannot represent the storage level if that relation holds! So, how could you think that VAR_Act represents the storage level during the time slice?

I think I have understood your point and I am convinced. My current understanding about Var_Act is what you corrected me in your earlier post. Var_Act does not represent the storage level in that timeslice and it represents the storage level multiplied by the number of days in that particular season.

But coming to the second point about earlier thought of Var_Act as the storage level during that time slice.
Storage level, what I had thought was the energy content in the storage at that particular time slice. Then Var_Act (T1)+Var_FIn(T1)–Var_FOut(T1)= Var_Act(T2), this relation still holds, right? Instead of energy, if think of a water storage tank which had 300 litres of water in timeslice T1 which is what I understood as the storage level in that timeslice. Now in the timeslice T1, 50 litres of water is poured in (Var_FIn) and 20 litres of water is taken out (Var_Fout), then the storage level in tank will be 330 litres. This will be the storage level in timeslice T2.

Correct me If I am wrong.

[Antti-L]

AA> Var_Act does not represent the storage level in that timeslice and it represents the storage level multiplied by the number of days in that particular season.

 No, I have not said that to be generally true. That is correct only for DAYNITE storage, as I have said. The multiplier corresponds to the number of cycles under each parent timeslice. But yes, on the DAYNITE level, the multiplier is indeed the number of days under the parent timelice (the season in your case).

AA> Storage level, what I had thought was the energy content in the storage at that particular time slice.

  Yes, of course it is.  But VAR_ACT is not, for a DAYNITE or WEEKLY storage that have multiple cycles.

AA> Then Var_Act (T1)+Var_FIn(T1)–Var_FOut(T1)= Var_Act(T2), this relation still holds, right?

  Yes, surely that holds, as confirmed by me both in the earlier discussion and in my previous post above.

AA> Instead of energy, if think of a water storage tank which had 300 litres of water in timeslice T1 which is what I understood as the storage level in that timeslice. Now in the timeslice T1, 50 litres of water is poured in (Var_FIn) and 20 litres of water is taken out (Var_Fout), then the storage level in tank will be 330 litres. This will be the storage level in timeslice T2.

  No, because Var_Fin and Var_Fout (and also Var_Act, which you did not refer to in the above) are all aggregated over the days in each season.  So, assuming 30.345 days, Var_Fin would be 30.345 × 50 litres, Var_Fout would be 30.345 × 20 litres (and Var_Act would be first 30.345 × 300 litres and then 30.345 × 330 litres). Thus, Var_Act is no longer the storage level, but many times larger, just like the seasonal input and output flows are many times larger than the daily ones.

[MohammedAbiAfthab]

If the process timeslice level (PRC_TSL) is SEASON, NCAP_AF=0.5 would mean limiting the storage level to at most 50% of the nominal maximum annual output according to the capacity (if you have specified NCAP_AFC(ANNUAL)).

Dear Antti,

In this case, when I put SEASON in the timeslice level (Tslvl in VEDA), there is no operation in daynite level. How can I have both daynight and seasonal operation, along with restricting the activity to say 16.67% of maximum annual output.

I am trying to have a seasonal storage with 60 days of storage capacity with daynight and seasonal operation.

Regards
Abi Afthab

[Antti-L]

I think you already know how you can have both daynight and seasonal operation: By defining the storage to be of type STS, no? At least I have seen you using STS storage in your model...

And I think we already discussed the case of DAYNITE storage. As mentioned before, for a DAYNITE storage, you can define NCAP_AF in addition to NCAP_AFC(ANNUAL) for defining the maximum storage level in proportion to the nominal max. output in one day.

So, to repeat, if you have specified NCAP_AFC(ANNUAL), and if the process timeslice level (PRC_TSL) is DAYNITE, NCAP_AF=60 would mean limiting the storage level to at most 60 times the nominal maximum daily output according to the capacity, so to 60 days' storage (in terms of nominal maximum output).

[MohammedAbiAfthab]

I think you already know how you can have both daynight and seasonal operation: By defining the storage to be of type STS, no?  At least I have seen you using STS storage in your model...

And I think we already discussed the case of DAYNITE storage. As mentioned before, for a DAYNITE storage, you can define NCAP_AF in addition to NCAP_AFC(ANNUAL) for defining the maximum storage level in proportion to the nominal max. output in one day.

So, to repeat, if you have specified NCAP_AFC(ANNUAL), and if the process timeslice level (PRC_TSL) is DAYNITE, NCAP_AF=60 would mean limiting the storage level to at most 60 times the nominal maximum daily output according to the capacity, so to 60 days' storage (in terms of nominal maximum output).

Yes I knew it is STS. This NCAP_AF=60, I had guessed. Thanks for confirming it.