View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000162OpenFOAM[All Projects] Bugpublic2011-03-16 11:062011-07-18 17:31
Reporterchershyan 
Assigned Tomattijs 
PriorityimmediateSeveritycrashReproducibilityalways
StatusresolvedResolutionno change required 
PlatformLinuxOSUbuntuOS Version10.04
Product Version1.7.x 
Target VersionFixed in Version 
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.
Attached Filestxt file icon snappyHexMesh_bug_reporting.txt [^] (2,778 bytes) 2011-03-16 11:06 [Show Content]

- Relationships

-  Notes
(0000442)
mattijs (manager)
2011-06-15 15: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 15:54 mattijs Note Added: 0000442
2011-06-16 21:17 mattijs Status new => closed
2011-06-16 21:17 mattijs Assigned To => mattijs
2011-06-16 21:17 mattijs Resolution open => no change required
2011-07-18 17:31 mattijs Status closed => resolved