Create XMPMExplicit solver to simulate the strain localization and OSO landslide

[yliang-sn]

Summary

This RFC is to propose the eXtended Material Point Method (XMPM) solver. The XMPM solver is to be used for modeling discontinuous problems.

Motivation

To extend the capability of treating discontinuity particularly for simulations of strain localization and OSO landslide.

Design Detail

Solver class: The class XMPMExplicit is created. It’s derived from the solver class MPMBase and has a similar scheme with traditional MPM. Take the USF for example, the additional initialization is needed including:

1. Read and initialize the discontinuous surface
2. Initialize the LSM values at the particles

main timestep loop:

1. Determine the cell type (regular, full-through, part-through) by the position of the crack surface.
2. Determine the node type (regular, enriched). The nodes of the full-through cell are enriched.
3. Map the particle mass, momentum to nodes (including enriched quantities) by iterating over all the particles.
4. Update the particle strain, stress
5. Solve the nodal momentum equation
6. Update the particle position, velocities
7. Update the position of discontinuous surface
8. Apply propagation law and update the LSM values (in the future) While mapping and updating, the formulations will be replaced by the XMPM scheme. Frictional contact on the discontinuous surface needs to be implemented.

Discontinuous description: The XMPMExplicit solver describes the discontinuities independent from the background grid. A class named DiscontinuousSurface used within the XMPMExplicit is implemented to store and update the information (such as the nodes and elements) of the surfaces.

//! discontinuity
  std::map<unsigned, std::shared_ptr<mpm:: DiscontinuousSurface >> discontinuities_;

Multiple cracks also can be handled.

Particle: namespace mpm::Particle::XMPM is created. scalar type: Level Set function values are needed for now, which is initialized by the crack surface and updated while propagating. The functions to update the particle positions, velocities, stresses, and strains are needed. The formulations will be different. These functions will be defined as free functions.

nodal_mass = nodes_[i]->mass(phase) + sgn(phi_) * nodes_[i]->mass_h(phase);
nodal_velocity += shapefn_[i] * (nodes_[i]->momentum(phase)+ sgn(phi_)*nodes_[i]→momentum_h(phase))/nodal_mass;
this->coordinates_ += nodal_velocity * dt;

Node: To handle the enriched quantities (mass_h_, momentum_h_, internal_force_, external_force_) for the enriched nodes, the nodal_properties will be used. https://github.com/cb-geo/mpm/issues/636#issue-618412909

//! Nodal property pool
std::shared_ptr<mpm::NodalProperties> nodal_properties_{nullptr};

The functions of the enriched nodes will be also defined as free functions.

Drawbacks

Unresolved questions

1. The discontinuous surface is predefined now. The initialization criterion need to be realized in the future
2. The propagation of the surface in 3D will be difficult.

   Prior Art

3. Liang Y, Benedek T, Zhang X, et al. Material point method with enriched shape function for crack problems[J]. Computer Methods in Applied Mechanics and Engineering, 2017: 541-562.
4. Nairn J A. Material Point Method Calculations with Explicit Cracks[J]. Cmes-computer Modeling in Engineering & Sciences, 2003, 4(6): 649-664.
5. Moes N, Dolbow J E, Belytschko T, et al. A finite element method for crack growth without remeshing[J]. International Journal for Numerical Methods in Engineering, 1999, 46(1): 131-150.

[kks32]

@yliang-sn Thank you for the RFC, but this does not provide sufficient design detail to review. Please provide code outlines, inheritance relationships, code snippets, and explain in detail so anyone who is not familiar with the method will be able to review understand the requirements. What properties would be needed in Particle, Node, and Element? Please provide class design outlines and code snippets. Also note #637 restricts inheriting classes, especially Particles, where the derived class behaves like a superclass to the base class. This is not a good design approach, and overall consensus is to avoid deriving Particle classes. Please refer to #637 to creating particle properties and revise the RFC.

Please revise the RFC to fill the sections in Drawbacks (design), Rationale for this design choice, Prior art and unresolved questions.

[bodhinandach]

I am curious, will the solver only be planned to work in 3D? How about 2D?

[yliang-sn]

@bodhinandach It can be applied in 2D. I want to work on 3D first for the Oso landslide and then 2D.

[yliang-sn]

@kks32 @bodhinandach I reedited the RFC.

[kks32]

1. Do we need new element types?
2. Will we end up having a mix of normal nodes and enrinched nodes? What properties would enriched nodes have?

[kks32]

What do you mean by: Memory stored might not be used for the nodes, which doesn’t belong to the full-through cells.?

[kks32]

Would level sets be implemented as a separate class, how would that design look like?

[yliang-sn]

1. Do we need new element types?
2. Will we end up having a mix of normal nodes and enriched nodes? What properties would enriched nodes have?

1. I don't need it for now. Only the element type needs to be stored. I do it in the DiscontinuousSurface class.
2. Yes. But all the nodes will the XMPMNode object. For Heaviside enrichment, there will be Enrich_H (bool), Enrich_mass (scalar), Enrich_momentum (vector), Enrich_internal_force(vector), Enrich_external_force(vector). Maybe Enrich_contact_force(vector) in the future. The enriched nodes have additional degrees of freedom. The formulations to initialization and update will be different. The operation on the enriched nodes will be the same as the regular nodes just with the new formulations.

[yliang-sn]

What do you mean by: Memory stored might not be used for the nodes, which doesn’t belong to the full-through cells.?

Only the nodes near the cracks are enriched. It's usually a small fraction of the total but it's changing with the movement of the material. It won't have much influence.

[yliang-sn]

Would level sets be implemented as a separate class, how would that design look like?

Not for now. I explicitly describe the discontinuous surface.

[kks32]

What do you mean by: Memory stored might not be used for the nodes, which doesn’t belong to the full-through cells.?

Only the nodes near the cracks are enriched. It's usually a small fraction of the total but it's changing with the movement of the material. It won't have much influence.

Does this mean we have to switch between node types or would all node types be XMPMNodes?

[kks32]

Would level sets be implemented as a separate class, how would that design look like?

Not for now. I explicitly describe the discontinuous surface.

How would the discontinous surface be defined in the node class?

[kks32]

1. Do we need new element types?
2. Will we end up having a mix of normal nodes and enriched nodes? What properties would enriched nodes have?

1. I don't need it for now. Only the element type needs to be stored. I do it in the `DiscontinuousSurface` class.

2. Yes. But all the nodes will the `XMPMNode` object. For Heaviside enrichment, there will be `Enrich_H (bool), Enrich_mass (scalar), Enrich_momentum (vector),  Enrich_internal_force(vector), Enrich_external_force(vector).` Maybe `Enrich_contact_force(vector)` in the future.  The enriched nodes have additional degrees of freedom. The formulations to initialization and update will be different. The operation on the enriched nodes will be the same as the regular nodes just with the new formulations.

These would need to be defined in separate free functions, and deriving node class to specialize certain functions which won't be used in other node classes is not a good way. We can derive new node classes as long as the functions are consistent, any specialized function which is only applicable for a certain type of nodes must go as a free function.

[yliang-sn]

What do you mean by: Memory stored might not be used for the nodes, which doesn’t belong to the full-through cells.?

Only the nodes near the cracks are enriched. It's usually a small fraction of the total but it's changing with the movement of the material. It won't have much influence.

Does this mean we have to switch between node types or would all node types be XMPMNodes?

ALL the node types would be XMPMNodes.

[yliang-sn]

Would level sets be implemented as a separate class, how would that design look like?

Not for now. I explicitly describe the discontinuous surface.

How would the discontinous surface be defined in the node class?

I need to define a class to describe the discontinuity and it's stored in the XMPMSolver class.

[bodhinandach]

ALL the node types would be XMPMNodes.

Just a short confirmation. This means that all the other nodes far away from the discontinuity surface will also have the memory allocated for all the variables listed in the following right?

For Heaviside enrichment, there will be Enrich_H (bool), Enrich_mass (scalar), Enrich_momentum (vector), Enrich_internal_force(vector), Enrich_external_force(vector). Maybe Enrich_contact_force(vector) in the future.

I am not sure that's the best way in terms of memory storage. Rather than changing the overall node, I would guess that the nodal_properties that we have is more efficient. Do you think we can somewhat utilize that?

[yliang-sn]

ALL the node types would be XMPMNodes.

Just a short confirmation. This means that all the other nodes far away from the discontinuity surface will also have the memory allocated for all the variables listed in the following right? Yes.

For Heaviside enrichment, there will be Enrich_H (bool), Enrich_mass (scalar), Enrich_momentum (vector), Enrich_internal_force(vector), Enrich_external_force(vector). Maybe Enrich_contact_force(vector) in the future.

I am not sure that's the best way in terms of memory storage. Rather than changing the overall node, I would guess that the nodal_properties that we have is more efficient. Do you think we can somewhat utilize that? The enriched nodes are changing during the simulation. We can discuss this.

[kks32]

@yliang-sn we can't see your response in the last message.

[yliang-sn]

@yliang-sn we can't see your response in the last message.

Yes. I talked with Nanda yesterday. I will define in separate free function.

[kks32]

@yliang-sn could you please update the RFC accordingly.

[yliang-sn]

@yliang-sn could you please update the RFC accordingly.

Sure. Could I update after our meeting tomorrow? I actually have some questions to discuss with you and Nanda.

[kks32]

Requested updates to the RFC

0. No need to derive the Node class, instead use NodalProperties and free functions to define XMPMNode functions
1. Retain the discontinuity class as is, and we'll investigate the best way to move forward

[stale[bot]]

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.

[yliang-sn]

working on validation problems.

[stale[bot]]

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.