[Users] questions about working elliptic solver thorns

Comer Duncan comer.duncan at gmail.com
Fri May 29 09:40:45 CDT 2015


Hi Erik,

Thanks for your informative take on the status of elliptic solvers.  I am
out on travel at the moment and will be traveling home next Monday.  So
maybe the next next Monday?

>From what you describe it seems clear that having an elliptic solver which
knows about mesh refinement is sort of hard. Is the multigrid solver of
Eloisa  Carpet aware?  If so, I would probably elect to use it so long as
it is designed to work for asymtotically flat initial data.

If not,  I wonder whether it would be reasonable to take the output of a
solver done on unigrid and read it and remap it onto an AMR grid?  Then run
it as usual in ET.  Either make the solver itself internally a Carpet aware
thing or try to do it after the solver is done.  Not an ideal way perhaps
but perhaps a workaround.

Comer





On Thu, May 28, 2015 at 11:30 PM, Erik Schnetter <schnetter at cct.lsu.edu>
wrote:

> On Wed, May 27, 2015 at 2:50 PM, Comer Duncan <comer.duncan at gmail.com>
> wrote:
>
>> Hi Erik,
>>
>> Frank suggested you might be an appropriate person to ask about elliptic
>> solver thorns that work in the current release of ET. I have, as you know,
>> built Hilbert and have built the development version.
>>
>> I am wanting to write a thorn which prepares a geon, approximated by
>> initial data which has toroidal symmetry and is bounded. The desired
>> distribution would be placed on the r axis in cylindrical coordinates and
>> have a gaussian distribution. In the actual application, of course the
>> initial data would be interpolated onto a Cartesian coordinate mesh or
>> meshes.  I just want to solve the Hamiltonian constraint and have the
>> initial data be time-symmetric. This sounds like a pretty simple thing to
>> do. I think I could start with Brill and put q to my purposes and pretty
>> much get out what I want.  However, the IDBrill does not seem to work.
>> Also, I am wondering what kinds of elliptic solvers you know of that are
>> fully supported in ET?  Frank mentioned a petsc thorn. It does not get
>> downloaded and built by default and looking at the einsteintoolkit.th
>> file it is mentioned in:
>>
>> # CactusElliptic thorns
>> !TARGET   = $ARR
>> !TYPE     = git
>> !URL      = https://bitbucket.org/cactuscode/cactuselliptic.git
>> !REPO_PATH= $2
>> !CHECKOUT = CactusElliptic/EllPETSc CactusElliptic/TATPETSc
>> CactusElliptic/EllBase
>> #DISABLED CactusElliptic/EllPETSc
>> CactusElliptic/EllSOR
>> CactusElliptic/TATelliptic
>> #DISABLED CactusElliptic/TATPETSc
>>
>> However, what's with the DISABLED reference to EllPETSc is a bit
>> concerning. So before I go though the exercise to look more into the
>> EllPETSc, I thought  I'd ask whether the EllPETSc thorn is fully compatible
>> with Hilbert?
>>
>> Can you thus please bring me up to the current moment on just what
>> elliptic solvers are in use for initial data construction in Hilbert?  I
>> know many people have been focussing on the multiple BH problem, so there's
>> not much traffic anymore about Brill.  I do want to run Brill though and
>> also do the "geon" problem.
>>
>> Thanks for your advice and any pointers you can give.
>>
>
> Comer
>
> The #DISABLED just means that it has been disabled, not that the thorn is
> bad. We only disable it because PETSc is a large package and may be
> difficult to install, and only very few people use PETSc with Cactus. I am
> regularly building with PETSc, and have also run the ET tests with PETSc
> enable on some of our machines.
>
> I don't recommend using SOR. If you use mesh refinement, or if you use a
> machine more powerful than a laptop, then you can afford domains that are
> so large that SOR converges too slowly to be useful.
>
> BAM_Elliptic is not freely available. It also has not been used in more
> than a decade, and I doubt it would be useful to resurrect it.
>
> PETSc is a modern, full-featured elliptic solver. Unfortunately, there is
> no integration with Cactus's grid functions if you want to use mesh
> refinement. If you can live with a unigrid simulation, then EllPETSc allows
> you to solve linear elliptic equations. The thorns EllBase or EllPETSc
> should have some documentation on this; if not, maybe we can discuss next
> Monday during the ET telecon.
>
> There is also a thorn TATPETSc that can solve non-linear elliptic
> equations (also unigrid only).
>
> I haven't used these thorns in production in quite some time. Our initial
> conditions typically come from third-party solvers, e.g. Lorene or
> TwoPunctures.
>
> The most modern solution is probably the multigrid solver that Eloisa
> wrote and that Ian described.
>
>
> The situation of elliptic solvers in Cactus is not as good as I would like
> it to be. To help you out, it is probably best to talk in person, so that
> we see what you need. Do you have time next Monday to call in to our ET
> telecon?
>
> -erik
>
> --
> Erik Schnetter <schnetter at cct.lsu.edu>
> http://www.perimeterinstitute.ca/personal/eschnetter/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20150529/7058f0ac/attachment.html 


More information about the Users mailing list