Open michaeldenes opened 1 month ago
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)
Note that #1739 si also related to this; providing a warning when not all particlemstarttimes are multiples of outputdt
There are a number of parameters necessary for a
parcels
simulation. Two very important ones are in thepset.execute()
statement, specifically theoutputdt
which determines the frequency particle positions and variables are stored on disk, anddt
which is the timestepping frequency.Currently, there are no errors or warnings raised when
outputdt
is not an integer multiple ofdt
, 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)
, anddt = 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
andoutputdt
should line up as well!@VeckoTheGecko @sruehs