[CIG-SHORT] Short-Term Crustal Dynamics priorities
Charles Williams
willic3 at rpi.edu
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
More information about the CIG-SHORT
mailing list