Versions Compared

Old Version 42

changes.mady.by.user Jin Wang

Saved on

compared with

New Version 43

changes.mady.by.user Jin Wang

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Translucency Action

The logic around decisions to create demand associated with a translucency action is as follows

  1. Are we in the specified season?
  2. Are we in event?

The action is 'in event' if Reference flow > Start threshold 

Any time the reference flow < end threshold, the event is ended. 

Target flow is reference flow * % translucency.

Where:
reference flow = the flow defined by a function (such as reservoir inflow) 
Water demand(t) = min(Target flow - ForecastFlow(t), available water)

Note. Where a Translucency action uses planned forcing environmental water rather than held environmental water, the action should not be associated with a flow manager.

Translucency Reference Flow 

A translucency reference flow is often used to represent an inflow to a storage. The translucency action is configured below the storage, too allow for flow patterns to be replicated downstream. The assumption is that the reference flow is occurring at the closest storage (ie minimum travel time).  

Evaluate success and condition for translucency action events

Success is defined by the total volume delivered over the demand period (based on required flow duration and rate) and is expressed as a percentage.Translucency action success is fixed at 100% for every time step, and over the event 100% of timesteps much be succesful. This sets the time since last succesfull event For example, if the threshold is set at 80%,andeventthatdelivered80% success or more is flagged as successful. This allows for flexibility in the definition of success. Success will be calculated as the model runs and days since last success will be recorded for use in the calculation of condition.

The user can specify a condition function, but by default, the days since last success divided by the desired return interval will be used as a measure of condition. 

Life cycle of a spell

There are 9 states a spell can be in:

  1. Dormant
  2. Waiting for trigger
  3. Rise Phase
  4. Main spell phase
  5. Finished ordering
  6. Fall phase
  7. Complete
  8. Interrupted
  9. PlannedForcing

Every spell starts in the dormant state and transitions through various states during the course of a season. The transitions occur either in the constraint, ordering or flow phase of the environmental flow node. Each phase and its effect on state is described in more detail below.

Dormant

Each spell starts in the dormant state. At the beginning of each start of the season, the node creates the number of spells equal to the user set Number of spells in season property. These spells are put in a queue.
Constraint Phase
The node will check the current spell, if it is empty, the spell on the top of the queue is removed as designated as the current spell. The spell will then transition from Dormant to Waiting for a trigger and run the Waiting for trigger constraint phase (and future phases).
Ordering Phase
In this state, nothing is done during the ordering phase
Flow Phase
In this state, nothing is done during the flow phase.

Waiting for trigger

When a spell is in the Waiting for trigger phase, it is waiting for the user-defined start threshold to be met. It should be noted that a spell only considers constraints and orders external to the node for triggering. This means that spells cannot be triggered by other spells within the node.

Constraint Phase
If the minimum interval between planned forced spells is non zero, the node will check the number of timesteps between now and the last successful spell. If this value is less than the minimum interval value, nothing will be done even if the threshold is met.
The spell will check if the minimum upstream constraint is greater than the spell start threshold for this timestep (since it can be a function). If this condition is met, the spell will transition to the Rise Phase and run the Rise phase's ordering phase (and future phases).
If there is not enough time in a season to complete this spell (minimum spell duration + now > end of the season), then the spell transitions to the Interrupted state. Since this is checked on spells before they reach any further states, spells will never run out of time in a season once they are in a state later than the Rise Phase.
Ordering Phase
If the minimum interval between planned forced spells is non zero, the node will check the number of timesteps between now and the last successful spell. If the difference between these times is greater than the rise time duration (see below), nothingwill be done even if the threshold is met.
The spell will check if downstream orders are greater than the spell start threshold for this timestep (since it can be a function). If this condition is met, the spell will transition to the Rise phase and run the Rise phase's ordering phase (and future phases).
Flow Phase
In this state, nothing is done during the flow phase. If a spell is in this state during the flow phase, it means that the threshold has not been met. If it has been met, the spell will be in a different state at this point in time.

Rise Phase

During the rise phase, orders are placed to try to transition between the current flow at the node and the target volume. If there is not rise defined, then the spell will transition into the main spell phase.

Regardless of what rise method is used, a rise phase can be broken down into how many timesteps are required, and what volume is required to order. The spell will transition to the Main Spell Phase once this spell has been in this state for the calculated number of timesteps. It does not matter if the rise phase orders are successful or not.

Constraint Phase
If the remaining timesteps required for the rise phase is zero, the spell will transition to Main Spell Phase and run the Constraint Phase.
Otherwise, a demand value is calculated based on upstream constraints.

Ordering Phase
A demand value for the rise phase is calculated based on the downstream orders.
Flow Phase
In this state, nothing is done during the flow phase.


Main Spell Phase

During this phase, demands are calculated to be equal to the target value. Demand values will be generated for at least the minimum spell duration.  If the extend spell option is used, demands will continue to be placed until the value evaluates to false.

Constraint Phase
The demand during the constraint phase will be set to the target flow for timestep.
Ordering Phase
The demand during the ordering phase will be set to the target flow for this timestep.
Flow Phase
During the flow phase, the received flows are compared to the demands.
If the End Spell if it will fail option is enabled and a spell is not considered successful (see section on success for how this is calculated), the spell will transition to the Complete state.
If all orders for this spell have been placed, the spell will transition into the Finished Ordering Spell Phase and continue its flow phase. The Spell is considered
If the spell has been in the main spell phase for at least the minimum duration, spell success is checked. This means that success includes timesteps outside of minimum spell duration (e.g. due to end thresholds not being met or extend spell duration flag).

Finished Ordering Spell

During this phase, all demands have been made, the node is just waiting to receive them (due to travel time). Once they are received, a spell in this state will

Constraint Phase
No further demands are required so this phase will do nothing.
Ordering Phase
No further demands are required so this phase will do nothing
Flow Phase
In this phase, spell success is checked against the received water as per Main Spell Phase.
Once all demands have been received (successfully or unsuccessfully), the spell will begin checking the received flows for end threshold.
End threshold is met when the received flow at the node is less than the End Threshold value for Duration required below threshold timesteps. If this condition is met, the spell moves into Fall Phase state.

Fall Phase

The fall phase operates in a similar way to the rise phase. Demands will be calculated

Constraint Phase
The fall demand is calculated based on upstream constraints and the target flow of the last timestep in the main spell phase. See the rise and fall section for more details.
The first timestep the spell is in this phase, a fall duration is calculated. This is used in the fall phase to count how many timesteps the spell has been in the fall phase
before finishing the spell.
Ordering Phase
The fall demand is calculated based on downstream orders and the target flow of the last timestep in the main spell phase. See the rise and fall section for more details.
Flow Phase
The spell checks how many timesteps it has been in this phase, compared to the number of timesteps required in the fall phase (calculated in the Constraint Phase). Once this condition is met, the spell transitions to the Completed State.

Completed

This is an end state for the spell. If a node sees it's current spell is in this state, it will get the next spell out of the queue.

Interrupted

This is an end state for the spell. If a node sees it's current spell is in this state, it will get the next spell out of the queue.
Planned

Forcing

This state is used to immediately move a spell into the Waiting for Trigger state. This will only get used if Allow forcing of spells is on and the number of seasons that have failed is greater or equal to the user specified number of season failures before forcing. These spells will be added at the latest possible timestep that will allow all spells to successfully complete.

Ordering

Without a flow manager:

The order placed in the system without a flow manager depends on min upstream constraint or downstream orders.

If the minimum constraint is greater than the action with the maximum demand then the order placed in the system will be zero.

Otherwise, the order will be the maximum demand minus the downstream order.

With a flow manager:

The order placed in the system with a flow manager depends on min upstream constraint or downstream orders and other actions at the node with a higher priority (specified in the flow manager).

If the minimum constraint is greater than the action with the maximum demand then the order placed in the system will be zero.

Otherwise, the order will be the maximum demand minus the downstream order and the order of any other action with a higher priority.

This ensures that actions in higher priority groups will debit their accounts before lower priority actions and that the total order does not exceed the action with the largest demand.

Input Data

Refer to the Source User Guide for detailed data requirements and formats.

Output data

The model outputs daily surface and base flow. This may be saved in ML/d, m3/s or mm/d. See environmental flow recorders for r\descriptions