Conversation
…sures that resume does not load particle types multiple times. Also only adds unique particle types to particle_types_. Not clanged. Not tested.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #115 +/- ##
=======================================
Coverage 95.76% 95.76%
=======================================
Files 244 244
Lines 51467 51470 +3
=======================================
+ Hits 49284 49287 +3
Misses 2183 2183 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
bodhinandach
left a comment
bodhinandach
left a comment
There was a problem hiding this comment.
@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. |
| //! Read HDF5 particles with type name | ||
| template <unsigned Tdim> | ||
| bool mpm::Mesh<Tdim>::read_particles_hdf5(const std::string& filename, | ||
| const std::string& type_name, | ||
| const std::string& particle_type) { | ||
| bool status = false; | ||
| if (type_name == "particles" || type_name == "fluid_particles") | ||
| status = this->read_particles_hdf5(filename, particle_type); | ||
| else if (type_name == "twophase_particles") | ||
| status = this->read_particles_hdf5_twophase(filename, particle_type); | ||
| return status; | ||
| } | ||
|
|
There was a problem hiding this comment.
Wouldn't we still need these lines?
There was a problem hiding this comment.
Becomes the read_hdf5() function in mpm_base.
| 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); | ||
| } | ||
|
|
There was a problem hiding this comment.
Any specific reasons why this is moved to read_hdf5() function? Just to tidy it up?
There was a problem hiding this comment.
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.
| //! Read HDF5 particles with type name | ||
| //! \param[in] filename Name of HDF5 file to write particles data | ||
| //! \param[in] typename Name of particle type name | ||
| //! \param[in] particle_type Particle type to be generated | ||
| //! \retval status Status of reading HDF5 output | ||
| bool read_particles_hdf5(const std::string& filename, | ||
| const std::string& type_name, | ||
| const std::string& particle_type); |
There was a problem hiding this comment.
Becomes the read_hdf5() function in mpm_base.
|
Updates from attempts with multi-particle-type simulations with pml simulation:
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. |
3 participants
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:
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.initialise_particle_types, a modification has been made to only add distinct particle types.Related Issues/PRs
N/A
Additional context
N/A