Page History

...

The model definition for the reservoir can be configured in a model file that follows the Integrated Reservoir Model schema. The model options are described below.

Schema

For reference, an example Integrated Reservoir Model file is example IntegratedReservoirModel file is attached.

<IntegratedReservoirModel xmlns="http://www.wldelft.nl/fews" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.wldelft.nl/fews https://fewsdocs.deltares.nl/schemas/version1.0/adapter-schemas/IntegratedReservoirModel.xsd">
    	<general>
        		<missingValue>-999</missingValue>
    	</general>
    	<reservoir id="H555001">
        <general>
            		<general>
			<description>reservoir management H555001</description>
            			<poolRoutingScheme>levelPoolMethod</poolRoutingScheme>
            			<dynamicInterpolation>true</dynamicInterpolation>
            <elevationInterpolationMethod>linear interpolation</elevationInterpolationMethod>
            <elevationInterval>0.00005</elevationInterval>
        			<interpolationMethod>linear</interpolationMethod>
			<elevationInterval>0.0005</elevationInterval>
			<extrapolationMethod>linear</extrapolationMethod>
		</general>
        <!--Height (LGH) vs. Storage (m3)-->
        <storageCharacteristics>
            <storageTable>
                <elevationStorageRecord elevation="292.9" storage="0"/>
                <elevationStorageRecord elevation="293.0" storage="500"/>
                ...
                <elevationStorageRecord elevation="335.4" storage="720992000"/>
                <elevationStorageRecord elevation="335.6" storage="732795000"/>
            </storageTable>
        </storageCharacteristics>
        <!--Height (LGH) vs Spill (m3/s-->
        <uncontrolledOutlet id="outlet">
            <capacityCharacteristics>
                <outletTable>
                    <elevationOutletRecord elevation="292.9" outlet="0"/>
                    <elevationOutletRecord elevation="293.0" outlet="0"/>
					...
                    <elevationOutletRecord elevation="335.4" outlet="9768"/>
                    <elevationOutletRecord elevation="335.6" outlet="10278"/>
                </outletTable>
            </capacityCharacteristics>
            <input>
                <release>QOut</release>
            </input>
            <output>
                <release>QOut</release>
            </output>
        </uncontrolledOutlet>
        <input>
            <inflow>IIn</inflow>
            <level>HIn</level>
        </input>
        <output>
            <inflow>IOut</inflow>
            <release>QOut</release>
            <storage>SOut</storage>
            <level>HOut</level>
        </output>
    </reservoir>
</IntegratedReservoirModel>				</outletTable>
			</capacityCharacteristics>
		</uncontrolledOutlet>
		<input>
			<inflow>IIn</inflow>
			<level>HIn</level>
			<release>QOut</release>
		</input>
		<output>
			<inflow>IOut</inflow>
			<release>QOut</release>
			<storage>SOut</storage>
			<level>HOut</level>
			<error>EOut</error>
		</output>
	</reservoir>
</IntegratedReservoirModel>

In XML Grid View this looks the following

Image Added

general

In the general section of the reservoir model, a missingValue element needs to be configured. It is important to match the missingValue as defined in the Delft-FEWS General Adapter configuration for the model run.

...

• poolRoutingScheme
• dynamicInterpolation
• elevationInterpolationMethodinterpolationMethod
• elevationInterval
• extrapolationMethod (from 2023.02)
• storageCharacteristics

poolRoutingScheme

...

When the dynamicInterpolation element is set to false, the level/storage and level/outlet tables are precalculated (only once) using the elevationInterpolationMethod, to the specified elevationInterval.  

...

interpolationMethod

Linear interpolation is the only available interpolation method

...

The elevationInterval is the elevation resolution at which the configured level/storage and level/outlet tables need to be recalculated to achieve a higher granularity. Note that the level output at each timestep is processed to that specific elevationInterval. When the model looks up a value from the table, the largest precalculated table elements smaller than the lookup value will be used (i.e. the model always rounds down). The consequence is that reservoir inflows/releases at a timestep that result in level/storage changes smaller than the interval/resolution will not be taken into account. The model does not perform any shadow accounting to keep track of these volumes. This means that the model will generally underestimate the flow when dynamicInterpolation element is set to false, and water balance will not be closed for that run type. For larger reservoirs (more volume per unit water disk) the elevationInterval needs to be set to higher resolutions to account for this. 

storageCharacteristics

The storageCharacteristic storageTable contains a storage-level lookup table that is strictly increasing. Note that this table should have the identical storage inputs as the capacityCharacteristics outletTable from the uncontrolledOutlet.

uncontrolledOutlet

The uncontrolledOutlet element contains capacityCharacteristics outletTable which relates storage-release. Note that this table should have the identical storage inputs as the storageCharacteristic storageTable.

the elevationInterval needs to be set to higher resolutions to account for this. 

extrapolationMethod

The available extrapolation options are: notAllowed. linear, maxMin

storageCharacteristics

The storageCharacteristic storageTable contains a storage-level lookup table that is strictly increasing. Note that this table should have the identical storage inputs as the capacityCharacteristics outletTable from the uncontrolledOutlet.

uncontrolledOutlet

The uncontrolledOutlet element contains capacityCharacteristics outletTable which relates storage-release. Note that this table should have the identical storage inputs as the storageCharacteristic storageTable.

input / output variables and files

In the input section, the model input variables will be configured.

The <input><inflow> element is required

The <input><level> element is optional, and can be set to the timeseries variable that can overwrite (take precedence) over the level as a result from the release table computation. For a given timestep, if the level input timeseries (e.g. HIn) contains a value, this level is applied. The model will determine the resulting release from closing the waterbalance (thus not using the release lookup value)

The <input><release> element is optional, and can similarly The <input><release> element can be set to the timeseries variable that can overwrite (take precedence) over the lookup value for the outlet. This means that for a given timestep, if the outlet input timeseries (e.g. QIn) contains a value, this release is applied.

The <output><release> element determines where the resulting release timeseries is saved to.

input / output variables and files

This input option was added in 2023.02

When both a level and a release input value are available for a timestep, the model will use those values and write them to the output. A waterbalance error term will be calculated and saved for that timestep as well.

In the input section, the model input variables will be configured. The model will look for the required variables in the the parameter field of the PI timeseries (see idMapping). The Reservoir Model code will try to parse the configured model variables (like IIn, QOut, etc) from the parameterId of the PI timeseries, the locationId is not used. In the output section, the model output variables will be configured. When writing the output timeseries, the locationId used in the import PI xml files will be used as the locationId in the output PI xml files. The output model variableId's will be used as the parameter in the timeseries.

...

• importState.xml
  • level values, or (HIn)
  • storage values (SIn)
• import.xml
  • inflow (IIn)outlet (optional) (QIn)
  • outlet (optional) (QIn)

The following output timeseries file is suggested:

• export.xml
  • inflow (IOut)
  • release (QOut)
  • storage (SOut)
  • level (HOut)
  • error (EOut)

Note that for the suggested variableId's in the provided example, the postfix postfix In and Out are used to denote if the series are Inputs for, or Outputs from the model.

State values

The The startDateTime and endDateTime in the run_info file are used by the model to determine the start (startDateTime) and end (endDateTime) of the model run. The model will pick the starting (state) value for level/storage (level has precedent in case of an inconsistency), inflow, outlet from the inputTimeSeriesFiles at the specific datetime. It will use the output variables to look for the state timeseries. The model will first check for a state level value. If a starting level value is missing in the input, the model will use the starting storage value. If both starting level/storage cannot be determined from the input files, the model will use the first level element as defined in the storage table as the starting level. A Warning message will be generated to notify the operator of this situation.

Inflow and outlet values at the starting time are not required at the first timestep and these values will not be used for storage calculations (no calculation at the first timestep). When these values are not provided as inputs, a value of 0 is assumed (and written to the output).

When no inflows into the reservoir are defined at all, the model will not calculate, but also it will not error out. It will produce and export.xml with missings (except for the initial values). When some intermediate inflow values are missing, the model will stop calculating at the point. It will not error out (and not throw a warning), it will produces an export.xml with calculated values up until the point an inflow value was missing and it will have missings for all outputs from that moment in time.

The following output timeseries file is suggested:

...

...

In case state functionality is configured in the the run_info file (inputStateDescriptionFile is defined), the model will also write (all) the outputs to the write location as defined in the stateLocation file (e.g. exportState.xml)

...