May 2014 Phil Bugs for RW 6.5
Edit 5-14-2014

3718: Crash changing the timestep in the Run control

• 5-13-2014 ... Bug3718 Git Branch ... on hold until next week.
• 5-05-2014
• 5-02-2014

Two of our 15 Accounting regression tests DO show this crash.  (This isn't just an old model thing, as I had suggested).

• accountingRules (274 daily timesteps)
  ... the similar accountingHeronInflow model does not crash (also 274 daily timesteps)
• WaterRightsTests

The other Accounting regression tests also do not show the crash:

• urgwomPlanning -- only a 30 daily timestep model. 
  
• 10 variations of the "wra*" -- only 10 daily timesteps.

Debug builds show two areas of assertion failures.  The fix I implemented for the first (not checked in to the trunk) is necessary to get to the second:

1. In the process of the Link Manager's "checkAllSharing" method -- which starts or stops series slot series sharing (as appropriate) -- the SeriesSlot method which starts sharing (p_startSharingSeriesWith) forces affected MultiSlots to recompute.  That fails debug-only assertions because various linked slots may not yet have been set to the new timestep size (monthly).  I added a mechanism to conditionally refrain from forcing MultiSlot recomputations down in that SeriesSlot method, and instead return that information to the caller (LinkMgr) to perform those recomputations after all relevant series slots have be set to the new timestep size.
    
2. In the course of applying the Aggregated Inputs (the code Neil implemented), setting values on an Accounting slot (which is now monthly) encounters inconsistent end-dates on the Flag series.  Enhanced debug code I created shows this data (the Flag series is missing one final timestep):

• CONSISTENCY FAILURE (Flag End);
• share 11-01-1996 00:00:00;
• flag 10-01-1996 00:00:00;
• @ slot Azotea Outlet^SanJuan.Outflow

WORKAROUND: The crash can be avoided by first re-synchronizing all slots (including Accounting, but excluding slots with a different timestep from the run) BEFORE changing the timestep size from daily to monthly.  (But this would have the effect of truncating Series Slot data after the Run Finish date; this is significant because we have developed a mechanism to aggregate Inputs in series data when moving to a larger timesteps -- only common transitions are supported).

The code changes I have in the temporary Bug3718 git branch are:

(For #1, above):

• Optional parameter (can be NULL) added to these two methods to return information about the MultiSlots needing to be recomputed:

1. SeriesSlot::p_startSharingSeriesWith (SeriesSlot *other,
       QList<MultiSlotLinkSlotPair>* multiSlotLinkPairsNeedingRecomp);
2. LinkMgr::checkSharing(Link*, QList<MultiSlotLinkSlotPair>* multiSlotLinkPairsNeedingRecomp) const
      (CALLED FROM LinkMgr::checkAllSharing()).

• Cleanup and enhancements to this diagnostic check method, reporting more information about Split Series inconsistency problems.  This changes are limited to this single diagnostic method:

SeriesSlot::p_checkSplitSeriesConsistency() const

I recommend adopting these changes (in the actual trunk).

Here is a view of the "Bug3718" git branch:
https://cadswes2.colorado.edu/internal/cgi-bin/gitweb/gitweb.pl/builds.git/shortlog/refs/heads/Bug3718
... see the top-most commit.

I will continue the analysis of this bug.

I tested a load of the bug model with series sharing disabled: That avoids the crash. I also tried saving that model (with series sharing disabled), and the reloading it. Reloading that no-sharing copy exhibited the crash only when series sharing was enabled in RiverWare. The only relevant criteria is whether "sharing" is active in the current RiverWare session.

Note the size difference of the two saved files (both gzip'ed):

• 110,528 KB -- bug3718.gz
• 153,592 KB -- bug3718_noshare.gz

Well, I might have thought that Gnats 3718, being reported so long ago, was unlikely to still be relevant.  I tried a lot of models -- all but one (see following) succeeded in changing from a daily to monthly timestep.  I DID find an LCRA accounting model which reliably exhibits this crash in both release and debug builds.  I've copied it to the bug directory as bug3718.gz. In a debug build, an assertion fails (but I don't see that assertion reported in the release build).

Running the model is not necessary. Just switch it from a daily timestep to a monthly timestep.  The LinkMgr::checkSharing() method determines that the series slots on both sides of a link should have shared series, but don't currently.  In attempting to 'start sharing', down in SeriesSlot::p_propagateValue (called from assignStdValue()), a relevant link which is found to 'be sharing', isn't.  That fails an assertion.

Since this is caused by changing the model timestep, I did check to see if this was a mistake about trying to start series sharing with two slots having different step sizes.  That doesn't seem to be it; the two slots (up in LinkMgr::checkSharing at least) both seem to have monthly timesteps (at least as indicated at the SeriesSlot level).

This 9-year-old bug may still be worth pursuing.

--- (end) ---