3.1.3. New AMR tasks¶
A new AMR task (A) is ready to update immediately, since it was spawned from a
task that was ready to update at that specific time. To update, with guard
cells filled, it needs to have an nbor list. The nbor list must have
the required nbors, and the nbor links must have needed
and download
both set to true.
When that task (A) nbor list was created, and indeed when any new nbor list is
created, that very action should trigger an init_nbors()
in the nbors of
the A task (but not in nbors of nbors!). So, the caller of the init_nbors()
must also call set_init_nbors()
, which set bits%init_nbors
in all nbors
of the 1st task.
One of those nbors (B) may be virtual, and that tasks should also get new nbor lists, both on the rank (a) that triggers the chain of events, and on the rank (b) that are owns task (B).
The rank (b) that owns the virtual task (B) also has (or will get) a copy of
the task (A) that triggered the event chain, and since the principle is that
the virtual tasks behave exactly as their originals do, we need only to ensure
that the thread on rank (b) that unpacks the virtual copy of (A) also performs a
set_init_nbors()
call, which then triggers an init_nbors()
in the next
update of the boundary task (B) on rank (b), which then gets send in copy to
rank (a), as un update of its virtual task (B), where it gets a new nbor list,
provided that the bits%init_nbors
that caused the thread on rank (b) to
generate a new nbor list still is set when the copy of the task arrives in rank
(a).
Hence, when a thread updating a boundary task discovers a bits%init_nbors
,
it should not clear that bit until after the send_to_vnbors()
call.