Add CT_MultiLevel elliptic solver to the Einstein Toolkit

Create issue
Issue #1676 closed
Ian Hinder created an issue

This elliptic solver (http://lists.einsteintoolkit.org/pipermail/users/2013-August/003174.html) is being used by more people now, and it would be good to have it in the toolkit. It has tests and documentation, and the author supports (though has not requested) inclusion (http://lists.einsteintoolkit.org/pipermail/users/2014-January/003425.html).

Keyword:

Comments (8)

  1. Ian Hinder reporter
    • changed status to open
    • removed comment

    At an ET telecon, it was suggested that we should have an example of the use of this thorn for the gallery before including it in the toolkit.

  2. Ian Hinder reporter
    • removed comment

    Eloisa has provided a gallery entry, and I have added it to a staging area for the ET gallery:

    http://einsteintoolkit.org/about/gallery/incoming.php

    I have written a brief description, but probably Eloisa could do a better job. I will ask her to update what I have written.

    Does anything else need to be done before this is added to the toolkit? Someone other than Eloisa should also check that they can run the gallery example, and are able to check out the code and that it passes all its tests. The next step would seem to be to add it to the thorn list.

  3. Frank Löffler
    • removed comment

    Looks perfect to me. I wish we would have examples that good for more things. Since inclusion was already discussed, and the only missing point was an example for the use: please feel free to include the thorn in the toolkit. I leave it to Eloisa to either decide about moving the source to some ET repository, or give the maintainers write access (e.g. to be able to take care of releases and possibly bug fixes). Also, please use the https URL for bitbucket repositories.

  4. Eloisa Bentivegna
    • removed comment
    • changed watchers to eloisa

    Thanks, guys. I assume you are looking for a description of the example, not of the solver itself?

    The repository move sounds like a good idea, but let me take a few days to think it over.

  5. Ian Hinder reporter
    • removed comment

    I think it's fine to keep the thorn in its current BitBucket repository. It is part of its own arrangement, which is the repository, anyway. The thorn is described in the documentation, which I linked to. I would like to update the description that I added to http://einsteintoolkit.org/about/gallery/incoming.php. It currently reads

    This simulation shows how to solve an elliptic equation. The source term and boundary conditions are specified via grid functions, in this case provided by the CT_Analytic thorn. Fixed mesh refinement concentrates points in the neighbourhood of the Gaussians, and a multigrid algorithm is used to solve the Poisson equation. The plots below show the converged solution, and the norm of the solution error as a function of time.

    First, is this correct? I just realised that I didn't explain that the Gaussians were source terms (are they?). It would be good to describe what is used as the boundary condition; I couldn't tell from briefly looking at the parameter file. Also, if it's easy to change a grid spacing parameter and have it run on a workstation or laptop, we could mention that as well, so that people can try it out without a cluster. I assume that with a lower resolution, it will converge much faster as well? We could also include a reference to the paper describing the solver.

  6. Ian Hinder reporter
    • removed comment

    The galley example text has been updated. The code will live in the CTThorns repository.

    The current holdup is a couple of test failures which seem to be triggered by switching from the original to the rewrite version of McLachlan. The tests output ML_BSSN::ham, and this differs between the two McLachlan versions. Since there is no evolution in CT_MultiLevel, we will probably remove McLachlan from the tests, and test just the ADMBase variables. Independently of adding the solver to the toolkit, we should also understand why the rewrite of McLachlan caused changes in the constraints. Erik said that the constraints should differ only by roundoff. It's possible that "roundoff" for the solver is quite large, due to the method used, so that the solver variables meet the usual Cactus default tolerances, but the constraints do not.

  7. Log in to comment