Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Earthquake MPM #692

Open
ezrayst opened this issue Aug 20, 2020 · 6 comments
Open

Earthquake MPM #692

ezrayst opened this issue Aug 20, 2020 · 6 comments

Comments

@ezrayst
Copy link
Contributor

ezrayst commented Aug 20, 2020

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)
    image

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

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

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
image

and a more complicated slope failure problem in Example 3.15.
image

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
Copy link
Contributor

kks32 commented Aug 24, 2020

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
Copy link
Collaborator

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
Copy link
Contributor Author

ezrayst commented Aug 30, 2020

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
Copy link
Contributor Author

ezrayst commented Aug 30, 2020

@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
Copy link

stale bot commented Oct 29, 2020

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
Copy link

stale bot commented Dec 28, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants