-
Notifications
You must be signed in to change notification settings - Fork 119
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Negative element count for max.-refinement level 12 on a fractal Menger sponge setup #324
Comments
With debug flags the output reads
|
Thanks for the report. We use 32 bit integers for local (per-process) counts and 64 bits for global (sum over processes) counts. We do not check whether we overrun the 32 bits locally, which is what the example provokes. If you want to play this safe, you may refine non-recursively and partition in between the calls to refine to have a more even load balance. |
Our counts are signed, on purpose, so you have INT32_MAX available, separately on every process. If you really want to go over this bound locally, redefine p4est_locidx to 64 bits in p4est_base.h, along with the other constants there. |
I see. Thank you very much for the explanation! |
Description
I created a timing setup to measure ghost layer creation timings for a fractally refined Menger sponge (3D resp. hex) as a stress test.
When setting max. refinement level to 12 the output gives negative global element count (serial and parallel with a small number of MPI tasks). Till max. ref. level 11 all runs just fine.
Update:
With 32 MPI tasks on the same machine (36 cores, 128 GB RAM) the example runs without problems.
To Reproduce
A minimal working example looks as follows which is a modified version of the
example/timings/bricks{2,3}.c
program.Call it with option
-l 12
for hex mesh and the output reads:Additional information
Operating system, build configuration, etc.
Configure:
../p4est/configure --prefix="$(pwd)/local" --enable-mpi
Compiler: gcc 12.1.0
OS: Linux 6.8.0-47-generic
I tested this also on a cluster with different environment and compiler. Same result.
I get the same wrong result with an analog setup in t8code. See this PR: DLR-AMR/t8code#1287
The text was updated successfully, but these errors were encountered: