Betriebsplan/en: Unterschied zwischen den Versionen

Aus TALSIM Docs
Keine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
 
(34 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 3: Zeile 3:
{{Navigation|vorher=Systemelementsdaten|hoch=Arbeitsschritte zur Modellerstellung|nachher=Simulation}}
{{Navigation|vorher=Systemelementsdaten|hoch=Arbeitsschritte zur Modellerstellung|nachher=Simulation}}


Talsim-NG includes a [[Special:MyLanguage/Bewirtschaftungsmodell|reservoir operation model]], i.e.it offers the possibility to simulate storage regulation and distribution through defined operating rules. Existing or proposed operating rules need to be converted into a Talsim-NG compatible form.
Talsim-NG includes a [[Special:MyLanguage/Bewirtschaftungsmodell|storage operation model]], i.e.it offers the possibility to simulate storage regulation and distribution through defined operating rules. Existing or proposed operating rules need to be converted into a Talsim-NG compatible form.


The model equivalent to conducting measurements within the river basin is the retrieval of so-called [[#systemzustand|system states]] of the system elements. Further, these system states are processed and connected to mathematical and logical operators (also consecutively) into [[#zustandsgruppe|control clusters]]. The variety of options and possible connections allows for the representation of almost any desired operating rule. The system state / the control cluster representing the operating rule is linked to the system element to which the rule should be applied to. In the case of a reservoir, physical boundaries for releases as well as internal dependencies can be implemented. This results in the [[#steuerlogik|control logic]] of the river basin model.
The model equivalent to conducting measurements within the river basin is the retrieval of so-called [[#systemzustand|system states]] of the system elements. Further, these system states are processed and connected to mathematical and logical operators (also consecutively) into [[#zustandsgruppe|control clusters]]. The variety of options and possible connections allows for the representation of almost any desired operating rule. The system state / the control cluster representing the operating rule is linked to the system element to which the rule should be applied to. In the case of a storage, physical boundaries for releases as well as internal dependencies can be implemented. The result is the [[#steuerlogik|control logic]] of the river basin model.




Zeile 12: Zeile 12:
==System State==
==System State==


To determine how to represent a system state / system states, one should consider the following questions reagarding the operation rules:
To determine how to represent a system state / system states, one should consider the following questions regarding the operation rules:




Zeile 20: Zeile 20:
| Measured variable  
| Measured variable  
| Which measured variables are the operating rules based on? Which variables are measured?
| Which measured variables are the operating rules based on? Which variables are measured?
| Which is the equivalent simulated variable, or which simulated variable could be used for reference / derivation? All simulated variables i.e. the system element's input, output, and state variables are generally accessible  (e.g. discharge, reservoir volume, ...).
| Which is the equivalent simulated variable, or which simulated variable could be used for reference / derivation? All simulated variables i.e. the system element's input, output, and state variables are generally accessible  (e.g. discharge, storage volume, ...).
|rowspan="2"| Choose a system element and a simulated variable. <br/> &rarr; Implement a system state.
|rowspan="2"| Choose a system element and a simulated variable. <br/> &rarr; Implement a system state.
|-
|-
Zeile 98: Zeile 98:


A balance can be defined as
A balance can be defined as
[[Datei:Schema Definition Bilanz_EN.png|thumb|Choices to define a balance]]
[[Datei:Schema Definition Bilanz.png|thumb|Choices to define a balance]]
<ol style="list-style-type:lower-alpha">
<ol style="list-style-type:lower-alpha">
   <li>an average over the last n time steps (max. 1200)</li>
   <li>an average over the last n time steps (max. 1200)</li>
Zeile 169: Zeile 169:




If the user chooses to define constants for the implementation of the operating, it is likewise possible with the option capacity curve:
If the user chooses to define constants for the implementation of the operating rules, it is also possible with the option ''capacity curve'':


{|class=wikitable style="width: 15%
{|class=wikitable style="width: 15%
|+ Function: result= constant
|+ Function: result= constant
! X-Wert || Y-Wert
! x-value || y-value
|-
|-
| 0 || 20
| 0 || 20
Zeile 184: Zeile 184:
====Annual Pattern====
====Annual Pattern====


In the option ''annual pattern'', a function with one supporting point is defined for various time periods within a year. With a constant annual pattern, the subdivision is done by month, resulting in a total of 12 supporting points. In the case of the variable annual pattern the subdivision is made at any desired date.
With the option ''annual pattern'', a function with one supporting point is defined for each chosen time period within one year. With a constant annual pattern, the division of the year into time periods is undertaken by month, resulting in a total of 12 supporting points. With a variable annual pattern, the division of the year into time periods is undertaken at the desired dates.


For every (temporal) supporting point in the annual pattern values for x and y are declared. Is the system state bevor the transformation smaller than the x value, it is set to zero. Is it equal or bigger than the x value, it is transformed to the y value. The current date / timestamp decides which supporting point is used for the transformation.  
For each (temporal) supporting point, values for x and y are entered. If, before the transformation, the system state value is smaller than the x-value, it is set to zero. If it is equal to or bigger than the x-value, it is transformed to the y-value. Every current date / time stamp constitutes which respective supporting point is then used for the transformation.  


Default is that the supporting points are kept constant within each respective time frame. Yet, it is also possible to interpolate over time(???)
By default, the supporting points are kept constant within each time frame. Yet, it is also possible to linearly interpolate over time.




Zeile 194: Zeile 194:
====Pool-based Operating Plan====
====Pool-based Operating Plan====


With the option ''Pool-based operating plan'' the reservoir storage during a year is subdivided in different zones (pools) each pool is associated with a fixed release level. Hence any amount of increasing release levels is defined and for each defined time period the reservoir storage for each release level is given. However, the option ''Pool-based operating plan'' is not restricted to described usage. Generally, any chosen x-value (usually: reservoir storage) can be transformed time-dependent into a y-value (usually reservoir release) via a pool-based operatin plan. The y-values of the supporting points are increasing and identical for every timestep.
With the option ''pool-based operating plan'', the storage volume during a year is divided into different zones (pools), where each pool is associated with a fixed release level. Hence, for each defined release level and for each fixed time period the specific storage volumes are entered. However, the option ''pool-based operating plan'' is not restricted to this use. Generally, any chosen x-value (usually: storage volume) can be transformed into a y-value (usually: storage releases) via a pool-based operating plan. To do this, the y-values of the supporting points need to be ascending and identical for every timestep.


By default, the supporting points given by the user are interpreted as step values(?). However, it is possible to interpolate in time and / or between the supporting points of x-/y-values.<br clear="all" />
By default, the entered supporting points of the ''pool-based operating plan'' are interpreted similarly to a step function but in blocks. However, it is also possible to interpolate over time and / or interpolate linearly between the supporting points of x-/y-values.<br clear="all" />


<gallery mode="nolines" widths=600px heights=200px>
<gallery mode="nolines" widths=600px heights=200px>
Zeile 207: Zeile 207:
====Time-dependent Function====
====Time-dependent Function====


The ''time-dependent function'' is quite similar to the pool-based operating plan, yet more flexible: Among the different time periods, the supporting points of the y-values only have to correspond regaring count, but do not have to be identical in value. Furthermore, they do not necessarily have to be increasing. Hence for each time period any function with any chosen x- and y-value can be definend.
The ''time-dependent function'' acts similar to the pool-based operating plan, yet is more flexibly applicable: For different periods, the supporting points of the y-values only need to correspond regarding their number but do not have to be identical in value. Furthermore, they do not necessarily have to be ascending. Hence, one picks a user-defined function with individual x- and y-values.


By default, the supporting points given by the user are interpreted as step values(?). However, it is possible to interpolate in time and / or between the supporting points of x-/y-values.<br clear="all" />
By default, the entered supporting points are interpreted similarly to a step function, but in blocks. However, it is also possible to interpolate over time and / or interpolate linearly between the supporting points of x-/y-values.<br clear="all" />




Zeile 216: Zeile 216:
==Control Cluster==
==Control Cluster==


A control cluster is the linkage of system states and other control clusters with mathematical and logical operators. While a system state represents the condition of a system element, a control cluster can be a unified representation of several system states.  
A control cluster is the combination of system states and other control clusters using mathematical and logical operators. While a system state represents the condition of a system element, a control cluster describes the aggregation of several system states.  


The following operators are available for linkage:
The following operators are available for combination of system states:


{|class=wikitable  
{|class=wikitable  
| +/- || Addition and Subtraction
| +/- || Addition and subtraction
|-
|-
| ●/÷ || Multiplication and Division
| ●/÷ || Multiplication and division
|-
|-
|<>≤≥ || Comparative Operators
|<>≤≥ || Comparative operators
|-
|-
|mn, mx  || Minimum, Maximum
|mn, mx  || Minimum and maximum
|}
|}


A control cluster can consist of up to five different system states and/or control clusters. As control clusters can continuously be linked further there is no effective limitation regarding number. Any possible combination is feasible. There are no limitations regarding e.g. combination of different values and units. To reach a sensible combination is the obligation of the user.
A control cluster can consist of up to five different system states and/or control clusters. As control clusters can continuously be linked, there is no limit to their number, and any possible combination is feasible. There are no limits regarding e.g. the combination of different values and units. It is the user's responsibility to achieve reasonable combinations.


The system states/ control clusters from which a new control cluster is to be build can be scaled with a factor before linkage with an operator (see [[Special:MyLanguage/Verbindungsfenster|some window(?)]]).  
When building new control clusters, the comprising system states/control clusters can be scaled by a factor before using the operator for combination (see [[Special:MyLanguage/Verbindungsfenster|Connection window(?)]]).  


The control cluster itself, corresponding to the system states, has the [[#zustandsattribut-zweck|state attribute type]] and can be transformed further with a [[#transformationsfunktion|transformation function]] (see [[Special:MyLanguage/Zustandsattributefenster|state attribute something]]).
The control cluster itself, just like the system states, has a [[#zustandsattribut-zweck|system state attribute]] and can be transformed further with a [[#transformationsfunktion|transformation function]] (see [[Special:MyLanguage/Zustandsattributefenster|state attribute window]]).


Lastly the control cluster can be limited in its value range (see [[Special:MyLanguage/Verbindungsfenster|connections]]).
Lastly, the control cluster can be limited in its value range (see [[Special:MyLanguage/Verbindungsfenster|connections]]).




Zeile 243: Zeile 243:
==Control Logic==
==Control Logic==


When a rule in a control cluster/ system state is assigned in a way that it represents the desired release from a [[Special:MyLanguage/Speicherfenster|reservoir]] or the division from a [[Special:MyLanguage/Verzweigungsfenster|diversion]], the control cluster/ system state is connected with the respective system element. Dependencies among various releases can be implemented either in the definition of a control cluster or using the option [[Special:MyLanguage/Speicherfenster#Interne Abhängigkeiten|internal dependency]] from the reservoir element.
If a rule in a control cluster/ system state is assigned in a way that it represents the desired release from a [[Special:MyLanguage/Speicherfenster|storage]] or it describes the division from a [[Special:MyLanguage/Verzweigungsfenster|diversion]], the control cluster/ system state is connected to the respective system element. Dependencies between various releases can be implemented either via the definition of a control cluster or using the option [[Special:MyLanguage/Speicherfenster#Interne Abhängigkeiten|internal dependency]] from the storage element.

Aktuelle Version vom 30. August 2021, 11:16 Uhr

Sprachen:

Talsim-NG includes a storage operation model, i.e.it offers the possibility to simulate storage regulation and distribution through defined operating rules. Existing or proposed operating rules need to be converted into a Talsim-NG compatible form.

The model equivalent to conducting measurements within the river basin is the retrieval of so-called system states of the system elements. Further, these system states are processed and connected to mathematical and logical operators (also consecutively) into control clusters. The variety of options and possible connections allows for the representation of almost any desired operating rule. The system state / the control cluster representing the operating rule is linked to the system element to which the rule should be applied to. In the case of a storage, physical boundaries for releases as well as internal dependencies can be implemented. The result is the control logic of the river basin model.


System State

To determine how to represent a system state / system states, one should consider the following questions regarding the operation rules:


Subject Questions about real-world operating rule Questions about Talsim-NG river basin model Implementation in Talsim-NG
Measured variable Which measured variables are the operating rules based on? Which variables are measured? Which is the equivalent simulated variable, or which simulated variable could be used for reference / derivation? All simulated variables i.e. the system element's input, output, and state variables are generally accessible (e.g. discharge, storage volume, ...). Choose a system element and a simulated variable.
→ Implement a system state.
Spatial reference Which location is the measurement made at? Which specific system element (key) represents the measurement (with which simulated variable for the system state)?
Temporal reference What is the temporal reference of the measurement? Is the instantaneous value used, a balance, or a previous day's value? Which of the available options in Talsim-NG represents the temporal reference best? Define the objective of the system state and adjust the options for value changes respectively.
Transformation Is the measured value changed subsequently before its inclusion in the operating rule (e.g. unit conversion, weighting function, ...)? Which function in Talsim-NG represents the transformation? Select and implement the transformation function of the system state.


After answering the questions, a system state can be created. Subsequently, state attributes describing the system state can be specified. The following options are available:


Sytem State Attributes

Talsim-NG offers the following types of system state attributes:

A Current value Value is the current value without any modifications
F Function Value is transformed by applying a function
B Balance (with target) Value is used as a discrepancy from the target value in %
C Balance (without target) Value is calculated as a balance from several timesteps
Z Objective function Value is the result of an objective function
P Control gauge Currently disabled
S Sum Value is not a single value but is calculated as the sum of the system state


Current Value

The option current value uses the simulated value of the current timestep without any modifications:

result = current value of the system state


Function

The option function also uses the current timestep as time reference, but it includes the possibility to transform the value by applying a function. As the values from this option and all the following options (current value is the only exception) can be transformed, the general transformation process will only be explained in the next section.


Balance

A balance can be defined as

Choices to define a balance
  1. an average over the last n time steps (max. 1200)
  2. a fixed timeframe (start date to end date)
  3. a constant timeframe (moving average)
  4. the i-th time step

In the case of Balance (without target), the balance itself is the initial value for the subsequent transformation.

In the case of Balance (with target) the discrepancy from the target value is used as the initial value for the transformation and is calculated as follows:

Discrepancy = ((BALANCE- target value) / target value) * 100

The target value is defined as a constant possibly scaled with an annual pattern.

Sum

Value Modification

Transformation Function

The system states can be transformed additionally by applying a function (exception: current value). In the following all transformation options are listed:

KNL
Capacity curve
JGG
Constant annual pattern
GGL
Variable annual pattern
LAM
Pool-based operating plan
XYZ
Time-dependent function


Capacity Curve

The simplest option and the default for any system state that is not treated as current value is the capacity curve. The option takes previously entered supporting points to create a function, which is then used for the transformation of values. The function's entry value is corresponding to the system state's type (e.g. current value (entry value) with function (type), balance (entry value) with balance without target (type), or discrepancy (entry value) with balance with target (type)). The function can be either interpreted as a step function or interpolation between the supporting points is performed.

If the user chooses not to perform a transformation, the capacity curve can be defined as a 1:1 function. It is important that the entire value range is included because otherwise y-values smaller than the first supporting point by default use the y-value of the first supporting point and y-values bigger than the y-value of the last supporting point by default use the y-value of the last supporting point. In addition, the option to interpolate between the supporting points must be activated.

Function: entries unchanged
x-value y-value
-10000 -10000
10000 10000


If the user chooses to define constants for the implementation of the operating rules, it is also possible with the option capacity curve:

Function: result= constant
x-value y-value
0 20
1 20


Annual Pattern

With the option annual pattern, a function with one supporting point is defined for each chosen time period within one year. With a constant annual pattern, the division of the year into time periods is undertaken by month, resulting in a total of 12 supporting points. With a variable annual pattern, the division of the year into time periods is undertaken at the desired dates.

For each (temporal) supporting point, values for x and y are entered. If, before the transformation, the system state value is smaller than the x-value, it is set to zero. If it is equal to or bigger than the x-value, it is transformed to the y-value. Every current date / time stamp constitutes which respective supporting point is then used for the transformation.

By default, the supporting points are kept constant within each time frame. Yet, it is also possible to linearly interpolate over time.


Pool-based Operating Plan

With the option pool-based operating plan, the storage volume during a year is divided into different zones (pools), where each pool is associated with a fixed release level. Hence, for each defined release level and for each fixed time period the specific storage volumes are entered. However, the option pool-based operating plan is not restricted to this use. Generally, any chosen x-value (usually: storage volume) can be transformed into a y-value (usually: storage releases) via a pool-based operating plan. To do this, the y-values of the supporting points need to be ascending and identical for every timestep.

By default, the entered supporting points of the pool-based operating plan are interpreted similarly to a step function but in blocks. However, it is also possible to interpolate over time and / or interpolate linearly between the supporting points of x-/y-values.


Time-dependent Function

The time-dependent function acts similar to the pool-based operating plan, yet is more flexibly applicable: For different periods, the supporting points of the y-values only need to correspond regarding their number but do not have to be identical in value. Furthermore, they do not necessarily have to be ascending. Hence, one picks a user-defined function with individual x- and y-values.

By default, the entered supporting points are interpreted similarly to a step function, but in blocks. However, it is also possible to interpolate over time and / or interpolate linearly between the supporting points of x-/y-values.


Control Cluster

A control cluster is the combination of system states and other control clusters using mathematical and logical operators. While a system state represents the condition of a system element, a control cluster describes the aggregation of several system states.

The following operators are available for combination of system states:

+/- Addition and subtraction
●/÷ Multiplication and division
<>≤≥ Comparative operators
mn, mx Minimum and maximum

A control cluster can consist of up to five different system states and/or control clusters. As control clusters can continuously be linked, there is no limit to their number, and any possible combination is feasible. There are no limits regarding e.g. the combination of different values and units. It is the user's responsibility to achieve reasonable combinations.

When building new control clusters, the comprising system states/control clusters can be scaled by a factor before using the operator for combination (see Connection window(?)).

The control cluster itself, just like the system states, has a system state attribute and can be transformed further with a transformation function (see state attribute window).

Lastly, the control cluster can be limited in its value range (see connections).


Control Logic

If a rule in a control cluster/ system state is assigned in a way that it represents the desired release from a storage or it describes the division from a diversion, the control cluster/ system state is connected to the respective system element. Dependencies between various releases can be implemented either via the definition of a control cluster or using the option internal dependency from the storage element.