View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003970 | OpenFOAM | Bug | public | 2023-04-12 01:40 | 2023-04-13 17:11 |
| Reporter | handrake0724 | Assigned To | will | ||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | resolved | Resolution | fixed | ||
| Product Version | 10 | ||||
| Fixed in Version | 10 | ||||
| Summary | 0003970: inconsistent behavior of createNonConformalCouples in some mesh in serial and parallel execution | ||||
| Description | I am testing NCC for sliding mesh and find that createNonConformalCouples command shows inconsistent message in serial and parallel execution, respectively. In serial execution, the log reads // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // Create time Reading "createNonConformalCouplesDict" Create mesh for time = 0 Adding nonConformalCyclic interfaces between patches: (nonCouple1 nonCouple2) Named: (nonConformalCouple_on_nonCouple1 nonConformalCouple_on_nonCouple2) With transform: transformType none; patchToPatch: Calculating couplings between 92228 source faces and 92228 target faces Source min/average/max coverage = 0.9999999999998507/0.999999999999998/1.000000000000077 Target min/average/max coverage = 0.9999999999997982/0.9999999999999991/1.000000000000153 Source average openness/error/depth/angle = 8.036399968942091e-17/6.970029914210327e-15/1.795228539683142e-15/2.104964404208377e-07 Source max openness/error/depth/angle = 6.170872498989154e-16/2.289950195991059e-13/3.661871450879536e-14/1.909095910416422e-06 193972 couplings calculated in 16.422774s fvMeshStitcher: Connecting Writing mesh to 1e-07 End but parallel execution reads // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // Create time Reading "createNonConformalCouplesDict" Create mesh for time = 0 Adding nonConformalCyclic interfaces between patches: (nonCouple1 nonCouple2) Named: (nonConformalCouple_on_nonCouple1 nonConformalCouple_on_nonCouple2) With transform: transformType none; patchToPatch: Calculating couplings between 92228 source faces and 92228 target faces Source min/average/max coverage = 0.9999999999998507/1.000000023146119/1.000180016634776 Target min/average/max coverage = 0.71307653030402/0.9999507986124163/1.000000000000153 Source average openness/error/depth/angle = 8.031489393100866e-17/7.766498376871098e-06/7.733407289636433e-10/0.0003962600795478927 Source max openness/error/depth/angle = 6.170872498989154e-16/0.4301387904644676/3.99899270311335e-05/24.75136731116615 193900 couplings calculated in 3.430375s fvMeshStitcher: Connecting Writing mesh to 0 End Especially, Source max angle shows quite different order: 1.909095910416422e-06 vs. 24.75136731116615. I have checked tutorial/incompressible/pimpleFoam/RAS/propeller and found the case showed consistent results. pimpleFoam fails to run successfully if I first decompose the mesh and apply createBaffles, splitBaffles followed by createNonConformalCouples while pimpleFoam runs good if I first apply createBaffles, splitBaffles followed by createNonConfomalCouples and then decompose the mesh. I could provide snappyHexMeshDict and geometries but the total size of the files exceeds the limit (2MB). | ||||
| Steps To Reproduce | Compare the results of the following steps. case 1 a) decompose the mesh b) createBaffles in parallel mode c) splitBaffles in parallel mode d) createNonConformalCouples in parallel mode case 2 a) createBaffles in serial mode b) splitBaffles in serial mode c) createNonConfomalCouples in serial mode d) decompose the mesh | ||||
| Tags | No tags attached. | ||||
|
|
There should not be a difference, so it might be a bug. To be clear, is this calculation happening at a time when the surface meshes line up exactly? It certainly looks that way in the serial output; an angle of 10^-6 is very small; you'd only get that if the patches were geometrically conformal. Have you updated to the latest patch version of OpenFOAM-10? A number of fixes have been implemented since release last summer. Better yet, have you tried OpenFOAM-dev? If you run `checkMesh -allGeometry` (in dev) in parallel it will write coverage fields into the `postProcessing` subdirectory. What do these look like? Where on the interface is the coverage different from the serial case? As you have determined, our large-ish parallelised tutorials do not show this difference between serial and parallel execution. So, I have no way of reproducing this. I would need the case. If the case is larger than the permitted upload size then you will need to make it available to us via some other file sharing service. |
|
|
Also, maybe try doing the decompose after `splitBaffles` but before `createNonConfomalCouples` to see if it is actually the parallelisation of the baffles utilities that is to blame in some way. |
|
|
As you noted, the surface meshes were geometrically conformal because the patches were generated from face zone by using createBaffles and splitBaffles. The executables for the OpenFOAM-10 were build from the latest patch version from OpenFOAM-10 repository. but I did not tried with OpenFOAM-dev. I will check it tomorrow and let you know the results. I will test it following you advice and let you know them as well. for the mesh, I will upload it on my google drive and share the url to it. |
|
|
I have check what you said. 1. the results of doing the decompose after splitBaffles but before createNonConformalCouples does not show any differences from serial execution. So, I think the parallelization of baffles is not the culprit. 2. The command built from OpenFOAM-dev repository showed the same behavior as OpenFOAM-10 repository. 3. the figures of the coverage on the interface are uploaded. As you can see, there are two faces which have coverage value less than 1 on the top of the cylinder. |
|
|
For case 1, I might make a mistake. doing the decompose after splitBaffles but before createNonConformalCouples has the same result (24.75136731116615.) as the parallel execution. |
|
|
I have uploaded the mesh in my google drive. the link is https://drive.google.com/file/d/1boHFOs9zW1hjonnciK17pG8u6Kq1ZI-e/view?usp=drivesdk |
|
|
The problem was in createBaffles. It should be fixed by these commits. https://github.com/OpenFOAM/OpenFOAM-dev/commit/5e8d1ff99ed35bc94a6874c185ade17a23e62bae https://github.com/OpenFOAM/OpenFOAM-10/commit/73bdbb2a3c7b82bbe554ca304180b20b6a931591 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2023-04-12 01:40 | handrake0724 | New Issue | |
| 2023-04-12 14:02 | will | Note Added: 0012987 | |
| 2023-04-12 14:03 | will | Note Edited: 0012987 | |
| 2023-04-12 14:05 | will | Note Added: 0012988 | |
| 2023-04-12 15:06 | handrake0724 | Note Added: 0012989 | |
| 2023-04-13 05:55 | handrake0724 | Note Added: 0012990 | |
| 2023-04-13 05:55 | handrake0724 | File Added: NCC_serial.png | |
| 2023-04-13 05:55 | handrake0724 | File Added: NCC_parallel.png | |
| 2023-04-13 06:24 | handrake0724 | Note Added: 0012991 | |
| 2023-04-13 06:39 | handrake0724 | Note Added: 0012992 | |
| 2023-04-13 17:11 | will | Assigned To | => will |
| 2023-04-13 17:11 | will | Status | new => resolved |
| 2023-04-13 17:11 | will | Resolution | open => fixed |
| 2023-04-13 17:11 | will | Fixed in Version | => 10 |
| 2023-04-13 17:11 | will | Note Added: 0012993 |
