2018-01-19 22:51 GMT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000309OpenFOAM[All Projects] Bugpublic2012-05-16 14:21
Assigned Touser4 
StatusclosedResolutionno change required 
PlatformSGI XE1300OSLinuxOS VersionSLES 10.1
Product Version 
Target VersionFixed in Version 
Summary0000309: SnappyHexMesh: unsnapped/irregular cells on flat surfaces
DescriptionI am meshing a building from a single stl file. Some irregular cells appear on some large flat surfaces. This did not happen using the same settings using 1.6 or 1.7.x. I have attached images showing the results with 2.0.x and 1.7.x. This problem occurs whether the meshing is done in one step (castellate and snap) or two steps (castellated then run again to snap) so this problem may be different to 0000295. Comparing the castellated mesh with the final result (image cc_combined_2.0.x.png) highlights that these features occur at some transitions in refinement level on the surface (this happens a few places in this case because the large surfaces are not perfectly aligned with the axis/blockmesh.)
Steps To ReproduceUse CC.stl file along with blockMeshDict and snappyHexMeshDict. Run with 1.7.x or 1.6 without problems (viewed after foamToVTK conversion). Running same files with 2.0.x reproduces problems in images.
Additional InformationI have a similar building geometry that demonstrates the same problems. I am keen to use 2.0.x in order to use the edge snapping features (which seems to work fine in this case in fact). The 2.0.x build for SLES10.1 was provided by SGI.
TagsNo tags attached.
Attached Files




sjrees (reporter)

This problem also occurs with version 2.1

Looking at the patch vtk file for the corresponding surface (as opposed to the whole field mesh vtk file) shows a good flat surface without problems. Hence this may partly be a vtk issue. I thought it might be due to the default treatment of polyhedra in vtk files but using the 'poly' option in foamToVTK reveals the same issue. I did notice that v1.7 does subdivide the cells at the problem locations in a different way to v2.0 and 2.1. Results also depend on the minTetQuality parameter and this was not present in v1.7. I still hope somebody can check this out please?



I've reenabled refining and snapping

    castellatedMesh true;
    snap true;

and set

    minTetQuality -1;

and get really good results in 2.1.x.


sjrees (reporter)

I don't see any improvement. My 2.1.x was built 16 April. I have been checking the mesh using the ExtractSurface filter in paraview.



Are you using paraFoam
- with VTKpolyhedron selected
- and no internal mesh selected, only patches

From your snapped pics it seems you are displaying and internal mesh without the VTKPolyhedron so it decomposes cells.


sjrees (reporter)

I have been using foamToVTK and the standard prebuilt paraview (3.14). I assumed the '-poly' option in foamToVTK would give a file with VTKPolyhedron? I saw earlier that viewing the patch file was different than viewing a surface extracted from the internal mesh. I just tried looking at the data using the native OpenFOAM reader in paraview 3.14 and don't see any problems. I wonder if there is a problem with the way foamToVTK is writing the mesh?



There is a slight difference in 'wedge' cell handling between paraFoam and foamToVTK. The latter decomposes the shape, former handles it natively. (this is historic - in older versions of paraview the wedge/collapsed hex was not properly handled)

-Issue History
Date Modified Username Field Change
2011-10-06 14:52 sjrees New Issue
2011-10-06 14:52 sjrees File Added: SHM_bug_6_10_11.zip
2011-10-06 14:53 sjrees File Added: cc_snapped_2.0.x.png
2011-10-06 14:53 sjrees File Added: cc_snapped_1.7.x.png
2011-10-06 14:54 sjrees File Added: cc_combined_2.0.x.png
2012-04-23 13:35 sjrees Note Added: 0001282
2012-04-26 09:58 user4 Note Added: 0001287
2012-04-27 12:57 sjrees Note Added: 0001291
2012-04-27 14:55 user4 Note Added: 0001292
2012-04-27 15:52 sjrees Note Added: 0001293
2012-05-16 14:21 user4 Note Added: 0001321
2012-05-16 14:21 user4 Status new => closed
2012-05-16 14:21 user4 Assigned To => user4
2012-05-16 14:21 user4 Resolution open => no change required
+Issue History