Generic elliptic solver

Notes

Requirements:

• Steve: FunWave, need parallelism and mesh refinement;
• Ian: 6-variable, linear elliptic equation, may need mesh refinement and definitely parallelism;
• Eloisa: generic solver, easy to use and to experiment with more important than efficiency, no restriction on topology, mesh refinement would be good but doesn't need it for everything;
• Do these requirements limit the type of solver? Can we use multigrid? Spectral?
• Boundary conditions play now a more important role than for hyperbolic problems. Are the current mechanisms for specifying them enough? Do we need, say, inner boundaries?

Existing tools:

• Scott's multigrid AMR elliptic solver, second order with extension to fourth order coming soon; integrate with Cactus via own data conversions, but currently making it talk to Carpet. Available immediately via SVN;
• Eloisa has experimented with OpenFOAM: nice and flexible, not great for accuracy, need to import data to Cactus afterwards (not complicated, but unfeasible to do at each timestep).
• Current CactusElliptic: EllBase gives interface to register elliptic solvers, currently not much implemented (SOR), equation type is a little restrictive (linear), compatibility with AMR unknown;
• CarpetPETSc (can PETSc work with AMR)?
• Lorene/KADATH;
• Existing implementations:
  • TwoPunctures;
  • NoExcision (FD conjugate-gradient, system of decoupled equations, no AMR);
  • Kranc-generated Laplace solver via relaxation;
  • BAM_Elliptic (https://svn.aei.mpg.de/numrel/AEIThorns/BAM_Elliptic/trunk/; usability? license?);
  • TATElliptic (interface only)?
  • Aaryn's solver (2D)?
• There's currently nothing that allows for AMR!
• Chombo multigrid AMR?

Possible directions:

• EllBase road, make type of equation more generic:
  • Add more terms and coefficients;
  • Ian: specify the equation via a callback for the residual, a registration method for the variables to solve for and possibly the derivatives/jacobians, much like in MoL (these could be generated via Kranc); this would also really only work with relaxation methods, not for direct inversion methods. Many solvers, all working along these guidelines? EllBase would provide the interface;
• Petsc
  • Use petsc directly
  • Write an interface between petsc and cactus

Discussion and conclusions

• Erik has some experience implementing solvers based on the PETSc library, and has confidence that this method would yield robust tools as long as one is willing to code up all the equation jacobians; these will be variably complicated depending on the type of mesh refinement, i.e. relatively simple for unigrid or old-school multipatch, more complicated for new multipatch and AMR. This means one could complete this project step-by-step, progressively adding AMR capabilities by coding up the appropriate jacobians;