Before implementing the various USACE‑SWD policies, it is necessary to build and calibrate a model of the physical river basin network. This involves selecting objects and linking them together to accurately represent the physical features of the river basin. In addition, user methods are selected to model various physical processes (i.e. spill, evaporation, seepage, routing, etc.) depending on the level of modeling detail required.

Initially, the model should be run in Simulation mode. In Simulation, RiverWare solves an exactly determined system given a set of user inputs. No rules or policy constraints are involved in the solution. Each object performs a mass balance calculation and solves any user selected methods. The purpose of the simulation model is to ensure that the physical features of the basin are correctly modeled. In this stage of model development, the modeler checks input data for accuracy, checks for proper mass balance and routing, and calibrates the model. Only after the physical model has been calibrated, should the modeler begin implementing policy through the use of rules.

Following is a very general description of the steps involved in building a simulation model. These steps should be performed in order with the exception of Step 5., and Step 6. which are interchangeable. Each step is discussed in greater detail below.

See “Selecting the Controller and Setting Run Times” in Model Building Quick Start for details.

Before adding objects to the workspace, the user should select the model timestep and specify the start and end dates of the run. This is done through the Run Control dialog.

Set the number of timestep after the run for which dispatching should be allowed. Typically you can set this equal to the forecast period. See “Post-run Dispatching” for instructions.

The first step when setting up a model is specifying the display units for objects taken from the palette. The internal units in RiverWare are SI units but you can define the display units, scale, precision and format by setting up a Unit Scheme. In the Unit Scheme you configure these four attributes for each unit type. Then you can define exceptions to the general rule. That is, for a specific slot you may want to show the values in some other display unit. See “Unit Schemes” in User Interface for details.

Build the model network with appropriate selection of objects from the RiverWare object palette. Include control point objects at the desired locations.

On each object, select methods to model various physical processes (i.e. spill, evaporation, seepage, routing, etc.) depending on the level of modeling detail required. See “Reservoir Objects” for details on these methods for the basic simulation model.

Slots on objects should be linked to form the network representing the basin. For example, Reservoir Outflow should be linked to the downstream control point or reach’s Inflow slot.

Supply the required data to the objects. There are two types of data, table or parameter data and mass balance data.

Once all objects have been configured (method selection and input data) and have been linked together, the model is ready for simulation. When the model is run, it should compute the inflow forecasts, mass balance the reservoir objects, and properly route releases downstream. The purpose of these simulations is to ensure that the modeling of the physical system has been done correctly. During this stage the model should be calibrated if necessary. Any error messages or data problems need to be resolved before moving to policy modeling. Since the inflows, uncontrolled area flows, and storage or pool elevation values have been input, each reservoir should mass balance correctly to solve for outflow. These outflows should also be routed downstream. The modeler can also input reservoir outflows and check the resulting storages and pool elevations. The resulting values computed by RiverWare should be checked against known values for accuracy. See “Modeling Unregulated Conditions” for details on viewing and analyzing results.

When selecting a reservoir object to represent a reservoir/dam that has power production capabilities, it is best to select a power reservoir object even if the model will not be used for modeling power initially. It is easy to enable and disable power modeling on a power reservoir object but it is not as easy to change from a storage reservoir to a power reservoir after the model has already been completed.

Input the relationship between pool elevation and storage in the Elevation Volume Table slot. Also, for every reservoir, an initial Pool Elevation or Storage is required.

On storage reservoirs, input the pool elevation versus release information in the Max Release slot (For level power reservoirs, similar data will be entered based on the selected power method as described in the next section).

For level power reservoirs, the user must select a method in the Power Calculation category regardless of whether or not the object will be used for power calculation. If the object will not initially be used to compute power, select the No Power Turbine Flow method. When this method is selected the Max Flow Through Turbines slot will be added and should be populated with the relationship between pool elevation and the maximum outflow through the turbines. However, no power calculations will take place. If the user does wish to model power, he/she should select the appropriate power calculation method. At this stage any of the methods can be used, but if releases are to be made using the HydropowerRelease function (see “Hydropower”), then the Peak Power Equation with Off Peak Spill method should be selected. See “Peak Power Equation with Off Peak Spill” in Objects and Methods for details on the required data.

When a power method is selected, a tailwater method must also be selected. See “Tailwater” in Objects and Methods for details on the available methods.

When setting up the tailwater method, there are some important aspects to remember. The Tailwater Base Value is a series slot that is used to link to a downstream reservoir’s Pool Elevation. If the Tailwater Base Value is not linked to a downstream reservoir, it is best to leave NaNs in the Tailwater Base Value and have the Tailwater Table include all of the data necessary to calculate the correct tailwater.

This section describes how SUPER tailwater data can be input into the Tailwater Table to mimic SUPER’s functionality. In SUPER, there is a variable called the Block Loading Tailwater Elevation (BLTE). This is defined as the tailwater that results when releasing Turbine Capacity with the reservoir at the top of the power pool with no other releases. In this description, this is called the “Turbine Capacity at Top of Power Pool.”

The Tailwater Table can be input such that the look up flow will result in the correct tailwater elevation. The table will be as follows: If the flow is less than or equal to the Turbine Capacity at Top of Power Pool, then the tailwater is a constant value equal to the BLTE. If the flow is greater than the turbine capacity at top of power pool, then the value is from the right portion of the curve. See Figure 2.1. Based on sample input data, only the right portion of the curve is currently input into SUPER. This method will allow the USACE‑SWD to first input the table to mimic the SUPER methodology but in the future, the full table can be input.

In RiverWare, a spill is a portion of the outflow that does not go through the turbines (on a power reservoir) or through the main release works (on a storage reservoir). Spills can be controlled (Regulated Spill and Bypass) or uncontrolled (Unregulated Spill).

The spill calculation category is used to model various spillway structures and configurations. Select a spill method only if the model will differentiate between spillway outflow and outflow through the release gates. If a single curve is used to represent total reservoir outflow as a function of pool elevation, then no spill method is necessary. On a storage reservoir the flow vs. pool elevation data is held in the Max Release slot while on power reservoirs it is held in the power method specific slot. If uncontrolled spillways or additional controlled release structures need to be modeled, select the appropriate spill method. If a spill method is selected, enter flow vs. pool elevation data for the various release and spill structures modeled. See “Spill” in Objects and Methods for details on the spill methods.

If a spill method is selected, input the pool elevation vs. spill information on the appropriate slots. For USACE‑SWD applications, the “Drift” slots are not used and can remain empty.

Previously, the USACE‑SWD used a single relationship to define the maximum outflow as a function of pool elevation. This relationship is called the free flow rating curve. The free flow rating curve includes outflow through the turbines, regulated spillways, and unregulated spillways. Normally, the proper spill method would be selected to model each of these outflow structures separately. The data in the free flow rating curve would then need to be disaggregated for each outflow structure modeled. Originally, the USACE‑SWD decided not to model each outflow structure separately and wanted to leave the free flow rating curve intact (as opposed to disaggregating the information). Therefore, they did not select a spill method and instead input the free flow rating curve (maximum total outflow vs. pool elevation) in the Max Release slot on storage reservoirs and in the Max Flow Through Turbines slot on power reservoirs. RiverWare will solve normally when configured in this fashion. Instead of using spillways and regulated spill structures, all outflow is sent through the Release slot (on storage reservoirs) or the Turbine Release slot (on power reservoirs). While this will not affect the reservoir calculations, it is misleading because the Turbine Release and Release slots will show outflow for both the release and spill structures. This would not work if the reservoir is being used to compute power. In that case, a spill method should be selected. The sum of the turbine release capacity and spill capacities should equal the free flow rating curve.

If more than one spillway or release structure is being modeled on a given reservoir, RiverWare sends the reservoir outflow through these structures in a specific order. If there is an uncontrolled spillway, the spill over that structure is computed based on the average pool elevation over the timestep. Any remaining outflow is then sent through the turbines, if it is a power reservoir, or through the Release slot if it is a storage reservoir (the maximum release information is held in the Max Release slot). If there is any remaining outflow, it is sent through the Regulated Spill slot or the Bypass spill slot depending on the spill method selected. In general, RiverWare assumes that all outflow should go through the turbines (or the Release slot on storage reservoirs) and any excess is sent through the regulated spill structures.

There are many slots on the reservoirs that can represent sources and sinks to the mass balance. This section describes the recommended structure for the inflows to the reservoir.

The Inflow slot represents the inflow to the reservoir from upstream (routed flows from upstream, not uncontrolled area flows). Therefore, the Inflow slot on all reservoirs should be linked to the Outflow slot of the upstream object unless the reservoir is a headwater reservoir. If it is a headwater reservoir, a flow rate of zero should be input for all timesteps (including values through the last dispatch timestep) in the Inflow slot (the reservoir will still receive inflow from the Hydrologic Inflow Forecast slot).

Since the inflow to each reservoir will be known (either propagated from an upstream object or input to zero), one other piece of data must be input for each timestep to allow the reservoir to mass balance. An initial value for either storage or pool elevation must be input and then values must be input at each timestep for either pool elevation, storage or outflow. For testing purposes, and to ensure proper mass balancing, various combinations of inflow, outflow, storage and pool elevations can be input and evaluated.

The reservoir objects (and control points) are used to bring uncontrolled area flows into the system. The USACE‑SWD data for uncontrolled area flows is the cumulative, uncontrolled area flow from the upstream reservoir to the control point, adjusted for routing. As a result, it cannot be input directly into the Local Inflow slot or the flows would be multiply counted. Also, the uncontrolled flows must be forecasted to provide an estimate throughout the forecast period. Specific methods must be selected to deal with these two unique features. See “Forecasting Incremental Local Inflows From Cumulative Flows” for details.

Seepage through the face of the dam is modeled by selecting the Input Seepage of Single Seepage Value method in the Seepage category. These methods allows the user to input a timeseries of seepage values or a constant value. The Reservoir.Seepage slot should then be linked to the downstream object’s Local Inflow slot. Figure 2.2 shows the correct linking structure.

There are several other user method categories available on the reservoir that are not discussed in this document. Decide what additional physical processes need to be modeled (if any) and then select the appropriate methods and input the appropriate data. Possibilities include evaporation and precipitation, or bank storage. See “User Methods” in Objects and Methods for details on the methods and associated slots.

The Reach object is used to route water through the network. Also, water diversions from the river must come out of the Reach object. The Inflow slot should be linked upstream and the Outflow slot should be linked downstream. See “User Methods” in Objects and Methods for details about user methods not discussed here.

The Step Response routing method is typically used by the USACE‑SWD; see “Step Response” in Objects and Methods for details. This is the same routing algorithm used in the FloodControl predefined function in RiverWare. If the user selects a different routing method, then the final releases will be routed with a different method than that used in the algorithm to determine the flood control releases.

If the Step Response method is selected, input the number of routing coefficients in the Num of Coeff slot on the reach object. The routing coefficients are input in the Lag Coeff slot. These coefficients are the INCREMENTAL routing coefficients that apply to that reach specifically (as opposed to the direct routing coefficients used on the control points for the computation of flood control releases).

Sometimes, the routing coefficients are not fixed, but are dependent on the flow in the reach, particularly during high flow events. In this situation, the Variable Step Response routing method should be used; see “Variable Step Response” in Objects and Methods for details. See “Alternative Routing Coefficients Methods” for details.

On any reach in the model that does not have routing (i.e. the No Routing method is selected), the user should select the No Local Inflow, Solve Outflow method in the Local Inflow and Solution Direction category; see “No Local Inflow, Solve Outflow” in Objects and Methods for details. This method forces the reach to always solve in the downstream direction. This eliminates the possibility of unintentional upstream solving as a result of complicated rule priorities.

In certain basins, the USACE‑SWD simulates the loss of water released from a reservoir to meet downstream demands. In the GainLoss category, the Base Plus Fractional Loss method models loss to meet all the following criteria. See “Base Plus Fractional Loss” in Objects and Methods for details.

In addition, the base loss and fraction above that base can be entered seasonally for future extensibility. Select this method or another method in this category to model transit losses.

The confluence object brings together flows from two objects. Select the Solve Downstream Only method in the Confluence Solution Direction category; see “Solve Downstream Only” in Objects and Methods for details. This method forces the confluence to always solve in the downstream direction. This eliminates the possibility of unintentional upstream solving as a result of complicated rule priorities.

The control point models a location on a river where certain flow requirements (maximum and minimums) must be maintained. The control points are used for flood control operations such that the flood control releases do not cause an exceedence of channel capacity at these points. They also represent the location for low-flow demands and additions of uncontrolled local flows.

Control points (and reservoirs) are used to bring uncontrolled area flows into the system. The USACE‑SWD data for uncontrolled area flows is the cumulative, uncontrolled area flow from the upstream reservoir to the control point, adjusted for routing. As a result, it cannot be input directly into the Local Inflow slot or the flows would be multiply counted. Also, the uncontrolled flows must be forecasted to provide an estimate throughout the forecast period. Specific methods must be selected to deal with these two unique aspects. See “Forecasting Incremental Local Inflows From Cumulative Flows” for details.

Control Points located at the outflow of a reservoir (or those that don’t have local inflows) should not use these methods; they should keep the None method selected in the Local Inflow category.

The water user diverts water from either a reach or reservoir, uses a certain amount, and returns the rest. The USACE‑SWD uses Water User objects to simulate reservoir and reach diversions in their models. In the simulation/calibration model, the user should only configure water users to make direct from reach diversions. Any diversions from the reservoirs should be input directly on the reservoir’s Diversion slot. When the policies are implemented to determine the reservoir diversions, there are additional methods and linking structure that must be created. See “Reservoir Diversions” for details.

Typically, some water users remove water from the system but do not return any water. Other Water Users are used to divert from one reservoir or reach and pump it into other reservoirs. These Water Users return all the diverted flow to the other reservoir. On each water user, the user should select the Fraction Return Flow method in the Return Flow category. Then, in the Fraction Return Flow Input category select one of the following:

Data objects are useful for storing data that is not directly applicable to a simulation object. For example, a data object can be used to hold system data. Custom slots can be created on data objects or on simulation objects. For example. custom slots can be created on the reservoir to hold historical reservoir data for easy comparison with the RiverWare results. Also, custom expression slots and statistical table slots can be used for post processing and analysis of the data. See “Objects and Methods” in Objects and Methods for details on data objects See “Statistical Slots and Probability Plots” for details on USACE‑SWD analysis tools.

In USACE‑SWD basins, streamflow data represents the cumulative inflow to the river up to that point. These cumulative inflows cannot be routed downstream in RiverWare since the next downstream Control Point also has cumulative inflows. However, routing inflows in RiverWare is useful so that diversions can be made from Reaches and so that the Reaches will be routing the correct flows. In order to address this problem, methods were developed to use the cumulative inflows at Control Points and Reservoirs, and calculate the Incremental Flows. The methods calculate the forecasted incremental local inflows at each control point and reservoir within a subbasin given the cumulative local inflows. These methods are described in this section and in the objects specific help.

Users will first need to set up a computational subbasin for each group of control points and reservoirs that contain cumulative local inflow data. The computational subbasin(s) must include all control points and reservoirs which contain the cumulative local inflow data as well as all the intervening reaches and confluences. Each control point and reach should only be included in one reservoir's subbasin. For example, in Figure 2.3, there is a subbasin that contains Clayton, Clayton_Antlers, Antlers, Antlers_Diver_Reach, Antlers_Hugo, and Hugo. The subbasin does not go upstream any further because Sardis Outflow and Tuskahoma Dam Site either have no locals or the locals are already included in Outflow.

For each computational subbasin, select the Compute Forecast Period Incremental Local Inflows method from the Compute Incremental Local Inflows category. This enables the Reservoir Boundary for Incrementals category. Because cumulative local inflow data is only cumulative until a reservoir is reached, select the Stop at Reservoirs method from the Reservoir Boundary for Incrementals category.

Additionally, all headwater reservoirs and those with reservoirs with no upstream objects that have cumulative inflows should be placed in a single computational subbasin. Then on the subbasin, select the Compute Forecast Period Incremental Local Inflows method from the Compute Incremental Local Inflows category. This enables the Reservoir Boundary for Incrementals category. Select the Reservoirs Only method from the Reservoir Boundary for Incrementals category; see “Reservoirs Only” in Objects and Methods for details. This method allows the user to input local inflow data into the Cumulative Hydrologic Inflow slot on the reservoirs but the reservoirs do not have any upstream objects for which there are cumulative local inflows. This usually happens on headwater reservoirs but can also occur when a reservoir is directly downstream of another reservoir and inflows do not accumulate between the two reservoirs. This method allows users to input cumulative inflows consistently throughout the model in the Cumulative Hydrologic Inflow slot.

For each control point and reservoir in each computational subbasin several new methods must be selected. Method selection on multiple objects can be accomplished efficiently through the Multiple Object Method Selector. The Multiple Object Method Selector is enabled by selecting Workspace, then Objects, then Select Methods on Objects.

In RiverWare, local inflows are called Local Inflows on Control Points and Hydrologic Inflows on Reservoirs. In this discussion, we will use the terminology Local Inflows exclusively; please substitute Hydrologic Inflows anywhere a reservoir is referenced.

For each control point and reservoir in an incremental calculation subbasin, users should specify the following criteria. The listed methods are described in the object-specific documentation.

With this setup, the user then inputs the cumulative flows into the Cumulative Local Inflow slot (on control points) or the Cumulative Hydrologic Inflow slot on the reservoirs.

In routing reaches, the user must input enough data before the start of the run (presimulation) to allow the reaches to solve for the Outflow at the first (and possibly subsequent) timestep. The necessary slots and number of presimulation values required to ensure solution of the entire system at the start timestep depends on the number, type, linkages, method selection and parameterization of objects in the system.

In most circumstances, the modeler identifies the presimulation data requirements through knowledge of the system or trial and error. These data are then specified (manually or via input DMIs) to provide the model with required and reasonable data. This section describes an approach to automatically initializing flow slots at presimulation timesteps so routing can simulate successfully at the first computational timestep.

The following section describes the slots used in USACE‑SWD models requiring presimulation data.

Currently in USACE‑SWD models, all presimulation values are set to zero. On the Local Inflow, Diversion, and Return Flow slots, this value may be reasonable. But zero reservoir outflow does not seem reasonable as this value will propagate downstream. Therefore, the above slots can be initialized using one of the following methods:

For each object, the method determines the number of required presimulation values by visiting each downstream reach object and looking at the routing characteristics. The search is stopped when a reservoir or other object that does not dispatch before the first timestep is met or the downstream-most point in the basin is found. Objects that do not dispatch before the timestep are: Reservoir (all types), Pipeline, Inline Pump and Bifurcation. The upstream to downstream search will stop at any of these points.

Reservoirs of all types, Pipelines, Inline Pumps and Bifurcations will not calculate a mass balance for timesteps before the begin of the run, so reaches downstream of these points must be initialized as if they were at the top of their basins. For example, flows above a reservoir will not affect the outflows specified for the reservoir because the reservoir cannot solve prior to the start timestep.

To ensure that this algorithm produces the same results for model files without the initialization method, every object is checked to see that it is a member in a subbasin with an initialization method. If the object is not a member, the number of lags calculated will be zero, and the results of the first dispatch timestep will be the same as without these methods selected.

The number of required presimulation values will be determined as follows:

See “Initialize Flow Slots for Routing” in Objects and Methods for details.

To apply the initialization functionality to an existing USACE‑SWD model, the following steps are required.

This section will identify and walk through these steps.

The Initialization methods reside on a Computational Subbasin. While several computational subbasins exist in USACE‑SWD models, it is recommended that a new subbasin be created to ensure that all simulation objects be considered for initialization; not just those listed in an existing subbasin.

If further flexibility is required, the user may create separate subbasins to initialize objects differently. For example, choose to specify all reservoirs as part of a Computational Subbasin that Backcasts the Initial Value. All the other objects should be part of a Computational Subbasin that would Backcast Zeros. This approach is possible because all of the objects in the model should be in a subbasin to find the correct downstream lag, they don’t necessarily have to be in the same subbasin.

In past USACE‑SWD models, slots requiring initialization values were set with rules and/or were set manually. If desired, these user-input values may now be removed, resulting in the model relying more fully on the Initialization methods. Remember that these user input values or any extra values do not interfere with proper execution of the Initialization methods, but may be unnecessary. While there are several means to accomplish removing the initial values, during development and testing CADSWES staff found the following method to be relatively efficient.

Remember that certain slots require user input at the Initial Timestep, such as Reservoir Storage or Pool Elevation.

If previous initialization efforts included usage of rules to initialize diversions, return flows or local inflows, these rules should be removed or deactivated. If the chosen method is Backcast Zeros, the model should run.

Change no-lag reaches to use the No Local Inflow, Solve Outflow method to avoid requiring the Local Inflow to have a initial value. See “No Local Inflow, Solve Outflow” in Objects and Methods for details.

Diagnostics are available for the initialization methods under the Dispatch Management, SimObj category. Make sure to select the computational subbasin in the object filtering section.

In the USACE‑SWD flood control routing methods, releases are routed using the Step Response routing method. During extreme large events with overbank flow, the channel routing coefficients are insufficiently accurate to model the routing of water down the reach, i.e., large flows that occupy the overbanks have different travel times. This section outlines the required simulation functionality and proposes a design to add the capability to RiverWare to provide for alternative routing coefficients during high flows, both in the reach simulation and in the flood control release algorithm.

The USACE‑SWD typically uses the Step Response Routing method to route water in RiverWare simulations. There are two separate sets of routing coefficients used, one set for each control point and one set for each reach. The control point routing coefficients are used in the flood control algorithm’s release determination while the reach routing coefficients are used in the simulation to route water. These two routing methods are described below.

One set of routing coefficients for each upstream reservoir resides on the control point Routing Coefficients slot. These coefficients are used only in the flood control algorithm to estimate the effect reservoir releases would have on downstream flooding. In the flood control algorithm water is routed from each upstream reservoir directly to the control point (i.e. reservoir outflow routed to control point) using Equation 2.2.

The estimated flow at the control point is the sum of the contribution from each upstream reservoir. This equation is only used in the routing in the flood control calculation (i.e. rule function evaluation) and does not actually route water to the control point. These calculations are used by the rule to set reservoir outflows.

The reach is used to route water in the simulation after reservoir outflows have been set. On the reach, the following equation is used to incrementally route water in the reach (i.e. route Inflow plus Local Inflows to Outflow) during the simulation. Step Response routing uses Equation 2.3.

This equation is used to calculate the current and future outflows (from t = current to t = number of coeffs). All of the C values are calculated outside of the model and for each set of coefficients, the C values sum to 1.0.

To simulate large flows accurately, it is necessary to use alternative routing coefficients only at high flows for both the flood control calculation and the reach simulation. These routing coefficients come into effect when flows are above thresholds. These coefficients are used when the flow is above a threshold in both the flood control algorithm and the reach routing.

To implement the above approach, various methods must be selected.

In the simulation/calibration model, you have the following choices:

Then, populate the Variable Lag Coefficients table slot with data.

When Flood Control is implemented, a computational subbasin must have the correct method selections. Generally, the same subbasin used for Flood Control should be used for this purpose; see “Flood Control” for details. This subbasin will contain most, if not all objects in the basin. On this subbasin, select the Compute Aggregate Coefficients method in the Control Point Variable Routing Coefficients category.

Additionally, on each control point downstream of a reach with alternative coefficients, the user must select the Compute Aggregate Coefficients method or Compute Aggregate Coeffs every Timestep method in the Variable Routing Coefficients category. No additional data entry is required on the control point for this method (although the standard Routing Coefficients table are typically input on the control point for the normal flow conditions).

To enable this approach, the user must select methods on the objects summarized in Table 2.4.

The flood control algorithm accesses the correct set of routing coefficients based on the method selection. On a given control point,

Once the set of coefficients are determined, the flood control algorithm proceeds as usual. The algorithm will use the coefficients throughout flood control execution and throughout the forecast period.

Forecasting and basin lag times result in situations where the last timesteps of the run may not solve correctly if the objects have not solved past the end of the run. To allow objects to solve past the end of the run, you must configure post-run dispatching. Figure 2.5 shows a timeline diagram when post-run dispatching will occur.

To configure post-run dispatching, set the number of post-run dispatch timesteps equal to the forecast period; see “Number of Post-Run Dispatch Timesteps” in User Interface for details. For dispatching to occur after the end of the run, certain data must be specified. Following is a description of the required data for post run dispatching

The forecasting and disaggregation of cumulative local inflows is done at the beginning of each timestep. The forecasting will be executed at Begin Timestep on the last timestep, but will not occur after that. That is, even though the objects dispatch past the end of the run, no additional forecasting is required. But, local inflow data is required after the end of the run through the Period of Perfect Knowledge. That is, the user only needs to input Cumulative Local Inflows through the run end plus the Period of Perfect Knowledge on each inflow location.

Following is data that will be automatically filled in at beginning of run and there is not a valid value. No user interaction is required.

Following is data that is typically input by the user (input or using a DMI). These will need to be input for post-run timesteps as well. DMIs or rules (RBS or Init) can be configured to quickly set this data.

Following is data that is may be input, but with different method selections, the data can be automatically set for all timesteps, including post-run.