Opened 7 years ago

Last modified 6 years ago

#694 reopened defect

Behavior of Slab_Transfer between components owned by the same process

Reported by: Eloisa Bentivegna Owned by:
Priority: major Milestone:
Component: Cactus Version: development version
Keywords: Slab Cc: hfinkel@…


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.

Attachments (2)

ks-mclachlan.par (7.4 KB) - added by Eloisa Bentivegna 7 years ago.
Small run with periodic boundary conditions.
periodic.patch (6.0 KB) - added by Erik Schnetter 7 years ago.

Download all attachments as: .zip

Change History (10)

Changed 7 years ago by Eloisa Bentivegna

Attachment: ks-mclachlan.par added

Small run with periodic boundary conditions.

comment:1 Changed 7 years ago by Erik Schnetter

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.

comment:2 Changed 7 years ago by Erik Schnetter

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

comment:3 Changed 7 years ago by Erik Schnetter

Status: newreview

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

Changed 7 years ago by Erik Schnetter

Attachment: periodic.patch added

comment:4 Changed 7 years ago by Eloisa Bentivegna

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?

comment:5 Changed 7 years ago by Ian Hinder

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?

comment:6 Changed 7 years ago by Eloisa Bentivegna

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.

comment:7 Changed 7 years ago by Ian Hinder

Status: reviewreopened

comment:8 Changed 6 years ago by Eloisa Bentivegna

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.

Modify Ticket

Change Properties
Set your email in Preferences
as reopened 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.
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.