[CIG-SHORT] pylith processing error

[Brad Aagaard]

Bobby,

Keep ksp_rtol and snes_rtol small (1.0e-20).

Keep
friction.zero_tolerance > ksp_atol
snes_atol > friction.zero_tolerance

See the examples/3d/hex8/step14 for where to specify 
friction.zero_tolerance.

Regards,
Brad


On 11/27/2012 03:08 PM, BOK10 at pitt.edu wrote:
> Brad,
>
> That helped a lot, thank you!
>
> My last question for today is more specific to my problem. If i'm looking
> to see how long it takes to move a fault >1cm for at least 75% of the
> total length of the fault, what are reasonable atol/rtol values to try?
> I've tried a bunch of different things, but when I decrease them from
> their current state of atol 1.0e-12 and 1rtol 1.0e-12, the length of time
> it takes seems to double from estimates I had before. Though, I'm not sure
> that the non linear solver converged in those previous cases...
>
> Bobby
>
>
>> Bobby,
>>
>> When the nonlinear solve (SNES) doesn't converge, it means the solution
>> you are getting has error on the order of the tolerance when it
>> diverged. On certain parts of the domain, the error could be larger.
>>
>> Running in parallel should help reduce the time it takes to run a
>> simulation.
>>
>> Nonlinear solver convergence will be slow in problems with through-going
>> faults and when there is fault opening due to how we update the slip
>> estimate when sliding occurs. In these cases there is little that can be
>> done in tuning the parameters. We need to improve the nonlinear solver
>> to handle these problems.
>>
>> Regards,
>> Brad
>>
>>
>> On 11/27/2012 01:46 PM, BOK10 at pitt.edu wrote:
>>> Hi Brad,
>>>
>>> I've played around with the examples and looked at a very coarse problem
>>> with the same configuration. I also tried tuning the parameters so that
>>> it
>>> runs faster, which works, the only problem is that the slip rate on my
>>> fault is faster when I compare it to what I had before.
>>>
>>> I have my ksp_rtol at 1.0e-8 and ksp_atol at 1.0e-12. The max_it for the
>>> ksp is now 800 which seems to stop it from ever running into a problem
>>> in
>>> that regard, but the snes still won't diverge. I have the same rtol and
>>> atol values for the snes, and I've tried an snes max_it of 200 (no
>>> convergence), and one of 1000 (converged, but took about 35 minutes to
>>> process one time stamp).
>>>
>>> I guess my major question is: what does it mean when the non linear
>>> solver
>>> doesn't converge? How would this affect the results? I'm having
>>> difficulty
>>> wrapping my head around this.
>>>
>>> Thanks,
>>> Bobby
>>>
>>>
>>>> Bobby,
>>>>
>>>> I suggest playing around with the examples or a very coarse problem
>>>> with
>>>> the same configuration to try to tune the parameters so that it runs
>>>> faster. Also read the section on PETSc solver parameters in the
>>>> "Running
>>>> PyLith" chapter of the manual.
>>>>
>>>> Regards,
>>>> Brad
>>>>
>>>>
>>>> On 11/27/2012 12:08 PM, BOK10 at pitt.edu wrote:
>>>>> It looks like my KSP_max_it was off by a bit (300, but now 320). My
>>>>> SNES_Max_it is causing a divergence issue, and I have it set at 300.
>>>>> It
>>>>> says its not converging. My concern is that right now it take 4-5
>>>>> hours
>>>>> to
>>>>> process each simulation. Is there a way around this? Can I change my
>>>>> SNES_atol or rtol to something more reasonable?
>>>>>
>>>>> Bobby
>>>>>
>>>>>
>>>>>
>>>>>> Bobby,
>>>>>>
>>>>>> Your description is far too vague for us to diagnose the problem. I
>>>>>> suggest that you look at the usual suspects, such as is the solve
>>>>>> converging (use ksp_converged_reason = true and snes_converged_reason
>>>>>> =
>>>>>> true).
>>>>>>
>>>>>> Regards,
>>>>>> Brad
>>>>>>
>>>>>>
>>>>>> On 11/27/2012 07:57 AM, BOK10 at pitt.edu wrote:
>>>>>>> To clarify: the vtk output (the values in it) at some point is
>>>>>>> identical
>>>>>>> to the last one to process correctly. It usually occurs in the
>>>>>>> latter
>>>>>>> part
>>>>>>> of the simulation, but there are a few instances where it happens in
>>>>>>> the
>>>>>>> first bit, then resumes normally.
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I'm running a simulation for 400 years with a 5 year dt, and it can
>>>>>>>> process it fine for the first half, but then sometimes it will just
>>>>>>>> give
>>>>>>>> me nothing in the output files (0kb size) and the last 20-30 of 80
>>>>>>>> vtk
>>>>>>>> files write really quickly and have the same exact values. Is there
>>>>>>>> a
>>>>>>>> way
>>>>>>>> to fix this?
>>>>>>>>
>>>>>>>> Bobby
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>
>
>
>