[Users] Release Announcement: IllinoisGRMHD Thorn

[Zach Etienne]

Dear ET folks,

After months of work, I am pleased to release my rewrite of the Illinois
numerical relativity group's staggered A-field GRMHD thorn to the ET
community. The new thorn is called IllinoisGRMHD, and yields results
identical (within roundoff error) to the original GRMHD code of the
Illinois group with AMR & unigrids, with bitant symmetry & without, and
with single or multiple MPI processes. We used precisely these GRMHD
algorithms to produce our latest GRMHD-based papers.

IllinoisGRMHD is written entirely in C, except for some C++ file I/O for
debugging purposes, and all loops are OpenMP-compatible. The coding
standard is C99.

I would like to thank Frank and the CCT folks, who have graciously agreed
to host IllinoisGRMHD on the ET SVN server, as the thorn awaits
maintainers' approval for incorporation into the official ET.

Download IllinoisGRMHD via the following command:
svn co
https://svn.einsteintoolkit.org/cactus/EinsteinEvolve/IllinoisGRMHD/trunk/

Browse IllinoisGRMHD source code in your web browser via:
https://svn.einsteintoolkit.org/cactus/EinsteinEvolve/IllinoisGRMHD/trunk/

** Background **
Roughly a decade of work has gone into the original code, and nearly all of
the credit for debugging that battle-hardened code goes to Stu Shapiro and
other former & current members of his group, to whom I give my great thanks
and send the following message: Despite weeks entirely devoted to debugging
this rewritten code, I found no major bugs in the original code.

** License **
The IllinoisGRMHD thorn is hereby released under the GNU GPL v2 or higher,
to maximize compatibility with the ET thorns.

** Changes from Original Code **
The IllinoisGRMHD thorn contains significantly fewer lines than the code on
which it is based, for two reasons:

1) Functionality that is no longer used (mostly dead code at this point)
has been removed, and

2) New data structures in the code make it more compact, reducing the total
number of lines in the reconstruction & MHD RHS evaluation routines to
~1200. I hope that the data structures in the new code will make it easier
to read, less intimidating for beginners, and much easier to modify &
extend, to do new science.

I started development of IllinoisGRMHD as a standalone code, to minimize
the turnaround time in the first round of debugging and to try new ideas
for enhancing the performance, as well as making the code more compact and
easier to read. The standalone driver routines still exist, but bugfixes
found in the "thorn version" have not yet been backported to these
routines. I am happy to report that the new code is significantly faster
than the original code.

** Conservative-to-Primitives Routines **
We previously released our Conservative-to-Primitives routines to the ET
mailing list, based on the very nice 2D HARM primitive solver of Scott
Noble et al. An updated version is included in this release.

** Future Work **
Now that the IllinoisGRMHD thorn has been released, there is still some
work to do, summarized below.

1) If using AMR grids, this thorn requires support for staggered
prolongation & restriction algorithms within Carpet. We open-sourced these
algorithms for an old version of Carpet back in March of 2012. Since then,
Carpet has moved forward and these original algorithms (which we still use
in our old version of Carpet) are no longer compatible with the latest ET.
Philipp Moesta informed me
over the summer that he has ported these operators to a more recent Carpet,
and I will be working with him in the coming weeks to incorporate these
into the latest Carpet.

2) This thorn currently exists as a drop-in replacement for the original
GRMHD thorn of the Illinois group. I will be working in the coming weeks to
make it more like a drop-in replacement for GRHydro instead, though perhaps
someday it could be incorporated into GRHydro.

3) There are several minor to-do tasks remaining in the code, marked within
comments labeled "FIXME" (grep for it).

4) There exist several possible avenues for code optimization, such as some
possibly extraneous SYNC's within the schedule.ccl file.

5) More and better comments that clarify what the code is doing will be
incorporated.

6) I am unsure how strongly this code violates coding standards &
practices. E.g., I sometimes break lines according to the width of my
laptop screen. Also, I love variable & function names that explain
*exactly* what they do, which for some (possibly good) reason is frowned
upon by other C/C++ programmers. I personally find that long names make it
easier to read & understand a code years later.

7) I apologize for the lack of full written documentation at this point,
but promise that it will be forthcoming. In the meantime, I encourage you
to look at the large number of comments in the code, and if you find a
point of confusion, please email me, and I'll fix it!

-Zach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20131002/0ca1cc10/attachment.html