<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body>
<div class="BodyFragment"><font size="2"><span style="font-size:10pt;">
<div class="PlainText">Dear Aspect team and users, <br>
<br>
AGU seemed a good time for some of us ASPECT users to gather <br>
around a table and talk about our experience so far and our future plans. <br>
Present to the meeting were:<br>
<br>
- Anne Glerum <br>
- Rene Gassmoeller<br>
- Juliane Dannberg<br>
- Sacha Brune<br>
- Ian Rose<br>
- Jonathan Perry-Houts<br>
- Katrina Arredondo<br>
- Rajesh Kommu (CIG)<br>
- Cedric Thieulot<br>
<br>
What follows is a list of points, wishes, and questions <br>
we came up with that evening:<br>
<br>
- C.T. showed in his talk (hereby attached) that the Rayleigh-Taylor experiment as
<br>
presented in van Keken et al. (JGR 1997) run with ASPECT yields <br>
abnormal results. It is of course understood that this experiment<br>
does not constitute a true benchmark since no analytical solution is<br>
known, but having a look at ASPECT's results vs. the results obtained<br>
with many other codes over the past 15 years leads to the inescapable <br>
conclusion that ASPECT (as provided to the user in version r1889) <br>
is the most 'off' in terms of second Vrms peak location and height. <br>
Even more worrying is the lack of convergence to stable results <br>
when resolution is increased. <br>
Despite varying many parameters this puzzling effect could not be eliminated.<br>
Since many users are currently busy studying plume dynamics, it is our<br>
belief that this problem should be addressed within the briefest delay.<br>
<br>
- During an informal conversation around a poster, a researcher himself busy<br>
implementing compositional fields as a way to track materials told C.T. that<br>
after careful testing he concluded that the entropy viscosity method was not <br>
the best out there, which somehow goes against the philosophy of the code. <br>
Given that the dynamics of lithospheric deformation is driven<br>
more by density differences between materials than temperature effects, <br>
having a thoroughly tested and validated stabilisation scheme seems to be a <br>
pressing task. <br>
<br>
- The cookbooks provided in the manual/distribution are useful but new ones <br>
should be added (such as the R-T experiment when fixed), especially ones which <br>
would involve large deformation of multiple materials. All users happily agreed to
<br>
provide some in the near future. <br>
<br>
- Given that ASPECT relies on many libraries (DEAL.II, trilinos, p4est, blas, ...),<br>
and that users install and run it on rather different systems, <br>
few of us were certain that the code was running at<br>
peak performance. We therefore suggested that all cookbooks should come with <br>
an indicative run time (provided by us) for first order comparison. <br>
<br>
- The virtual machine should be better advertised (in the manual, and online too), as it is<br>
an easy way to test the code before switching to ASPECT.<br>
<br>
- Nonlinear solvers (type and properties) should be better described and thoroughly
<br>
checked. Pertaining parameters to said solvers should also be made available to the user<br>
with advice on how to tune them.<br>
<br>
- The issue of stress boundary conditions was brought up by those of us concerned
<br>
with lithospheric-scale experiments. Could these be implemented ? if so in which delay ?<br>
Could so-called open boundary conditions be implemented too ? Anne would like to cooperate on those.<br>
<br>
- Parameters regarding the pre-conditioner and the solver are at the moment hidden
<br>
from the user. It is probably a good thing for beginners, but could there be some
<br>
sort of expert mode which would allow to tune these algorithms from the input file
<br>
for more advanced users ?<br>
<br>
- While Courant condition-based timesteps are useful, we would also like to have the possibility
<br>
of using constant timesteps without having to resort to hard coding. <br>
<br>
- Dynamic mesh refinement is a very great feature of the code but it was our opinion
<br>
that the coarsening sometimes yields very very coarse meshes and a minimum refinement level
<br>
(overriding the coarsening algorithm if necessary) would be greatly appreciated. <br>
Juliane has been working on this issue recently and seems to be ready to incorporate this
<br>
in the main version.<br>
<br>
- The issue of being able to switch between trilinos and petsc in a simple way was brought up.<br>
How much effort would this take ? Could it be done ?<br>
<br>
- Two users (Julianne & Jonathan) are currently looking into melt migration problems.
<br>
<br>
- The implementation of elasticity is now being looked at by Phd Student Sylvia Rockel at GFZ.<br>
<br>
- Some of us find the code slow. Given its unique features and algorithms, this <br>
feeling has to be backed up by hard facts. Could CIG demonstrate that for comparable simulations,
<br>
it does indeed does better than CITCOM ? Katrina is willing to look at this point with
<br>
the help of CIG. How could we define an objective metric for performance so that one can compare his or
<br>
her code with ASPECT ? <br>
<br>
- CITCOM and many other codes of the past 20 years use Q1P0 elements. While we understand
<br>
that this element is not without issues, its stencil and its first order nature would most likely
<br>
yield smaller matrices which are faster to solve. However it should be supplemented with<br>
a pressure smoothing algorithm. What is the developer stance on this element, and are you willing<br>
to implement a pressure filtering scheme ? (C.T. has some experience with these schemes.)<br>
<br>
- At the moment, the general 'simple' material model can only deal with two materials (a background one
<br>
and an additional composition). It is our opinion that a simple material model should
<br>
allow for an indefinite number of compositions and that the averaging scheme equations should be
<br>
modified accordingly. At the same time, the manual should mention and <br>
justify why the geometric averaging for viscosity has been chosen. <br>
Anne has such a model and is willing to provide it in the near future. <br>
This would allow CT for instance to provide the setup for the Schmeling et al. 2008 experiment<br>
or the Crameri et al. 2012 experiment as additional cookbooks. <br>
<br>
- Ian has been looking at the implementation of a real free surface + stabilisation and is willing to<br>
introduce it in the release code with the help/supervision of the developers.<br>
<br>
- The manual shows results of the Blankenbach et al. (1989) experiment for all three<br>
Rayleigh numbers but surprisingly results are truncated in time and the system <br>
has not yet reached steady state. <br>
<br>
- There were informal talks these past months on the forum about level set methods
<br>
and active tracers. Could the developers clarify their intentions with regards to
<br>
these approaches ?<br>
<br>
- Tutorial videos could also be beneficial to new users. <br>
<br>
We also thought that in order for ASPECT to be accepted by the community<br>
more pro-active steps should be taken at EGU, AGU and similar meetings: <br>
ASPECT developers should make sure they come to these meetings and promote <br>
their work while users show applications and extensions. Mini-workshops and <br>
users social activities could also be organised during these meetings to promote<br>
cooperation. Perhaps in Europe, the users could help organise these.<br>
<br>
The deadline for EGU is January 16. Would it be a good idea that all<br>
ASPECT users submit their abstracts in the same session to provide a strong front?
<br>
<br>
Although realising this is a long list of points, we look forward to your response and a fruitful cooperation.<br>
<br>
Kind regards,<br>
<br>
the 'A' team :)<br>
<br>
<br>
<br>
</div>
</span></font></div>
<div class="BodyFragment"><font size="2"><span style="font-size:10pt;">
<div class="PlainText"><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</div>
</span></font></div>
</body>
</html>