temporalmax/min diagnostics with spin_up_time give incorrect results

[Stephan Kramer]

The temporalmin and temporalmax diagnostic fields are initialised at the first timestep with the field values of the source field at the first time step. In subsequent timesteps the minimum/maximum at each node between 1) the minimum/maximum over the previous timesteps (stored in the diagnostic field itself before being updated), and 2) the current source field value is computed, and used to update the diagnostic field. When a spin_up_time is specified this updating only happens after the specified time. At the first timestep after this time however, the diagnostic field is still initialised with the source field value at timestep 0 - so if, in some places, this initial value is already lower (higher) than the field value will ever reach *after* the spin up time, the diagnostic field will never be updated and always keeps its initial value.

A typical example is a FreeSurface field initialised to zero, after the spin up time it may be that the free surface only varies between strictly positive values, in which its temporalmin will incorrectly remain zero - or vice versa the FreeSurface, in some places, may only vary between striclty negative values, in which case its temporalmax is incorrectly calculated to be zero.

What should happen is that in the first timestep after the spin-up time it should ignore previous values of the diagnostic field. Working out whether we are in the first timestep after the spin_up_time is tricky, due to adaptive timesteps etc. A slightly ugly way to achieve this is to initialize the field with huge() or -huge().

Anyone a better idea?

[Jon Hill (jon-hill)]

Nope, initialise with huge()/-huge() :)