#942 Schedule or stoptime problem,

[nikhilgupta10]

Solutions are different in a model that includes or does not include a schedule; the schedule is never used by any of the objects. Adding the schedule makes the solution incorrect. In addition, when adding a stoptime to the model, the solution is always correct.

Under the hood, the delta from t0 -> t1 is correct (60 seconds, due to a 60s recorder in the model) in the \correct\ cases, but suddenly changes to 'random' values between 600 and 6000 in the incorrect cases.

Suspect either a memory error in the schedule or an adverse interaction with the stoptime.

Simple sample file is attached.

,

[nikhilgupta10]

nikhilgupta10 imported these comments from Sourceforge: "dchassin":- status: new --> accepted ,

"dchassin":Confirm erroneous results on Mac OSX version as well (see attached). The climate object updates differently depending on whether the stoptime is included.,

"dchassin":The problem appears to be in core/exec.c:exec_sync_set. There is a test for changing the sync time based on a soft-sync event for which the corresponding assignment to step_to is missing a unary negation operation. This causes erroneous results in any case where an internal object or property causes in a previously found sync time to be changed. The negative value can cause other objects that use valid_to to get stuck in object_sync until the valid_to time is run out.

The fix is being testing in ticket/942 as I write. Discussion of whether a patch for branch/3.2 is required will be follow.,

"dchassin":Mac OSX test ok. See attached (matlab and mysql error were expected). Posted to ticket/942 at r5373.,

"dchassin":Windows X64 test ok. See attached (matlab error was expected).,

"dchassin":Windows X64 replacement EXE is attached if anyone would like to test it on their system.,

"dchassin":Mac OSX replacement bin is attached for testing purposes. It replaces /usr/local/bin/gridlabd.bin. ,

"dchassin":- status: accepted --> assigned

• assigned_to: David P. Chassin --> Jason Fuller ,

  "dchassin":The fix is ready to be merged to trunk and branches as appropriate.,

  "dchassin":The following patch is proposed to fix this problem.,

  "dchassin":The patch was applied to branch/3.2 at r5400,

  "andyfisher":Can we close this ticket then?,

  "jcfuller":If it's been merged, then yes.,