[CIG-SHORT] Pylith Time Step Module

Brad Aagaard baagaard at usgs.gov
Wed Jun 14 12:27:51 PDT 2017


On 06/14/2017 11:11 AM, Ge Li wrote:
> Dear Brad,
> 
> I’m now trying to develop my own module of time step module, where
> 
> time step is calculated based on the slip-rate, grid size as well as 
> frictional
> 
> law properties, e.g. constitutive b values.  Currently, these values
> 
> are obtained by reading .vtk files from previous step. Keeping
> 
> reading ASCII files, however, can be inefficient and slow down the code.
> 
> My question is how can I get access to these data/state variables from
> 
> /pylith/TimeStepTest.py directly? I’m having a difficult time reading 
> the code
> 
> recently and hope you could give me a hand.

The workflow for adaptive time stepping is that the time step object 
will loop over all of the integrators (e.g., materials and faults) and 
ask them to compute the stable time step for their calculation. It then 
computes an overall stable time step based on the minimum time step 
reported by the integrators.

See the timeStep method in pylith/problems/TimeStepAdapt.py and the 
_stableTimeStep method in pylith/problems/TimeStep.py for this top-level 
workflow. Notice that _stableTimeStep() calls stableTimeStep(mesh) for 
each of the integrators.

All of the integrators have this stableTimeStep(mesh) method. For 
example, ElasticityExplicit and ElasticityImplicit objects in 
libsrc/pylith/feassemble each have stableTimeStep() methods. 
ElasticityExplicit calls stableTimeStepExplicit() and ElasticityImplicit 
calls stableTimeStepImplicit(). For explicit time stepping,

For explicit time stepping, see the stableTimeStepExlicit method in 
libsrc/pylith/materials/ElasticMaterial. Note that it computes a minimum 
cell width and then passes that as an argument to the 
_stableTimeStepExplicit() method that is implemented in each material.

In order to provide other criteria for the stable time step, you will 
need to implement an alternative _stableTimeStepImplicit() or 
_stableTimeStepExplicit() methods in all materials that you use. These 
methods have the material properties and state variables as arguments. 
If you need additional state information, you would have to compute it 
on the fly from those values or add state variables.

If this is too complicated for your intention, then an alternative would 
be to use HDF5 files for your output. ASCII VTK file are fine for simple 
runs, but you should use HDF5 files for production runs. HDF5 files are 
binary and can be read/written in parallel so the I/O is much faster.

Regards,
Brad


More information about the CIG-SHORT mailing list