Behavior of Slab_Transfer between components owned by the same process

Issue #694 closed
Eloisa Bentivegna created an issue

Slab's documentation states that the Slab_Transfer only works when each process handles a single rectangular component. This affects small runs with periodic boundary conditions (imposed through Slab_Transfer), where two or more components on a single process are common because refinements that try to go past the symmetry boundary are carried over to the opposite side. Currently (attached parameter file), Slab_Transfer silently fails and the boundaries are simply never touched after initial data (except for the usual timelevel cycling).

I'm not sure how easy it is to extend this functionality, but a check that Slab_Transfer is only used as intended should be inserted as soon as possible.

Keyword: Slab

Comments (10)

  1. Erik Schnetter
    • removed comment

    The best short-term solution I can think of is to initialise all boundary points with nan before calling Slab_Transfer. This would at least catch uninitialised points. There could even be a loop checking for these nans and aborting after calling Slab_Transfer.

  2. Erik Schnetter
    • removed comment

    Other symmetry thorns do have such a test. The code could probably just be copied over.

  3. Erik Schnetter
    • changed status to open
    • removed comment

    The attached patch to CactusNumerical/Periodic allows checking whether Slab applied its boundary conditions correctly.

  4. Eloisa Bentivegna reporter
    • removed comment

    I think that the portion of this patch that sets/checks for poison acts on all of a component's boundaries, including e.g. interprocessor boundaries, which Slab_Transfer is not supposed to fill in. I assume we need to introduce some logic like we have elsewhere, with a boolean "is_symmetry_boundary"-type variable to check whether a point has to be filled by Periodic?

  5. Ian Hinder
    • removed comment

    I assume from comment:4 that the patch does not work as intended, and throws an error when it finds poison on the interprocessor boundaries?

  6. Eloisa Bentivegna reporter
    • removed comment

    That's correct, the patched code will poison all boundaries, call Slab_Transfer which only acts on the symmetry boundaries, and finally check for poison, finding it on the interprocessor boundaries if any exist. Please disregard this ticket until we have figured out whether this is the right direction to pursue.

  7. Eloisa Bentivegna reporter
    • removed comment

    In order to use periodic boundary conditions with AMR, the new LSUThorns/PeriodicCarpet should be used instead. The defect in thorn Periodic remains, but a simple error message (pointing perhaps to PeriodicCarpet) should be enough to warn the user when this thorn is used with AMR.

  8. Log in to comment