WeylScal4 should use the kranc script rather than calling Mathematica directly

[Ian Hinder]

The attached patch makes WeylScal4 use the "kranc" script rather than calling Mathematica directly. This enables all the error-detection provided by Kranc and leads to tidier output.

This patch can either be committed now or after the release. The files it touches are not used during use of WeylScal4, only during generation.

Keyword: WeylScal4 Keyword: testsuite

[Roland Haas]

a good deal of the previous complication was due to the dsire to support Kranc installations (and locations of the WeylScal4.m file) in different locations. This patch removes this option. I would like to keep the old options. The 'kranc' script itself is not more sophisticated than runmath (though I like the PIPEERROR error checking if it actually detects more errors. Does Kranc really output "Thorn generated successfully" if this is not the case? That would look like a bug to me.).

[Ian Hinder]

I can add the additional search locations for Kranc back to runmath.sh. The script will still be significantly simpler as all it needs to do is find Kranc. Everything else should be handled in the kranc script to avoid duplication.

The kranc script is more sophisticated than runmath.sh, since it runs Kranc using the !RunKranc package. This package checks for any exceptions or messages generated and catches these, printing them in a sensible way. It then makes !MathKernel return a nonzero exit code (usually it returns 0 even if a critical error has occurred). It also sets things like the !PageWidth so that there are no continuation lines in the output, and runs mathematica in a way which does not print spurious things like In[] etc.

In some cases, Kranc might output "Thorn XX generated successfully" if messages occurred during the computation. There is, unfortunately, no way that I have found to abort on the first message (see comments in !RunKranc.m). If messages are generated, I cannot guarantee that the thorn is correct.

Kranc's input validation is not perfect - the original aim was to be very liberal in what we accept to avoid having to write code to allow every different function that the user might want to use. This might not have been a good idea. Now that we have a good idea of what is needed, we can reverse that and accept nothing unless it is valid and expected, but this has not been done yet.

[Roland Haas]

I am not convinced if the logic that is in runmath and that tries to find the Kranc installation should be in Bin/kranc, it seems to be too ET specific and fragile. If we use Bin/kranc (which provides RunKranc which I had not noticed, sorry), the I would suggest to have runmath look for Bin/kranc and to (if it is not present) extent Bin/kranc to accept an environment variable or something similar to tell it where to look for the Mathematica packages (in case someone eg. copies or links kranc into $HOME/bin or so).

This was the original reason for the complicated logic, to give users the ability to use their own Kranc installation and setup (eg. the ones that do not get WeylScal4 out of the ET).

Though if it is decided that we prefer a simple and clean setup that will work from within ET (and expect users who want to use something else to be experienced enough to run their own method), then I would think that Ian's initial commit is best and should be accepted.

[Tanja Bode]

Given that the purpose of these scripts is to (re-)generate thorns ''within'' the ET setup, the initial patch by Ian using the Kranc script makes sense. It would, however, still be nice to have ''some'' simple method to override the default, hard-coded Kranc location in case you want to try a different version without having to copy a git branch to yet ''another'' Cactus tree (when these code forests can now be in the 10s of GB in size). In this case, though, it would be prudent to make sure the location of the kranc script used is presented in the output. Come to think of it, logging the current branch of the Kranc repository would also be useful. Is either of this done? This wouldn't safe-guard against using an unintentional branch of a Kranc instance, but at least serve as a record so you can verify which version was used.

[Ian Hinder]

Roland: I was actually proposing that the logic for finding Kranc that was originally in runmath be restored to runmath (which is part of WeylScal4), not to the kranc script. The kranc script is inside Kranc, and hence cannot be used to find Kranc! As you say, it is ET-specific. Once the kranc script has been found, the only thing that can go wrong is that $0 of the kranc script does not point to the original Kranc directory, but to a symlink. We can canonicalise the path within the kranc script to fix this case, though it seems complicated to do this in a portable way.

Tanja: I like that idea. We can print the path to Kranc from the kranc script, as well as the git branch and hash, if it is a git repository.

Assuming that the symlink issue is solved, all the logic related to finding kranc needs to go into runmath.sh. This will be duplicated (and customised) for every thorn which needs to find Kranc. Can we make it general enough that the runmath.sh script can be the same for each thorn, e.g. for WeylScal4 and for McLachlan?

[Erik Schnetter]

I committed this change. runmath.sh uses KRANCPATH if it is set, and otherwise assumes the Einstein Toolkit directory layout.

I will open another ticket for the two feature requests asking Kranc to output its directory and branch.