CT_MultiLevel

Eloisa Bentivegna <eloisa.bentivegna@ct.infn.it>

May 27 2013

Abstract

This thorn implements a multigrid solver for systems of elliptic partial differential equations. It uses Carpet’s interface to handle loops over the grid hierarchy and pass information between different components. The system of equations is passed to the solver via parameters pointing to the external grid functions that hold the equation coefficients.

1 Introduction

CT_MultiLevel is a Cactus thorn that implements a multigrid solver for elliptic partial differential equations (PDEs). The implementation is rather standard, and it also allows for local AMR grids (in which case it uses a rudimentary multilevel algorithm).

This thorn requires Carpet, which it uses to manage the access to the grid structure (via the BEGIN_*_LOOP and END_*_LOOP macros) and to pass information between the different levels (via the restriction and prolongation operators).

Structurally, the solver can tackle any type of equation or system of equations, their coefficients being passed to CT_MultiLevel via string parameters holding the names of the corresponding grid function. The thorn comes with a number of test cases which should be easy to customize and extend.

2 Principle of multigrid

Multigrid schemes are designed to solve elliptic equations on a hierarchy of grids, with the goal of speeding up the convergence rate of relaxation algorithms (such as Gauss-Seidel) by eliminating different frequency modes of the solution error on different grids. It is known that relaxation techniques are very effective at eliminating the high-frequency part of the error; when solving an elliptic PDE on a grid, it is then advantageous to relax it on a coarser grid beforehand and interpolate the result back onto the original grid. Complex schemes involving several grid levels, each with a different PDE, can be designed to maximize the speed up. Please refer to [1] for the details.

3 Using This Thorn

CT_MultiLevel, along with the rest of the Cosmology arrangement, is released under the General Public License, version 2 and higher. The copyright of this thorn remains with myself.

3.1 Obtaining This Thorn

CT_MultiLevel is publicly available in COSMOTOOLKIT’s git repository:

   git clone https://eloisa@bitbucket.org/eloisa/cosmology.git

A helper thorn CT_Analytic is available under the same repository.

3.2 Basic Usage

In order to solve an elliptic PDE with CT_MultiLevel, CT_MultiLevel can be simply compiled in, with the requirement that Carpet is compiled as well. The thorn also inherits from boundary and grid for boundary APIs and coordinate labels.

Currently, the equation is solved in a single schedule call at CCTK_INITIAL, in GLOBAL_LATE mode (to ensure that necessary objects such as the grid arrays have been populated).

As the equation coefficients will be set by grid functions, a thorn allocating and setting these grid functions to the desired values has to be included. Another thorn in the Cosmology arrangement, CT_Analytic, serves this purpose. Grid functions of other origin are naturally just as good.

Each equation in the system to solve is parametrized as follows:

cxxxxψ + cxyxyψ + cxzxzψ + cyyyyψ + cyzyzψ + czzzzψ + (1) cxxψ + cyyψ + czzψ + c0ψn0 + c1ψn1 + c2ψn2 + c3ψn3 + c4ψn4 = 0 (2)

All the coefficients c and the powers n can be specified by setting the parameters *_gfname[*] to the desired grid function name. These parameters are arrays to allow for the solution of systems of equations.

The only other parameter which must be set to ensure correct operation is CT_MultiLevel::topMGlevel, which tells the solver which is the finest refinement level that covers the entire domain in which the equation is to be solved. All levels below and including this will be used in the classical multigrid sense (e.g., in a V- or FMG-cycle). The ones above will be treated as local AMR boxes, and be solved via a multilevel prescription; presently, this involves simply interpolating the solution from the topMGlevel refinement level at the end of the multigrid part and relaxing it progressively, from coarser to finer, on all the local grids.

Other parameters control the stopping criteria (numbers of relaxation sweeps and residual tolerance), the finite-differencing order used to discretized the equation, the number of equations in the system, and whether the solution error should be calculated (this obviously requires the exact solution to be known and stored in a grid function, its name passed to CT_MultiLevel via the usual parameter mechanism).

Concrete examples on how to set these parameters are provided below.

3.3 Special Behaviour

When the equation coefficients cannot be passed in via external grid functions (as is the case, for instance, when solving a coupled system of PDEs), then one can resort to auxiliary functions, which are recalculated after each relaxation sweep. The actual algorithm used to populate these coefficient has to be provided by the user; some examples are provided under src/auxiliaries. These values are stored in CT_MultiLevel’s auxiliaries variable group.

All coefficients, auxiliaries, and other useful grid functions are stored in the pointer structure coeffptr, to which the user can further append pointers to extra external grid functions, which are not used as PDE coefficients (and thus do not need additional storage space and shouldn’t be introduced as auxiliaries), but are still needed by the solver. Examples can be found under src/extra.

Finally, if variable resetting is necessary after each relaxation step (for instance, when solving linear problems in periodic domains), a suitable calculation needs to be provided by the user, similar to the examples in src/integral.

3.4 Interaction With Other Thorns

CT_MultiLevel uses some of Carpet’s macros to access different components of a grid hierarchy, and its prolongation and restriction operators to pass information between them.

Furthermore, CT_MultiLevel needs at least one external thorn to set the PDE coefficients. The helper thorn CT_Analytic can be used to this purpose, but any set of external grid functions will serve the purpose.

3.5 Examples

The solver is described in [2], along with a number of examples. I rediscuss some of those below from the technical standpoint, highlighting which parameters need to be set in each case and whether other information is required from the user.

3.6 Poisson’s equation

Poisson’s equation reads:

Δψ + ρ = 0 (3)

where ρ is a known source function and ψ is an unknown to solve for. Its Laplacian, Δψ, simply represents the sum of its diagonal second-order derivatives:

Δψ = xxψ + yyψ + zzψ (4)

so that cxx_gfname[0], cyy_gfname[0] and czz_gfname[0] all have to be set to one. The source term can be specified freely. CT_Analytic can be used to set all coefficients, e.g. setting the CT_Analytic::free_data parameter to exact, where the coefficients of the diagonal second-order derivatives are all one, the source term can be set to a linear combination of a gaussian, a sine, and a 1r term, and all the other coefficients default to zero. To choose a gaussian source term, for instance, one can set:

CT_Analytic::free_data             = "exact"  
CT_Analytic::ampG                  = 1  
CT_Analytic::sigma                 = 0.5

and then pass the relevant grid functions to CT_MultiLevel:

CT_MultiLevel::cxx_gfname[0]       = "CT_Analytic::testcxx"  
CT_MultiLevel::cyy_gfname[0]       = "CT_Analytic::testcyy"  
CT_MultiLevel::czz_gfname[0]       = "CT_Analytic::testczz"  
CT_MultiLevel::c0_gfname[0]        = "CT_Analytic::testc0"  
CT_MultiLevel::n0[0]               = 0

CT_Analytic can also be used to set the initial guess for the solver:

CT_MultiLevel::inipsi_gfname[0]    = "CT_Analytic::testinipsi"

Any coefficient that is not specified explicitly via a parameter will be initialized to zero.

Other parameters can be used to tune the solver’s behavior, including the cycling mode through the different levels and the stopping criterion. The parameter file par/poisson.par provides a concrete example.

3.7 The Einstein constraint system for a spherical distribution of matter

Let’s consider Einstein’s constraints in the Lichnerowicz-York form and in a conformally-flat space, i.e. a coupled system of four PDEs for the four functions ψ and Xi:

Δψ K2 12 ψ5 + 1 8AijAijψ7 = 2πρψ5 (5) ΔXi + ijXj 2 3ψ6δij iK = 8πjiψ10 (6)

where

Aij = iXj + jXi + 2 3δijkXk (7)

and K, ρ and ji are freely specifiable functions.

Due to conformal flatness, again Δ = xx + yy + zz. However, in this case we have the additional complication that the coefficient of the ψ7 term in the first equation depends on Xi, and therefore has to be updated during the solution process. This is accomplished by storing this coefficient in an auxiliary function, filled by the function CT_SetAuxiliaries initially and after each Gauss-Seidel iteration. The recipe to fill this grid function is contained in src/auxiliaries/Lump.cc.

The parameter specification for this case is then:

CT_Analytic::free_data             = "Lump"  
CT_Analytic::Kc                    = -0.1  
CT_Analytic::ampG                  = 1  
CT_Analytic::ampC                  = 1  
CT_Analytic::ampV                  = 0.1  
CT_Analytic::sigma                 = 0.2  
CT_Analytic::vecA                  = 0.6

which specifies the equation coefficients and the free data K, ρ and Xi, and:

CT_MultiLevel::inipsi_gfname[0]    = "CT_Analytic::testinipsi"  
CT_MultiLevel::cxx_gfname[0]       = "CT_Analytic::testcxx"  
CT_MultiLevel::cyy_gfname[0]       = "CT_Analytic::testcyy"  
CT_MultiLevel::czz_gfname[0]       = "CT_Analytic::testczz"  
CT_MultiLevel::n0[0]               = 5  
CT_MultiLevel::c0_gfname[0]        = "CT_Analytic::testc0"  
CT_MultiLevel::n1[0]               = 0  
CT_MultiLevel::c1_gfname[0]        = "CT_Analytic::testc1"  
CT_MultiLevel::n2[0]               = -7  
CT_MultiLevel::c2_gfname[0]        = "CT_MultiLevel::ct_auxiliary[0]"  
 
CT_MultiLevel::inipsi_gfname[1]    = "CT_Analytic::testinixx"  
CT_MultiLevel::cxx_gfname[1]       = "CT_Analytic::testcxx"  
CT_MultiLevel::cyy_gfname[1]       = "CT_Analytic::testcyy"  
CT_MultiLevel::czz_gfname[1]       = "CT_Analytic::testczz"  
CT_MultiLevel::n0[1]               = 0  
CT_MultiLevel::c0_gfname[1]        = "CT_Analytic::testc2"  
CT_MultiLevel::n1[1]               = 0  
CT_MultiLevel::c1_gfname[1]        = "CT_MultiLevel::ct_auxiliary[1]"  
 
CT_MultiLevel::inipsi_gfname[2]    = "CT_Analytic::testinixy"  
CT_MultiLevel::cxx_gfname[2]       = "CT_Analytic::testcxx"  
CT_MultiLevel::cyy_gfname[2]       = "CT_Analytic::testcyy"  
CT_MultiLevel::czz_gfname[2]       = "CT_Analytic::testczz"  
CT_MultiLevel::n0[2]               = 0  
CT_MultiLevel::c0_gfname[2]        = "CT_Analytic::testc3"  
CT_MultiLevel::n1[2]               = 0  
CT_MultiLevel::c1_gfname[2]        = "CT_MultiLevel::ct_auxiliary[2]"  
 
CT_MultiLevel::inipsi_gfname[3]    = "CT_Analytic::testinixz"  
CT_MultiLevel::cxx_gfname[3]       = "CT_Analytic::testcxx"  
CT_MultiLevel::cyy_gfname[3]       = "CT_Analytic::testcyy"  
CT_MultiLevel::czz_gfname[3]       = "CT_Analytic::testczz"  
CT_MultiLevel::n0[3]               = 0  
CT_MultiLevel::c0_gfname[3]        = "CT_Analytic::testc4"  
CT_MultiLevel::n1[3]               = 0  
CT_MultiLevel::c1_gfname[3]        = "CT_MultiLevel::ct_auxiliary[3]"

which informs CT_MultiLevel on the grid functions holding the coefficients and on the existence of auxiliary functions.

Further parameters control other aspects of the solution, and can be found in par/constraints_spherical.par. In particular, the parameter CT_MultiLevel::number_of_equations has to be set explicitly to four to accomodate the full system of equations.