[CIG-SHORT] How does Pylith number vertices on fault

[Hongfeng Yang]

Thanks, Brad. Then that goes to my previous question: how should I 
locate the vertex on the fault using the v_fault label?

When I track the slip and stress on different points on the fault, I 
found the normal slip was indeed very large and the normal stress was 
decreased drastically to 0, as shown in the attached figure, 
tettrack.png. I've tried different stress drop and friction parameters 
which all lead to very large normal slip and small normal traction using 
a tetrahedron mesh.

However, when I changed the mesh scheme from tetrahedron to hexahedra 
for the same fault geometry, I can see a rupture initiated and 
propagated on the fault. Tracking stress and slip history at one point 
on the fault would show reasonable stress change and slip.

Varying the tolerance would make pylith run a longer simulation, but the 
results are not going to change based on my previous experience.

This intrigues me to think of the mesh quality. But after a number of 
unsuccessful experiment in CUBIT of playing around different grid size 
and smoothing schemes, I want to verify which element on the fault is 
indeed cracking every time. If I can manually fixed it, I would expect 
to see a correct simulation or a different point that stops the run.

Thanks,

Hongfeng

On 10/04/2012 11:27 AM, Brad Aagaard wrote:
> Hongfeng,
>
> The v_fault in the error message refers to the internal Sieve label for
> a vertex on the fault. It does not directly correspond to the numbering
> of vertices in the mesh or fault in the output or the input mesh. For
> example, Sieve does not numbering vertices differently from cells. In
> fact, it labels cells first and then labels vertices. This should be
> transparent to the user except in diagnosing error messages that expose
> the Sieve labels.
>
> The error message you are getting suggests the solver tolerances are not
> setup properly. You are getting a very small opening and small
> compressive normal traction, which means the linear solver tolerance was
> not tight enough or the friction zero tolerance was not large enough.
>
> Regards,
> Brad
>
>
> On 10/04/2012 07:39 AM, Hongfeng Yang wrote:
>> Hi Developers,
>>
>> I am tracking time history of variables on particular vertices on the
>> fault. However, I found the vertex ID in Pylith (v_fault) is larger than
>> the total number of vertices on the fault. How can I convert the value
>> of v_fault back to the vertex location on the fault surface?
>>
>> For example, I got the following fault opening error message
>> WARNING! Fault opening with nonzero traction., v_fault: 4154, opening:
>> 1.03716e-10, normal traction: -0.0042952
>> mpinemesis: faults/FaultCohesiveDyn.cc:382: virtual void
>> pylith::faults::FaultCohesiveDyn::integrateResidual(const
>> pylith::topology::Field<pylith::topology::Mesh>&, PylithScalar,
>> pylith::topology::SolutionFields*): Assertion `fabs(tractionNormal) <
>> _zeroTolerance' failed.
>> [0]0:Return code = 0, signaled with Aborted
>>
>> v_fault points to vertex ID 4154. The total number of vertices on the
>> fault is 1472, however.
>>
>> Thanks,
>>
>> Hongfeng
>>
> _______________________________________________
> CIG-SHORT mailing list
> CIG-SHORT at geodynamics.org
> http://geodynamics.org/cgi-bin/mailman/listinfo/cig-short
>


-- 
Postdoc Investigator
Woods Hole Oceanographic Institution
Dept. Geology and Geophysics
360 Woods Hole Rd, MS 24
Woods Hole, MA 02543

-------------- next part --------------
A non-text attachment was scrubbed...
Name: hextrack.png
Type: image/png
Size: 4951 bytes
Desc: not available
Url : http://geodynamics.org/pipermail/cig-short/attachments/20121004/8a391fd4/attachment.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tettrack.png
Type: image/png
Size: 5874 bytes
Desc: not available
Url : http://geodynamics.org/pipermail/cig-short/attachments/20121004/8a391fd4/attachment-0001.png