[aspect-devel] AGU meeting feedback

[Thieulot, C. (Cedric)]

Dear Aspect team and users,

AGU seemed a good time for some of us ASPECT users to gather
around a table and talk about our experience so far and our future plans.
Present to the meeting were:

- Anne Glerum
- Rene Gassmoeller
- Juliane Dannberg
- Sacha Brune
- Ian Rose
- Jonathan Perry-Houts
- Katrina Arredondo
- Rajesh Kommu (CIG)
- Cedric Thieulot

What follows is a list of points, wishes, and questions
we came up with that evening:

- C.T. showed in his talk (hereby attached) that the Rayleigh-Taylor experiment as
presented in van Keken et al. (JGR 1997) run with ASPECT yields
abnormal results. It is of course understood that this experiment
does not constitute a true benchmark since no analytical solution is
known, but having a look at ASPECT's results vs. the results obtained
with many other codes over the past 15 years leads to the inescapable
conclusion that ASPECT (as provided to the user in version r1889)
is the most 'off' in terms of second Vrms peak location and height.
Even more worrying is the lack of convergence to stable results
when resolution is increased.
Despite varying many parameters this puzzling effect could not be eliminated.
Since many users are currently busy studying plume dynamics, it is our
belief that this problem should be addressed within the briefest delay.

- During an informal conversation around a poster, a researcher himself busy
implementing compositional fields as a way to track materials told C.T. that
after careful testing he concluded that the entropy viscosity method was not
the best out there, which somehow goes against the philosophy of the code.
Given that the dynamics of lithospheric deformation is driven
more by density differences between materials than temperature effects,
having a thoroughly tested and validated stabilisation scheme seems to be a
pressing task.

- The cookbooks provided in the manual/distribution are useful but new ones
should be added (such as the R-T experiment when fixed), especially ones which
would involve large deformation of multiple materials. All users happily agreed to
provide some in the near future.

- Given that ASPECT relies on many libraries (DEAL.II, trilinos, p4est, blas, ...),
and that users install and run it on rather different systems,
few of us were certain that the code was running at
peak performance. We therefore suggested that all cookbooks should come with
an indicative run time (provided by us) for first order comparison.

- The virtual machine should be better advertised (in the manual, and online too), as it is
an easy way to test the code before switching to ASPECT.

- Nonlinear solvers (type and properties) should be better described and thoroughly
checked. Pertaining parameters to said solvers should also be made available to the user
with advice on how to tune them.

- The issue of stress boundary conditions was brought up by those of us concerned
with lithospheric-scale experiments. Could these be implemented ? if so in which delay ?
Could so-called open boundary conditions be implemented too ? Anne would like to cooperate on those.

- Parameters regarding the pre-conditioner and the solver are at the moment hidden
from the user. It is probably a good thing for beginners, but could there be some
sort of expert mode which would allow to tune these algorithms from the input file
for more advanced users ?

- While Courant condition-based timesteps are useful, we would also like to have the possibility
of using constant timesteps without having to resort to hard coding.

- Dynamic mesh refinement is a very great feature of the code but it was our opinion
that the coarsening sometimes yields very very coarse meshes and a minimum refinement level
(overriding the coarsening algorithm if necessary) would be greatly appreciated.
Juliane has been working on this issue recently and seems to be ready to incorporate this
in the main version.

- The issue of being able to switch between trilinos and petsc in a simple way was brought up.
How much effort would this take ? Could it be done ?

- Two users (Julianne & Jonathan) are currently looking into melt migration problems.

- The implementation of elasticity is now being looked at by Phd Student Sylvia Rockel at GFZ.

- Some of us find the code slow. Given its unique features and algorithms, this
feeling has to be backed up by hard facts. Could CIG demonstrate that for comparable simulations,
it does indeed does better than CITCOM ? Katrina is willing to look at this point with
the help of CIG. How could we define an objective metric for performance so that one can compare his or
her code with ASPECT ?

- CITCOM and many other codes of the past 20 years use Q1P0 elements. While we understand
that this element is not without issues, its stencil and its first order nature would most likely
yield smaller matrices which are faster to solve. However it should be supplemented with
a pressure smoothing algorithm. What is the developer stance on this element, and are you willing
to implement a pressure filtering scheme ? (C.T. has some experience with these schemes.)

- At the moment, the general 'simple' material model can only deal with two materials (a background one
and an additional composition). It is our opinion that a simple material model should
allow for an indefinite number of compositions and that the averaging scheme equations should be
modified accordingly. At the same time, the manual should mention and
justify why the geometric averaging for viscosity has been chosen.
Anne has such a model and is willing to provide it in the near future.
This would allow CT for instance to provide the setup for the Schmeling et al. 2008 experiment
or the Crameri et al. 2012 experiment as additional cookbooks.

- Ian has been looking at the implementation of a real free surface + stabilisation and is willing to
introduce it in the release code with the help/supervision of the developers.

- The manual shows results of the Blankenbach et al. (1989) experiment for all three
Rayleigh numbers but surprisingly results are truncated in time and the system
has not yet reached steady state.

- There were informal talks these past months on the forum about level set methods
and active tracers. Could the developers clarify their intentions with regards to
these approaches ?

- Tutorial videos could also be beneficial to new users.

We also thought that in order for ASPECT to be accepted by the community
more pro-active steps should be taken at EGU, AGU and similar meetings:
ASPECT developers should make sure they come to these meetings and promote
their work while users show applications and extensions. Mini-workshops and
users social activities could also be organised during these meetings to promote
cooperation. Perhaps in Europe, the users could help organise these.

The deadline for EGU is January 16. Would it be a good idea that all
ASPECT users submit their abstracts in the same session to provide a strong front?

Although realising this is a long list of points, we look forward to your response and a fruitful cooperation.

Kind regards,

the 'A' team :)


















-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://geodynamics.org/pipermail/aspect-devel/attachments/20131220/38470751/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pres.pdf
Type: application/pdf
Size: 2374454 bytes
Desc: pres.pdf
URL: <http://geodynamics.org/pipermail/aspect-devel/attachments/20131220/38470751/attachment-0001.pdf>