Initialize Flow Slots for Routing
This category contains methods that are used to initialize slots that are required to be known for routing to solve at the start timestep. It sets values in these slots at presimulation timesteps according to the selected method. There are three methods: the default, no-action None, Backcast Zeros and Backcast Initial Value. No slots are added by any of these methods.
The methods are executed at the beginning of run. When either the Backcast Zeros and Backcast Initial Value are executed, an internal helper method is called that does the work. There are four parts to this helper method:
2. Resize the slots, if necessary, to include the earliest dispatch timestep.
4. Set values on slots, as required.
Method Details
Following is a detailed description of the four parts of the method.
1. Loop through the Computational Subbasin’s objects to identify slots of interest
The helper method considers each simulation object belonging to the Computational Subbasin and creates a list of slots that are required for initialization
The following slots are added if they are not linked to an upstream object; that is, they are the headwater in the basin.
Note: The slots consider their linking status to determine if they are headwater object. However, linking the slot to a DataObject, though not truly an upstream object, will cause the slot to be left off the list.
– Aggregate Reach.Inflow
– Confluence.Inflow1
– Confluence.Inflow2
– Control Point.Inflow
– Gage.Inflow
– Inline Power Plant.Inflow
– Reach Inflow
The following slots are added if the slot is linked. In the code, the slot at the downstream end of the link is added to the list of slots. Since the two slots are linked, values will propagate.
– Inline Pump.Outflow
– Pipeline.Outflow
– Reservoir.Outflow
– Reservoir.Seepage (when instantiated)
– Reach.Outflow when Kinematic, Kinematic Improved, or Muskingum routing is used. Reaches using these routing methods only dispatch during the run range. They also require input values on the initial timestep. As a result, they are considered boundary conditions for the computational subbasin method.
The following slots are added based on the specified conditions
– Reach.Diversion: added to the list if it is in use (that is, instantiated by method selection) and linked.
– Reach.Return Flow: added to the list if it is in use and linked.
– Reach.Local Inflow: added to the list if it is in use.
Diagnostics for this specific process exist under Dispatch Management, Object.
2. Resize the slots
For each of the slots of interest, the helper method resizes the slots, as necessary, to include the first possible dispatch timestep. The first possible dispatch timestep is unique for each object and is determined as follows:
– Look for the earliest input on the current object and any linked upstream objects. See Initialization in Solution Approaches for more information on this algorithm.
– For objects that are a part of a subbasin with either the Backcast Zeros or Backcast Initial Value method selected, the method will look downstream at each Reach object and sum the required number of routing timesteps. For each downstream Reach, the required number of presimulation timesteps is as follows:
• No Routing 0 timesteps
• Time Lag or Variable Step Response: lag rounded up to the next timestep. (that is, 36hr lag in a model with a 1 Day timestep means 48 hrs = 2 days or 2 presimulation timesteps are required)
• Kinematic, Kinematic Improved, or Muskingum: No error is issued, but no presimulation timesteps are added. See below.
If a Reach does not have one of these routing methods selected, an error will be issued and the run will stop. The search is stopped when:
• An object that does not dispatch before the start of the run is met, such as a reservoir or a reach using Kinematic, Kinematic Improved, or Muskingum routing.
• the downstream most point in the basin is found.
The earliest timestep found by this algorithm is the first dispatch timestep for that object.
Note: This search algorithm is only valid for certain objects. The following objects will return an error if included in the subbasin as they have multiple outflows:
• Bifurcation
• Pipe Junction
Objects not typically on the main channel will not work in the search algorithm.
3. Determine the value to set
The helper method determines the value to use for initialization based on the selected method as described for either the Backcast Zeros or Backcast Initial Value method.
4. Set values on slots
Based on the slot of interest and given the earliest dispatch timestep and an initialization value, a fairly simple algorithm is used to set those values on the slot. For each timestep between the earliest dispatch timestep and the initial timestep (inclusive), if the value on the slot is not valid, it is set to the initialization value. As always, these method will not overwrite any inputs that exist on the slot.
Note: When initializing Reservoir.Seepage, if the Single Seepage Value method is selected on the reservoir, at the beginning of the run, the Seepage is set equal to the Single Seepage Value if the initial Seepage is not input. Then when the Backcast Initial Value method executes, it will have an initial value that it will then back-cast, no further inputs are required. If the user wants to Backcast Zeros, they will need to input a 0 on the initial Seepage, otherwise the scalar value will be used for the initial timestep and zeros for all other presimulation timesteps. As always, inputs will not be overwritten by these methods.
NoneThis is the default, no-action method. This should be selected when the user wants to explicitly input required initialization values directly onto the flow slots.
Backcast Zeros The flow value 0.0 is used to initialize all required presimulation values. This should be selected when the user does not want to input a value for the initial timestep and / or a flow of 0.0 is acceptable for initialization.
Backcast Initial ValueThe earliest known presimulation value from the slot is used for initialization. The algorithm begins with the initial timestep and works backwards towards the earliest dispatch timestep. It finds the earliest valid value before encountering an invalid (NaN) value. The found value is returned for initialization. If no invalid value is found, the value at the earliest dispatch timestep is returned (although it will have no effect). If the value at the initial timestep is invalid, a fatal error is issued.
Revised: 01/05/2024