Bug if first output time = simulation start time

[adrien-ga]

Simstrat seems to crash (or rather, start an infinite loop...) if the first output time corresponds exactly to the simulation start time, and is specified in a file. Did not check what happens also if output times are before the simulation start time and/or if they are specified directly in the par file.

[d-vanzo]

I am not able to reproduce the bug... can you share a TestCase_LakeZurich.par that causes the crash? Then I can have a look.

[adrien-ga]

Here you go, this setup crashes. From a warning message due to forcing, it actually seems that Simstrat does not start exactly when it is instructed to (at 8308.4), but just a little bit later, so that it cannot write that exact time as output.

[adrien-ga]

Can somehow not attach the file, here it is... Q:\Diverses\Scratch-Disk\Surf\Adrien\LakePiburger.zip

[d-vanzo]

I found the bug but I did not fix because the timestep&output_time handling concept is not clear to me (i.e. the adjusted timestep)... so I do not want to mess up.

Simstrat does not start exactly when it is instructed to (at 8308.4)

...This is not the problem, the fact that the first time is 8308.39999 is just rounding stuff.

The bug is in the timestep updating (sismstrat.f90, line 171). In case of first output time = starting time the dt is set to 0.0 and the marching loop get stucked. There are multiple ways to fix this, in case we can discuss.

[f-baerenbold]

Well, this is not really a bug. If the first output time corresponds exactly to the simulation start then what actually should be printed are the initial conditions. Do we want this? If yes, I can add it as an option, but is it really helpful? Of course it is not helpful either that the code runs infinitely without warning at the moment... I would prefer to just print out the initial conditions anyway (or not) and then have an error message if the first output time corresponds "exactly" to the simulation start. Because then the dt is actually zero for the first step and we will get NaN's if it is calculated.

While looking for the "bug I actually found a real bug which occurs when the output time interval is smaller than the dt chosen in the par-file. I will correct it once we have decided on the matter above.

Let me know.

[adrien-ga]

Hey Fabian and Davide Thanks for your answers! I agree with you Fabian, but still Simstrat must have kind of an expectable behaviour: if the output time is requested, then it must be printed, unless of course it does not fall within the simulation bounds at all - then there should be a message and an error. That allows also to run automated things such as PEST without having to take care of whether Simstrat wants to print initial conditions or not, right? When I run the code I provided you, Simstrat says "first forcing date after simulation start time" and prints two dates, one of which is the forcing start date, the other one is a time significantly after 8308.4 - I thought that this second date was the simulation start, but apparently not? Then what is it? Cheers, Adrien

[f-baerenbold]

Exactly, the behaviour should be "expectable". It is just not very neat to define a threshold below which the initial conditions will be printed. But the threshold is necessary because if the dt is too small (or 0 in the extreme) we might have problems in the numerics. But we probably just have to do this.

Your second paragraph is something different and has nothing to do with output times. The warning occurs because the simulation start time is before the first meteorological forcing data and so Simstrat will extrapolate the forcing data (but still issues a warning). The first date is the simulation start and the second date is the starting date of the forcing file.

[f-baerenbold]

Issue should be solved, please check updated version on the master branch (https://github.com/Eawag-AppliedSystemAnalysis/Simstrat/commit/759f4ec8906d2b4ffce806a064b2a029599a284c).