Reply To: Number of Cuboids for Geometry related to Parallel Compilation?
At a minimum you need one cuboid per process – otherwise processes without a cuboid can perform no work as no part of the simulation space belongs to them. If you initialize the number of cuboids with some multiple of singleton::mpi().getSize() this is automatically the case. This is also how it is implemented for our examples, you do not need to change anything here to run it with SLURM / on a HPC cluster.
Yes, “problem dependent” meant to include “geometry dependent”. You do not necessarily need to increase the cuboid count for complex geometries (what complex even means is not well defined of course :-))
In general I would advise to use one cuboid per process. You can then check if there are lots of unused areas and refine the number of cuboids further. However all of this needs to happen while benchmarking as a lower overhead of empty cells will not necessarily translate into better performance. e.g. more cuboids will require more communication.