(batteries-included)= # Battery functionality ## Introduction With the increasing role played by intermittent forms of renewable energy such as wind and solar power as well as the future use of short term storage forms such as hydrogen, there is a clear need for an increasingly detailed time resolution in the energy scheduling problem. EMPS solves the long term hydro scheduling problem with reservoir balance constraints with a weekly time resolution. We here detail a new functionality which enables an hourly time resolution for reservoir balances for the aggregated system. Although there have already been efforts made in achieving hourly resolution through more formal optimization methods as exemplified by Reopt, FanSi, EMPSW, and the recent ngLTM, they come at the expense of increased computational time. While the computational times for the above methods are still considerable, EMPS enjoys much faster speeds due to the use of heuristics in the optimization problem. This presents a possibility to incorporate an hourly resolution while still retaining the favorable scaling that EMPS offers. > This document presents the new functionality through general theory and some hands-on examples of its usage. Notably, a new application *batgen* is introduced in order to enable the modeling of batteries. ### System The concept of a battery is modeled as an EMPS area with an aggregated hydro model equipped with a pump. In Fig. 1, we sketch the model description of a multi-area model connected to batteries. The dataset is comprised of a set of standard areas (right) connected to a battery/flexibility area (left). ![Basic system description](battery_illustration.png)

Fig. 1: Basic system description for an EMPS dataset + battery. As illustrated on the left, the flexibility area/battery may include the description of loads, contracts as well as the possibility of pumping to the aggregated model.


The battery's maximum energy storage corresponds to the energy content of a filled hydro reservoir. While the battery's discharge corresponds to the reservoir's production, the description of a pump on the aggregate level has so far been missing in EMPS. In order to describe pumping, we introduce the following quantities: * Max pumping capacity [capacity] * Pumping efficiency [per unit] * Pumping costs [$\mathrm{\frac{currency}{energy}}$] The minimal description of a battery in EMPS is a single aggregated hydro area. However, it can also be set up so as to include thermal production units, loads, wind and solar power etc. Please note, that it is not possible to model a battery in an EMPS area containing a detailed hydro system. To make it easier for EMPS to solve problems resulting from models containing batteries, it is highly recommended to group a battery area together with at least one other “normal” area into a _market calibration area_ (_"Samkjøringsområde”_). Please note that if you define at least one market calibration area, then all areas in the model must be put into one-and-only-one market calibration area. ### End-of-week water values Although the battery functionality concerns short term storage on the time scale of hours, the specification of end-of-week water values (henceforth abbreviated as end-values) remain important in order for the model to work. We outline three modes of operation, one of which is implicit, whereas two are explicit in the sense that they depend on user input. For this purpose, we provide end-values exogenously which will be given as a time-dependent input series. #### Standard EMPS calibration This method uses the EMPS strategy calculation to obtain water values. * Usage recommendation: Very large batteries operating with a long-term strategy and approching battery storage limits seasonally. #### Endogenously calculated water values based on the solution from the previous week The end-value method is based on the marginal value of water for the storage level from the previous weeks solution, this end-value is assumed to be a good estimate for the following week. The value is assumed to be the same for all storage levels. For the first week an exogenously given end-value is used. * Usage recommendation: Batteries operating with a short-term strategy and approching battery storage limits several times per week. #### Exogenously given water values The user specifies the end-value for each week as a function of end storage level in % (not the values calculated by the EMPS strategy calculation). * Usage recommendation: Batteries operating on a medium-term strategy, when the two endogenous end-value calculations does not necessarily provide an adequate operation of the batteries. Battery storage limits approched from weekly and to several times a year. This option may require user experimentation to obtain water values for adequate battery operation. Contact SINTEF for guidance if necessary. ## Usage In the following, we will describe the basic usage of the battery functionality. The starting point may be any EMPS dataset as sketched in Fig. 1. The standard areas + battery areas are defined as a normal EMPS dataset (ENMD, DETD, MASKENETT.DATA files etc.), where each battery area is described by an ENMD file. For the creation of an ENMD file, we recommend taking a copy of an existing ENMD file (preferrably for an area with aggregated hydro power) and modifying it through the application *enmdat*. A minimal example of a battery ENMD file which is part of a 3-area dataset is shown below ``` 0,T, * Data group 0 100,00,53,02,11,11,06,2024, * File version, timestamp 3,'BATTERY ', * Area number and name 1,T, * Datagruppe GENERELL: Various guiding parameters 1, 2024, * Num years data period, First year data period 1.00000, * ETHA 8,T, * Data group ENMAGASIN: Max reservoir and station limit 5000.028, 50.000, * Max reservoir (GWh), max production (MW) for the aggregate reservoir model 10,T, * Data group 10: Manually adjusted reservoir and prod. limits 52, 100.00, * Upper reservoir limit; end week, reservoir filling (%) 52, 0.00, * Lower reservoir limit; end week, reservoir filling (%) 52, 100.00, * Upper production limit; end week, production (%) 52, 0.00, * Lower production limit; end week, production (%) 3,T, * Data group VANNVERDI: Data related to water value calculations 1, 52, * Start W.V., end W.V. 51, 40,0.001, * Num. reservoir discretization pts. W.V.,Max num. int W.V., Pres. requirement W.V. T, 0, 0, 1, * Aut. gen. weight, Num. inflow alt. for wv. calculation, Num. end weeks, Num. inflow states in wv. calc. 16,T, * Data group FASTKON: Contract obligations and contract rights. 99, 0,' ',F, * Load number, Category, Name, Eget(T) >>__099 4,T * Data group PREFDA: purchase/import, sale/export, thermal energy, rationing. 998, 20,'FLOMKRAFT ',F, 0.00000, * Typenum, Category, Name, Eget(T), Extra variable. >>..998 52, 0.0100, * End week, Price 999, 40,'Rasjonering ',F, 0.00000, * Typenum, Category, Name, Eget(T), Extra variable. >>..999 52, 450.0000, * End week, Price 99999, 0,'SluttPref', F,0.0, End Preferansefunksjon 5,T, * Data group REGULERT ENERGITILSIG: 'BATTERY.R30', * Filename regulated inflow 52, 0.0, * Regulated inflow: end week, conversion factor 7,T, * Data group UREGULERT ENERGITILSIG: 'BATTERY.U30', * Filename unregulated inflow 52, 0.0, * Unregulated inflow: end week, conversion factor 100,T ``` The ENMD file contains information about both the energy storage as well as the production (group 8, 10). We also need to set references to regulated and unregulated energy inflow series (groups 5 and 7), but we can use a scaling factor of zero (or negligibly small such as 10^-4) such that the energy level of the battery in practice only depend on the charging (pumping) and the discharge (production). ### Environment The functionality is enabled by default. In order to deactivate it, run the following command ```bash set "LTM_MPS_BATTERY=FALSE" ``` Please note the presence of double quotes and the lack of spaces between the variable name, the equal sign, and the value of the variable. This is the recommended way of setting environment values in the Cmd shell on the Windows platform, since spaces are valid characters in both variable names and values. ## Generating input A battery input file can be generated in the dataset folder as follows ```python batgen --generate ``` This command generates the file "battery_gen.json" with default parameters and serves as the input file for the battery functionality. The resulting json file has the following structure ```json { "battery": { "exogenous_endvalue": [ [ [ 1, 2, 3, 4, "...", "...", "...", 47, 48, 49, 50, 51 ] ] ], "charging_efficiency": [ [ 1.0 ] ], "max_charging_power": [ [ 50.0 ] ], "charging_cost": [ [ 5.0 ] ], "endvalue_type": [ 0 ], "area_index_for_battery": [ 3 ], "start_week_index_for_battery_values": [ 1 ] } } ``` where the arrays are defined as follows: | Parameter | Description | Dimensions | Unit | |------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-|-| | n1 | Number of areas without batteries in the model | 1 | | | n2 | Number of batteries | 1 | | | n3 | Number of break-points in time series | 1 | | | area_index_for_battery | The indices of the areas containing batteries | n2 | | | endvalue_type | Containing integer codes with the following legal values:
0: EMPS strategy calculation
1: Water values set to the previous week's values, with "exogenous_endvalue" used to set the water values in the first week of simulation
2: Use "exogenous_endvalue" in order to set the water value at "start_week_index_for_battery_values" | n2 | | | start_week_index_for_battery_values| Start week for each time step in break-point time-series, the parameter value for each interval is constant | n3 | Time | | exogenous_endvalue | 51 is the number of reservoir discretizations and corresponding values are given as exogenous end-values for the battery. The choice of currency must be consistent in EMPS. | 51,n2,n3 | $\mathrm{\frac{currency}{Mm3}}$ | | charging_efficiency | Charging efficiency [per unit] for each battery area and for each time step | n2,n3| | | max_charging_power | Can be thought of as the pumping capacity for each battery area and for each time step | n2,n3| MW | | charging_cost | The cost of pumping for each battery area and for each time step | n2,n3 | $\mathrm{\frac{currency}{energy}}$ | **Array requirements:** The dimensions of the arrays exogenous_endvalue, charging_efficiency, max_charging_power and charging_cost must be equal. The range of legal values for the various input parameters can be summarized in the following table | Parameter, x | Range | | :--- | :----: | | Area index | $1 \le x \le n1 + n2$ | | End value type | $0$, $1$ or $2$ | | Start week index | $1 \le x \le \mathrm{num. \;weeks\; data\; period}$ | | Exogenous end-value | $x \ge 0$ | | Charging efficiency | $0 \lt x \le 1$ | | Max charging power | $x \ge 0$ | | Charging cost | $x \ge 0$ | Running the command ```python batgen --generate n1 n2 n3 ``` will result in a version of the "battery_gen.json" file where all the arrays are dimensioned according to the values of the input parameters to the `--generate` option. Without any user supplied values for n1, n2 and n3, the default values of $2,1,1$ will be used. For usage with EMPS, the user needs to generate a corresponding h5 file, 'battery.h5'. Provided the json file exists, this can be done as follows ```python batgen --file battery_gen.json ``` Although the h5 file contains exactly the same information as the json file, the h5 format conforms to the already well established standard used in LTM of using h5 files. We provide the json input as an option as it is a convenient format which can be easily modified in any text editor and is easy to serialize/deserialize with most modern programming languages. Please make sure that all battery parameters sent into EMPS honors the range of legal values as described in the table above. ### Internal dataset consistency The '--generate' option is a useful tool in order to get the battery functionality up and running quickly. Notice, however, that the field 'start_week_index_for_battery_values' depends on the data period of the surrounding EMPS dataset. Therefore, we have implemented an internal check in the program which checks the file 'LtmSystem.xml' in the current working directory and extracts the data period. If the file is not found, a data period of 52 weeks is assumed. While this covers the basic usage, the user can also specify other options. More information is available through the following command ```python batgen --help ``` ## EMPS ### Model calibration The water value calculation, done by the application *svannverdi*, consists of an iterative loop in which the total production per year in each area is checked for convergence. Usually, default convergence criteria are set based on the energy inflow of an area. As the battery area has negligible inflow, this may result in unnecessary iterations. Seing as the water values for the battery areas are not essential for the simulation of the system, their convergence limits can be set to high values. In order to specify new limits in the LTM menu, type ``` FAKTST -> KONVGR -> ``` Having set the necessary options in the "SIMUL" menu and saved the changes, run ```python emps LtmSystem.xml ``` ## Conclusion In summary, we have presented a new functionality capable of modeling short term storage in EMPS. Its usage can be summarized in the following steps * Either "attach" the battery to an existing area containing aggregated hydro, or create a new area for it based on an old one using *enmdat*. * Generate the necessary input for the battery through *batgen*. * If a new area was created, attach the battery area to the rest of the system through 'MASKENETT.DATA', 'LtmSystem.xml' and 'EmpsSamtap.xml'. * Run EMPS after adjusting the convergence criteria.