[CIG-SHORT] convergence troubles: drucker-prager material with fault

Matthew Knepley knepley at mcs.anl.gov
Thu Dec 5 16:07:06 PST 2013


On Thu, Dec 5, 2013 at 5:52 PM, Eric Lindsey <elindsey at ucsd.edu> wrote:

> On Thu, Dec 5, 2013 at 8:55 AM, Matthew Knepley <knepley at mcs.anl.gov>wrote:
>
>> On Wed, Dec 4, 2013 at 11:23 PM, Eric Lindsey <elindsey at ucsd.edu> wrote:
>>
>>> Hi guys,
>>>
>>> I'm having some trouble getting the model with a fault in an
>>> elastoplastic rheology (plane strain) to converge. I'm pretty sure I've
>>> fixed all the boundary conditions to behave correctly now. The LU method
>>> fails entirely once yielding occurs, and the approximate method
>>> (multiplicative fieldsplit using ml and jacobi for the two domains) does
>>> not converge. More details:
>>>
>>> The first thing I tried was using (solver04.cfg) from the tutorial,
>>> which is a schur fieldsplit with LU and the custom Pylith preconditioner.
>>> In the case of a fault in a purely elastic material, this procedure is
>>> working fine. The nonlinear solve does take over 100 iterations, I'm not
>>> sure if this is just a function of my mesh; anyway I'm not too worried
>>> about optimization yet.
>>>
>>
>> Is this a through going fault? The linear solve is exact, so we would not
>> expect this.
>>
>
> The fault does extend all the way through the domain; there are traction
> boundary conditions on those sides of the domain that match the stresses on
> the fault. The fault itself has static friction -- so I think some
> nonlinear iterations are required to solve for the slip that satisfies the
> mohr-coulomb condition on the fault. The linear solves do finish in 1
> iteration, but I think the Jacobi preconditioner for the fault
> (fieldsplit_1) is pretty weak, which explains the number of nonlinear
> iterations. Unless I've misunderstood this.
>

You can change that jacobi to ml. This will give the AMG PC for the custom
fault preconditioner. I think that is what we recommend for hard
things in the presentation.

Through-going faults have a known problem with nonlinear iterates. We think
we have it fixed for the next release.


>
>>
>>> In the plastic case, whenever stresses near the bends in the fault begin
>>> to exceed the yield criterion (I increase them slowly to this value over
>>> several time steps), I get a Zero Pivot error. But maybe this is not
>>> unexpected for a plastic rheology?
>>>
>>
>> Using this option
>>
>> fs_fieldsplit_0_pc_factor_shift_type = nonzero
>>
>> will prevent a 0-pviot, but the preconditioner becomes weaker.
>>
>
>>    Matt
>>
>
> Thanks - I think this helped... It did prevent the zero pivot in the
> plastic case, but now one of the inner linear solves fails to converge
> (after 10,000 iterations), eventually leading to Pylith giving up with the
> message:
>
> WARNING! Fault opening with nonzero traction., v_fault: 175, opening:
> 1.41881e-09, normal traction: -6103.07
>
> The normal traction is still negative and this doesn't happen in the
> elastic case... I think this must be a numerical issue. So there is still
> an issue with my solver once plastic yielding starts, I think.
>

Brad is right about the tolerances. This is another thing we hope to remedy
with the new formulation. Right now, if the inner tolerance
is too small, you cannot satisfy it and you take tons of iterates.

   Matt


>
>> I also tried the solver options for an approximate solution with
>>> multiplicative fieldsplit suggested by Brad (solver08.cfg): The elastic
>>> case still works fine; it uses way more KSP iterates but still finishes in
>>> about the same total time. But the plastic case still throws a Zero Pivot.
>>> When I ran it earlier without increasing snes_max_it, I got a string of
>>> these messages instead:
>>>
>>> "Nonlinear solve did not converge due to DIVERGED_FNORM_NAN iterations 0"
>>>
>>> In either case, I think I must need a better solver. I've gone back
>>> through the tutorial videos for the solvers, but I'm not very clear on how
>>> to apply the nonlinear options from the driven cavity problem to my
>>> situation, or really where to start. My input files are attached, but I'm
>>> happy to send any additional files or output as needed. Any insight,
>>> suggestions, or wild guesses?
>>>
>>> Thanks
>>> Eric
>>>
>>>
>>>
>>> _______________________________________________
>>> CIG-SHORT mailing list
>>> CIG-SHORT at geodynamics.org
>>> http://geodynamics.org/cgi-bin/mailman/listinfo/cig-short
>>>
>>
>>
>>
>> --
>> What most experimenters take for granted before they begin their
>> experiments is infinitely more interesting than any results to which their
>> experiments lead.
>> -- Norbert Wiener
>>
>> _______________________________________________
>> CIG-SHORT mailing list
>> CIG-SHORT at geodynamics.org
>> http://geodynamics.org/cgi-bin/mailman/listinfo/cig-short
>>
>
>
> _______________________________________________
> CIG-SHORT mailing list
> CIG-SHORT at geodynamics.org
> http://geodynamics.org/cgi-bin/mailman/listinfo/cig-short
>



-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://geodynamics.org/pipermail/cig-short/attachments/20131205/c2b37a4a/attachment.html>


More information about the CIG-SHORT mailing list