Hi Colin, On 30/04/16 20:40, Colin Cotter wrote:
Hi Martin, I discussed this complex number issue with Terry Haut a while ago. He has an equivalent formulation that stays entirely in real numbers - this is because the complex values appear as conjugate pairs. So, it's probably easiest to move to this real-only formulation.
I thought that the conjugate pairs (of \alpha) are important to reduce the sum of REXI terms to half of it but not for the reformulation to a real-only problem. This should be always possible - independent of the conjugate pairs (and also goes partly back to a document from Terry one year ago!).
By the way, the Coriolis term does make a big difference to how things are solved, I think that it will only be possible to efficiently solve this system using hybridisation techniques: this was the foundation of the proposal that we put in to NERC with Beth in January.
Back in 2015 I thought that it's a good idea to numerically investigate iterative solvers (Jacobi / CG / MG) for REXI in SWEET since I thought that we'd need iterative solvers for LFRic/GungHo to get REXI running. You can find a lynx document with some preliminary results about this here: https://github.com/schreiberx/sweet/tree/master/doc/notes_on_iterative_solve... It's just a sketch to start writing some documentation on the problem but it turned out to be by far more challenging. It was just a test implementation, but none of the implemented solvers seemed to converge fast enough or only with a very low (and useless) resolution. MG was implemented with a 2x2 <-> 1x1 restr./prolong. CG was only converging if implementing a non-standard residual computation. The "it doesn't make difference" referred to the weak formulation of the Coriolis term. It should be definitively challenging to write a GMG for this, but I don't see a major problem with an AMG solver. They should be able to cope with the varying Coriolis term and in particular with the \alpha poles generating large off-diagonal values. I'm more worried about numerical cancellation issues since we might get get several orders of magnitude different values in the matrix due to large imaginary \alpha values for large time steps.
To answer your other questions: we are converging towards a Firedrake dynamical core code, this is being developed on github: https://github.com/firedrakeproject/dcore but things are not really ready for integration with REXI yet, we still need to demonstrate that the basic discretisation works for 3D on the sphere.
Nice! Weather-drake ;-)
We have a plan to implement a multigrid solver for the the REXI scheme for FEM shallow water, and then develop an APINT scheme using Firedrake for shallow water on the sphere with Jemma, we should probably discuss to make sure that we don't tread on each other's toes.
Thanks for letting me know about the NERC project. Apart from the APinT stuff it sounds very much like what I am/was partly working on (also involving other researchers...). Maybe next time all the people who are *really* working on this should hand in a project... Let's discuss the rest off-list. Cheers, Martin
all the best --cjc
On 30 April 2016 at 07:35, Martin SCHREIBER <M.Schreiber@exeter.ac.uk <mailto:M.Schreiber@exeter.ac.uk>> wrote:
Dear Firedrakers,
I discussed yesterday with Andrew if Firedrake can be (ab)used to solve PDEs with a non-traditional time stepping method (we call it REXI) and he suggested me to drop an Email to this mailing list. (@David/Colin: It's related to our parallelization-in-time work).
Let L be the linear operator of the SWE on the sphere in advective form including the average height (by putting the perturbation into the non-linear part). L also contains the longitude-varying Coriolis term, but this shouldn't make a big difference here.
As one building block of the new time stepping method we like to solve the SoEs given by (\alpha - L) U = U0 with \alpha a complex shifted pole creating a non-singular SoE and U0 the DoFs to solve for.
I don't see any problem to write this in weak formulation as it is required in Firedrake.
Now the following questions arise:
* Is Firedrake able to assemble and solve these system of equations with the complex value \alpha? It's only important to keep the real values of "U". The imaginary values of U are not important if that's of any help.
* If not, is Firedrake still able to solve a reformulation which would have a 6x6 linear operator instead of a 3x3 and 6 DoFs (3 pseudo DoFs) per cell? (Basically reformulating the SoE with real values instead of complex ones).
* Is there any Firedrake code publicly available with the GungHo FEM dyn-core on the sphere with a C-grid?
* A question related to possible future work: Is Firedrake supporting Semi-Lagrangian methods efficiently?
Cheers,
Martin
-- Dr. rer.-nat. Martin Schreiber Lecturer, proleptic Scientific and High-Performance Computing University of Exeter
College of Engineering, Mathematics and Physical Sciences Harrison Building, Room 319, North Park Road, Exeter, EX4 4QF
_______________________________________________ firedrake mailing list firedrake@imperial.ac.uk <mailto:firedrake@imperial.ac.uk> https://mailman.ic.ac.uk/mailman/listinfo/firedrake
-- http://www.imperial.ac.uk/people/colin.cotter
www.cambridge.org/9781107663916 <http://www.cambridge.org/9781107663916>
_______________________________________________ firedrake mailing list firedrake@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/firedrake
-- Dr. rer.-nat. Martin Schreiber Lecturer, proleptic Scientific and High-Performance Computing University of Exeter College of Engineering, Mathematics and Physical Sciences Harrison Building, Room 319, North Park Road, Exeter, EX4 4QF