- removed comment
Fix all thorns that attempt reductions in local mode
Recently these produce a level three warning (simfactorie's default) whenever they attempt to do so and clutter the log files.
Keyword:
Comments (16)
-
-
reporter - removed comment
I currently know of
- SphericalSurface::SphericalSurface_SetupRes
- none other so far
It turns out the thorn that gave me most warnings was a private thorn (author has been notified).
The SphericalSurface routine is actually fairly complicated since it first accesses grid functions then reduces then accesses some more based on information just collected.
-
- removed comment
Is this routine (SphericalSurface::SphericalSurface_SetupRes) used often? I believe it offers the capability to examine the grid structure and then choose a resolution for the spherical surface that corresponds to that of the 3D grid. While superficially convenient, this is (a) not adaptive, (b) could be done in the parameter file (since one knows the resolutions there), and (c) does not permit convergence tests.
If this feature is rarely used, then it does not need to be corrected.
-
reporter - changed status to open
- removed comment
the attached patch has CarpetReduce use CCTK_ScheduleQueryCurrentFunction to find out which thorn is calling reduction in local or singlemap mode.
Ok to apply to Carpet?
-
- changed status to open
- removed comment
Please apply.
-
reporter - removed comment
applied.
-
reporter - removed comment
I just found that RotatingSymmetry90 also contains a reduction call (in rotatingsymmetry90.c line 175). However since it uses TAT/Slab it "can only be used if there is a single local component per MPI process" anyway. Also moving the affected lines outside into a LEVEL mode routine defeats an optimization to quit early if there is nothing to do and the routine in question is not a scheduled routine to begin with. It does however make runs with RotatingSymmetry90 produce very large log files (if -L3 is used).
The same seems to apply to RotatingSymmetry180.
-
reporter - changed status to open
- removed comment
We should either fix the symmetry thorns or revert (my) extra warnings in the array reduction routines in carpetreduce (the GF reduction routines seem to cause fewer warnings).
-
reporter - changed status to open
- removed comment
-
- removed comment
We should increase the warning level for the release (L4?) since this is the safest option, and then discuss what to do in the development branch later.
-
reporter - changed status to open
- removed comment
done. I set the level to WARN_DEBUG (L4) in 12ee1105096a. I am leaving this ticket open for possible re-review of the patches to rotatingsymmetry* after the release.
-
- changed milestone to ET_2012_11
- removed comment
-
reporter - changed status to open
- removed comment
-
- changed status to open
- removed comment
Please apply.
Please change the variable name "time_of_extent_computation" to "valid_for_iteration" or similar, and/or add a comment to the variable's declaration.
-
reporter - removed comment
applied as rev 74 and 77 of RotatingSymmetry90 and RotatingSymmetry180 respectively. I changed the variable name to extent_valid_for_iteration.
-
reporter - changed status to resolved
- removed comment
- Log in to comment
It would help to list the thorns that do this here, and probably open a separate ticket for each of them (in case it's not too many).