Generic elliptic solver - Revision history

Bentivegna at 10:39, 3 November 2011

2011-11-03T10:39:45Z

Hinder: /* Plan */

2011-11-03T08:57:18Z

‎Plan

Hinder: /* Discussion and conclusions */

2011-11-03T08:56:32Z

‎Discussion and conclusions

Bentivegna at 17:33, 2 November 2011

2011-11-02T17:33:20Z

Bentivegna at 17:14, 2 November 2011

2011-11-02T17:14:27Z

Bentivegna at 17:07, 2 November 2011

2011-11-02T17:07:58Z

Bentivegna at 16:47, 2 November 2011

2011-11-02T16:47:07Z

Hinder: /* Notes */

2011-11-02T15:55:09Z

‎Notes

Hinder: /* Notes */

2011-11-02T15:54:47Z

‎Notes

Bentivegna at 13:56, 2 November 2011

2011-11-02T13:56:51Z

@@ Line 11: / Line 11: @@
 * 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)? LSUPETSc?
+* CarpetPETSc (can PETSc work with AMR)? LSUPETSc? Note: PETSc doesn't work with OpenMP;
 * Lorene/KADATH;
 * Existing implementations:
@@ Line 23: / Line 23: @@
 * Chombo multigrid AMR?
 * HYPRE?
 Possible directions:

←Older revision		Revision as of 08:57, 3 November 2011
Line 41:		Line 41:
	* Take LSUPETSc as a basis, and try to add the missing pieces to make it work with the grids we're interested in;		* Take LSUPETSc as a basis, and try to add the missing pieces to make it work with the grids we're interested in;
	* Check with the TexMEx developers what their roadmap is for integration with Carpet, and see if we can make this tool solve generic equations.		* Check with the TexMEx developers what their roadmap is for integration with Carpet, and see if we can make this tool solve generic equations.
		+	* Implement a conjugate-gradient solver in Kranc and then try to generalise to a generic elliptic interface.

@@ Line 36: / Line 36: @@
 * 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;
 * TexMEx, a multigrid solver with AMR capabilities, is currently available in Cactus. The integration with Cactus (and Carpet) is currently minimal: TexMEx is used as a black box that produces the result (with its own data structures, etc.) and only at the end communicates it to Cactus. This prevents the framework from seeing inside its algorithm, which is not ideal for debugging, and additionally makes it hard to extend the package, e.g. by letting the user specify a callback function to calculate the residual. As of now, TexMEx implements the hamiltonian constraint, which doesn't help who (Steve, Ian) is interested in solving other types of equations.
 ====Plan====
 * Take LSUPETSc as a basis, and try to add the missing pieces to make it work with the grids we're interested in;
 * Check with the TexMEx developers what their roadmap is for integration with Carpet, and see if we can make this tool solve generic equations.

@@ Line 35: / Line 35: @@
 * There is a distinction between inversion methods and relaxation methods; the former use matrix inversion to solve a linear system (possibly coming from the linearization of a non-linear problem), whereas the latter reduce the residuals to zero by implementing the corresponding parabolic equation and let the solution relax to a static one. PETSc has some infrastructure for relaxation methods (namely, multigrid solvers), but has much more in the way of inversion methods (along with linearization methods). Additionally, AMR is easy to cope with in the inversion methods, where the grid (in real space or in frequency space) is mapped to a matrix and its "connectivity" is irrelevant, but is harder to have around in relaxation methods, where the jacobians of all the involved operators (including prolongation, ...) have to appear;
 * 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;
-* TexMEx, a multigrid solver with AMR capabilities, is currently available in Cactus. The integration with Cactus (and Carpet) is currently minimal: TexMEx is used as a black box that produces the result (with its own data structures, etc.) and only at the end communicates it to Cactus. This prevents the framework from seeing inside its algorithm, which is not ideal for debugging, and additionally makes it hard to extend the package, e.g. by letting the user specify a callback function to calculate the residual. As of now, TexMEx implements the hamiltonian constraint, which doesn't help who (Steve, Ian) is interested in solving other types of equations;
+* TexMEx, a multigrid solver with AMR capabilities, is currently available in Cactus. The integration with Cactus (and Carpet) is currently minimal: TexMEx is used as a black box that produces the result (with its own data structures, etc.) and only at the end communicates it to Cactus. This prevents the framework from seeing inside its algorithm, which is not ideal for debugging, and additionally makes it hard to extend the package, e.g. by letting the user specify a callback function to calculate the residual. As of now, TexMEx implements the hamiltonian constraint, which doesn't help who (Steve, Ian) is interested in solving other types of equations.
 ====Plan====

@@ Line 11: / Line 11: @@
 * 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)?
+* CarpetPETSc (can PETSc work with AMR)? LSUPETSc?
 * Lorene/KADATH;
 * Existing implementations:
@@ Line 36: / Line 36: @@
 * 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;
 * TexMEx, a multigrid solver with AMR capabilities, is currently available in Cactus. The integration with Cactus (and Carpet) is currently minimal: TexMEx is used as a black box that produces the result (with its own data structures, etc.) and only at the end communicates it to Cactus. This prevents the framework from seeing inside its algorithm, which is not ideal for debugging, and additionally makes it hard to extend the package, e.g. by letting the user specify a callback function to calculate the residual. As of now, TexMEx implements the hamiltonian constraint, which doesn't help who (Steve, Ian) is interested in solving other types of equations;

@@ Line 22: / Line 22: @@
 * There's currently nothing that allows for AMR!
 * Chombo multigrid AMR?
 Possible directions:
@@ Line 32: / Line 33: @@
 ====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;

←Older revision		Revision as of 16:47, 2 November 2011
Line 30:		Line 30:
	** Use petsc directly		** Use petsc directly
	** Write an interface between petsc and cactus		** 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;

@@ Line 27: / Line 27: @@
 ** 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;
 ** Use petsc directly
 ** Write an interface between petsc and cactus

←Older revision		Revision as of 15:54, 2 November 2011
Line 27:		Line 27:
	** Add more terms and coefficients;		** 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;		** 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;
		+	** Use petsc directly
		+	** Write an interface between petsc and cactus