...
Time since Last Successful Spell: Time step counter that starts after any successful spell in the season. If spell extension is enabled, the counter will be set to zero when the spells minimum duration has been reached and remains zero until the spell extension is finished. It counts from the end of the spell not including fall phase
Volume Ordered: This is the volume ordered by the environmental flow node on top of the downstream order. When the upstream minimum constraint is larger than the full requirement, no order will be placed. This is the default volume that will be debited from the account(s).
Volume ordered is constrained by the account balance (if the EFN is managed by the EFM), whereas Residual Requirement is not. The volume is calculated at the order phase. Volume ordered will be deducted during ordering phase for order debit or during flow phase for use debit. For order debit it will debit the order at min travel time.[WL1]
Spell Extension: Recorder flags days when spell was extended
Successful time steps in current spell: During a spell, this counter keeps track of the number of time steps that had a flow rate within the specified proportion of target flow required to mark success. This recorder is reset at the end of the spell For example if the target flow is 10,000 ML/d and an 80% proportion was specified as required for success (see success criteria), then all days with flow >= 8,000ML/d are counted as successful days.
Time in current spell: This is a time step recorder, counting the number of time steps the spell has been underway. This is used in combination with the ‘Successful time steps in current spell’ to determine success against the duration criterion.
Time since Last Successful Season: Time step counter that starts after the last successful spell in a successful season. It counts from the end of the spell not including fall phase
Time since Last Successful Spell: Time step counter that starts after any successful spell in the season. It counts from the end of the spell not including fall phase
Timesteps Spell is Actively Ordering: The number of timesteps a spell will attempt to place orders. This gets reset after the spells fall phase. This is used in environmental flow manager functions to determine if an action is currently ordering.
Volume Ordered : This is the volume of the order that was actually put into the system. The difference between Volume Ordered and Residual Requirement is that Volume Ordered is constrained by account balance, while Residual Requirement is not. The sum of all action's Volume Ordered recorders is the amount that node has ordered that time step.
Translucency Action
Recorders available for translucency actions are listed below. If they are defined as above no further explanation is given.
Antecedent Condition: Not used for this action. This recorder will always return 0 By default, the antecedent condition for a translucency rule will be zero. As translucency actions do not have a return interval, the action will always be required.
Full Requirement: The The required flow for an action. (i.e. Translucency percentage x The product of Translucency Percentage and Translucency reference flow when in an event).
Residual Requirement: This recorder is only non-zero when is the order the environmental flow node is used with a flow manager. The residual requirement is the amount this action will have to try to orderhas to place on top of the downstream order in order to reach the full requirement. The full requirement is reduced based on downstream orders, minimum upstream constraints and other actions at this node that are a higher priority. This value of higher priority. When the upstream minimum constraint is larger than the full requirement, no order will be placed by the flow node (i.e. the residual requirement would be zero). Requirement is calculated at the order phase. The Residual Requirement is not restricted by account balances.
Time since Last Succesful Successful Event: Time step Timestep counter that starts after a successful event. An event is considered successful if, once triggered, at least Translucency percentage x Translucency reference flow the Full Requirement is received every time step timestep until the end threshold is met End Threshold is met.
Note: if a translucency action is defined by a function Time Since Last Successful Event may become complicated. For example, using the function “if($Now.Month=1,1000,0)”, a reference flow of 1000 ML/d will be ordered in January. When a flow of 1000 ML/d is not achieved in January, the Time Since Last Successful Event recorder will begin counting, until 1000 ML/d is achieved again. However, a reference flow of zero will be required for Feb-Dec. The timesteps in these months will still be considered successful regardless of the flow, as it is always achieving what the function has defined (i.e. at least 0 ML/d) and Time Since Last Successful Event will be set to zero.
Volume Ordered: This is the volume ordered by the environmental flow node on top of the order that was actually put into the system. The difference between Volume Ordered and Residual Requirement is that Volume Ordered is constrained by account balance, while downstream order. When the upstream minimum constraint is larger than the full requirement, no order will be placed. This is the default volume that will be debited from the account(s).
Volume ordered in constrained by the account balance (whereas Residual Requirement is not). The sum of all action's Volume Ordered recorders is the amount that node has ordered that time step.
...
volume is calculated at the order phase. Volume ordered will be deducted during ordering phase for order debit or during flow phase for use debit. For order debit it will debit the order at min travel time.
Environmental Flow Manager
Groups
Under ‘Groups’ > Group Name > ‘Actions’ > Action Name:
Enabled[IT1] : Recorder indicates when the Environmental Flow Manager has enabled an event.
Priority:[IT2] Recorder showing the priority of the action. The priority of an action is determined given condition and importance,as per the equation below.
Priority is used as a ranking, i.e. the action with lowest priority will be considered first.
Under ‘Groups’ > Group Name:
Estimated Cost: The estimated cost for the group. The cost of an action is specified by the user (and in case a function is used, the result for the function can be recorded). The cost of the group is the total of cost for all action within the group.
Priority: Recorder to show the priority of the group. Group priority is set to lowest priority ranking for any of the actions within the group (i.e. action with highest priority).
Under ‘Groups’:
Manager Priority: The Manager Priority is table presenting relevant information about the prioritisation process for every timestep. The user can select a date, or use the scroll bar or arrow buttons to step through the timeseries.
For the selected date, the table presents for each Group, whether it was Enabled, whether it was Actively Ordering, the Group’s Priority, Prioritised Order and Estimated Cost and Total Portfolio Balance.
The table also presents per Portfolio, Initial Balance (excluding adjustment), Initial Balance (including adjustment), Final Balance (including adjustment), and Total Adjustment.
Portfolios
Under ‘Portfolios’ > Portfolio Name:
Account Balance After Prioritisation: The balance of the portfolio after each group has been prioritised. This will have the account balance at the end of the resource assessment phase minus the estimated cost of each enabled group (these costs are distributed as specified in the group's portfolio priority/share properties). This value includes any balance adjustment values.
Account Balance including adjustment: The portfolio account balance after resource assessment phase including any balance adjustment values.
Total Balance Adjustment: The sum of all account balance adjustments.
[IT1]Not sure why this is reported for the actions, as the EMF enables group (not individual actions)
[IT2]This should be the priority for the action – but currently it seems to be set to the group priority… Could this be checked and reported?
Manager Priority: A recorder that contains a snapshot of the priorisation process every timestep. It contains the groups priority, estimate cost, total portfolio balance as it was when that group was prioritised. This means that a groups priority in this recorder and the estimate cost recorder may give different values since the estimate cost recorder contains the value at the end of the priorisation process. The table also includes portfolio balances before and after prioritisation.
...