Overlapped patch boxes with nesting_buffer 2

[PhilipDeegan]

Hi,

We have noticed what appears to be overlapped patch boxes on level 2 in a simulation we have configured. This only seems to appear when we have set "nesting_buffer" to 2, it does not appear with 1 or 0.

(very red box showing the overlapped region)

Is there some reason why you might consider a nesting_buffer of >= 2 to be invalid? If you would like to reproduce this for yourself we have a branch and dockerfiles ready.

base dockerfile: https://github.com/PHARCHIVE/phare-teamcity-agent src dependencies dockerfile: https://github.com/PHARCHIVE/phare-teamcity-agent_dep for both, to build Fedora 34 images run:

./build_image.sh 34

load docker container

docker run -it 129.104.6.165:32219/phare/teamcity-fedora_dep:34 bash

in docker container:

git clone https://github.com/PhilipDeegan/PHARE -b tag2d --depth 1 --recursive phare; cd phare
(mkdir build; cd build; cmake .. -G Ninja; ninja )
export PYTHONPATH=$PWD:$PWD/build:$PWD/pyphare
mpirun -n 12 python3 -u tools/bench/real/bench_harris.py

We sometimes get segfaults running this simulation, and other times we see the overlap before crashing. So you might have to run "mpirun -n 12 python3 -u tools/bench/real/bench_harris.py" more than once. but it should make something like the above image if it doesn't segfault, and the overlap is generated. If it doesn't segfault, it will probably look like it's hanging, but just leave it for a while, once you get an error showing

"Domains overlap {box0} {box1}"

It has run "successfully"

I'm here if you have any questions.

Thanks

[nselliott]

It is a known possibility that the nesting buffer enforcement can cause this kind of overlap. The reason is that nesting is enforced at the end of the box generation algorithm, and it removes only the minimal amount of zones needed to satisfy the nesting buffer size. Sometimes that removal causes a box to be left behind that is smaller than the minimum patch size restriction, and in that case the box is caused to grow, even if it causes an overlap with neighboring patches.

This appears to be what happened in the image you show here. A small piece was removed from the upper right of a box, leaving a narrow box behind, which was then made to grow to the left.

A couple ideas: This is very unlikely to occur when using TileClustering for your box generation rather than BergerRigoutsos. Also, there is an input parameter allow_patches_smaller_than_minimum_size_to_prevent_overlap in PatchHierarchy that can be used to prevent the growing of the narrow box, if the application can accept an occasional patch with a size below the requested minimum.