[puchibran]

Hello everyone,


I am encountering an issue with `snappyHexMesh` when running in parallel using `runParallel`.

- When running `snappyHexMesh` in single-core mode, everything works perfectly, and the mesh passes all checks (`checkMesh` results are fine).
- However, when I use `runParallel`, mesh inconsistencies occur. It seems like that the `sanp` and `addLayers` doesn't perform.

### Additional Information:
1. **Environment Details:**
- OpenFOAM version: v2306.
- Number of processors used: 16.

2. **Error Observed:**
- After running in parallel, the mesh shows inconsistencies like:
- These issues do not occur in single-core runs.

3. **Configuration:**
- snappyHexMesh: https://webapp-doc-images.s3.ap-nort...ppyHexMeshDict
- decomposeParDict: https://webapp-doc-images.s3.ap-nort...composeParDict
- Allrun: https://webapp-doc-images.s3.ap-nort...aws.com/Allrun
- log.snappyHexMesh: https://webapp-doc-images.s3.ap-nort....snappyHexMesh

### Question:
- What could be causing these mesh inconsistencies when using parallel processing?
- Are there specific steps or best practices to ensure consistent meshing with `snappyHexMesh` in parallel mode?

Any insights or troubleshooting advice would be greatly appreciated!

[CFD_with_Skill-Lync]

What decomposition method are you using?
Generally, the type of decomposition could affect the feature capturing capabilities. Try to keep the decomposition to simple or hierarchical to achieve best results.

[KY412]

It seems your issue is related to the following error message found in log.snappyHexMesh.

[1] --> FOAM FATAL ERROR: (openfoam-2306)
[1] face 135 area does not match neighbour by 0.0317069% -- possible face ordering problem.
patch:procBoundary1to2 my area:0.00312538 neighbour area:0.00312438 matching tolerance:4.0629e-07

The problem appears to stem from a mismatch in the surface areas of the decomposed meshes, which might be tied to the fact that this is a 2D case.

Has anyone encountered and resolved a similar issue?