include con2prim framework by Siegel, Moesta et al. into ET

[Roland Haas]

GRMHD_con2prim

GRMHD_con2prim is a general-purpose framework that comes with various methods for the recovery of primitive variables from conservative variables in general-relativistic magnetohydrodynamics (GRMHD) with dynamical spacetimes.

GRMHD_con2prim is available at the Zenodo repository with DOI 10.5281/zenodo.1213306. A separate updated development version is available at https://bitbucket.org/dsiegel/grmhd_con2prim.

The associated detailed methods paper is:

Siegel, D., Moesta, P., Desai, D., Wu, S. (2018), "Recovery schemes for primitive variables in general-relativistic magnetohydrodynamics", ApJS accepted, https://arxiv.org/abs/1712.07538.

The DOI of the Zenodo repository (and the url of the development repository if appropriate) as well as the paper mentioned above should be cited in any academic work that uses GRMHD_con2prim or is based on GRMHD_con2prim, i.e., the code published in this repository.

While this code is free to use (see license below), we ask everyone who uses it to report bugs and to share further development based on this code, for the benefit of everyone else.

Citable DOI and citation request on Zenodo: https://zenodo.org/record/1213306

[Roland Haas]

@pmoesta @dsiegel : we are finally going ahead with trying to update the ET’s con2prim methods. GRHydro C++ for sure, possible also in a way that can be used in IllinoisGRMHD as well.

‌

[Wolfgang Kastaun]

Note there is also a newer development that might be of interest:

https://arxiv.org/abs/2005.01821

The library is publicly available here

https://zenodo.org/record/3785075

https://github.com/wokast/RePrimAnd

Besides con2prim, it contains a whole EOS framework. Moreover, I am already working on the EinsteinToolkit integration.

‌

‌

[Gabriele Bozzola]

Our group (University of Arizona) has already ported the con2prim to Einstein Toolkit and has a preliminary version of integration with IllinoisGRMHD. In its current stage, the code is not ready for release, but a lot of work has already been done and more work is ongoing.

[Roland Haas]

There was some old discussion (and two proof of concept implementations) for an external, switchable con2prim thorn (at that point for GRHydro only) http://lists.einsteintoolkit.org/pipermail/users/2017-February/005326.html and demo implementations in the branch: https://bitbucket.org/einsteintoolkit/einsteinevolve/branch/rhaas/con2primng in the Zelmani_Con2PrimNG thorn (method 1) and the ExternalGRHydroCon2Prim thorn (method 2).

Though neither one is going to be quite “right” since they are both tied to GRHydro and a layer that can hook to either IllinoisGRMHD or GRHydro on one side and either the 2018 Siegel et al. or the 2020 Kastaun et al. method my be preferable.

[Roland Haas]

Maria tentatively offered to look into con2prim in ET call on 2020-06-11.

Might need further discussion in ET calls based interest in this ticket.

[Roland Haas]

Relevant bits from today’s ET call minutes (http://lists.einsteintoolkit.org/pipermail/users/2020-June/007479.html):

Other groups are ading these methods, like Gabriele Bozzola to IllinoisGRMHD, and Wolfgang Kastaun is also working on these methods.  Wolfgang's method has
a proof of solution to roots...if it has a solution.  ZE, often with AMR the conservatives can be ill-valued.  His code has a lot of dependencies, Boost, Ninja, etc.

ZE, the ideal interface for any GRMHD code is not a con2prim solver that does everything at all points, but one where you call it and it does it at one point. 
Convenient if you can do it in one OpenMP loop, so the point-by-point is better.  Suppose it fails to find a root, if it fails fall-back to another method.  Make the interface a point-wise method.  RH agrees.  But point-wise is maybe the
other extreme, you may want that it takes a 1D array of data and then flags individual SIMD-parallelization a Newton-Raphson method.  ZE, in some cases it is
faster to us a quartic solver in some cases.

RH, if this is a summer project for other groups with an end time, suggest waiting until the end of summer to see what their results are.

‌

[Roland Haas]

@Vasileios Paschalidis says (in email http://lists.einsteintoolkit.org/pipermail/users/2020-June/007480.html):

Just saying that my students Pedro Espino and Gabriele worked on this. We already have a working code that is interfaced with ILGRMHD, but the interface is generic enough and should be straightforward to include it in other codes as well. It is a summer project for us. There are some final outstanding issues that we need to iron out, and as soon as we are happy with it, our goal is to work with you and share the code with the ET.

‌

[Roland Haas]

Wait until @Gabriele Bozzola reports back.

[Roland Haas]

@Gabriele Bozzola would you be able to give an update on any of this in one of the next few ET calls (Thu 9AM Central Time).

‌

[Gabriele Bozzola]

My part of the project consisted of porting GRMHD_con2prim to the Einstein Toolkit. Given the tremendous work done by Dan Siegel et al, this was rather straightforward to do. The code is implemented in a thorn ConservativeToPrimitive that provide a Cactus function con2prim. The code is tested with a separate thorn that implements the same test implemented in GRMHD_con2prim. I don’t think that there’s much more to say about this.

Pedro Espino is actively working on the more challenging problem of integrating this into IllinoisGRMHD. I will relay the request to him.

‌

‌

[Pedro Espino]

We have interfaced the implementation of con2prim with IllinoisGRMHD and EOS_Omni, including the evolution of the electron fraction. We’ve achieved a stable evolution of a TOV star and a BNS built using LORENE. We are currently diagnosing the convergence of the hydro solution using several initial data thorns, including RNS (already within the toolkit) and our own thorn which imports initial data generated using the Cook et al. code. Generation of reliable TOV initial data has been a problem, as we find inconsistencies between the ID generated by different thorns. A lot of time has gone into debugging RNS, and we now recognize that EOS tables with many entries are required. I plan on reporting the convergence rate of our hydro solution once these ID errors have been sorted out.