Fix all thorns that attempt reductions in local mode

Create issue
Issue #813 closed
Roland Haas created an issue

Recently these produce a level three warning (simfactorie's default) whenever they attempt to do so and clutter the log files.


Comments (17)

  1. Frank Löffler
    • removed 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).

  2. Roland Haas 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.

  3. Erik Schnetter
    • 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.

  4. Roland Haas 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?

  5. Roland Haas 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.

  6. Roland Haas 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).

  7. Erik Schnetter
    • 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.

  8. Roland Haas 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.

  9. Erik Schnetter
    • 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.

  10. Roland Haas reporter
    • removed comment

    applied as rev 74 and 77 of RotatingSymmetry90 and RotatingSymmetry180 respectively. I changed the variable name to extent_valid_for_iteration.

  11. Log in to comment