CyclicAMI decomposition
Summary
for some cases where the mesh is highly refinned and the simulation uses cyclicAMI when decomposing the case (while using scotch decomposition), sometimes it breaks sometimes it does not. This has been discussed in cfd-online https://www.cfd-online.com/Forums/openfoam-solving/95697-problem-using-ami-15.html, and have been adressed in the lasts versions of OF to keep the cyclicAMI in same processor, neverthless the randomness of this behavior and that this is not mentionned in the manual of the cyclicAMI is problematic, especially considering that the error that we get (when it is not working) is not at all helpful, as for example, checkMesh gives an error that does not give any leads that the issue is coming from the decomposition of the mesh.
Steps to reproduce
sadly, I don't have a case where this happens, but I found myself in this case while creating complex meshes (see 15th page first post of the link of cfd-online) with highly refined mesh and that were decomposing the domain with scotch (in around 90 processors), while changing the different refinements I found myself in three different scenarios:
- the case would run correctly, and the checkMesh will output correct and nice weights for the source and target patches.
- the case would not run, and the checkMesh will run but will output some cells with 0 weight.
- the case would not run, and the checkMesh neither, when it arrives to check the weights of the cyclicAMI patches it will simply give an error without any relevant information.
this happened while doing a mesh convergence with a case where sometimes more or less refined will run correctly. Furthermore, in the examples where i found myself in cases 2. and 3., when I created a set of cells using topoSet with the cells of the cyclicAMIs (source and target) and then redistribute the same region using a decomposeDict with
constraints { processors { type singleProcessorFaceSets; sets ((AMI -1)); } }
then if it was the 2. case, the weights increased (almost to 0.8 the minimum weights when they were 0) and if it was the 3. case, the checkMesh will run correctly as in case 1. and then the case will run normally.
Example case
What is the current bug behaviour?
What is the expected correct behavior?
Relevant logs and/or images
Environment information
- OpenFOAM version :
- Operating system :
- Hardware info :
- Compiler :