Battery CAP much higher than ACT needs

[SongminYu]

Dear message-ix team, I have been developing a model for China including multiple sectors. In the power sector, I included battery storage. This attached excel shows the ACT and CAP results of three technologies -- battery, battery_charger, and battery_discharger -- as well as a brief pivot analysis.

Looking at the "pivot" sheet, as shown in the ACT area, the three technologies works fine together: the battery column is "state-of-charge", correctly calculated given the values in the other two columns.

However, what I found problematic is, the CAP value is much higher than the ACT needs... For example, taking the battery in Beijing in 2025 as example, the CAP of battery is 4451. However, the biggest "state-of-charge" that ever existed for 2025 in Beijing, is 93...

My questions are:

• How is the CAP calculated for battery (or "storage technologies" in general) in MESSAGE? Usually, it is ACT/capacity_factor for other normal technologies. Apparently, it is not the case for storage technologies.
• In my result, I also notice very high use of battery in some hours. For example, in some hours in 2060, battery can save 40% of the total generation of all ppls. In some other hours in 2060, battery can discharge 50% of the total generation of all ppls. These look very unrealistic to me, but the ACT area in the "pivot" sheet looks correct for these hours. I assume the model is solved successfully, but I should have somehow limited the use of battery, for example, it cannot be charged/discharged too fast. Is it possible to implement such constraints?
• Overall, I feel the storage in my model is used very optimistically... I don't know where it could be wrong... I hope I can receive some suggestions to check more details...

[glatterf42]

Hi @SongminYu, thanks for these questions! I have raised them in today's team meeting and received the following answers:
Your general observation is correct: storage technologies are too good to be true in their current implementation. MESSAGEix was not designed to be a Power Systems Model, so it is lacking the capabilities of hourly resolution that would be required to properly constrain charging and discharging rates. There are currently no plans to develop such functionality for MESSAGEix, though @SiddharthJoshi-Git suggested that it might be possible to construct new technologies "charge" and "discharge" that are working on top of the storage technologies and constrain their growth rates with the existing features. Please note that no one in the MESSAGE team has done this before, so we can't properly guide you in how to do this. Nevertheless, please share your experiments and results, we're curious to learn!

That being said, there are two things that might interest you:

1. @behnam-zakeri has previously worked on storage technologies, but for seasonal storage. Maybe this work can be expanded to also cover your use case.
2. @ebbekyhl has worked on coupling MESSAGEix to an actual Power Systems Model, PyPSA. Maybe you two can connect and share your knowledge/code to utilize the same coupling here.

As for your first question, the team noted that @behnam-zakeri would be the best to answer this. Though I'm thinking that these calculations must also be coded in the GAMS code, so if you don't want to wait, understanding that should yield the answer, too.

[SongminYu]

Hi @glatterf42, thanks a lot for your quick and detailed response! I was guessing that the battery was implemented "optimistically". But it helps a lot to be confirmed by IIASA colleagues. I also understand that MESSAGE was designed more for "annual resolution" by default. The hourly resolution is more of an additional feature implemented later. So the modeling of storage technologies is not the strength of the framework.

At first, I was thinking about limiting the "charging/discharging speed", like some "capacity factor" of batteries. For example, if 2MWh electricity needs to be stored, you need a much larger battery because the speed may be limited at 10% charging per hour, meaning a 20MWh battery is enough. Then, as a result, the battery will become expensive for investment. However, the CAP of battery was already quite high even without the "charging speed limit". That's why I was even more curious about how the CAP is calculated for batteries. Look forward to the answer from @behnam-zakeri!

Thanks for the suggestion by @SiddharthJoshi-Git! Following this idea, I try to roughly describe my understanding as follows:

• Following the documentation of storage modeling, my current implementation of battery already includes three components: battery charger, battery (the container), and battery discharger.
• The aim is to limit the charging (and discharging) rate of battery, which means to limit $ACT_{battery charger} / CAP_{battery}$ (and $ACT_{battery discharger} / CAP_{battery}$).
• This form looks like a capacity_factor, but across technologies. So, with the existing capacity of message-ix, we may consider adding two technologies: battery charger abstract, battery discharger abstract:
  • by using the relation feature, we force $CAP_{battery charger abstract} = CAP_{battery} = CAP_{battery discharger}$
  • by using the relation feature, we force $ACT_{battery charger abstract} = ACT_{battery charger}$ and $ACT_{battery discharger abstract} = ACT_{battery discharger}$
• Then, we constrain the capacity_factor of battery charger abstract (and battery discharger abstract) at the subannual level, to reflect the charging rate constraint.
• The estimation of this capacity_factor depends on the time-resolution of the model. For example,
  • If the time-resolution is not high, e.g., seasonal, the capacity_factor can be 1, meaning that in one timeslice of the model, the whole battery can be charged from empty to full, or discharged from full to empty.
  • If the time-resolution is high, e.g., hourly, the capacity_factor maybe 0.3, meaning that in one timeslice of the model, only 30% the whole battery can be charged or discharged.

I am not familiar with the relation feature in message-ix, neither the implementation of storage modeling. I don't know if the steps above sound realistic or if there are obvious problems. Any suggestions would be much appreciated!

Besides, I wonder what @ebbekyhl has explored in message-ix and why he finally decided to give up implementing everything in message and choose to do a coupling. I personally found message-ix could be flexible enough to properly model the power system (multiple nodes, bidirectional trade with "modes" for modeling electricity trade/transmission). If a workaround can be developed for storage modeling based on exisiting features in message-ix, combining its flexibilities for modeling other technologies (constructing technology network with input-output coefficients, etc.), message-ix can model the whole energy system very well. I have been trying to develop such a model for China. I know PyPSA has been extended to include demand-side sectors, so the whole energy system as well, but I haven't explored much there.

[behnam-zakeri]

Thanks @SongminYu and @glatterf42 for the discussion. I add a few points to clarify some of the points mentioned above:

1- The storage formulation in MESSAGE is very flexible and relatively comprehensive (covering many aspects of storage solutions), aimed at modeling various technologies (thermal, material, water, electricity storage etc.). More interestingly, in MESSAGEix one can define various storage technologies at different temporal levels, e.g., you can parameterize pumped hydro to operate at the monthly level, while batteries at the daily level. There are a few studies and projects that have used the storage feature, e.g., the Central Asia project, which used the storage for a complicated pumped hydropower model in the region, linking water and electricity cycles to each other: https://github.com/iiasa/central-asia-storage

2- While MESSAGEix is not a power system model, one can use the feature of sub-annual time slices (hereafter "time slices") to model variability in supply and demand for selected time slices or even in an hourly manner. A power system model would be a better fit for high-resolution studies as ramping rates, AC/DC power flow, unit commitment etc., can be represented more easily than MESSAGEix.

3- Charger, discharger, and storage reservoir can be paramterized separately, and constrained like any other technology in MESSAGEix, e.g., by growth rates for their activity/capacity (from one year to another), min/max activity in certain time slices or capacity in certain model periods, relating activity in one time slice to activity in another time slice or to a maximum (share constraints), cost parameters, etc.

4- @SongminYu it would be useful if you could explain why you think MESSAGEix is "optimistic" toward batteries or storage. Have you used possible constraints to control the behavior of your technology? You can test this, e.g., by:

• Increase the investment cost of storage 10 times and see if you see any impact on the results.
• Put an upper bound on the capacity of storage and see if the model is still feasible using other technologies

5- Related to the relationship between activity and capacity in a model with time slices, the duration of time slices duration_time plays a role too see formulation here. The shorter the time slice, the higher the capacity needed to get the same level of activity. See the examples below for an arbitrary technology:
a- In a model without time slices: for an annual ACT of 1 GWa and capacity_factor of 0.5, you need CAP = 2 GW
b- In a model with two time slices, each half of the year: for a seasonal ACT of 0.5 GWa and capacity_factor in each season being still 0.5, you would still need CAP = 2 GW = ACT / (capacity_factor * duration_time) = 0.5 GWa / (0.5 * 0.5).
c- But in a model with two time slices, one 20% of the year and another one 80% of the year (the same capcity factor of 0.5 for each season): for getting ACT of 0.5 GWa in the shorter time slice, you would now need CAP = 5 GW (=0.5 GWa / (0.2 * 0.5)
In other words, in example (c) you need 5 GW to meet an annual demand of 1 GWa, while in (a) and (b) you need 2 GW to meet the same demand. This is because we needed a large capacity to generate activity in a relatively short time slice.

I hope this helps to clarify.

[SongminYu]

Hi @behnam-zakeri, thanks for your detailed answer! I agree that MESSAGEix is very flexible to model the whole energy system, including the power system with its sub-annual time slices. It maybe easier to implement in a framework like PyPSA, but MESSAGEix can also do the work. I plan to integrate the transmission line in the next stage following "3.1. Bilateral trade and "mode" of operation" in this tutorial.

Responding to your suggestions and questions:

First, by "optimistic", I was meaning that the "charging rate (speed)" of battery (or storage in general) is not constrained, i.e., all available renewable generation surplus can be charged into battery in one timeslice. The other parameters like cost are working well I believe.

Second, I haven't added capacity_factor for battery in my model. Maybe this is why the CAP results looked a bit "random" to me. Thanks for giving the examples especially mentioning the impact of duration. I will try adding it and run the model again.

Third, apart from adding the capacity_factor (maximum working time of capacity in percentage of the whole year), I think it is necessary to add some parameter to limit the "charging rate (speed)" for battery:

• As suggested by the documentation, my battery is constructed with 3 technologies: "battery_charger", "battery_discharger", and "battery (reservoir)".
• As shown in the excel file attached in my first post here, the ACT values of "battery" is its "state-of-charge". The ACT values of "battery_charger" and "battery_discharger" are the charging/discharging flows.
• In this case, if I want to limit "charging/discharging rate" with some parameter, it should be the ACT of "battery_charger/battery_discharger" divided by the CAP of "battery". This is not the capacity_factor parameter like normal technologies in MESSAGEix. I asked about this in my reply above. Following the suggestion by @SiddharthJoshi-Git, I roughly listed the steps that I may try. Could you have a look at that? Thank you!