Warning for misaligned timestepping and outputdt

[michaeldenes]

There are a number of parameters necessary for a parcels simulation. Two very important ones are in the pset.execute() statement, specifically the outputdt which determines the frequency particle positions and variables are stored on disk, and dt which is the timestepping frequency.

Currently, there are no errors or warnings raised when outputdt is not an integer multiple of dt, and quite frankly, I have no idea what the result of that is.

Consider a simulation with the following settings: runtime = timedelta(days=1), outputdt = timedelta(hours=1), and dt = timedelta(minutes=25). We expect 24 observations, spaced 60 minutes apart. However, when performing the timestepping procedure, we will compute the particle locations (and other variables) at times 0m, 25m, 50m, 1h15m, 1h40m, 2h5m, and so on. Not until 6h have passed will the timestepping procedure occur at the same time as the output procedure.

While I don't think we should force users to save their particle locations at some integer multiple of their timestepping scheme, I do think a warning should be displayed, letting the user know that their output frequency does not align with their timestepping scheme.

On writing this, a similar argument can be made that the runtime and outputdt should line up as well!

@VeckoTheGecko @sruehs

[erikvansebille]

Good point; thanks for raising @michaeldenes! I agree that a warning when outputdt is not an integer multiple of dt would be appropriate.

On writing this, a similar argument can be made that the runtime and outputdt should line up as well!

That I'm not sure about. Users may want to run 1 (second) longer so that the last output is also stored in the zarr file (see also Caveat 3 at the Kernel Loop tutorial)

[erikvansebille]

Note that #1739 si also related to this; providing a warning when not all particlemstarttimes are multiples of outputdt