jgiven100 commented 3 years ago

State_vars smoothing for post-processing & upcoming features

Summary

This feature allows user selection of a single state_vars for smoothing via the input .json. The smoothed state_vars will be used in potential upcoming features (e.g. particle removal), visualization, and other post-processing. The structure of this feature is almost entirely based on the current pressure_smoothing implementation.

Motivation

Current post-processing and visualization can utilize smoothed state_vars
Upcoming features will benefit from selecting between regular and smoothed state_vars

Example

Below shows pdstrain used as part of a particle removal criteria for a borehole model. Without adjusting the current MPM calculations, having access to a pdstrain_smooth provides a more realistic particle removal geometry for the same time step:

Design Detail

Within the input .json the state_vars to be smoothed will be defined within the analysis section:

  "analysis": {
    ...,
    "state_vars_smoothing" : "pdstrain"
  },

Within the node.h the a private state_vars_ parameter and public state_vars() and update_state_vars() functions will be added. The input for update_state_vars() will include:

private:
  //! state_vars_
  Eigen::Matrix<double, 1, Tnphases> state_vars_;

For the node.tcc the state_vars_ will be initialized to 0. update_state_vars() will have similar implementation to the current update_mass_pressure():

//! Update state_vars at the nodes from particle
template <unsigned Tdim, unsigned Tdof, unsigned Tnphases>
void mpm::Node<Tdim, Tdof, Tnphases>::update_state_vars(
    unsigned phase, double mass_state_vars) noexcept {
  // Assert
  assert(phase < Tnphases);

  const double tolerance = 0.;
  // Compute state_vars
  if (state_vars_(phase) >= tolerance) {
    node_mutex_.lock();
    state_vars_(phase) += mass_state_vars / mass_(phase);
    node_mutex_.unlock();
  }
}

Both map_state_vars_to_node() and compute_state_vars_smoothing() will be added to particle.tcc. Here the state_vars of interest will be pulled from the input .json and passed to map_state_vars_to_node().

//! Map particle state_vars to nodes
template <unsigned Tdim>
bool mpm::Particle<Tdim>::map_state_vars_to_nodes(unsigned phase) noexcept {
  // Mass is initialized
  assert(mass_ != std::numeric_limits<double>::max());

 auto state_vars_smooth= io_->json_object("state_vars_smoothing");

  bool status = false;
  // Check if particle mass is set and state_vars is found
  if (mass_ != std::numeric_limits<double>::max() &&
      (state_variables_[phase].find(state_vars_smooth) !=
       state_variables_[phase].end())) {
    // Map particle state_vars to nodes
    for (unsigned i = 0; i < nodes_.size(); ++i)
      nodes_[i]->update_mass_state_vars(
          phase, shapefn_[i] * mass_ * state_variables_[phase][state_vars_smooth]);

    status = true;
  }
  return status;
}

// Compute state_vars smoothing of the particle based on nodal state_vars
template <unsigned Tdim>
bool mpm::Particle<Tdim>::compute_state_vars_smoothing(unsigned phase) noexcept {
  // Assert
  assert(cell_ != nullptr);

  auto state_vars_smooth= io_->json_object("state_vars_smoothing");

  bool status = false;
  // Check if particle has a valid cell ptr
  if (cell_ != nullptr && (state_variables_[phase].find(state_vars_smooth) !=
                           state_variables_[phase].end())) {

    double state_vars = 0.;
    // Update particle state_vars to interpolated nodal state_vars
    for (unsigned i = 0; i < this->nodes_.size(); ++i)
      state_vars += shapefn_[i] * nodes_[i]->state_vars(phase);

    state_variables_[phase][state_vars_smooth] = state_vars;
    status = true;
  }
  return status;
}

The smoothing procedure will be called from mpm_base.tcc same as current pressure smoothing if state_vars_smoothing is present in the input .json.

    // Smooth state_vars for particle removal
   this->state_vars_smoothing(phase);

Note

A very similar implementation scheme has bee successful within a personal repo, but hard-coded for pdstrain smoothing. The focus of the RFC is making nomenclature generic and allowing for state_vars selection via input .json

Drawbacks

Implementation only allows for smoothing a single state_vars
Smoothing procedure is separate from MPM calculations, thus is a "dead-end" calculation
Requires updates to most/all material models

Rationale and Alternatives

Main alternative is to not pursue this feature
Due to the similarities to pressure smoothing, design is mostly based on existing code structure (i.e. limited other designs were considered)
Without this implementation, potential particle removal feature is less likely

Prior Art

Much of the proposed implementation is based of pressure_smoothing: https://github.com/cb-geo/mpm/pull/396

Unresolved questions

What is the best way to allow for multiple state_vars to be smoothed?
Are there potential features beyond particle removal that benefit from "dead-end" smoothing procedure?

Changelog

(Sept. 10) Remove smooth state variable from material
(Sept. 10) Update to replace selected state_vars with smoothed versions, not to make copies. This is the typical scheme for "smoothing" procedures

jgiven100 commented 3 years ago

RFC updated:

smooth state variable removed from material class
Smoothing scheme now replaces selected state_vars instead of making copies. (This is the expected default behavior for "smoothing" features).

stale[bot] commented 3 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.

kks32 commented 3 years ago

@jgiven100 I'll keep this issue open

stale[bot] commented 3 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.

cb-geo / mpm