[CIG-SHORT] 2 Questionsrefined meshing, heterogeneous material.

[Brad Aagaard]

On 01/26/2011 08:02 AM, Niz wrote:
> I am struggling in a very simple 2D simulation SCEC-TPV11 simulation.
> A 50m spacial resolution on fault meshing works fine, but when i try
> to use a mesh with 25m resolution on fault, I don't get a proper
> initiation as nodes outside the nucleation patch start to move (see
> joined figure). Lowering up to 1e-5s time step didn't work, I also
> increased the maximum iterations with still no success, I wish to know
> if I am overlooking important parameters or should i continue to
> increase the pre-conditioners till I get my result? I put the setup
> files in
> ftp://ftp-lgit.obs.ujf-grenoble.fr/pub/lgit/moussatn/

I examined your input files and was unable to pinput found the problem, 
but I do have a few initial comments:

(1) Using the ExplicitLumped formulation results in lumping of the mass 
matrix, which decouples solving the equations. As a result, a very 
simple non-PETSc solver is used. This means that all of the PETSc 
options (such as the preconditioners) are ignored except the log_summary 
option. It looks like you modeled your input after some of the other 
SCEC dynamic rupture benchmark input files. I haven't had a chance to go 
back and clean them up and remove superfluous settings. Sorry about that.

(2) The mesh quality looks okay, so the stable time step should be about 
1/2 the value used in the 50m resolution simulation.

(3) The PyLith releases and development version (trunk) are not 
precisely compatible with the SCEC dynamic rupture benchmark 
specifications. The benchmark descriptions impose some odd constraints, 
such as not allowing the fault to open when it is under tension and not 
allowing healing (strength remains at the dynamic level even after 
sliding stops for the slip weakening friction model). As a result, we 
created a separate PyLith branch (branches/pylith-scecdynrup) that 
includes modifications to the code that implement these unusual 
constraints, while remaining up-to-date with the development version 
(trunk).

My guess is there is a problem in the spatial database files, such as 
setting up a file for use with a linear interpolation query type but 
using the default nearest point query, or vice versa. Adding fields 
(such as the fault constitutive parameters) to the fault_info output and 
examining that file usually isolates the problem. If after examining the 
fault info file, you still can't find the problem, let me know and I 
will find time to dive deeper into the input files.

> On another matter, I don't understand in the manual how the file
> mat_prop.spatial.db can specify 2 different material properties for a
> volume on one side of the fault. Do I need to introduce 3 bodies
> instead, with 2 contact interface with cohesive cells? (one stick-slip
> for the fault and one stick for the heterogeneity)

I am not sure I understand your question. If the objective is to specify 
different physical properties for the elastic material on each side of 
the fault, then you do not need multiple materials (multiple CUBIT 
blocks). You can simply setup the spatial database file so that the 
physical properties vary in space. For a constrast in physical 
properties across the fault, you can create a line of 4 points 
perpendicular to the fault with 2 immediate adjacent to the fault and 2 
far enough away to span the domain. Specifying the same values for each 
pair of points on the opposite sides of the fault will result in 
different physical properties being used for each side of the fault. For 
example, for a fault at x=0, you could specify physical properties A at 
x=-10, x=-0.001 and physical properties B at x=+10 and x=+0.001. For 
linear interpolation, the spatial database data-dim is 1 and the query 
type is linear.

Brad