Dear everyone,
I would like to confirm the following: In the case of subduction, by running the forward model in step06, then calculating the Green’s function in steps 07 and 08, and using actual GPS observation data, we can invert for the fault slip rates, correct? If so, can we obtain the backslip at each point by subtracting the a_priori_value given in the slip_invert.cfg file from the slip values obtained through inversion?
I appreciate your time and look forward to your response.
Sincerely,
Xiao Yang
In an inversion with Green’s functions, you are finding how to sum those Green’s functions to reproduce the observations. So the results of the inversion depend on what processes are included in your observations. If your observations correspond to the coseismic slip in an earthquake, then your inversion will produce an estimate of coseismic slip. If your observations correspond to interseismic deformation without any slip in the seismogenic zone, then your inversion will produce an estimate of deep interseismic slip. I suggest you think about what processes are captured by your observations and then write down the equations for the deformation assuming a linear formulation (superposition).
Thank you very much for your response. I also want to ask whether vertical observation data is necessary in actual observation data in order to use slip_invert.py for inversion. However, it seems that the error in vertical observation data is relatively larger compared to horizontal data. Wouldn’t this have a significant impact on the inversion results?
The use of the vertical component in an inversion is dependent on the situation. For a vertical strike-slip fault, the vertical deformation is much smaller than the horizontal components. As you point out, it might not be important in an inversion. However, for a dip-sip fault, the vertical deformation may be similar to the horizontal components and would be important to include in the inversion.
Thank you very much for your response, sir. I tried to apply sliding velocity to the model boundaries based on step 06, but I keep getting a message indicating that the y_neg boundary is over-constrained, for example: RuntimeError: Found overly constrained point while setting up constraints for DirichletBC boundary condition ‘boundary_yneg’. Number of DOF at point 251576 is 3 and number of attempted constraints is 4.
application called MPI_Abort(MPI_COMM_WORLD, -1) - process 0
/public1/home/t0s000462/xiaoy/Pylith/pylith-2.2.2-linux-x86_64/bin/nemesis: mpirun: exit 255
/public1/home/t0s000462/xiaoy/Pylith/pylith-2.2.2-linux-x86_64/bin/pylith: /public1/home/t0s000462/xiaoy/Pylith/pylith-2.2.2-linux-x86_64/bin/nemesis: exit 1.
Is this because the same points are being assigned different values, or is it not possible to apply boundary conditions in this step? Below is my relevant code.
pylithapp.cfg (8.0 KB)
step06.cfg (8.6 KB)
spatial.txt (610.2 KB)
Too many constraints on a boundary usually comes from constraining the same degrees of freedom from two different boundary conditions at locations where the boundary conditions overlay. For example, constraining the x and y degrees of freedom on one face of a cube while also constraining the x and y degrees of freedom on another face; this creates 4 constraints on the edge of the cube where the faces intersect. PyLith v2 doesn’t check to see if the constraints are the same; instead it generates an error based on the number of constraints from the parameters.
The workaround is to eliminate the overlap in the constraints. With zero displacement boundary conditions, we usually only constrain the degree of freedom perpendicular to the boundary. With velocity boundary conditions, you may want to constrain both degrees of freedom, so you could resolve this issue by eliminating the overlap in the boundary conditions (for example, one boundary condition would remove the vertices along the edges of the cube).