[CIG-SHORT] debugging rate-state quasi-static simulation

Tue Nov 21 15:38:42 PST 2017

Ekaterina,

I am still baffled by the behavior of the linear solver. The linear 
(KSP) solve within the nonlinear solver (SNES) is taking several hundred 
iterations and it looks like your absolute tolerance is around 1.0e-17. 
This is where I would start your debugging. I forgot that the JSON 
parameter file doesn't include the PETSc parameters. Can you send your 
.cfg file with the solver parameters you are using?

I am not sure what you mean by "artifacts" and fluctuations. With rate 
and state friction, I have seen the slip jump forward and backward when 
the nonlinear solve has trouble converging. When this happens, I think 
the solution is poorly resolved. Either the spatial and/or temporal 
discretizations are too large and/or the rate-state friction parameters 
need to be adjusted to help regularize the solution. For example, using 
a laboratory value of the Dc parameter with kilometer sized cells will 
almost certainly have convergence problems due to inadequate resolution 
of the cohesive zone.

Sorry for the delay in responding.

Regards,
Brad

On 11/14/2017 06:18 PM, Ekaterina Bolotskaya wrote:
> Dear Brad,
> 
> Thanks for helping with this!
> 
> Attached are the json parameter file and the log file for the same simulation run on pylith v2.2.1.
> 
> I made the time step 4 times smaller: 1 year -> 0.25 year
> I'm using friction_pc_type = asm, which seems to be appropriate for my case. Please correct me, if I'm wrong.
> This one doesn't have a convergence error, but it stops converging at the same time step as it used to, I just made the maximum time smaller to be able to look at xmf result files.
> 
> In this simulation not only the convergence is a problem, the results themselves seem to have a lot of computational artifacts and fluctuations, where I wouldn't expect them (tractions and slip on the fault, state parameter).
> 
> Although when I'm looking at the results of step06 in examples/2d/subduction, those seem to have even more fluctuations for the fault slip and traction (slabtop). Should I just interpolate mine and ignore the artifacts or is there something wrong?
> 
> Thanks!
> 
> 
> Best regards,
> Ekaterina Bolotskaya
> 
> PhD in Geophysics,
> Earth, Atmospheric and Planetary Science Department,
> Massachusetts Institute of Technology
> E-mail. bolee at mit.edu
> Mob. +1 (857) 284-2805
>           +7 (963) 995-36-33
> 
> ________________________________________
> From: CIG-SHORT [cig-short-bounces at geodynamics.org] on behalf of Brad Aagaard [baagaard at usgs.gov]
> Sent: Thursday, October 26, 2017 13:56
> To: cig-short at geodynamics.org
> Subject: Re: [CIG-SHORT] debugging rate-state quasi-static simulation
> 
> Ekaterina,
> 
> Your 53_log.log file shows that the SNES solver converged for several
> time steps with 1 iteration (consistent with no slip) and then there
> were 14 time steps with multiple iterations that did converge
> (consistent with frictional slip starting). The time step before the
> SNES solve failed to converge in 400 iterations required 198 nonlinear
> iterations. I extracted this information using grep on the log file. So
> it looks like the simulation was proceeding normally. You may need to
> reduce your time step to get the nonlinear solve to converge in a
> reasonable number of iterations. You can also increase the number of
> SNES iterations allowed using snes_max_it.
> 
> I also noticed that your linear solves are requiring about 600
> iterations. For a mesh with 20K cells I would expect much faster
> convergence in the linear solve IF you are using the solver and
> preconditioner parameters we recommend for real research problems
> (share/settings/solver_fault_fieldsplit.cfg).
> 
> If you would like further help in debugging this simulation, please use
> PyLith version 2.2.0 or later (I suggest the latest version v2.2.1) and
> send the JSON parameter file that is automatically created by the run.
> This file includes all of the parameters in your .cfg files or command
> line and we can easily view it using the PyLith Parameter viewer. Please
> see Section 4.10 of the PyLith v2.2.1 manual for more information.
> 
> For real research problems, we also strongly recommend using HDF5 output
> rather than VTK as the I/O is much faster and they make post-processing
> with Matlab or Python much easier. You can load the corresponding Xdmf
> file into ParaView as described in the PyLith manual.
> 
> Regards,
> Brad
> 
> 
> 
> 
> On 10/25/2017 08:35 PM, Ekaterina Bolotskaya wrote:
>> Dear Brad,
>>
>> I'm using Pylith 2.1.3 and my info outputs are .vtk
>> Please find the two info files (fault and statevars) and the log attached.
>> Hope, that helps.
>>
>> Thanks!
>>
>> Best regards,
>> Ekaterina Bolotskaya
>>
>> PhD in Geophysics,
>> Earth, Atmospheric and Planetary Science Department,
>> Massachusetts Institute of Technology
>> E-mail. bolee at mit.edu
>> Mob. +1 (857) 284-2805
>>            +7 (963) 995-36-33
>>
>> ________________________________________
>> From: CIG-SHORT [cig-short-bounces at geodynamics.org] on behalf of Brad Aagaard [baagaard at usgs.gov]
>> Sent: Wednesday, October 25, 2017 19:31
>> To: cig-short at geodynamics.org
>> Subject: Re: [CIG-SHORT] CSEC benchmarks pylith files on Github?
>>
>> On 10/25/17 3:58 PM, Ekaterina Bolotskaya wrote:
>>> Dear developers,
>>>
>>> I'm failing to find pylith files (I'm looking here:
>>> https://github.com/geodynamics/pylith_benchmarks) that were used to
>>> obtain the results shown here http://scecdata.usc.edu/cvws/cgi-bin/cvws.cgi
>>>
>>> Also is that correct that there's just one pylith rate-and-state
>>> friction benchmark on the SCEC website
>>> (http://scecdata.usc.edu/cvws/cgi-bin/cvws.cgi): tpv102 - Rate-state
>>> friction, ageing law, half-space?
>>
>> The files are in dynamic/scecdynrup/tpv102. These files may need
>> updating for work with PyLith v2.X.X.
>>
>>> I'm also looking at step06 in examples/2d/subduction and step14
>>> in examples/3d/hex8. Are there any more rate-and-state friction examples
>>> I can look at? Espesially m-scale (rather than km-scale) ones, as my
>>> m-scale rate-and-state simulation is not converging and I thing scaling
>>> might be one of the problems (I'm using
>>> appropriate normalizer.length_scale).
>>
>> I think the examples you list are the ones we have for quasistatic modeling.
>>
>>> (My simulation is 2D, 2m by 3m, trilateral mesh, buried fault with rate
>>> and state friction in the middle, I'm fixing vertical displacement along
>>> all boundaries and applying compression in both x and y direction and
>>> shear traction rates).
>>
>> Do you have sufficient Dirichlet BC to eliminate all rigid body motion
>> (translation and rotation)? If so, turn on the KSP and SNES monitors and
>> send your JSON parameter file (generated automatically in v2.2.1)  and
>> your entire log.
>>
>> Regards,
>> Brad
>>
>> _______________________________________________
>> CIG-SHORT mailing list
>> CIG-SHORT at geodynamics.org
>> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/cig-short
>>
> 
> _______________________________________________
> CIG-SHORT mailing list
> CIG-SHORT at geodynamics.org
> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/cig-short
> 