View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000309 | OpenFOAM | Bug | public | 2011-10-06 14:52 | 2012-05-16 14:21 |
Reporter | Assigned To | ||||
Priority | normal | Severity | major | Reproducibility | always |
Status | closed | Resolution | no change required | ||
Platform | SGI XE1300 | OS | Linux | OS Version | SLES 10.1 |
Summary | 0000309: SnappyHexMesh: unsnapped/irregular cells on flat surfaces | ||||
Description | I 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 Reproduce | Use 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 Information | I 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. | ||||
Tags | No tags attached. | ||||
2011-10-06 14:52
|
|
2011-10-06 14:53
|
|
2011-10-06 14:53
|
|
2011-10-06 14:54
|
|
|
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. |
|
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. |
|
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) |
Date Modified | Username | Field | Change |
---|---|---|---|
2011-10-06 14:52 |
|
New Issue | |
2011-10-06 14:52 |
|
File Added: SHM_bug_6_10_11.zip | |
2011-10-06 14:53 |
|
File Added: cc_snapped_2.0.x.png | |
2011-10-06 14:53 |
|
File Added: cc_snapped_1.7.x.png | |
2011-10-06 14:54 |
|
File Added: cc_combined_2.0.x.png | |
2012-04-23 13:35 |
|
Note Added: 0001282 | |
2012-04-26 09:58 |
|
Note Added: 0001287 | |
2012-04-27 12:57 |
|
Note Added: 0001291 | |
2012-04-27 14:55 |
|
Note Added: 0001292 | |
2012-04-27 15:52 |
|
Note Added: 0001293 | |
2012-05-16 14:21 |
|
Note Added: 0001321 | |
2012-05-16 14:21 |
|
Status | new => closed |
2012-05-16 14:21 |
|
Assigned To | => user4 |
2012-05-16 14:21 |
|
Resolution | open => no change required |