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

Add Particle I/O: restart & restart_checkpoint #342

Merged
merged 23 commits into from
Aug 7, 2024

Conversation

JBlaschke
Copy link
Contributor

Adding particle I/O. Working on proper tests now.

This will also read FHDeX particles.

@ax3l let me know if you have early feedback

@ax3l ax3l self-requested a review July 30, 2024 00:46
@ax3l ax3l added the component: particles Particles label Jul 30, 2024
Copy link
Member

@ax3l ax3l left a comment

Choose a reason for hiding this comment

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

Looks great so far! 👍

tests/test_plotfileparticledata.py Outdated Show resolved Hide resolved
tests/test_plotfileparticledata.py Outdated Show resolved Hide resolved
@BenWibking
Copy link
Contributor

Does a separate particle container need to be created for each app? We have this (+more to come):
https://github.com/quokka-astro/quokka/blob/c37cfb21266fb793d2ff39d865a3f2174a3912e9/src/particles/CICParticles.hpp#L25

@BenWibking
Copy link
Contributor

The real problem is that we will have some ParticleContainers with a variable number of real components for each simulation...

@ax3l
Copy link
Member

ax3l commented Aug 1, 2024

Does a separate particle container need to be created for each app? We have this (+more to come):
https://github.com/quokka-astro/quokka/blob/c37cfb21266fb793d2ff39d865a3f2174a3912e9/src/particles/CICParticles.hpp#L25
The real problem is that we will have some ParticleContainers with a variable number of real components for each simulation...

Yes, so far.
I see two ways to solve this:
a) expose the header for PC creation, so you can specialize for your code downstream or
b) more forward looking, codes could try to use a minimal set of compile-time components (e.g., ND positions only in pure SoA format) and instead use runtime components for all other attributes. That way, we only have to specialize one base class that everyone ca use. I doubt there is a significant performance impact, but we need to evaluate that in applications.

Another change I will put into BLAST codes is to use the Polymorphic particle container, where Arena is not a template parameter. On the PC level, having the Arena a C++ template appears unnecessary to me and should not have any performance benefits (in symmetry, the MultiFabs also have it only as a runtime parameter).

@ax3l ax3l marked this pull request as ready for review August 2, 2024 01:23
@ax3l ax3l self-assigned this Aug 2, 2024
@JBlaschke
Copy link
Contributor Author

I'm currently stalled on a head-scratcher: when I run test_aos.py on its own, it works fine. If I run it in pytest I get:

tests/test_aos.py::test_aos_init amrex::Error::0::ParmParse::Initialize(): already initialized! !!!

Most strange ... any advice?

@ax3l
Copy link
Member

ax3l commented Aug 2, 2024

The issue is a double init. You can remove this:
#342 (comment)

We init and finalize amrex in a fixture for all tests here:
https://github.com/AMReX-Codes/pyamrex/blob/development/tests/conftest.py
so this is not needed again in the test file.

To run only your latest test while you develop, run this:

python3 -m pytest tests/test_plotfileparticledata.py

the tests are not intended to be run without the pytest module, but can be sub-selected for productivity to feel like a standalone script.

@ax3l
Copy link
Member

ax3l commented Aug 4, 2024

It looks like when building in debug mode (with more checks), the test still fails.

@JBlaschke
Copy link
Contributor Author

Any idea why the tests fail? Seems to depend on compiler version... Which is never a good sign...

@ax3l
Copy link
Member

ax3l commented Aug 4, 2024

Please see comments from yesterday. It fails in debug mode, where AMReX does more checks for validity. Likely because the added positions do not line up with the domain decomposition.

from last commit
pre-commit hook fix. the lambda is named anyway here
Use `py::overload_cast` helper
src/Particle/CMakeLists.txt Outdated Show resolved Hide resolved
Rpart[i + particles_tile_ct].to_soa(p)
particles_tile_ct += len(aos_numpy)

pc.redistribute()
Copy link
Member

@ax3l ax3l Aug 5, 2024

Choose a reason for hiding this comment

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

@JBlaschke This fixed the pc.OK() issue that you saw when running AMReX in Debug mode. Please double check (maybe with print debugging) if this does what you expect to do or if you geometry needs adjustment, if the pc.redistribute removes particles.

@ax3l ax3l changed the title Add Particle I/O Add Particle I/O: restart & restart_checkpoint Aug 5, 2024
Copy link
Member

@ax3l ax3l left a comment

Choose a reason for hiding this comment

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

Thank you, Johannes! 🚀 ✨

@ax3l ax3l enabled auto-merge (squash) August 5, 2024 16:37
@ax3l ax3l mentioned this pull request Aug 5, 2024
void init_ParticleContainer_FHDeX(py::module& m) {
using namespace amrex;

make_ParticleContainer_and_Iterators<Particle<16, 4>, 0, 0>(m);
Copy link
Member

Choose a reason for hiding this comment

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

@JBlaschke do you need this for 1D, 2D and 3D AMReX builds or only for 3D?

@ax3l ax3l merged commit 04d8110 into AMReX-Codes:development Aug 7, 2024
17 of 20 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants