Skip to content

Conversation

@erikvansebille
Copy link
Member

This PR reverts to using float inside the kernel (as in v3), as performance tests have shown that this is approx 50% faster. See e.g. Parcels-code/parcels-benchmarks#1 (comment)

  • Chose the correct base branch (main for v3 changes, v4-dev for v4 changes)
  • Added tests

As performance tests have shown that this is approx 50% faster
@erikvansebille
Copy link
Member Author

Note that in this PR< we still assume that the user inputs particle.time, endtime, runtime, dt etc as np.datetime64 or np.timedelta64. This requires quite a bit of type-conversion under the hood. The code would het simpler if we expect (all/most of) these inputs to be floats too. Not sure if that's worth it, though

Copy link
Contributor

@VeckoTheGecko VeckoTheGecko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to adjust some things - not sure if that has to be in this PR though, happy for it to come in a different one

@github-project-automation github-project-automation bot moved this from Backlog to Ready in Parcels development Jul 28, 2025
@VeckoTheGecko VeckoTheGecko mentioned this pull request Jul 28, 2025
3 tasks
Small correctness fix. Otherwise could have run into edge cases with multiple fields defined on different (yet compatible) calendars.
@erikvansebille
Copy link
Member Author

We're not pursuing this anymore; getting good performance with numpy.datetime

@github-project-automation github-project-automation bot moved this from Ready to Done in Parcels development Sep 2, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

3 participants