[aspect-devel] AGU meeting feedback

[Timo Heister]

>> - 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.

I would be interested in rerunning this exact setup. Cedric, can you
please send me the .prm?

A couple of things that come to my mind:
1. Are these tests using the intel compilers? We have been struggling
with intel compiler bugs with the latest deal.II release and I am not
trusting the compiler settings we used before 8.1 (which we in the
process of releasing right now)
2. Could the second peak be initiated by an instability that depends
on the mesh? All the runs are on a mesh with an even number of
elements. It would be easy to test this by changing the geometry model
to call subdivided_hyper_rectangle() with an odd number of repitions
instead of hyper_rectangle().
3. What is that strange smearing at the top right half (starting at
t=1000 on slide 15) on the bottom of the plume? This looks
non-physical to me.

> Yes. We've brought out a new deal.II release a couple of days ago and will
> follow up with a new Aspect release after the new year. I'm sure Timo will
> be willing to also update the virtual machine and we can make sure we link
> better to it from the website.

Yes, I will update that soon. I guess we should be able to do a new
aspect release in January.

>> - 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.
>
> Same here -- patches are definitely welcome. The place to modify is
> core.cc:refine_mesh().

This already found its way into Aspect, see "Minimum refinement level"
in the parameter file.

>> - 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 ?
>
> Timo did a lot of work in deal.II to allow for such experiments. I will let
> him comment on this.

Note that there is two ways to implement PETSc support:
1. the same way we have been using PETSc in deal.II so far and that
works the same way as Trilinos: block solvers are handled by deal.II
not by the linear algebra library. This is not very difficult to do,
but I haven't gotten around doing this, because I don't see an
immediate gain.
2. Let PETSc deal with the block system (or even coupled with
temperature; nonlinear solvers; etc). This is more difficult and I
don't know how to make this work, yet.

>> - 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 ?
>
> I think it would be great to have such a comparison, preferably in terms of
> error as a function of run time. I don't know how it will turn out (I have
> hopes that it helps that Aspect is now at least 50% faster than it used to
> be 6 months ago). I'll use the opportunity to again point at the new section
> in the manual on how to make Aspect run faster.

I, too, would like to see comparisons, especially because those
experiments would point us at things to improve.

>> - 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.)
>
>
> I don't know enough about these schemes. Given the length of the TODO list,
> it's not close to the top for me. The Q1P0 scheme is known to be very
> diffusive and have issues with stability which makes me rather reluctant to
> use it.

Q1P0 is not a stable element, so you would need an additional
stabilization scheme, which would introduce additional parameters that
need tuning and add diffusion you don't want. I think Stokes systems
nowadays should be solved using stable discretizations.

>> - 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.

Agreed, I have been talking to him about this a couple of times and
offered my help. I hope we can make this happen in 2014.


-- 
Timo Heister
http://www.math.clemson.edu/~heister/