# IEA-ETSAP Forum

Full Version: Modelling of a Storage Process
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
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
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:
vsaini Wrote: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.
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
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.
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
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.