Hi. I'm compiling an *extremely* simple cactus executable designed to run the testsuite "vectors" in LSUThorns/Vectors. If I were to believe the parameter file vectors.par, I should need exactly the following seven thorns:
CartGrid3D CoordBase IOASCII IOUtil PUGH PUGHSlab Vectors
However, if I begin to compile a minimal Cactus configuration using only these (in current ET stable release Gauss --- ET_2013_05), I quickly hit the warnings below, implying that I *also* need SymBase and Boundary.
Now these are warnings, not errors; perhaps the code would compile fine and run OK anyway (I haven't tried). But surely trying to schedule a routine in a particular group or timebin means that the thorn responsible for such groups/timebins should be an actual dependency? Why are Boundary and SymBase not *required* in the interface.ccl of CartGrid3D?
Bernard
------------------------------------------------------ Warnings were generated during execution of the CST ------------------------------------------------------
CST warning: -> Scheduling routine RegisterSymmetryBoundaries from thorn CartGrid3D in non-existent group or timebin SymmetryRegister HINT: If this routine should be scheduled check the spelling of the group or timebin name. Note that scheduling IN must be used to schedule a routine to run in a thorn-defined schedule group, whereas scheduling AT is used for a usual timebin. (Schedule IN may also be used with the usual timebins, but in this case the full name of the bin must be used, e.g. CCTK_EVOL and not EVOL)
CST warning: -> Scheduling routine CartGrid3D_ApplyBC from thorn CartGrid3D in non-existent group or timebin BoundaryConditions HINT: If this routine should be scheduled check the spelling of the group or timebin name. Note that scheduling IN must be used to schedule a routine to run in a thorn-defined schedule group, whereas scheduling AT is used for a usual timebin. (Schedule IN may also be used with the usual timebins, but in this case the full name of the bin must be used, e.g. CCTK_EVOL and not EVOL)
Bernard
The test suite in LSUThorns/Vectors is self-contained, and you need only this thorn to run it. This will indicate (on stdout) whether there was an error or not.
However, to fit into the Cactus test suite mechanism, the test suite needs to output a file. This requires a few other thorns, including PUGH and IOASCII. The warnings that are reported are harmless, since the content of the file does not matter -- what only matters is that there is at least one file generated when the self-test succeeds.
In general, scheduling a routine into a non-existing schedule bin means that this routine is not executed. In many cases, this is just the right thing to do. In other cases, this is e.g. due to an error in schedule.ccl, which is why we moved from "silently not scheduling" to reporting warnings about these. In this case, the warnings are harmless and no need to worry, since the thorns Boundary and SymBase are not actually required by CartGrid3D. One wishes there was a way to indicate this in the schedule.ccl so that these warnings could be omitted.
-erik
On 2013-07-17, at 11:06 , "Kelly, Bernard J. (GSFC-660.0)[UNIVERSITY OF MARYLAND BALTIMORE COUNTY]" bernard.j.kelly@nasa.gov wrote:
Hi. I'm compiling an *extremely* simple cactus executable designed to run the testsuite "vectors" in LSUThorns/Vectors. If I were to believe the parameter file vectors.par, I should need exactly the following seven thorns:
CartGrid3D CoordBase IOASCII IOUtil PUGH PUGHSlab Vectors
However, if I begin to compile a minimal Cactus configuration using only these (in current ET stable release Gauss --- ET_2013_05), I quickly hit the warnings below, implying that I *also* need SymBase and Boundary.
Now these are warnings, not errors; perhaps the code would compile fine and run OK anyway (I haven't tried). But surely trying to schedule a routine in a particular group or timebin means that the thorn responsible for such groups/timebins should be an actual dependency? Why are Boundary and SymBase not *required* in the interface.ccl of CartGrid3D?
Bernard
Warnings were generated during execution of the CST
CST warning: -> Scheduling routine RegisterSymmetryBoundaries from thorn CartGrid3D in non-existent group or timebin SymmetryRegister HINT: If this routine should be scheduled check the spelling of the group or timebin name. Note that scheduling IN must be used to schedule a routine to run in a thorn-defined schedule group, whereas scheduling AT is used for a usual timebin. (Schedule IN may also be used with the usual timebins, but in this case the full name of the bin must be used, e.g. CCTK_EVOL and not EVOL)
CST warning: -> Scheduling routine CartGrid3D_ApplyBC from thorn CartGrid3D in non-existent group or timebin BoundaryConditions HINT: If this routine should be scheduled check the spelling of the group or timebin name. Note that scheduling IN must be used to schedule a routine to run in a thorn-defined schedule group, whereas scheduling AT is used for a usual timebin. (Schedule IN may also be used with the usual timebins, but in this case the full name of the bin must be used, e.g. CCTK_EVOL and not EVOL)
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Hello Bernard,
Now these are warnings, not errors; perhaps the code would compile fine and run OK anyway (I haven't tried). But surely trying to schedule a routine in a particular group or timebin means that the thorn responsible for such groups/timebins should be an actual dependency? Why are Boundary and SymBase not *required* in the interface.ccl of CartGrid3D?
To my knowledge these routines implement the old-style boundary routines for octant, quadrant, bitant symmetry (ie if cartgrid3d::domain is not "full"). The thorn would run fine without and in fact using those options is deprecated (in favor of ReflectionSymmetry which does require SymBase which does require Boundary). Having said that, I would not *want* to run without Boundary on grounds of not knowing which thorns silently assumes it is present, but it is not required for CartGrid3D (eg the wavetoysimple example does not use it).
Yours, Roland
users@lists.einsteintoolkit.org
-
Erik Schnetter -
Kelly, Bernard J. (GSFC-660.0)[UNIVERSITY OF MARYLAND BALTIMORE COUNTY] -
Roland Haas