[CIG-SHORT] Short-Term Crustal Dynamics priorities

Thu May 15 11:09:45 PDT 2008

Hi Eric,

You bring up a couple of PyLith development questions that we can  
address somewhat in the near-term, but should probably also be  
discussed at the CFEM meeting.  They are:

1.  Time stepping.  At present, this is fairly rigid in PyLith, since  
we just allow uniform time-step sizes at present.  This is easily  
changed, however, and the code has been set up to allow a more general  
approach.  At the other end of the spectrum is completely adaptive  
time stepping.  Brad and I are working on a strategy for this right  
now.  For linear viscoelastic models, we can get a pretty good  
estimate of the maximum allowable time step size as a fraction of the  
Maxwell time.  I believe that we may also need to consider loading  
conditions, however, and I need to do some experimentation with that.   
We need to devise a strategy that optimizes the computation time where  
we balance the benefit of longer time steps against the penalty of  
having to reform the stiffness matrix every time we change the time  
step size.  We will try to come up with a default strategy that is  
fairly optimal, with a few parameters that can be changed by users who  
want to experiment.  One factor we need to consider is the matter of  
output for a purely adaptive scheme.  For efficiency (and ease of code  
development), it is easier to have the time step size computed  
independently of the time(s) of requested output.  In that case, users  
would not have fine-grained control over when output occurs.  They can  
either request output every 'n' time steps, or request output at given  
times.  If they request output at given times, the given times would  
just be guidelines, and they would get output at times that fall on or  
immediately after the requested time.  We need to determine whether  
this sort of behavior is acceptable to users, or if they require  
better control.

This leads to the second part of your time-stepping question, which is  
the ability to specify a set of time step sizes.  This is easily  
implemented, and might be the best option for people that want more  
control over time step sizes and output.  We will be adding some  
additional time step control options in the near future, but community  
feedback would be very helpful in determining what people would most  
like to see.

2.  Prestresses.  This can mean more than one thing.  One way that  
they have been used in the past is to represent gravitational stresses  
in the absence of tectonic forces, so that when gravity is suddenly  
'turned on', there is not an unrealistic deformation associated with  
it.  This could also mean the state of stress due to 'spinning up' a  
model, so that it is not necessary to spin the model back up.  In this  
case, it is probably necessary to save the entire state of the model  
(a restart file), since future deformation may depend on state  
variables in addition to the stresses.  We need to know which of these  
is meant, and which will be more useful to people.  Also, there aren't  
any official methods of dealing with gravitational prestresses that I  
know of.  I have come up with my own methods in the past, but it would  
be good to have some community feedback so that we end up with  
something that is easy to use, but still gives us something that is  
mathematically and physically sound.

I think that the simplest approach for gravitational prestresses is to  
allow users to input their own prestresses.  These could be computed  
analytically (in some cases) or generated by a previous finite element  
run.  Again, some community input is required to determine the best  
way to go with this.

Thanks for your feedback.  I hope that we can get people thinking a  
bit more about what specific PyLith features they would like to see,  
as well as more general ideas about future directions for the cig- 
short community.

Thanks,
Charles

On May 14, 2008, at 12:41 PM, Eric Andreas Hetland wrote:

>
> Since there has been no discussion on this list, and the web page  
> does not
> look like I should add random discussion, my 2c:
>
>> (1) What obstacles inhibit your abilities to create realistic models?
>> (2) What modeling tools would eliminate/reduce these obstacles?
> I think that while having realistic models (by this I am under the
> impression you mean geometrically complicated, SCEC-CBM type models)  
> is a
> good target to work towards, at this point I am not sure that focus  
> should
> shift from the basic code development.
>
>> (3) If you are using PyLith, what features do wish it had?
>> (4) If you are not using PyLith, why? Are you waiting for a  
>> particular set of
>> features to be added? Is it too difficult to learn? Is it too slow?  
>> Is it too
>> inefficient?
> I have used previous versions of pylith, but I am not actively using  
> pylith
> now - the main reason is that FEMs have not been my focus for the  
> past few
> months, and geofest has worked for the FEMs I have done. From  
> speaking to
> people who use pylith, my understanding is that pre-stresses can not  
> be
> applied to pylith models - if true, this is a huge limitation that  
> would
> keep me from using pylith. The learning curve does indeed seem  
> steep, but
> tractable.
>
> Concerning the recent discussion on variable time stepping on this  
> list: is
> it possible to define time-step groups, as in Tecton and Geofest? As I
> understand this discussion, the choice is between one constant time  
> step vs.
> adaptive time stepping. Isn't there a middle ground?
>
>> (5) Are you satisfied with the pace of PyLith development? Would  
>> you be
>> willing to work on PyLith development? What sort of training (if  
>> any) would
>> you need?
>
> Yes, I am satisfied. I think that the developers are doing a  
> tremendous job
> at it. I am not qualified to work on the code development.
>
>> (6) What other types of modeling tools, besides PyLith, do we want  
>> developed?
>
> I do not think that resources should be shifted away from Pylith at  
> this
> stage. If this is about goals past Pylith (at least ver 1.5), then  
> that is a
> separate discussion.
>
>> (7) Are there useful semi-analytic codes that would be of great use  
>> if they
>> were more portable? documented? open-source? more efficient? Should  
>> we divert
>> resources from PyLith development to support this task?
>
> There are useful semi-analytic codes out there, but resources should
> absolutely not be shifted from Pylith development. If the community  
> feels
> strongly for #7, the exact codes should be identified and additional
> resources should be provided for it, possibly support to the original
> authors of the solutions.
>
> My opinions.
> Eric.
>
>
> _______________________________________________
> CIG-SHORT mailing list
> CIG-SHORT at geodynamics.org
> http://geodynamics.org/cgi-bin/mailman/listinfo/cig-short
>

Charles A. Williams
Dept. of Earth & Environmental Sciences
Science Center, 2C01B
Rensselaer Polytechnic Institute
Troy, NY  12180
Phone:    (518) 276-3369
FAX:        (518) 276-2012
e-mail:    willic3 at rpi.edu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://geodynamics.org/pipermail/cig-short/attachments/20080515/891d04e5/attachment-0001.htm 