View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001936 | OpenFOAM | [All Projects] Bug | public | 2015-12-02 10:23 | 2016-07-22 15:27 |
| Reporter | wgvanveen | Assigned To | henry | ||
| Priority | normal | Severity | minor | Reproducibility | random |
| Status | resolved | Resolution | fixed | ||
| Platform | Unix | OS | Other | OS Version | (please specify) |
| Product Version | |||||
| Fixed in Version | dev | ||||
| Summary | 0001936: SnappyHexMesh unable to split AMI patches | ||||
| Description | When running snappyHexMesh in either serial or parallel mode the boundary describing an AMI patch is not split correctly. When rotating the mesh using moveDynamicMesh -checkAMI some of the faces are connected to the wrong patch creating very strange cells. | ||||
| Steps To Reproduce | I have added the case file to repoduce the error with using the parallel computation (but it works in serial). blockMesh surfaceFeatureExtract decomposePar mpirun -np 2 snappyHexMesh -parallel reconstructParMesh (move the polyMesh from 0.002 to constant) moveDynamicMesh -checkAMI | ||||
| Tags | No tags attached. | ||||
|
|
AMI.tar.gz (14,909 bytes) |
|
|
I wanted to take a look into this weekend, but it didn't happen. Nonetheless, I'm also waiting for wgvanveen's case that also reproduces the issue with a serial run. In addition, this was originally addressed in the forum, in this thread: http://www.cfd-online.com/Forums/openfoam-meshing/163257-splitting-mesh-ami.html All of this to say that: this problem, when running in parallel, is already fixed in the OpenFOAM-history repository. Nonetheless, given that the autoMesh libraries are still considerably different (history vs dev), it will take me a while to study the changes that most likely fixes this issue, namely this commit: https://github.com/OpenCFD/OpenFOAM-history/commit/329714260a56335d2b9c2ab0d179a4f792d66ad4 |
|
|
snappySnapDriver.C (97,135 bytes) |
|
|
I've uploaded a fixed version of OpenFOAM-dev/src/mesh/snappyHexMesh/snappyHexMeshDriver/snappySnapDriver.C. In your case the cylinder geometry seems to have inwards pointing normals so the cellZone will be the outside of the geometry. Either flip your normals or use 'cellZoneInside outside' in the snappyHexMeshDict. The reasons for failure were that in parallel a point would only get duplicated if all the processors having the point all agreed on duplicating. For this particular algorithm it should be the opposite -if one decides to duplicate all should duplicate. Could you test this on some more geometries / decompositions and get back to us? Could you test this version and let us know? |
|
|
Resolved in OpenFOAM-dev by commit 7f373fe967a454c45048c7678a930e4c8a7a0fb1 Please reopen if further test still show this problem. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-12-02 10:23 | wgvanveen | New Issue | |
| 2015-12-02 10:23 | wgvanveen | File Added: AMI.tar.gz | |
| 2015-12-13 21:35 | wyldckat | Note Added: 0005756 | |
| 2016-07-21 14:23 | MattijsJ | File Added: snappySnapDriver.C | |
| 2016-07-21 14:29 | MattijsJ | Note Added: 0006548 | |
| 2016-07-22 15:26 | henry | Note Added: 0006557 | |
| 2016-07-22 15:26 | henry | Status | new => resolved |
| 2016-07-22 15:26 | henry | Fixed in Version | => dev |
| 2016-07-22 15:26 | henry | Resolution | open => fixed |
| 2016-07-22 15:26 | henry | Assigned To | => henry |
