ResSim 3.5 Known Issues

Overview

Pre-release, beta versions of HEC-ResSim 3.5 have been widely used within USACE for several years and packaged with recent CWMS software.  Thus HEC-ResSim 3.5 is known to be stable, and the most significant, show-stopping issues have been addressed.  However, there are many smaller, known issues that still exist and were not addressed prior to release due to funding and timing.  We have documented those issues on this page. 

If you encounter any undocumented issues within version 3.5, please report them!

Important Computational Issues

These issues have the potential to cause a significant impact on results, but can be handled with informed modeling, such as proper input, work-arounds, or in some cases refraining from using certain features.

Miscalculation of Physical Maximum Capacity

The determination of the maximum release capacity of a reservoir and its outlets is an important piece of the release decision logic in ResSim, but it is also a computation that is harder to produce accurately than you might expect.  You see, at any instant of time, the release capacity is a function of the pool elevation, so what is the release capacity for a timestep?  Is it the capacity at the start of the timestep, or at the end of the timestep , or is it an average over the timestep?  The first option, at the start, is easy because we “know” the elevation at the end of the previous timestep - which is the elevation at beginning of the current 0timestep. But, don’t know the elevation at the end of the timestep because we still need to make decisions that will result in the elevation at the end of the timestep. Depending on the release we decide to make, the pool elevation during the timestep could vary substantially. But to make that decision, we need to know the maximum release capacity (PhysMaxCap) – you can see it is a vicious circle. 

The algorithm that ResSim currently uses to determine PhysMaxCap for each outlet (and for the reservoir) assumes that each outlet is releasing at its starting capacity for the timestep. ResSim uses the mass balance equation to calculate the resulting change in storage from which it then looks up the ending elevation for the timestep.  Because each outlet has been assumed to be releasing at its starting capacity, a lot of water will be assumed to have left the reservoir, resulting in a potentially very low ending elevation. ResSim then averages the beginning and ending elevations and looks up the release capacity for that average elevation and calls that average PhysMaxCap. 

Thus, this problem manifests as an unexpectedly low PhysMaxCap due to a low estimate of average elevation. Unfortunately, the longer the timestep, the worse this estimate of PhysMaxCap may be, especially in reservoirs with small pools and large release capacity.  We are aware of this limitation in the algorithm but, as of this release, we have not settled on a better approach. [NOTE: this estimate of ending elevation is only used for the PhysMaxCap calculations and is not stored nor used elsewhere in the program.  In fact, ResSim uses a very different calculation to estimate ending elevation for the purposes of the rules and other operational decisions.]

RSS-543 - Getting issue details... STATUS

How to Address: Workarounds for this problem are usually model specific because what works for one might not work for another – or causes other problems.  But here are some workarounds we employed with some success:

• Use a smaller timestep.
• Consider the function of the reservoir and the impact or importance of storage. Is the reservoir a storage project, or is it a “run of river” project? 
  • Run-of-River project: we have seen this problem most in run-of-river reservoirs where the storage is small but the release capacity is large so that the reservoir can pass large events without concern. In such a reservoir, the storage of the pool is essentially irrelevant because the operations keep the pool level.  So, give it a fictional huge pool, or give it a constant release capacity, or both.
  • Storage project: this kind of reservoir is harder to find an effective workaround for but the options are still related to the definition of the storage pool and the definition of the outlet capacity. 
    • Try adding volume to the pool without changing its relative change in storage across the operating range. In other words, add 1,000,000 acft to each entry in the elevation-storage table, then add a new zero row at the top, and set the elevation of that zero storage fictionally low (10’-100’ below the actual bottom of the pool).  In this test, you are looking to see if the larger overall storage allows the estimate of PhysMaxCap to be more appropriate to the operations.  To check before and after, the PhysMaxCap is stored to the simulation.dss file as //reservoir-name-outlet-name/FLOW-MAXLIM/…/
    • Try setting the capacity of your outlet(s) to a constant. Although you can check on /FLOW-MAXLIM/, what’s more important is that your operations reflect the desired operation and do not release more than they should.  If you must model your outlets with a constant capacity curve, you can impose the physical capacity constraint on them with a maximum release rule, function of previous or period average elevation, and put the original capacity curve in there as the function.

Monte Carlo Bugs

Numerous issues were found with the Monte Carlo feature in late stage testing. This feature is not widely used, and thus has not undergone the same level of functional testing as most of ResSim. Some Monte Carlo applications may work, while others have user interface bugs or computational bugs, and they are not always reproducible. 

How to Address: Please use caution with this feature, and reach out to the HEC ResSim team if you would like to discuss your Monte Carlo modeling options.

Input Variable Empirical Distribution UI Issues

The MC Input variable empirical distribution table does not work correctly. Sometimes the table inverts. In any type of sorting user will get the “Empirical Distribution Data is not valid. Distribution values must be strictly monotonically decreasing” error message. Sometimes the probability values is changed in the first or last row.

RSS-736 - Getting issue details... STATUS

Random Variable Wizard Distribution UI Issues

The Random Variable Wizard displays various UI issues, including nonresponsive buttons and disappearing tables.

RSS-388 - Getting issue details... STATUS

Input Variable "Edit" Button Launches Wrong Wizard

The Monte Carlo Input variable Edit Button does not allow editing.  Instead, it launches the Random Variable Wizard and adds a new Variable

RSS-734 - Getting issue details... STATUS

Exceedance Probability Precision Issues

Some exceedance probabilities appear to be displaying all digits out to limit of double floating point precision. This might only occur in the seasonal table.

RSS-735 - Getting issue details... STATUS

Changes to Settings cause Compute Failure

If the user changes Monte Carlo settings, such as the output variable, between computes in a simulation, the compute will fail with an error about being unable to get DSS data:

"Monte Carlo Compute Data Errors: Simulation does not have active Monte Carlo convergence variables." In order to clear this, the user must change the option on the `MC Controls` tab to `clear previous MC...` before they can run the simulation again. 

RSS-741 - Getting issue details... STATUS

Save To/From Base Misses some Settings

The Alternative "Save to Base" or "Replace from Base" options in the Simulation Module do not reliably copy all the Monte Carlo settings. Use caution.

RSS-733 - Getting issue details... STATUS

"Inflow Multiplier" check box is required to see all variation of MC results

RSS-1061 - Getting issue details... STATUS

Mod Puls Routing Mass Balance Error

Scenario: Occurs when Mod Puls storage-outflow relationship does not start with a zero flow entry

How to Address: provide complete and valid input data.

A user discovered a problem in the mass balance (conservation of mass) while performing a network connectivity and mass balance check. They setup an alternative using a constant 1cfs inflow time series at each inflow location in their model.  Most routing reaches in the model were using Modified Puls routing. When they reviewed the flows throughout the network, they found the downstream-most outflow was ~504 cfs when it should have been ~4cfs - the system was creating water somewhere!  The user isolated the problem to a Mod Puls routing reach below the lowest reservoir; it had a storage-outflow relationship whose smallest outflow value was 500 cfs.  By setting the routing to NULL in this reach, the 500 cfs difference in expected outflow disappeared.  Further testing at HEC revealed that by entering an additional row into the top of the storage-outflow table with a zero outflow value, the reach produced a much more appropriate routed flow and the outflow at the mouth of the network was the ~4cfs that was expected.

The moral of the story:  When doing table lookups, ResSim will NOT extrapolate beyond the edges of the data provided in the table. If you haven't heard us tell you this before, well, you have now.  Thus, ResSim's Mod Puls routing method will not produce a routed flow smaller than the smallest flow in the reach's storage-outflow table (or larger than the largest outflow in the table). So, start all your Mod Puls storage-outflow tables with a zero flow entry or a flow entry that is lower than any value you would ever expect to see flowing through your routing reaches. And end these same tables with an outflow entry larger than you would ever expect, even in a 1000 year or dam-break event. 

HEC plans to add messaging and a data check to catch this potential issue at the start of each compute, but that has not been implemented as of this release.  However, the onus will remain on you, the user, to provide ResSim with complete and valid data.

RSS-146 - Getting issue details... STATUS

Decreasing Flow Rate of Change Rule may Impact Guide Curve Operations.

A user discovered a problem when analyzing the impacts of a decreasing flow rate of change rule on the operations of one of the reservoirs in his watershed.  In this case, he believed that the rate of change rule was preventing the reservoir from "staying on the guide curve" even though the value of the decreasing rate of change limit was such that it should not have limited the operation.  He performed several subsequent tests to verify his conclusion including removing all rules from the reservoir except the decreasing flow rate of change rule.  His tests isolated the problem - in his watershed - to:

• the reservoir needed to be part of the network with the other reservoir
• the reservoir had to have the decreasing rate of change rule in it
• the reservoir was not part of a system of reservoirs operating for a common objective (downstream control).
• the model had the option to include rate of change constraints in evaluating the guide curve release (this is the default).

If any of the above conditions was false, the reservoir was able to properly operate to meet guide curve operation, i.e., the problem behavior was not observed.

There was one interesting and unusual feature in the reservoir in question - it's guide curve was not a simple function of elevation, instead, it was a function of a state variable and thus a "computed" guide curve.  We have not determined if this could in any way have been related to the problem behavior.

Tests were performed in two other complex watersheds with multiple reservoirs and system operations.  We were unable to replicate the reported behavior in either watershed so we are unsure if the problem is specific to the watershed it was found in and we did investigate further before ResSim 3.5 was released.

How to Address: If you are suspicious that this problem is impacting the operation of your model, here are some workarounds that you can employ:

• turn off the option to evaluate the impacts of Rate of Change rules on Guide Curve logic: 

• or include the reservoir with one or more other reservoirs in a common compute block.  This can be through the use of a common downstream control rule or a "dummy rule" that's a function of the flow at a common downstream location.

RSS-528 - Getting issue details... STATUS

IF-Block Conditional Expressions that utilize Date/Time entries do not evaluate correctly.

During regression testing of IF-Blocks, the tester noticed that conditional expressions that utilized a Date/Time entry to compare against the current runtimestep did not result in a correct evaluation of TRUE or FALSE during all or most of the time window of his tests.  He performed several tests at different compute intervals and using different Date/Time values and he could not find a conditional expression that consistently evaluated correctly.  We were unable to address this issue before ResSim 3.5 was released.

Workaround:

• Do NOT use Date/Time entries when defining your conditional expressions.  Use Seasonal Dates, instead; Seasonal Dates are consistently evaluating correctly under all our tests.  The drawback is that Seasonal Dates always point to the "time" at the start of the specified day, which could mean that you will get a true result for a timestep whose value is at 2400 of the day before; and, you cannot specify any other time of day.

RSS-399 - Getting issue details... STATUS

Prescribed Release Rule Issues

The Prescribed Release Rule is a fairly new rule in ResSim.  It was designed to be a “hand regulation” rule that acted a bit like a release or elevation override but that was included in the standard rule stack and prioritized against other rules.  This rule’s setup is a list of prescriptions – each of which is defined by a time window over which it applies and an operator with an associated value (if needed).  The list of available operators depends on the release element you apply the rule to.  The following figures show the list of available operators for an outlet defined with a range of gate settings, for the reservoir pool, and for an outlet defined with only a maximum capacity curve.

Some Operators Should not be Options

The list of operators for an outlet group should be the same as those for an outlet with only a maximum capacity curve, but that’s one of the “bugs” we didn’t get addressed before release – the list is not as filtered as we’d like.  In other words, it includes Hold Previous Gate, Hold Starting Gate and Set Gate, when it really shouldn’t since an outlet group doesn’t really have gate setting information, even if all the outlets in the group do. 

RSS-398 - Getting issue details... STATUS

Corrected Operator Options Error from v3.3

Now, those of you who might have used the prescribed release rule in ResSim 3.3 or an earlier (Beta) release of ResSim 3.5 may notice that the list of operators includes four new entries and are missing two.  The missing entries are Hold Release and Hold Gate.  These were replaced with Hold Previous Release, Hold Previous Gate, Hold Starting Release, and Hold Starting Gate.  This is to address what we considered a bug or mis-implementation of the original operators.  We thought Hold Release (and Hold Gate) meant that the model would maintain the release or gate setting that was used in the time step before the prescription “kicked in”.  Instead, the prescription was using the release or gate setting that was used at the start of the simulation.  So, rather than change the original implementation, we simply named the existing operators more accurately (Hold Starting Release and Hold Starting Gate) and added the operators and the associated functionality that we were expecting (Hold Previous Release and Hold Previous Gate).  We also added tooltips to the operators to describe what each is supposed to do.

This issue was addressed in 3.5, but we included it here since we were already discussing Prescribed Release rules.

RSS-69 - Getting issue details... STATUS

Date and Time Specification Confusion

Another Prescribed Release Rule issue that did not get addressed is how ResSim uses the Date and Time entries with some of the operators – specifically the Hold Previous operators.  The issue was identified with Daily timestep alternatives.  The problem was described as: the prescription starts 1 day prior to the selected start date/time and uses the release or gate setting from 2 days prior. Investigations revealed that this may not be a “bug” as much as a misinterpretation of the date/time specified for the start time – but whether that misinterpretation is on the part of the program or the modeler, we hesitate to say.  But since it was confusing for those of us who designed the rule, we do feel that we need to do something to clear things up.  So, until this is addressed, be careful of how you define your prescriptions and verify that ResSim in doing what you intended (or adjust the prescription accordingly).  The original bug report also noted that the prescription was also ending one day before the end of the prescription, but we could not verify this; the prescription was ending right where we expected. 

RSS-396 - Getting issue details... STATUS

Date and Time Requirement without Warning

And, the last Known Issue with Prescribed Release rule is in the UI of the rule.  Some operators require that the start and/or end date/times be specified.  Most operators allow them to be left blank and will assume that blank means you want to use the start and/or end date/time of the simulation in their places.  However, the ELEV operators, Delta Elev and Target Elev MUST have an end date/time specified.  If the end date/time is left blank, the prescription will be ignored.  At present, you are warned about this requirement only if you click in the end date/time cell. 

RSS-397 - Getting issue details... STATUS

Release Allocation Issues

The UI for specifying the Release Allocation Options has changed significantly with ResSim 3.5.  And as sometimes happens with when we try to make things better, we add in problems.  But let’s start with the good stuff: The release allocation feature now allows you to define one or more release allocation strategies or sets and give each a name, but only one allocation set can be active per operation set. However, you can now create a Release Allocation IF-Block and define various IF and ElseIF conditional expressions; each IF, ElseIF, and Else clause in your IF-Block can then be assigned a different release allocation set.

The issues that were identified during testing that have not yet been addressed include:

• Duplicate Allocation Set names are not being prevented. Although this may only be an artifact of the conversion of the “default allocation set” being assigned a name by the network converter that was run on an older ResSim model when its network was opened with ResSim 3.5, we felt you should have a “heads-up” to be cautious when naming your allocation sets.
• The current implementation of the Allocation IF-Blocks only allows the creation of one Allocation IF-Block. Although you must name it like you would name an Allocation Set, you cannot create several IF-Blocks and then select one to be the active one for the operation set. 
• If you have created a release allocation with an IF-Block, you cannot switch back to a single allocation set unless you delete the IF-Block.
• User Interface gaffs such as typos and incorrect tooltips

RSS-580 - Getting issue details... STATUS

Vertical Datum Does Not Work

The Vertical Datum is a new feature that was developed in ResSim 3.5, but while early incarnations of the feature were able to assist uses by tracking and converting elevation data based on initial and selected display datum, later shared code work changed the approach to vertical datum handling in DSS, and the ResSim implementation is no longer reliably functional. The feature has been turned off by default in the ResSim user interface, since modelers can not depend on the feature to accurately convert elevations to different datums. 

Please see ResSim Discourse for further details: https://discourse.hecdev.net/t/ressim-3-5-vertical-datum-conversion-features/2153/2

Global Variables Issues & Limitations

Only a minimal initial implementation of Global Variables was done in ResSim 3.5.  Many of the planned features are incomplete or expected to be added later. The existing features are not all fully polished. Some of the most significant issues with Global Variables are as follows:

Global Variables Tables Issues

Improper Date/Time Entry is Possible

The Global Variable Tables will allow dates to be entered in non-chronological order. It is not known how improperly entered Date/Time data will affect model runs. Use caution with this datatype and enter it into tables carefully.

RSS-729 - Getting issue details... STATUS

Exceptions can be thrown with incomplete data entry

RSS-730 - Getting issue details... STATUS

Global Variables Values Do Not Consistently Copy in Trials

Testing showed that the first trial copied values fine, but in trials after that, the string and scalar values started changing.

RSS-571 - Getting issue details... STATUS

Limited Application of Global Variables

Only Timeseries Global Variables can be used in IF Statements

RSS-593 - Getting issue details... STATUS

Only Timeseries Global Variable can be used to define zones

RSS-594 - Getting issue details... STATUS

Operation Support Interface (OSI) Issues and Limitations

Many small bugs and limitations were identified with the initial implementation of the OSI in HEC-ResSim. We also have a scope for numerous enhancements for real time modeling with ResSim, including many in the OSI. These plans are projected after release of 4.0. ResSim 3.5 has only a few bug fixes since version 3.3.

Use Caution with Timesteps

Use caution when editing local flow timeseries with a timestep that is different than the compute timestep.  ResSim will interpolate an input local flow timeseries to the timestep of the compute (e.g. 15MIN to 1DAY), but users may experience unexpected behavior when editing that interpolated timeseries.  For best performance, ensure all timeseries that will be edited in the OSI use the same timestep as the ResSim compute timestep.

RSS-131 - Getting issue details... STATUS

Preprocess Observed Data for use in OSI

Time series identified in ResSim's Alternative Editor Time Series tab is processed during the standard data extraction to ensure it uses the correct time interval and data type to match the alternative settings. However the OSI does not process observed timeseries. Modelers who wish to use observed data within the OSI must first make sure the observed data time series referenced uses the correct time interval and data type (period-average or instantaneous).  

CWMS-1937 - Getting issue details... STATUS

Ensemble Bugs

Ensemble Plotting Issues

There have always been issues with plotting ensembles, and even when one is fixed, another often pops up. We have a wishlist of plotting improvements to make in the future.

RSS-35 - Getting issue details... STATUS

RSS-169 - Getting issue details... STATUS

Selecting the Ensembles using * in CAVI does not work

Whether using multi-threading or not, specifying "*" ensembles causes a compute failure.  This problem does not appear to happen in ResSim standalone, however, users have reported various similar issues since the implementation of the Ensemble Feature. Each time HEC tried to address the issues, but we did not always find a problem. It's possible that there are still related issues in both standalone and through CAVI.

RSS-651 - Getting issue details... STATUS

Selecting the Ensembles using a range does not work fully

RSS-668 - Getting issue details... STATUS

Overrides do not consistently work for Ensembles

The Overrides editor sometimes loses the connection between the active reservoir and the selected outlet.  Changes made to one combination may then get saved to another. Use caution - overrides may simply not work with Ensemble data at this time.

RSS-653 - Getting issue details... STATUS

Lower Risk Issues

Network Confirm Conversion (Save Now or Continue) Dialog Box is Out of Date

With each update to ResSim, the content and format of the file or files that represent the reservoir network evolves.  In an earlier version of ResSim, we added a Dialog box to remind users of that fact each time they open an older network in a newer version of ResSim.  But the content of that Dialog Box has become out of date and too specific to changes that happened in that earlier version.  One or more of our testers reported this discrepancy but we did not get it addressed before releasing ResSim 3.5.  The current (old) message box is this:

How to Address -

Here's what this box is trying to tell you:

Your reservoir network (myBasin) was written with an earlier version of ResSim.  While loading this network into memory, it has been updated to conform with the current network format and features.  If you Save Now, the updated network will be written to disk and will not be compatible with older versions of ResSim.  If you Continue without saving, you can continue to review the content of the network and may later choose to close without saving.

RSS-323 - Getting issue details... STATUS

API Issues

getLookbackTimeSeries() with APIs State Variable

The getLookbackTimeSeries() function is located in the State Variable Editor's Application Programming Interface (API) Tree, under StateVariable in the API branch. This function currently throws an error that the object has no attribute. Recommend modeler use getTimeSeries() in the interim, if needed. RSS-782 - Getting issue details... STATUS

Beware of Duplicate Names

ResSim requires a modeler to enter names for a whole lot of things, from streams to reservoir to outlets to rules and so much more.  Since it goes on and on, you may find it difficult to continually come up with new unique name for the “next thing”.  Well, there are two combinations we encountered recently where using the same name for two different things resulted in unfortunate consequences.  The first one – a network name and an alternative name were the same – we “fixed” by altering how certain network and alternative files are named so that users would not experience the “unfortunate consequences”.  The second combination, which we did not address (if we ever do), is when a state variable and a (time series) global variable are given the same name.  Yes, in one of our test watersheds, we gave the same name to a State Variable and to a time series Global Variable.  The unfortunate result was that when the output was written to DSS, one variable overwrote the other because all the pathname parts were the same (even the C part). 

How to manage - So, as a general rule, don’t give two “named things” in ResSim the same name.

New Rule Icons Exposed VERY Old Rules

In ResSim 3.5, we created a set of new icons, one for each rule type, to display next to the rule names in the Zone-Rules tree of the Reservoir Network.  The purpose of these icons was to enable a user to be reminded at a glance the type of the various rules that are being used in each zone of the current operation set.  Between these icons and good rule names, a lot of information about the operation set can be learned without detailed study of each rule.

But as we started to use and test ResSim 3.5 with some of our older watersheds, an unexpected situation arose.  We found the old, pink box icons occasionally appearing among the new icons in the Zone-Rules tree as illustrated below:

Upon investigation, we learned that in the early days of ResSim development, as we enhanced the early rule types to give them more functionality, we actually had to create new rule types and convert the old rules to those new rule types.  The logic to convert the old rules was added to the network loader (the code that reads your network from disk and loads it into memory).  Well, nothing's perfect and apparently, some rules did not get removed and (fully) replaced with their converted version; in fact, both the old rule and the converted rule, both with the same name, may appear in the same operations set (see the Max Rel - Dam rules in the above figure).  As far as we can tell, these old rules still work, are editable, and are linked to their converted counterparts so that edits applied to one appear in the other.  Since the code fix for this is complicated (and riskier than leaving things alone), we decided the best approach is one that each user who encounters this issue can apply for themselves:

How to Address -

If you encounter an operation set that displays one or more rules with a Pink Box icon, our recommendation is to:

• Create a simulation for a key event in which the rule or rules in question play an active role. Select an alternative that uses the operation set with the old rules in it.  Compute the alternative. 
• Next, create a trial of the alternative in the simulation, compute it, and verify that the trial's results duplicate the results from the parent.  The trial will remain unchanged in later steps but will be available for comparison as you update the operation set in the parent.
• In the parent alternative (NOT the trial)...
  • For each rule that you encounter that has a Pink Box Icon... 
    • Create a NEW rule (with a new name). 
    • Duplicate all the settings and attributes of the old and converted rules (by the same in name) in the new rule.
    • Place that new rule in the operation set immediately above each occurrence of the old rules. Do this for both the rules with the pink box icon and the rules with the new icon but the same name.
    • Remove the old and converted rules from the operation set.
• Compute the parent alternative. 
• Verify that the results of your revised operation set match those of the trial. 
• Once you are satisfied that all is as it should be...
  
  • SAVE THE ALTERNATIVE TO BASE.
• In the network module, open the network and verify that your changes saved back to the original network.
• Now, review the other operation sets in this reservoir.  If the old or converted rule appears in any of the other operation sets, you have two choices:
  1. Simply replace each instance of the old or converted rule with the NEW rule.  
  2. OR, if you are not fully confident that the new rule will properly replace the old rules in your other operation sets and their associated alternatives, then...
     • for each operation set that needs updating...
       • identify an alternative that uses that operation set
       • add that alternative to the simulation created above
       • Compute the alternative, then create a trial of it and compute the trial.  Verify the results are the same in the parent and its trial.
       • Now, in the parent alternative, replace each instance of the old and/or converted rules with the NEW rule in the operation set
       • Compute the alternative and compare the results with the trial.
       • When you are satisfied that all is as it should be, Save the alternative to Base
  3. Delete the rules from your reservoir.  Since your operation set should no longer have the old rules Delete... 

RSS-374 - Getting issue details... STATUS

ResSim will override the starting pool elevation if user provided elevation is below zero storage.

Actually, the issue here isn't really that ResSim is overriding the lookback elevation - we did that on purpose.  The issue is that ResSim is doing so without warning that user that it has done so.

If you are wondering why we added the lookback override in ResSim 3.5, here's the story... 

Pure flood control reservoirs (or dry dams) have historically been a "data problem" for ResSim and its modelers.  The primary problem is that the pool definition of a dry dam is often incomplete (from ResSim's perspective).  This is because a dry dam has a stream running through it whose channel is not usually included in the pool definition and thus the bottom of the pool (elevation of zero storage) usually starts at or above the stream's bank elevation.  To add to the problem, the invert of the lowest outlet of the dam usually coincides with the invert of the stream.  As a result, if the pool elevation is measured from a point within the channel, then during low-flow periods when the reservoir is "not storing", the measured pool elevation will be below "zero storage" of the reservoir and ResSim just doesn't understand how to "release water" from zero storage.  You see, the computations were originally designed on the premise that "you have to have water to release water".

Although we believe that ultimately the modeler should recognize that the stream channel running through the reservoir represents storage in the pool (and should adjust the pool definition accordingly), we decided to try to address some of the issues associated with dry dams in the computations so that ResSim did not continue to generate non-sensical results.  One of the changes included this override so that the mass balance computations were not starting at a point of "negative storage".

RSS-590 - Getting issue details... STATUS

Water Account Sets may appear more than once in the account set selector of the Alternative Editor.

We have encountered a user interface error that we have been unable to "make repeatable" (sometimes it happens and sometimes it doesn't and we cannot isolate a set up steps to make it occur).  When it occurs, one or more available water accounts sets will be listed more than once in the list of available water account sets.  This list appears when you attempt to select a water account set at the bottom of the Operations tab of the Alternative Editor:

Testing has shown that the repeated entries are not independent water account sets with the same name; rather they are simply duplicate entries in the list.  You can choose any one of the duplicated entries and ResSim will get the correct water account set you identified/selected.  When we have been able to make this problem "repeatable" so that we can find it in the code, we'll fix it.

RSS-255 - Getting issue details... STATUS