Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Warning for misaligned timestepping and outputdt #1697

Open
michaeldenes opened this issue Sep 10, 2024 · 1 comment
Open

Warning for misaligned timestepping and outputdt #1697

michaeldenes opened this issue Sep 10, 2024 · 1 comment
Labels

Comments

@michaeldenes
Copy link
Member

michaeldenes commented Sep 10, 2024

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
Copy link
Member

Good point; thanks for raising @michaeldenes! I agree that a warning when outputs 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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Backlog
Development

No branches or pull requests

3 participants