View Issue Details

IDProjectCategoryView StatusLast Update
0001936OpenFOAM[All Projects] Bugpublic2016-07-22 15:27
ReporterwgvanveenAssigned Tohenry 
PrioritynormalSeverityminorReproducibilityrandom
Status resolvedResolutionfixed 
PlatformUnixOSOtherOS Version(please specify)
Product Version 
Fixed in Versiondev 
Summary0001936: SnappyHexMesh unable to split AMI patches
DescriptionWhen 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 ReproduceI 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
TagsNo tags attached.

Activities

wgvanveen

2015-12-02 10:23

reporter  

AMI.tar.gz (14,909 bytes)

wyldckat

2015-12-13 21:35

updater   ~0005756

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

MattijsJ

2016-07-21 14:23

reporter  

snappySnapDriver.C (97,135 bytes)

MattijsJ

2016-07-21 14:29

reporter   ~0006548

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?

henry

2016-07-22 15:26

manager   ~0006557

Resolved in OpenFOAM-dev by commit 7f373fe967a454c45048c7678a930e4c8a7a0fb1

Please reopen if further test still show this problem.

Issue History

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