[CIG-SHORT] pylith processing error

[Brad Aagaard]

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
>>>>
>>>
>>>
>>>
>>
>>
>
>
>