[CIG-SHORT] 3d splay fault model does not converge in Pylith

[Brad Aagaard]

Shaoyang,

I finally got around to trying to run your simulation. I am finding that 
the solution doesn't converge at the second time step, consistent with 
what you are seeing.

My recommendation is to start with a static simulation with 1.0 m of 
slip in the direction you want. Get this working and then go to a 
creeping fault. If this simple static problem with a fault isn't 
converging, then try a static problem with Dirichlet BC on the sides 
causing deformation and no faults to see if removing the faults isolates 
the problem, i.e., is it the mesh or fault setup that prevents convergence?

Also, monitor the true residual to verify that the residual is 
decreasing. The default is the preconditioned residual, which can 
decrease even when the true residual does not.

[pylithapp.petsc]
ksp_monitor_true_residual = true

Some things you need to be aware of:

I noticed that your z-axis does not coincide with the default "up 
direction" for faults. In setting up the slip directions for the fault 
in 3-D, the default up direction is (0,0,1). You need to change this to 
(0,1,0).
myfault.up_dir = [0,1,0]

Another issue is creeping faults result in slip rates that are very 
small in terms of length scale compared to the discretization size. This 
can cause very ill-conditioning, which can be alleviated with proper 
choice of length and time scales.

Regards,
Brad



On 3/11/14, 8:21 AM, Shaoyang Li wrote:
> Hi Brad,
>
> Thanks for your suggestions. I tried the solver settings similar to
> examples/3d/tet4/step04.cfg. However, the frictional faults still do
> work as the attached figure. The displacement looks the same as I use
> the normal settings: only the nodes with Dirichlet boundary conditions
> moves. Any further suggestions are very welcome. Thanks a lot.
>
> My model solver settings are as follow:
> [pylithapp.timedependent.formulation]
> split_fields = True
> # Use custom preconditioning for the Lagrange multiplier vertices
> use_custom_constraint_pc = True
> matrix_type = aij
>
> [pylithapp.petsc]
> # Note that with 3 displacement components plus the Lagrange
> # multiplier vertices, we have split the fields into 2.
> fs_pc_type = fieldsplit
> fs_pc_fieldsplit_real_diagonal = true
> fs_pc_fieldsplit_type = multiplicative
> fs_fieldsplit_0_pc_type = ml
> fs_fieldsplit_1_pc_type = jacobi
> fs_fieldsplit_0_ksp_type = preonly
> fs_fieldsplit_1_ksp_type = preonly
>
> # Friction sensitivity solve used to compute the increment in slip
> # associated with changes in the Lagrange multiplier imposed by the
> # fault constitutive model.
> friction_pc_type = asm
> friction_sub_pc_factor_shift_type = nonzero
> friction_ksp_max_it = 50
> friction_ksp_gmres_restart = 30
> # Uncomment to view details of friction sensitivity solve.
> friction_ksp_monitor = true
> friction_ksp_view = true
> friction_ksp_converged_reason = true
>
> # PETSc summary -- useful for performance information.
> log_summary = true
>
> Regards
> shaoyang
>
> On Mon, 10 Mar 2014 16:14:49 -0700
>   Brad Aagaard <baagaard at usgs.gov> wrote:
>  > Please try the solver settings discussed in Table 4.4 on
>  >page 33 and examples/3d/tet4 (Section 7.7, page 119), in
>  >particular step04.cfg (Section 7.7.5.1, page 127).
>  >
>  > Regards,
>  > Brad
>  >
>  > On 03/08/2014 06:06 AM, Shaoyang Li wrote:
>  >> Dear Brad,
>  >>
>  >> I am playing around the 3d splay-subduction mesh in the
>  >>meshing example of
>  >> meshing/surface_nurbs/subduction in Pylith.
>  >>
>  >> In the model I push the x_pos and x_neg boundary to
>  >>drive megathrust and splay
>  >> fault system to frictional moving. However, this model
>  >>never calculate anything
>  >> due to not converge. I check all the cfg again and
>  >>again, and I donot know what
>  >> is the problem really from. I guess I need to use some
>  >>special parameters for
>  >> PETs but there is no similar example in manual that I
>  >>can mimic. Could you help
>  >> me to check it? Thanks a lot.
>  >>
>  >> The journal message file is log.txt in attached. And all
>  >>the other file are in
>  >> tar.gz file.
>  >>
>  >> Best regards,
>  >> Shaoyang
>  >>
>  >
>