View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0000162OpenFOAMBugpublic2011-03-16 11:062011-07-18 17:31
Reporteruser153Assigned Touser4 
PriorityimmediateSeveritycrashReproducibilityalways
Status resolvedResolutionno change required 
PlatformLinuxOSUbuntuOS Version10.04
Summary0000162: snappyHexMesh bugs from running in parallel - 'boundary' files & 0 directory files
DescriptionGreetings,

1. Bug in snappyHexMesh writing the boundary files and 0 directory files, causing the inability to directly go from performing a HexMeshing to a solver execution
2. Closer examination into the processor*/0/* initial conditions files (U, k, omega, p, nut), and compared against the processor*/0/polyMesh/boundary file shows that the files are not coherent => That is what is represented in the 'boundary' file is not correctly shown on the initial conditions files
3. Bug is "fixed" when manual editing of the processor*/0/* initial conditions files to correctly represent the boundary file.
3. This presents a limiting step for parallel processing.
Steps To Reproduce1. cp -r $FOAM_TUTORIALS/incompressible/simpleFoam/motorBike .
2. blockMesh
3. decomposePar (Note: decomposeParDict amended to 4 subdomains for this)
4. mpirun -np 4 snappyHexMesh -overwrite -parallel
5. mpirun -np 4 simpleFoam -parallel <Crashes>

A closer study using the following steps:
6. gunzip ./processor*/0/*.gz [unzip all the 0 initial condition files]
7. find ./processor* | xargs grep -iE "procBoundary"
8. find ./processor* | xargs grep -iE "motorBike_"

- Step7 reveals that there is a discrepancy in contents of the 0 initial conditions file as compared to the constant/polyMesh/boundary files. (e.g. for processor2, there are 3 procBoundary patches, but only 2 procBoundary are written to the initial conditions file)
- Step8 reveals that the motorBike boundary patches are not written in the 0 initial conditions file
Additional InformationCurrent stop-gap/workaround:
- Amend the workflow as below
- New steps are No. 4, 5, 6

1. blockMesh
2. decomposePar
3. mpirun -np 4 snappyHexMesh -overwrite -parallel
4. reconstructParMesh
5. rm -rf ./processor*
6. decomposePar
7. mpirun -np 4 simpleFoam -parallel

TagsNo tags attached.

Activities

user153

2011-03-16 11:06

 

snappyHexMesh_bug_reporting.txt (2,778 bytes)    
./processor0/constant/polyMesh/boundary:    procBoundary0to1
./processor0/constant/polyMesh/boundary:    procBoundary0to2
./processor0/0/omega:    procBoundary0to1
./processor0/0/omega:    procBoundary0to2
./processor0/0/k:    procBoundary0to1
./processor0/0/k:    procBoundary0to2
./processor0/0/U:    procBoundary0to1
./processor0/0/U:    procBoundary0to2
./processor0/0/nut:    procBoundary0to1
./processor0/0/nut:    procBoundary0to2
./processor0/0/p:    procBoundary0to1
./processor0/0/p:    procBoundary0to2
./processor0/0/polyMesh/boundary:    procBoundary0to1
./processor0/0/polyMesh/boundary:    procBoundary0to2
./processor1/constant/polyMesh/boundary:    procBoundary1to0
./processor1/constant/polyMesh/boundary:    procBoundary1to2
./processor1/constant/polyMesh/boundary:    procBoundary1to3
./processor1/0/omega:    procBoundary1to0
./processor1/0/omega:    procBoundary1to3
./processor1/0/k:    procBoundary1to0
./processor1/0/k:    procBoundary1to3
./processor1/0/U:    procBoundary1to0
./processor1/0/U:    procBoundary1to3
./processor1/0/nut:    procBoundary1to0
./processor1/0/nut:    procBoundary1to3
./processor1/0/p:    procBoundary1to0
./processor1/0/p:    procBoundary1to3
./processor1/0/polyMesh/boundary:    procBoundary1to0
./processor1/0/polyMesh/boundary:    procBoundary1to2
./processor1/0/polyMesh/boundary:    procBoundary1to3
./processor2/constant/polyMesh/boundary:    procBoundary2to0
./processor2/constant/polyMesh/boundary:    procBoundary2to1
./processor2/constant/polyMesh/boundary:    procBoundary2to3
./processor2/0/omega:    procBoundary2to0
./processor2/0/omega:    procBoundary2to3
./processor2/0/k:    procBoundary2to0
./processor2/0/k:    procBoundary2to3
./processor2/0/U:    procBoundary2to0
./processor2/0/U:    procBoundary2to3
./processor2/0/nut:    procBoundary2to0
./processor2/0/nut:    procBoundary2to3
./processor2/0/p:    procBoundary2to0
./processor2/0/p:    procBoundary2to3
./processor2/0/polyMesh/boundary:    procBoundary2to0
./processor2/0/polyMesh/boundary:    procBoundary2to1
./processor2/0/polyMesh/boundary:    procBoundary2to3
./processor3/constant/polyMesh/boundary:    procBoundary3to1
./processor3/constant/polyMesh/boundary:    procBoundary3to2
./processor3/0/omega:    procBoundary3to1
./processor3/0/omega:    procBoundary3to2
./processor3/0/k:    procBoundary3to1
./processor3/0/k:    procBoundary3to2
./processor3/0/U:    procBoundary3to1
./processor3/0/U:    procBoundary3to2
./processor3/0/nut:    procBoundary3to1
./processor3/0/nut:    procBoundary3to2
./processor3/0/p:    procBoundary3to1
./processor3/0/p:    procBoundary3to2
./processor3/0/polyMesh/boundary:    procBoundary3to1
./processor3/0/polyMesh/boundary:    procBoundary3to2
snappyHexMesh_bug_reporting.txt (2,778 bytes)   

user4

2011-06-15 15:54

  ~0000442

snappyHexMesh does not adapt any initial fields when it is meshing. Even though part of the starting (hex) mesh will always be present in the resulting mesh most patches will be introduced during meshing itself so these would still need to be set afterwards.

We tend to run 'changeDictionary' (see e.g. snappyMultiRegionHeater tutorial) to set the initial fields. changeDictionary can be run in parallel so between steps 4 and 5 in your parallel workflow.

Issue History

Date Modified Username Field Change
2011-03-16 11:06 user153 New Issue
2011-03-16 11:06 user153 File Added: snappyHexMesh_bug_reporting.txt
2011-06-15 15:54 user4 Note Added: 0000442
2011-06-16 21:17 user4 Status new => closed
2011-06-16 21:17 user4 Assigned To => user4
2011-06-16 21:17 user4 Resolution open => no change required
2011-07-18 17:31 user4 Status closed => resolved