Earthquake MPM

[ezrayst]

Earthquake MPM

Summary

In light of doing earthquake simulations using the MPM, features such as absorbing boundary and input ground motion have to be implemented. Validations can be done using Linear Elastic model though in the future, more advanced cyclic constitutive models are hoped to be implemented within the CB-Geo code.

Design Detail

There are three components to make an Earthquake MPM simulation:

• Input ground motion in terms of either acceleration-time or stress-time (Joyner and Chen, 1975; Graff 1991)
• Absorbing boundary (Lysmer and Kuhlemeyer, 1969)

Input ground motion in terms of acceleration-time on the node

This will be the most straight forward of all the implementations. A discrete ground motion consisting of the time and the acceleration is saved within constraints such as follow:

  bool assign_nodal_acceleration_constraints(
      const std::vector<std::tuple<mpm::Index, unsigned, int, double>>&
          acceleration_constraints);

This will replace the computed acceleration through the first principle. A time_history.h class is derived from the abstract function_base.h. Usually this math function is used to yield a value between 0 and 1, which will be multiplied by the prescribed traction or velocity. However, here, the prescribed acceleration is 1 where the time_history.h defines the acceleration given the time. In addition, another alternative input file will be implemented to read a file containing time and value (in this case it is acceleration).

An alternative is to utilize the linear math function and define the acceleration accordingly. More specialized class to contain the ground motion acceleration time history is preferred.

Input ground motion in terms of stress-time on the node

Joyner and Chen (1975) proposed to have a flexible base model where only soil is modeled instead of rock, where earthquake initiates. This calls for a transformation from the acceleration or velocity (kinematics) in the rock to stress induced in the soil. The applied stresses are now governed by these equations which are pre-processed to only stresses.

In terms of the implementation in the code, this is analogous to the traction boundary. The stresses will be translated into normal and shear forces on the nodes with time_history.h class defining the time history as discussed in the previous subsection.

Absorbing boundary

As mentioned, this work is based on Lysmer and Kuhlemeyer (1969). The idea is to assume dashpots providing viscous normal and shear tractions given by the following equation. Those tractions are now in the nodes and are functions of velocities. This will dissipate or absorb the earthquake ground motion and it is needed.

In terms of implementation, the tractions will be added to the governing equation in computing the acceleration, which is dependent on the current velocity. This will be done within constraints such as follow:

  bool assign_nodal_absorbing_constraints(double pwave_v, double swave_v);

This will call traction.h to be included in the governing equation.

Test cases

We will use a few elastic case from FLAC validations such as Example 3.2

and a more complicated slope failure problem in Example 3.15.

Other thoughts

Let's focus on the single-phase simulation as fluid-coupled usually has the acceleration applied to the solid body in FLAC (FDM) or FEM

[kks32]

Thanks @ezrayst for this RFC on Earthquake modeling in MPM. I have the following comments.

Could you please provide a design outline of how TimeHistories class will be derived from FunctionBase, what is the rationale for this choice?

The Mesh class will end up doing too much, we should extract boundary conditions outside of the mesh class.

It would be good to have Equal DOFs to simulate 1D site-response, not sure how that would look like with MPM particles.

[jgiven100]

A discrete ground motion consisting of the time and the acceleration is saved within constraints such as follow:

bool assign_nodal_acceleration_constraints(
const std::vector<std::tuple<mpm::Index, unsigned, int, double>>&
acceleration_constraints);

@ezrayst Would there be limitation on which nodes could have their computed accelerations replaced with this constraint? The figures show both internal and boundary inputs, would we also have the option for dynamic input at either (or both) locations?

[ezrayst]

Could you please provide a design outline of how TimeHistories class will be derived from FunctionBase, what is the rationale for this choice?

TimeHistories would be similar to the current LinearFunction with two main distinct differences: (1) the former will have significantly more data points compared to the latter which typically has 2 or 3 points for ramp loading, and (2) the former will have the acceleration value instead of a multiplier like the latter between 0 and 1.

The Mesh class will end up doing too much, we should extract boundary conditions outside of the mesh class.

I agree, but can we refactor this while seeing part of the code too? I agree to move some of boundary conditions into Constraints class.

It would be good to have Equal DOFs to simulate 1D site-response, not sure how that would look like with MPM particles.

I think it would be very nice too, but since they don't move that much, we might end up doing FEM. But doing 1D site-response with MPM would be very interesting.

Would there be limitation on which nodes could have their computed accelerations replaced with this constraint? The figures show both internal and boundary inputs, would we also have the option for dynamic input at either (or both) locations?

Good point Joel, and I think when we do dynamic simulation with absorbing boundary and shaking, we will not apply the kinematic boundaries like velocity and friction constraints. In practice, this is rather difficult to do and result in unwanted behaviors, so people opt for the flexible-base approach where the input shaking is in terms of stress instead of kinematics.

[ezrayst]

@kks32, as requested, here is the proposed timeline:

• Sep 18, 2020 - acceleration-time
• Oct 2, 2020 - stress-time
• Oct 16, 2020 - absorbing boundary
• Oct 30, 2020 - show validations

[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.

[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.