Modelling of a Storage Process

[vsaini]

Dear Dr. Antti,

Greetings of the day and Happy New Year 2020.

I am modelling a storage-based process in my model and I have query regarding the same. Please see my query in the attachment.

Looking forward for your guidance.

Warm Regards,

Vinay Saini

[Antti-L]

The capacity of your storage represents the maximum amount of energy that can be stored by the device.

As far as I can see, your conversion of the storage flows from PJ to MWh are quite correct.  Therefore, in 2035 the daily input into your storage is in total 4839.8 MWh.  According to your input data, only 60% of the storage capacity is available for operational use, and therefore the capacity needed for the daily charging of 4839.8 MWh is 4839.8 / 0.6 = 8066 MWh.  This amount of energy is equal to 0.029 PJ,  which we can convert to the capacity unit by dividing it by PRC_CAPACT=31.536.  Thus, in terms of your capacity units, the capacity required for the daily charging is 0.029 / 31.536 = 0.00092 GW = 0.92 MW.

As you can see, the calculation gives a value just slightly larger than what you show in your table, 0.90 MW.  However, I think that is probably due to a rounding error, because your capacity unit appears to be GW, and ANSWER-TIMES reports the results with only 4 decimal places, and so the reported value would be 0.0009 GW.

For 2040, similar calculation gives the capacity required for the daily charging as 0.0359 / 31.536 = 0.001138 GW ≈ 1.1 MW.

So, in response to your request:

Please, provide your guidance whether I am modelling the storage process in a right way and what could be the reason for capacity and Var_Flo_Out numbers variation.

AL>  I see nothing wrong with your modelling of the storage process, other than your unnecessarily big capacity unit (GW). I don't know the reasons for the variation in the discharging flows (Var_Flo_Out), but I think such a variation is quite natural for a storage operation.

[vsaini]

Dear Dr Antti,
Thank you for your reply.

I still have some doubts on the capacity number interpretation from the model. The number 0.90 MW in 2035 is taken out from the Var_Cap result parameter which shows the installed capacity for a process. If you say that 0.90 is the installed capacity then all the cost calculation from the model are done on this number?

Now if the installed capacity itself is 0.90 MW than the output of the process should not increase more than 0.90 MW in any instance because I am prescribing the Ncap_af of 100% as upper bound. But in my results, the outputs are increasing to as high as 2094 MW, which cannot happen from a battery capacity of 0.90 MW (kindly refer figure 2 and 3 on this link https://www.energy.gov/eere/solar/articl...torage-101). Therefore, I am bit confuse how to interpret the outputs of my process.

How would I interpret the duration of battery storage from these outputs? Furthermore, is there any way to prescribe the hours/duration for storage capacity type.

Regards
Vinay Saini

[Antti-L]

Sure, investment costs and fixed O&M are always specified per unit of capacity, and therefore the total (overnight) investment costs can be obtained by multiplying the unit investment cost by the capacity, and so on.

As I pointed out already, the capacity of your storage represents the maximum amount of energy that can be stored by the device.  Hence, the capacity does not limit the level of the output flow in any other way, but only through the amount stored. A capacity of 1 MW translates into 31.536 TJ = 8.76 GWh, and so the output level could be as much as 8760×0.86 MW, if the full storage (8.76 GWh) would be discharged in one hour (discharge efficiency=0.86).

If you want that the capacity directly limits the output level, please model the capacity in terms of the nominal maximum output level, and not in terms of the maximum amount of energy stored. We have gone through illustrative examples before, for example the hydro pondage example, so there should be no need to explain all that again.

[vsaini]

Dear Dr. Antti,

I tried to fix the use of storage capacity with the help assigning NCAP_AFC at (ANNUAL-TSL, DAYNITE, SEASON and WEEKLY) to both the input and output commodity at level 1. 

This limited the var_flo_out and Var_flo_in levels to the capacity level. However, this has created a new problem of charging and discharging of the storage process at some time slices in a year. Example multiple time slices in year 2035 as shown in attachment.

Any suggestions on what could be reason for this or which areas I need to further focus to rectify this issue?

Warm Regards
Vinay Saini

[Antti-L]

Ok, now you say there is a problem "of charging and discharging of the storage process at some time slices in a year".  I assume you mean charging and discharging in the same timeslice?  Well, at least I am able to use all my mobile battery devices also simultaneously while charging. I can receive and make calls, and run applications, while the device shows that charging takes place at the same time. So, I am not quite sure why you consider that posing a problem? I would consider it a much bigger problem if I would not be able to use the device while charging…  

Anyway, I can see that you have now modelled the storage device completely differently than your original device and description, without explaining the changes:

• You have completely changed the topology, which earlier had ELEG as an input and output but now completely unrelated commodities, and different for input and output.  And you give no explanation to these changes. Thus, I have no idea what these two new commodities represent, and whether there are perhaps many processes operating between them.
  


• You have added NCAP_AFC(r,y,p,com,tsl)=1 for all timeslice levels and both input and output commodities, but you give no explanation to all these parameters. I find these particularly strange, because NCAP_AFC(r,y,p,com,DAYNITE)=1 of course mathematically implies NCAP_AFC(r,y,p,com,tsl)=1 on all coarser timeslice levels, and so the parameters do not make any sense to me.
  


• You are still defining NCAP_AF(ANNUAL,LO)=0.4, even though you have defined neither any upper bound availability for the storage level nor any storage losses. The purpose of the NCAP_AF(ANNUAL,LO)=0.4 is therefore now unexplained to me (earlier, I understood it has a purpose, because you bounded the storage level by the capacity).
  


• You have also defined ACT_EFF for the process, although I think the process is meant to be a storage process, and in the documentation you can see that ACT_EFF cannot be used for storage.
  

Therefore, in view of your original modelling problem, where the process ST_BES_NP has ELEG as an input and output, maybe you could consider just trying the parameters shown in the picture below (note the ELEG in TOP_IN, TOP_OUT and PRC_ACTUNT):



Then, if you also want to bound the storage level by the capacity, you could also add NCAP_AFC(ACT) if you like (as explained in the documentation, or NCAP_AF(UP) if you follow the pondage example), and then an NCAP_AF(LO) would also make sense.  And if you want a different output availability (vs. input), you can define such by using NCAP_AFC(ELEG), if you like.

[vsaini]

Dear Dr. Antti,

AL> Ok, now you say there is a problem "of charging and discharging of the storage process at some time slices in a year".  I assume you mean charging and discharging in the same timeslice?  Well, at least I am able to use all my mobile battery devices also simultaneously while charging. I can receive and make calls, and run applications, while the device shows that charging takes place at the same time. So, I am not quite sure why you consider that posing a problem? I would consider it a much bigger problem if I would not be able to use the device while charging…  

VS> Simultaneous charging and discharging of mobile is good but I am not sure whether the same is true for a Battery storage plant as they are constructed to charge at low market price (off peak hours) and discharge at high market prices (typically during peak hours). Hence, I am not sure whether battery based storage plants can do charging and discharging at the same time. That’s why I pointed it as an issue.

AL> Anyway, I can see that you have now modelled the storage device completely differently than your original device and description, without explaining the changes:

• You have completely changed the topology, which earlier had ELEG as an input and output but now completely unrelated commodities, and different for input and output.  And you give no explanation to these changes. Thus, I have no idea what these two new commodities represent, and whether there are perhaps many processes operating between them.
• You have added NCAP_AFC(r,y,p,com,tsl)=1 for all timeslice levels and both input and output commodities, but you give no explanation to all these parameters. I find these particularly strange, because NCAP_AFC(r,y,p,com,DAYNITE)=1 of course mathematically implies NCAP_AFC(r,y,p,com,tsl)=1 on all coarser timeslice levels, and so the parameters do not make any sense to me.
• You are still defining NCAP_AF(ANNUAL,LO)=0.4, even though you have defined neither any upper bound availability for the storage level nor any storage losses. The purpose of the NCAP_AF(ANNUAL,LO)=0.4 is therefore now unexplained to me (earlier, I understood it has a purpose, because you bounded the storage level by the capacity).
• You have also defined ACT_EFF for the process, although I think the process is meant to be a storage process, and in the documentation you can see that ACT_EFF cannot be used for storage.

VS> Yes, I changed the topology and apologies for not explaining that in the previous post. I tried to limit the output from the storage process using NCAP_AFC and while doing so I did change the topology to have different names of input and output commodities as I was not aware of using the “NRG” in the commodity group, which could have simplified the process for me. Further, I was referring to the old documentation (from my system AnswerTIMES documentations) therefore; I missed the major points about the storage process and capabilities of its associated parameters. Now, I am referring to the new documentation.
So, I will do it again as per your suggestion, but I still need clarification on the following:

- I want to limit the storage capacity to 4 hours, so can I use NCAP_AFC('ACT') with value of 0.1666 at DAYNIGHT Time slice level (storage of 4 hours in a day i.e. 4/24 )? Further, what is ACT in the expression NCAP_AFC('ACT')? Is it the Activity? Because, in the drop down menu of AnswerTIMES it only shows ‘ACTGRP’. Is ‘ACTGRP’ the right one to select and model NCAP_AFC(ACT)?  

- I also want to model the depth of discharge in my storage process. For instance, if I want to model a depth of Discharge of 80%, which means at any given time my storage process charge will not go below 20% of the capacity then in-order to achieve that can I use the NCAP_AF (LO) (at annual level) with of 0.20?

Looking forward for your reply.

Warm Regards,
Vinay Saini

[Antti-L]

I want to limit the storage capacity to 4 hours, so can I use NCAP_AFC('ACT') with value of 0.1666 at DAYNIGHT Time slice level (storage of 4 hours in a day i.e. 4/24 )? Further, what is ACT in the expression NCAP_AFC('ACT')? Is it the Activity? Because, in the drop down menu of AnswerTIMES it only shows ‘ACTGRP’. Is ‘ACTGRP’ the right one to select and model NCAP_AFC(ACT)?

AL> Yes, 4 hours' capacity can be modelled by NCAP_AFC('ACT','DAYNITE') = 0.1666  (if it is a DAYNITE level storage process). Under ANSWER, ACT should be replaced by ACTGRP.  ACT / ACTGRP are GAMS labels.  But yes, they are used when defining NCAP_AFC for the activity (and activity represents the storage level).

I also want to model the depth of discharge in my storage process. For instance, if I want to model a depth of Discharge of 80%, which means at any given time my storage process charge will not go below 20% of the capacity then in-order to achieve that can I use the NCAP_AF (LO) (at annual level) with of 0.20?  

AL>  If you want to define a lower bound for the storage level in proportion to the capacity, you can indeed define it with NCAP_AF('ANNUAL','LO')=value.  If the full storage capacity (100%) corresponds to NCAP_AFC(ACT)=0.1666, 20% of the capacity would correspond to value=0.2×0.1666. Thus, I suspect that by setting NCAP_AF(ANNUAL,LO)=0.2 you would get an infeasible model, because your lower bound would be higher than the upper bound.  

[vsaini]

Dear Dr. Antti,

I have modelled the storage process as per your suggestion and it is working perfectly fine. I have used the following parameters:
NCAP_AFC (ACTGRP)- DAYNITE
NCAP_AFC (NRG)- DAYNITE
NCAP_COST
NCAP_FOM
NCAP_TLIFE
STG_EFF
The results are looking fine except for some time slices where the storage process charges and discharges at the same time.  

Just one more clarification regarding NCAP_AFC(ACT), I am using NCAP_AFC (ACT) with 0.16 value at DAY NIGHT time slices. So is it right to assume that the value is applicable on all the 24 (Day Night) time slices under the month of April and so on. 

On the NCAP_AF(LO) parameter, I tried to model this parameter in my storage process with the value of 0.20. The model ran without infeasibility although it did not installed any storage capacity. I even tried a model run with the ncap_cost value of 1 and still the model didn’t picked the storage process capacity (keeping all the other parameters similar to the previous example).   

Warm Regards
Vinay Saini

[Antti-L]

If you are modelling a storage with ELEG as input and output, and your storage efficiency is 0.86, there should be no reason for any simultaneous charging and discharging at the same timeslice, unless the price of ELEG is zero. So, simultaneous charging and discharging should occur only if the price is zero in those timeslices, because the efficiency loss would make it non-optimal when there is a price.

Concerning NCAP_AF(LO), of course setting it to 0.2 is inconsistent, if you define NCAP_AFC(ACT)=0.16, because then your lower bound availability would be higher than the upper bound. The only feasible solution would then be with CAP=0, as you have noticed.  To define a 20% minimum storage level, you should set NCAP_AF(LO)=0.16 × 0.2, as I already said earlier.

Yes, NCAP_AFC(DAYNITE) is applied to all DAYNITE timeslices.

[vsaini]

Thank you Dr Antti for your help and support.