[Users] IllinoisGRMHD Code Compatibility Layer

[Zach Etienne]

Hi Ian,

> Just a quick comment: maybe it would be possible to isolate all such
"extra" functionality in a single source file, and make it clear that this
is only present for compatibility, and isn't relevant to the internal
workings of the thorn.  It is true that
> compatibility code can make things cluttered, but maybe having it
separate would be enough?

Thanks for your comment.

Using Carpet/CarpetLib thorns as a template, I was able to figure out how
to remove the symlinks. In my previous email, I define [Function A] and
[Function B]. Regarding splitting this functionality into a single source
file,

* [Function A] exists within a source file called, appropriately enough,
"convert_ADM_to_BSSN__enforce_detgtij_eq_1__and_compute_gtupij.C"
* [Function B] exists next to a function that applies a fix
("apply_tau_floor") to the conservative variables, and both exist within a
source file called:
"apply_tau_floor__enforce_limits_on_primitives_and_recompute_conservs.C"

Now that the symlinks issue has been resolved, I would be happy to hear any
suggestions or comments you have regarding the current IllinoisGRMHD &
related thorns.

-Zach

*     *     *
Zachariah Etienne
Assistant Professor of Mathematics
West Virginia University

On Tue, Aug 18, 2015 at 5:48 AM, Ian Hinder <ian.hinder at aei.mpg.de> wrote:

>
> On 17 Aug 2015, at 20:23, Zach Etienne <zachetie at gmail.com> wrote:
>
> Hi Erik,
>
> Great questions.
>
> - Is it necessary to have an explicit conversion thorn? Couldn't these
> routines be simply part of IllinoisGRMHD? For example, McLachlan uses its
> own variable, and contains its own routines to convert from/to ADMBase.
>
> IllinoisGRMHD is designed to maximize user-friendliness, and to this end
> one of my goals is to minimize the amount of source code inside
> IllinoisGRMHD that is not directly related to GRMHD evolution. Thus if
> possible, I would prefer not incorporating functionality from these thorns
> into IllinoisGRMHD.
>
>
> Just a quick comment: maybe it would be possible to isolate all such
> "extra" functionality in a single source file, and make it clear that this
> is only present for compatibility, and isn't relevant to the internal
> workings of the thorn.  It is true that compatibility code can make things
> cluttered, but maybe having it separate would be enough?
>
> --
> Ian Hinder
> http://members.aei.mpg.de/ianhin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20150824/2a9f4ec2/attachment-0001.html