Generic elliptic solver
Revision as of 11:37, 2 November 2011 by Bentivegna (talk | contribs)
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 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)?
- 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;