Difference between revisions of "Generic elliptic solver"

From Einstein Toolkit Documentation
Jump to: navigation, search
Line 12: Line 12:
 
* Existing implementations:
 
* Existing implementations:
 
** TwoPunctures;
 
** TwoPunctures;
** NoExcision;
+
** NoExcision (FD conjugate-gradient, system of decoupled equations, no AMR);
 
** Kranc-generated Laplace solver via relaxation;
 
** Kranc-generated Laplace solver via relaxation;
** BAM_Elliptic;
+
** BAM_Elliptic (https://svn.aei.mpg.de/numrel/AEIThorns/BAM_Elliptic/trunk/; usability? license?);
 +
** TATElliptic?
 +
** Aaryn's solver (2D)?
  
 
Possible directions:
 
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 (this 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;

Revision as of 11:17, 2 November 2011

Notes

Requirements:

  • Steve: FunWave, need parallelism and mesh refinement;
  • Ian: 6-variable, linear elliptic equation, need mesh refinement and perhaps 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;

Existing tools:

  • Scott's 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?
  • Existing implementations:

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 (this 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;