[CIG-SHORT] Short-Term Crustal Dynamics priorities

[Eric Andreas Hetland]

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.