Run RiverWare More Efficiently
This section describes steps that can be taken to run RiverWare more efficiently and thus improve runtime performance.
Reduce Diagnostics Processing
When diagnostics are enabled, RiverWare must process diagnostics as well as perform the primary calculations of the simulation. The overhead associated with diagnostics consists of the following:
1. Decide whether individual diagnostics should be issued.
2. Collect the data to be posted.
3. Post the diagnostic.
In some contexts, Step 1. and Step 2. can require significant computation, but in most situations it is Step 3. that dominates diagnostic processing time. See About RiverWare Diagnostics for a general discussion of diagnostics.
Disable Diagnostics
Since the overhead associated with processing diagnostics can represent a significant fraction of a run, if they are not necessary, and performance is an issue, then it is best to disable them. To disable, make sure the Enable Informational Diagnostics option is not selected in the Diagnostics Manager.
Figure 1.7 Diagnostics Manager with diagnostics disabled
Filter Diagnostics
When diagnostics are being sent to the Diagnostic Output Window, the time to post a diagnostic is related to the number of diagnostics in the diagnostic output window. In other words, the more diagnostics that have already been posted, the more time it requires to post an additional diagnostic. This means that the time spent posting diagnostics within a total run is proportional to the square of the number of diagnostics posted. Thus even though posting an individual diagnostic is not expensive, it can take a lot of time to post a large number of them. By filtering diagnostics to post only those diagnostics currently of interest, run times are decreased and less effort is required to sift through diagnostics for the desired information.
Figure 1.8 shows the diagnostics filtering dialog with the following filters enabled:
• Timestep = January 12, 1996
• Rules = Mighty Min Flow for Fish Release
• Object = Mighty
• Slots = Mighty.Inflow, Outflow and Storage
Figure 1.8 Diagnostics filtered
Send Diagnostics to a File
Figure 1.9 Diagnostics Manager indicating to send diagnostics to a file
If it is useful to see many diagnostics, consider sending them to a file instead of to the Diagnostic Output Window. File I/O is relatively fast, and one can still view the diagnostics in a text editor, perhaps one with more sophisticated searching and filtering capabilities than those provided by the Diagnostic Output Window.
Note: Posting a diagnostic to the diagnostic output window requires additional memory usage, so sending diagnostics to a file instead of a window will reduce RiverWare memory use, which can have a positive impact on run times as well.
Break Long Runs Into Multiple Runs
For most models, the size of the RiverWare process is dominated by series data. If the model is too large to fit into virtual memory, there are two ways to break up the model, either in time or in space. To break the model up by time, divide the total run into multiple runs of shorter duration, configure DMIs to exchange data between runs, and write RCL scripts to conduct these runs in sequence. See Batch Mode and RiverWare Command Language in Automation Tools for details about RCL scripts.
Another possibility is to simulate upstream portions of the model for the full time range of interest and then import the results into a model that simulates the remainder of the basin. Of course, operational dependency of upstream objects on downstream objects may prevent this from being an option.
Close Unused Windows
Updating the graphical user interface during a run requires CPU time and increases the size of the RiverWare process. When it is desirable to run RiverWare interactively, you can reduce the amount of time updating dialogs during the run by closing them. This is especially important for series data such as that displayed by an SCT, a SeriesSlot dialog or a model run analysis dialog. Each time a slot value changes internally, the corresponding slot’s dialog might need to be updated if it is open. In general, if performance is critical, we recommend that all unused dialogs be closed.
Run in Batch Mode
Consider completely avoiding updating the user interface during a run by writing a RCL script to conduct a batch mode run. After a run, you can then bring up RiverWare interactively to analyze the results.
Improve Your RPL Set Logic
Although RiverWare often spends much of its time dispatching, RPL statement execution can represents a significant factor of the time spent during a rulebased simulation. Some RPL set logic is more computationally intensive than others, and changing RPL logic with this in mind can often improve model run times. Use the RPL Analysis tool to identify functions that are taking a long time or execute too many times (see RPL Analysis Tool). Then, determine if there is a more efficient way to write these functions. See Developing Efficient RPL Expressions in RiverWare Policy Language (RPL) for a list of suggestions to writing efficient RPL expressions.
Revised: 01/05/2024