View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000162OpenFOAM[All Projects] Bugpublic2011-03-16 11:062011-07-18 16:31
Assigned Touser4 
StatusresolvedResolutionno change required 
PlatformLinuxOSUbuntuOS Version10.04
Product Version 
Target VersionFixed in Version 
Summary0000162: snappyHexMesh bugs from running in parallel - 'boundary' files & 0 directory files

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.
Attached Filestxt file icon snappyHexMesh_bug_reporting.txt [^] (2,778 bytes) 2011-03-16 11:06 [Show Content]

- Relationships

-  Notes
2011-06-15 14:54

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 chershyan New Issue
2011-03-16 11:06 chershyan File Added: snappyHexMesh_bug_reporting.txt
2011-06-15 14:54 user4 Note Added: 0000442
2011-06-16 20:17 user4 Status new => closed
2011-06-16 20:17 user4 Assigned To => user4
2011-06-16 20:17 user4 Resolution open => no change required
2011-07-18 16:31 user4 Status closed => resolved