[Einstein Toolkit] #720: check at runtime that all REQUIREd and OPTIONAL thorns and capabilities are active
#720: check at runtime that all REQUIREd and OPTIONAL thorns and capabilities are active -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- This is an offshot of a discussion on the Cactus developers mailing list: http://cactuscode.org/pipermail/developers/2011-November/006258.html
On 6 Jan 2012 12:54:13 -0500 eschnett said:
What is currently missing is the mechanism that checks that all thorns providing required capabilities are activated. If they are not, code in inactive thorns is called -- this is fine as long as no Cactus infrastructure is used (parameters, scheduled routines, grid functions, etc.).
Yes, we should implement the respective checks; yes, we should automatically activate thorns required for capabilities (and maybe some others as well?); yes, we should then output this thorn list to the screen (done anyway) and into a file.
By the way, Cactus already determines which thorns need to be activated automatically as a service to the user in the error message that complains about missing thorns.
The idea seems to be to document all thorns whose code is executed in the parameter file.
Ian's original need might be served by an "OPTIONAL" statement in configuration.ccl (http://einsteintoolkit.org/documentation/UsersGuide/UsersGuidech12.html#x17-...) and some #ifdefs, maybe.
#720: check at runtime that all REQUIREd and OPTIONAL thorns and capabilities are active --------------------------+------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Resolution: | Keywords: --------------------------+-------------------------------------------------
Comment (by eschnett):
Ian's original expectation seems to be to be able to run the same code in the same executable both with and without LoopControl. This does not work -- whether to use LoopControl is a build-time decision. OPTIONAL allows writing code that works both with and without LoopControl, but one still has to choose at build time.
Ian's original need might be served by either not including LoopControl in his thorn list, or by activating LoopControl even when PUGH is used.
#720: check at runtime that all REQUIREd and OPTIONAL thorns and capabilities are active --------------------------+------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Resolution: | Keywords: --------------------------+-------------------------------------------------
Comment (by rhaas):
Oh, I had not realized that. You are certainly correct though (reading Ian's first email helps). Slab already uses "OPTIONAL LoopControl" so conpiles fine without LoopControl in the thornlist. So I guess the feature request might be amended to:
automatically activate REQUIRE'd and OPTIONAL thorns and capabilities?
Or was the intention only to move the tests (effectively) out of LoopControl and into the flesh?
#720: check at runtime that all REQUIREd and OPTIONAL thorns and capabilities are active --------------------------+------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Resolution: | Keywords: --------------------------+-------------------------------------------------
Comment (by rhaas):
To comment on my own comment. There are a thorns (eg NoExcision in its getlevelinfo.cc file for example) that have OPTIONAL Carpet in configuration.ccl but then at runtime check if Carpet is active and only then do something if Carpet is active. This particular case could (and likely should) be handled using the GetRefinementLevel aliased function, but similar logic to use some Carpet code when Carpet is active are conceivable. This of course might be an abuse of the capabilities system since it assumes that Carpet is the only thorn providing the Carpet capability.
trac@lists.einsteintoolkit.org
-
Einstein Toolkit