This value represents the maximum number of times a slot can be reset on a particular timestep during object dispatching. When forecasting, you may set slots in the future, that is, at timesteps later than the current controller timestep. The max iterations limit applies on each timestep and includes any resetting that has occurred. For example, a max iteration error would occur if a slot was set at timestep “t” more than the max iterations limit including when it was set when the object dispatched on controller timestep t-n,..., t-4, t-3, t-2 and t-1 and forecasted values at t.

RiverWare allocates space for the entire run length of each series. If, during the run, timesteps beyond the run are given values, RiverWare has to extend the series and copy over all the existing values, because RiverWare requires that the series values be stored in contiguous memory. This is a time consuming operation, so it is in the users' interest to avoid this operation. Thus, this parameter allows the users to allocate a little extra space if they know that their models will be solving for timesteps beyond the end of the run. This is particularly important where reach routing causes timesteps beyond then end of the run to acquire values. For example, if a reach has a routing coefficient vector of 40 elements, the series extension increment should be at least 40. A second example is if the model solves into the future throughout a defined forecast period. Set the Series Extension Increment equal to the forecast period as that many timestep will be required at the end of the run.

Series slots have upper and lower bounds that are used as part of an optimization solution. Using this parameter, you can show a warning message when values set in Simulation or Rulebased Simulation are outside these bounds. See Configure Slot Dialog Functionality for details.

Also in this dialog, Water Quality calculations may be enabled and configured. See Water Quality Overview in Water Quality for details.

Sometimes, computations are required past the end of the run. This is particularly true for models with lags and forecasting algorithms. For example, if you are trying to determine how much water to release on the run’s finish timestep and you have a two timestep lag to the controlling location, you need the downstream reaches to dispatch two timesteps past the end of the run.

The Number of Post-Run Dispatch Timesteps parameter represents the number of timesteps past the run finish timestep for which object dispatching will be allowed. Whether an object dispatches or not still depends on the knowns and unknowns, i.e. the dispatch conditions. Also, additional data may be required for the objects to correctly dispatch and solve. Data defaults (like reservoir diversion) will be set past the end of the run, too. Note, the Number of Post-Run Dispatch Timesteps is controller specific, that is, it can be different for the Simulation and Rulebased Simulation controllers.

This is the start month of the water year. This is currently only used by the Time Aggregation Series Slot computation. See Annual Aggregation Support for Non-calendar Water Years for details.

This checkmark specifies that any open Global Functions RPL sets should be saved with the model file. See Save Location in RiverWare Policy Language (RPL) for details.

Water Quality calculations may be enabled and configured. See Water Quality Overview in Water Quality for details.

This value represents the maximum number of times a slot can be reset on a particular timestep during object dispatching. When forecasting, you may set slots in the future, that is, at timesteps later than the current controller timestep. The max iterations limit applies on each timestep and includes any resetting that has occurred. For example, a max iteration error would occur if a slot was set at timestep “t” more than the max iterations limit including when it was set when the object dispatched on controller timestep t-n,..., t-4, t-3, t-2 and t-1 and forecasted values at t.

RiverWare allocates space for the entire run length of each series. If, during the run, timesteps beyond the run are given values, RiverWare has to extend the series and copy over all the existing values, because RiverWare requires that the series values be stored in contiguous memory. This is a time consuming operation, so it is in the users' interest to avoid this operation. Thus, this parameter allows the users to allocate a little extra space if they know that their models will be solving for timesteps beyond the end of the run. This is particularly important where reach routing causes timesteps beyond then end of the run to acquire values. For example, if a reach has a routing coefficient vector of 40 elements, the series extension increment should be at least 40. A second example is if the model solves into the future throughout a defined forecast period. Set the Series Extension Increment equal to the forecast period as that many timestep will be required at the end of the run.

Series slots have upper and lower bounds that are used as part of an optimization solution. Using this setting, you can show a warning message when values set in Simulation or Rulebased Simulation are outside these bounds. See Configure Slot Dialog Functionality for details.

This checkmark specifies that the loaded RBS ruleset should be saved with the model file. See Save Location in RiverWare Policy Language (RPL) for details.

This checkmark specifies that any open Global Functions RPL sets should be saved with the model file. See Save Location in RiverWare Policy Language (RPL) for details.

This integer value controls how many times the rulebased simulation controller will cycle through the timesteps. See Run Cycles in Solution Approaches for details.

Sometimes, computations are required past the end of the run. This is particularly true for models with lags and forecasting algorithms. For example, if you are trying to determine how much water to release on the run’s finish timestep and you have a two timestep lag to the controlling location, you need the downstream reaches to dispatch two timesteps past the end of the run.

The Number of Post-Run Dispatch Timesteps parameter represents the number of timesteps past the run finish timestep for which object dispatching will be allowed. Whether an object dispatches or not still depends on the knowns and unknowns, i.e. the dispatch conditions. Also, additional data may be required for the objects to correctly dispatch and solve. Data defaults (like reservoir diversion) will be set past the end of the run, too. Note, the Number of Post-Run Dispatch Timesteps is controller specific, that is, it can be different for the Simulation and Rulebased Simulation controllers.

In RPL, you can access the timestep represented by the function using the DispatchEndDate function; see DispatchCount in RiverWare Policy Language (RPL) for details.

This value indicates how many times a single rule can execute on each timestep.

This is the start month of the water year. This is currently only used by the Time Aggregation Series Slot computation. See Annual Aggregation Support for Non-calendar Water Years for details.

This parameters represents the maximum number of times an account slot can be reset or recalculated. When forecasting, you may set slots in the future, that is, at timesteps later than the current controller timestep. The max iterations limit applies on each timestep and includes any resetting that has occurred. For example, a max iteration error would occur if an account slot was set at timestep “t” more than the max iterations limit including when it was set on controller timestep t-n,..., t-4, t-3, t-2 and t-1 and forecasted values at t.