[Bug] Resume with multiple particle_types by cgeudeker · Pull Request #115 · geomechanics/mpm

cgeudeker · 2025-12-14T15:59:55Z

Describe the PR
When resuming a simulation with multiple particle_types, a full set of particles would be generated for each particle type. Additionally, it seems that each instance of the same particle type would be loaded in full, though subsequent generation would likely replace the previous. As such the following modifications have been made:

In ParticlePODTypeName, each distinct particle type has been assigned a specific POD type name, though these all lead to the eventual use of the "particles" POD type for file reading and writing.
In initialise_particle_types, a modification has been made to only add distinct particle types.
New .h5 files for each particle_type will be generated as a result, ensuring no multiple generations of the same particle upon resume.

Related Issues/PRs
N/A

Additional context
N/A

…sures that resume does not load particle types multiple times. Also only adds unique particle types to particle_types_. Not clanged. Not tested.

codecov · 2025-12-14T16:37:54Z

Codecov Report

❌ Patch coverage is 86.98630% with 38 lines in your changes missing coverage. Please review.
✅ Project coverage is 95.71%. Comparing base (b690d4a) to head (4e248b4).
⚠️ Report is 52 commits behind head on master.

Files with missing lines	Patch %	Lines
tests/io/write_mesh_particles.cc	77.65%	38 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #115      +/-   ##
==========================================
- Coverage   95.76%   95.71%   -0.05%     
==========================================
  Files         244      245       +1     
  Lines       51467    51730     +263     
==========================================
+ Hits        49284    49509     +225     
- Misses       2183     2221      +38

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

bodhinandach

@cgeudeker Thanks for finding and fixing this. Perhaps it is good to make some tests, if it is not too difficult?

cgeudeker · 2025-12-14T19:33:37Z

@cgeudeker Thanks for finding and fixing this. Perhaps it is good to make some tests, if it is not too difficult?

Yes will work on a couple.

bodhinandach · 2025-12-17T10:16:26Z

-    for (const auto ptype : particle_types_) {
-      std::string attribute = mpm::ParticlePODTypeName.at(ptype);
-      std::string extension = ".h5";
-
-      auto particles_file =
-          io_->output_file(attribute, extension, uuid_, step_, this->nsteps_)
-              .string();
-
-      // Load particle information from file
-      mesh_->read_particles_hdf5(particles_file, attribute, ptype);
-    }
-


Any specific reasons why this is moved to read_hdf5() function? Just to tidy it up?

Yes its mainly a tidy up, better follows the write approach as well. Just makes it a little more readable in my opinion, can switch it back if we want.

cgeudeker · 2025-12-17T10:37:29Z

Updates from attempts with multi-particle-type simulations with pml simulation:

🟢 Write functions working as expected in serial without resume.
🟢 Read and write functions working as expected in serial after resume.
🟡 Write functions maybe working with mpi without resume.
🟡 Read and write functions maybe working with mpi after resume.

Received a segmentation issue in the first time simulating with MPI and then received the previously observed pml-specific material information error in the first resume attempt. I have not been able to reproduce either and have only had it happen in the first instance of using either. After first instances, both have worked in each call so far. Screenshots of both cases below.
Without resume:

With resume:

…ultiple particle types

bodhinandach · 2026-03-01T23:15:22Z

@cgeudeker Would you be able to confirm if you have fixed the latest reported problem of seg fault in MPI resume?

bodhinandach

@cgeudeker Thanks for the effort. Overall, looks good to me. But I have some questions that I would like to understand.

bodhinandach · 2026-03-02T07:00:33Z

-    auto pod = std::static_pointer_cast<mpm::PODParticle>((*pitr)->pod());
-    particle_data.emplace_back(*pod);
+    if (particle_type == (*pitr)->type()) {
+      auto pod = std::static_pointer_cast<mpm::PODParticle>((*pitr)->pod());


This casting to mpm::PODParticle means that the different particle types should have the same POD t,ype right? That means single-phase particles cannot be output together with two-phase particles since they have different POD types. Is that the intention? I guess, we are not going to run a scenario of both multi-phase particles and single-phase particles simulated at the same time, right?

Maybe not true, since if there are different particle types, they're gonna call different functions from mpm_base.tcc.

The purpose of this check is just to confirm that only particles of the same particle type are output to the file that is being written in a given instance of the function call. I would assume all particles of a given type would have the same POD.

bodhinandach · 2026-03-02T07:01:20Z

-    particle_data.emplace_back(*pod);
+    if (particle_type == (*pitr)->type()) {
+      auto pod =
+          std::static_pointer_cast<mpm::PODParticleTwoPhase>((*pitr)->pod());


Same here, but vice versa.

Same here....

bodhinandach · 2026-03-02T07:04:41Z

+//! Read HDF5 files
+template <unsigned Tdim>
+void mpm::MPMBase<Tdim>::read_hdf5() {
+  // Read hdf5 file for single phase particle


Comment may be misleading

bodhinandach · 2026-03-02T07:07:31Z

-      // Load particle information from file
-      mesh_->read_particles_hdf5(particles_file, attribute, ptype);
-    }
+    this->read_hdf5();


I am not too sure what the necessity is to bundle them into a single function. Is this just to improve readability? Or is there any specific efficiency reason?

Only to improve readability and match the same naming conventions that the write pathway has. Can change back if desired.

cgeudeker · 2026-03-16T20:00:59Z

@cgeudeker Would you be able to confirm if you have fixed the latest reported problem of seg fault in MPI resume?

Yes this has been fixed. Simple 1D bar compression with two particle types, successfully ran in the four aforementioned cases (serial or mpi with and without resume) and yielded the same results.

cgeudeker added 2 commits December 13, 2025 13:58

Modifications to save different particle types to different files. En…

3694874

…sures that resume does not load particle types multiple times. Also only adds unique particle types to particle_types_. Not clanged. Not tested.

Clang formatted. Passes mpm tests.

5893b3f

cgeudeker added the bug Something isn't working label Dec 14, 2025

cgeudeker assigned bodhinandach, ningyiw01 and cgeudeker Dec 14, 2025

bodhinandach self-requested a review December 14, 2025 18:30

bodhinandach reviewed Dec 14, 2025

View reviewed changes

Comment thread include/solvers/mpm_base.tcc Outdated

cgeudeker added 2 commits December 16, 2025 17:14

New save structure for .h5 files. Not yet passing all tests.

d6fe5ed

Simplified write-read setup for HDF5. No updated test cases.

5fbb7b0

bodhinandach requested a review from Curiim December 17, 2025 10:11

bodhinandach reviewed Dec 17, 2025

View reviewed changes

Add test case for starting and resuming an implicit simulation with m…

4e248b4

…ultiple particle types

bodhinandach reviewed Mar 2, 2026

View reviewed changes

bodhinandach unassigned bodhinandach and ningyiw01 Mar 2, 2026

Conversation

cgeudeker commented Dec 14, 2025

Uh oh!

codecov Bot commented Dec 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

bodhinandach left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

cgeudeker commented Dec 14, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

cgeudeker commented Dec 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bodhinandach commented Mar 1, 2026

Uh oh!

bodhinandach left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cgeudeker commented Mar 16, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

codecov Bot commented Dec 14, 2025 •

edited

Loading

cgeudeker commented Dec 17, 2025 •

edited

Loading