<div dir="ltr">On Fri, May 29, 2015 at 10:40 AM, Comer Duncan <span dir="ltr"><<a href="mailto:comer.duncan@gmail.com" target="_blank">comer.duncan@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Erik,<div><br></div><div>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? </div><div><br></div><div>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. </div></div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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.</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>-erik</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="HOEnZb"><font color="#888888"><div><span style="color:rgb(80,0,80)">On Thu, May 28, 2015 at 11:30 PM, Erik Schnetter </span><span dir="ltr" style="color:rgb(80,0,80)"><<a href="mailto:schnetter@cct.lsu.edu" target="_blank">schnetter@cct.lsu.edu</a>></span><span style="color:rgb(80,0,80)"> wrote:</span><br></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>On Wed, May 27, 2015 at 2:50 PM, Comer Duncan <span dir="ltr"><<a href="mailto:comer.duncan@gmail.com" target="_blank">comer.duncan@gmail.com</a>></span> wrote:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Erik,<div><br></div><div>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. </div><div><br></div><div>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 <a href="http://einsteintoolkit.th" target="_blank">einsteintoolkit.th</a> file it is mentioned in:</div><div><br></div><div><div># CactusElliptic thorns</div><div>!TARGET = $ARR</div><div>!TYPE = git</div><div>!URL = <a href="https://bitbucket.org/cactuscode/cactuselliptic.git" target="_blank">https://bitbucket.org/cactuscode/cactuselliptic.git</a></div><div>!REPO_PATH= $2</div><div>!CHECKOUT = CactusElliptic/EllPETSc CactusElliptic/TATPETSc</div><div>CactusElliptic/EllBase</div><div>#DISABLED CactusElliptic/EllPETSc</div><div>CactusElliptic/EllSOR</div><div>CactusElliptic/TATelliptic</div><div>#DISABLED CactusElliptic/TATPETSc</div></div><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>Thanks for your advice and any pointers you can give.</div></div></blockquote><div><br></div><div>Comer</div><div><br></div></div></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>There is also a thorn TATPETSc that can solve non-linear elliptic equations (also unigrid only).</div><div><br></div><div>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.</div><div><br></div><div>The most modern solution is probably the multigrid solver that Eloisa wrote and that Ian described.</div><div><br></div><div><br></div><div>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?</div><span><font color="#888888"><div><br></div><div>-erik</div></font></span></div><span><font color="#888888"><div><br></div>-- <br><div>Erik Schnetter <<a href="mailto:schnetter@cct.lsu.edu" target="_blank">schnetter@cct.lsu.edu</a>><br><a href="http://www.perimeterinstitute.ca/personal/eschnetter/" target="_blank">http://www.perimeterinstitute.ca/personal/eschnetter/</a></div>
</font></span></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Erik Schnetter <<a href="mailto:schnetter@cct.lsu.edu" target="_blank">schnetter@cct.lsu.edu</a>><br><a href="http://www.perimeterinstitute.ca/personal/eschnetter/" target="_blank">http://www.perimeterinstitute.ca/personal/eschnetter/</a></div>
</div></div>