Modify

Opened 7 years ago

Last modified 6 years ago

#720 new enhancement

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

Reported by: Roland Haas Owned by:
Priority: minor Milestone:
Component: Cactus Version:
Keywords: Cc:

Description

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.

Attachments (0)

Change History (3)

comment:1 Changed 7 years ago by Erik Schnetter

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.

comment:2 Changed 7 years ago by Roland Haas

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?

comment:3 Changed 6 years ago by Roland Haas

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.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.
Next status will be 'review'.
as The resolution will be set.
to The owner will be changed from (none) to the specified user.
Next status will be 'confirmed'.
The owner will be changed from (none) to anonymous.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.