|Anonymous | Login | Signup for a new account||2016-07-26 12:06 UTC|
|My View | View Issues | Change Log | Roadmap | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000162||OpenFOAM||[All Projects] Bug||public||2011-03-16 11:06||2011-07-18 16:31|
|Status||resolved||Resolution||no change required|
|Target Version||Fixed in Version|
|Summary||0000162: 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 Reproduce||1. cp -r $FOAM_TUTORIALS/incompressible/simpleFoam/motorBike .|
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 Information||Current stop-gap/workaround:|
- Amend the workflow as below
- New steps are No. 4, 5, 6
3. mpirun -np 4 snappyHexMesh -overwrite -parallel
5. rm -rf ./processor*
7. mpirun -np 4 simpleFoam -parallel
|Tags||No tags attached.|
|Attached Files||snappyHexMesh_bug_reporting.txt [^] (2,778 bytes) 2011-03-16 11:06 [Show Content]|
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.
|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|