cb-geo / mpm

CB-Geo High-Performance Material Point Method
https://www.cb-geo.com/research/mpm
Other
247 stars 82 forks source link

Output variable libraries #594

Closed bodhinandach closed 4 years ago

bodhinandach commented 4 years ago

Describe the feature Generalization of particle output variables other than state_vars

Additional context I am thinking we should have a "vtk" input parameter back in the JSON file to output necessary variables. It doesn’t work at the moment after we change to particle_tensor_data, i.e. PR #583. Also, the only way to write an output implementation is to write it inside state_variables. This mess up the initial definition of state_variables, so I don’t think it is good. We can hardcoded it to mpm_base, but that's not the best way to do it again and again.

Instead, we should create a list (or library) of output variables, which can be simply a string, or some other advance class type if necessary, and should be associated with the type of the same variable. This can be scalar (including bool, int, unsigned, and double), vector, or tensor (2nd order tensor). This works just like a register.

There, when we have the list of output variables read from JSON, we just need to first validate, with respect to the default parameter, i.e. displacements, velocities. Stresses and Strains can be set as non-default as the automatic print now slows down the output as it results in 9 component prints, instead of 3 previously. After validation to remove repetition, we pass the validated string list into the library we defined to get the data type associated with each output variable.

The next process is straight forward, i.e. to pass this to the property_data in particle, which I think should be a function with a template of the data type, or at least an unsigned of size n={1, 3, or 9}. We can even generalize this by returning Eigen vector data type of size n. There, we can implement which function associated to return the output variables at the particle level (the same way or similar to the current code).

The current output routines can be used to produce the VTK file, or at least with minimum modification.

leo-py commented 4 years ago

sNew to here. I totally agree with your comment.

While you are thinking about refactoring code in the outputs part, I have a suggestion for you to consider. Currently, the mpm program generates outputs in hdf5 format by default. However, it will also generate outputs simultaneously in vtk and Partio formats if both vtk and Partio tools are installed on the platform. This brings extra computational cost and may be unnecessary. In addition to prescribe some output variables, it may also be possible to prescribe output format(s) by adding an option in the input json file to save some computational cost.

The code associated with generating outputs is shown below. See Line 339-350 in the mpm_explicit.tcc file.

    if (step_ % output_steps_ == 0) {
      // HDF5 outputs
      this->write_hdf5(this->step_, this->nsteps_);
#ifdef USE_VTK
      // VTK outputs
      this->write_vtk(this->step_, this->nsteps_);
#endif
#ifdef USE_PARTIO
      // Partio outputs
      this->write_partio(this->step_, this->nsteps_);
#endif
    }
bodhinandach commented 4 years ago

@leo-py Seems like a great idea. We will consider your thoughts. Many thanks

stale[bot] commented 4 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

bodhinandach commented 4 years ago

@kks32 Can we see this too while doing the refactor particle?