Throwing an error when dt has too high precision #1558
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As found by @sruehs and @ezekiel-lemur, parcels output can 'skip' timesteps when
dthas a very high precision (i.e. many digits behind the comma). This is very likely because of the test done when considering which particles to writehttps://github.com/OceanParcels/parcels/blob/a0ea4044c3ced351b65ec3a19ea3bd8d29f8bd3d/parcels/particledata.py#L322-L328
Solution is to throw an error when users provide a
dtthat has higher precision than 1e-6. Note that parcels before already threw an error whendt < 1e-6, now a value likedt=1+1e-6would also be caughtThe new testcase in example_globcurrent (with
dt = 81.2584344538292) indeed shows how the output file misses a few time-snapshots if this error is not raised