How to prevent fault reactivation in dynamic simulations

Dear Pylith team,

I’m trying to simulate a dynamic earthquake rupture based on interseismic locking models. I began with a simple planar fault which only has left-lateral traction. I found that during the rupture propagating, stress will accumulate at the surface, and then the fault will rupture again from the surface. I have set the stress drop to 0 and used a higher value of static friction coefficient at the surface, but it didn’t work. Is this because I missed something in Pylith settings or is the problem about the initial stress condition?

Thanks,
Cai

Here is the initial stress condition.

The stress accumulates at the surface

fault reactivation

The rupture behavior for dynamic spontaneous rupture depends on many factors, including the friction model and its parameters, the initial shear and normal tractions, and the rupture propagation. If you are using slip-weakening friction without healing, then once a location begins to slip, additional slip will occur with any additional increase in shear tractions assuming the normal traction is constant. Similarly, for a constant shear traction and decrease in the compressive normal traction can also trigger additional slip. For slip-weakening friction you can increase the cohesion and slip-weakening parameter (sometimes called the slip distance) to reduce reactivation near the ground surface.

1 Like

Thank you for answering. By the way, I found that when I run pylith with the command pylith pylithapp.cfg, only one core is used for calculation. How can I run in parallel? Can multicore computing significantly improve efficiency?

To run in parallel, simply use the --nodes=NPROCS command line argument, where NPROCS is the number of processes. See Section 3.5 in the PyLith v2.2 manual for information about running on a cluster.

The speed up is highly architecture dependent. In general, you will get significant speed on an individual computer or compute node of a cluster until you saturate the memory bus. Once the memory bus is saturated, using more processes on that individual computer or compute node will give very little additional speedup. The main speed up is going from a single computer to a cluster. See our 2013 JGR paper referenced in the manual for some analysis of the scalability, primarily for quasistatic problems.

1 Like

Thanks a lot for your answer.
I have a new problem when running the Pylith. It came up with an error:

mpinemesis: …/…/…/pylith-2.2.2/libsrc/pylith/feassemble/GeometryTet3D.cc:346: PylithScalar pylith::feassemble::GeometryTet3D::volume(const PylithScalar*, int, int) const: Assertion `det > 0.0’ failed.

I used the same model as before but meshed it with the method in examples/meshing/cubit_cellsize/ to have smaller cell size in nucleation area.

The error indicates that the volume of a cell (calculated using a determinant) is not positive. The cell may be inverted or severely distorted. Check the mesh quality.

Note: You should make it a habit to check the mesh quality before using a mesh. You want the condition number metric to be less than 2.0 (ideal is 1.0).

Hi, Brad. I’m sorry that I have to bother you again.
I built a model with two fault planes based on the example of SCEC benchmark TPV14. I found that the rupture only propagated on the main fault even if I increased the tractions on the branch fault. Could you explain why? Thanks.

The dynamics of earthquake rupture on branching faults is complex and depends on many factors, such as the fault stresses, branch geometry, rupture speed, and hypocenter. It can also depend on the resolution of the model; you need sufficient resolution to capture the radiated seismic waves and dynamic stress perturbations. You can look at the fault tractions on the fault surfaces and compare them against the friction stress. This should help you understand why the slip occurs where it does and where it does not.

I increased the resolution of the model and it works fine now. Thank you very much.