check at runtime that all REQUIREd and OPTIONAL thorns and capabilities are active

Create issue
Issue #720 resolved
Roland Haas created an issue

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-199000D2.5) and some #ifdefs, maybe.

Keyword:

Comments (4)

  1. Erik Schnetter
    • removed comment

    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.

  2. Roland Haas reporter
    • removed comment

    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?

  3. Roland Haas reporter
    • removed comment

    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.

  4. Roland Haas reporter
    • edited description
    • changed status to resolved

    REQUIRE'd thorns are being activated since git hash 4aa241b6 "Automatically activate required thorns" of cactus Fri Jan 18 02:02:31 2013 +0000.

    OPTIONAL capabilities must not be auto-activated since there are thorns around that OPTIONALly depend on other thorns but then check if those thorns are active at runtime before they use the capability.

    Admittedly this could also have been done by REQUIREing thorns, eg a thorn that REQUIREs Carpet to compile but only uses it if Carpet is active. The upside (from the thorn writer point of view, certainly not the user's) compared to using OPTIONAL is that the REQUIREing thorn does not have to use #ifdev HAVE_CAPABILITY_XXX.

  5. Log in to comment