#66 Pipistrelle aborts run at random times

[John Barnes]

Longer runs (about one hour elapsed time) of a three-component composition Bawdsey - MESO_i - SCAPE_1 simulating 200 years of beach evolution always fail at random times (e.g. after 31 years, 55 years).

The attached file CapturedOutput.txt shows an extract from the VS Output view for one such run that failed after 115 simulation years and some months. The run is normal up to time 20689.617935175 then sticks in a loop of repeated updates (the update function in the engine is not called) that trigger an error message and abort after 1000 repeats. Experimentation showed that a run could be nursed through to a successful conclusion by putting a conditional breakpoint (condition: updateCount > 1) at line 85 in OutputSpaceTime.cs which increments updateCount. This indicates that the underlying problem is timing-related, not a memory problem.

As a workaround (fix?) for this problem, I made the changes to OutputSpaceTime.cs shown in the attached file patchOutputSpaceTime.txt which introduces a 1 second Sleep when updateCount goes over 1.

[John Barnes]

I have seen this problem again (with the Sleep() in place) in a scenario where the function CanGetValueSetWithoutExtrapolationAt() had an argument with a time value of 11716.444770600003 and the Last item in the _cache had a time value of 11716.4447706. One of the components in the composition was compiled with SilverFrost FORTRAN will the others were complied with gFORTRAN and the calculated time values differed very slightly.

Seems wrong that this statement:

        return Time.EndTime(_cache.Last().Time) >= Time.EndTime(at);

is comparing double values for equality with no tolerance. The Time class has some support for tolerant comparisons but that is not being used in this case.