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@aei.mpg.de> wrote:

On 17 Aug 2015, at 20:23, Zach Etienne <zachetie@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?