[Users] questions about working elliptic solver thorns

Fri May 29 10:12:29 CDT 2015

On Fri, May 29, 2015 at 10:40 AM, Comer Duncan <comer.duncan at gmail.com>
wrote:

> 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.
>

Yes, it is. If you want to set up your own solver grid, then you can easily
use PETSc for this. If you want to use Carpet's AMR grids, then I would use
Eloisa's solver. Let's make sure she also have time when you call in.

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.
>

That always works. However, if you add a few levels, then you lose much,
both in accuracy (resolution), and due to the noise that interpolation adds.

-erik

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/
>>
>
>

-- 
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/cd6059c5/attachment-0001.html 