3.1.18. Level support¶
The AMR actions on a task – refine and derefine – should only be
done by the thread that is about to update the task, since any other
alternative would lead to serious synchronization problems. The
new level L-1
tasks that may be needed to support a new level L
task
can thus not be created until the next time the level L-2
task that needs
to be refined is updated.
The refine_t
data type has two methods related to checking for AMR
support (i.e., checking that all patches at level L
have level L-1
nbors
to get guard zone values from):
check_support()
checks if a new (child) patch actually has support. If not, it issues a WARNING in the rank log file. The task then takes guard zones values fromL-2
nbors, until the relevantL-1
nbors have been created.need_to_support()
checks if a givenL-2
level patch needs to be refined, to provide support for existing level L patches. If so, it creates such child patches(), along with any other refinement that may be detected a need for inrefine_t%needed
.
Both methods use 2-byte integer maps to detect lack of support – this method will work unmodified for moving patches.
A status bit (bits%support
) is available, and is used to communicate to
nbor patches about the need for support.
A new child patch is automatically sent vbor ranks when it is created, and
virtual patches are created there, as when any task arrives, with and id
that doesn’t exist yet on the rank. The bits%support
informs the rank
that this is a new AMR child patch.
Any new task arriving to a rank generates a call to list_t%init_nbor_nbors()
,
which uses position information to first create an nbor list for the
task itself, and then generates new nbor lists also for the nbors of the
task, since both sides of the nbor-nbor relation need to have consistent
nbor lists.