|
|
disc_castellated_and_snap_01.png (26,750 bytes) |
|
|
disc_castellated_and_snap_02.png (82,459 bytes) |
|
|
disc_castellated_only.png (25,450 bytes) |
|
|
disc_castellated_only_then_snap.png (73,782 bytes) |
|
|
|
|
|
|
|
|
dual_pass_01.png (57,338 bytes) |
|
|
dual_pass_02.png (112,348 bytes) |
|
|
single_pass_01.png (58,319 bytes) |
|
|
single_pass_02.png (118,937 bytes) |
|
|
I forgot to mention: Using: OpenFOAM-2.0.x (see www.OpenFOAM.org) Build: 2.0.x-222e193db8bc |
|
|
This is due to some special handling to avoid cells getting squashed. Cells with all points on the surface get removed to avoid this. However on thin surfaces this can cause gaps as your case demonstrates. snappyHexMesh in refinement-only mode disables this feature. Increase your refinement level on the 'wall' so you have two cells across the thickness and it doesn't do it. |
|
|
Many thanks for the quick response! Indeed, increasing the mesh resolution in the thin area does allow the mesh to be done in a single run. Then I think the only thing left for this bug report before it's closed would be this: please provide a more explicit parameter in "snappyHexMeshDict" that allows users to be aware of this functionality and therefore not requiring separate runs or even be able to reproduce the end result in either mode of execution. Perhaps a parameter that accepts these values: * -1 or not defined, for the normal behaviour; * 0 to not remove these cells; * >0 for the level of resolution increase in these cells (which would otherwise be removed). It's somewhat rare that these cases occur, where one only wants a thickness of a single cell in certain zone of a volume, but they do happen once in a while! Although it's understandable that such parameter might be considered unnecessary, specially if there are plans to make the algorithm more robust to avoid cells being squashed, without the need for absolute removal... |
|
|
Sorry to bother you again Mattijs, But I think this is still related to this bug report, so here goes... I've gone back to the "snappyHexMesh/flange" tutorial and have detected a few problems, some of which did not go away when I increased the resolution. You probably already know about these, but this still looks like a bug to me :( Newly attached files are as follows (all using polyhedron VTK mode): * flange_single_vs_dual_pass.png - shows the difference between using snappyHexMesh in a single run vs 2 separate stages, where there is a cell that doesn't disappear; the cells that cover the missing cell are somewhat squashed nonetheless... but passes the standard checkMesh. This also happens on the other side of this cylinder-like part. * problems_on_one_edge.png - this compares the STL+feature edges vs the resulting mesh. There are at two cells missing to complete this edge; this does not occur on the other side. Increasing the resolution on the whole mesh by one level fixes this... but 4x the number of cells just for this? * problems_on_underside.png - shows a series of missing cells to complete the underside surface near the hole. This is fixed when resolution is increased by one level. * flange_res2x_single_vs_dual.png - shows on the upper left a missing cell, even after the mesh resolution was increased; on the lower right shows the difference between single run vs two stages, where the single run seems to have a very strange cell arrangement, which also occurs when using the original refinement level. So the questions are: * Is this fixable with some other parameter, other than increasing the resolution even further? * Or is this a bug? I'm also asking this because the other geometry I'm working on, even after increasing the resolution to over 2 million cells, the surface still comes out "damaged", because it doesn't respect the feature edges, not even when using a two stage run! Best regards, Bruno |
|
|
flange_res2x_single_vs_dual.png (102,686 bytes) |
|
|
flange_single_vs_dual_pass.png (73,671 bytes) |
|
|
problems_on_one_edge.png (80,505 bytes) |
|
|
problems_on_underside.png (84,610 bytes) |
|
|
Updated to: Using: OpenFOAM-2.0.x (see www.OpenFOAM.org) Build: 2.0.x-3f9085f43276 Only today did I see that the latest 2.0.x already has new changes that already fix issues reported on the previous note: * The missing cell on the left in "flange_single_vs_dual_pass.png" now does exist. * "problems_on_underside.png" no longer occur with the default resolution on the tutorial. The following still occur: * "problems_on_one_edge.png" - still the same problem, as far as I can tell... * "flange_res2x_single_vs_dual.png" - doesn't exactly in the same place, but does in another place in the same cylinder-like shape. I remind you that this case is using +1 level on the defined levels on the tutorial case. And a new one appeared: * "normal_resolution_new_missing_cell.png" - shows on the left the detail of the selected cells on the right. Haven't tried running in a two stage scenario for this one. |
|
|
normal_resolution_new_missing_cell.png (48,634 bytes) |
|
|
Hi Bruno, I ran flange with // Surface-wise min and max refinement level level (3 3); and - do not see the "problems_on_one_edge.png" (which I assume is the fact that the corner does not get resolved properly). Both single and dual pass nicely recreate the corner. - do see some difference on flat surfaces. These are exactly the cells that get deleted in the single pass run as described in my above post. This is because it knows refinement to be followed by snapping. (we might want to use the refinement from snappyHexMesh on its own so it does not use any snapping-specific optimisations in a single-pass run) Kind regards, Mattijs |
|
|
Hi Mattijs, Many thanks for remembering about this report and for your kind reply. I've finally managed to check up on this today with OpenFOAM 2.1.x and to report back some of the findings I've made: - Those cells that seem to be missing, shown on the screen shots I've posted, namely: - flange_res2x_single_vs_dual.png - flange_single_vs_dual_pass.png - problems_on_underside.png - normal_resolution_new_missing_cell.png All seem to be a specific rendering problem. I say this because this was a conclusion I saw on the forum at cfd-online and because I've verified this here as well: if we check/display the surface patches, those "missing" cells are not reflected onto the patches. Therefore, the problem might be on the ParaView and/or plugin side, where some specific cell structures fail to be properly represented, even when the option "Use VTKPolyhedron" is checked. - As for the increased refinement, when increased to (3 3), the "problems_on_one_edge.png" no longer occur. But it's a pain that the mesh resolution has to be increased from the tutorial's default value, just to pick up properly on that edge, specially when the other edges snapped so nicely. This can also be somewhat fixed if instead of increasing resolution, we: - on the "blockMeshDict" file, the grading on Z is increased from 12 to 13. - or the Z value for the bounding box on the "-0.03" side is changed to "-0.028". Although with this value, the hole on the -Y side gets a more imperfect edge definition. - If that value is changed to "-0.027", it seems to give better results for the same (2 2) level than the default settings. I fully understand that mesh generation is pretty much an art itself, but this last item still feels like a bug that we keep "tripping" on. Many thanks once again and with my best regards, Bruno |
|
|
Hi Mattijs, I had similar experiences with snappyHexMesh (SHM). I need a coarse mesh for a complex geometry, and SHM does not give me exactly what I want. I was thinking about changing the algorithm a bit, but it looks like it is not that simple. I finally managed to prepare a file summarising an algorithm and a set of rules that I think can be used to generate the coarse mesh. I have shared the file here: https://docs.google.com/document/d/10gGQ-C7F0WzmRb1Ei9jTO_c4HKpiGBi_o_DaTQYAvNk/edit It would be great if you could give your comments on this. I added this note here because I thought it may address some of the problems reported in this bug. Thanks and sorry for interruption |
|
|
My understanding is that the issues reported here are resolved if the mesh is sufficiently fine for the snapping to be unambiguous. If this is the case I will close this report, if not please let us know how the latest snappyHexMesh version behaves and what changes are still required. |
|
|
I think so too, that this bug report can be closed. I only wanted to double-check how things were working with 2.3.x with this geometry, and whether the rendering issues were still occurring, before suggesting the same. But it you prefer, feel free to close this bug report. If I find anything more concrete, I'll open a new bug report specific for whichever issue I might find. Either way, whatever I find, will be more relevant to 2.3.x, than to 2.0.x. |
|
|
Sorry, forgot to state that the very first issue reported here has most likely been already solved in the latest snappyHexMesh versions, by both the "thin gap" feature and the ability of meshing exactly the same whether it's done in 2 or 3 steps vs all in one go, namely: http://www.openfoam.org/version2.3.0/snappyHexMesh.php |
|
|
Already fixed in OpenFOAM-2.3.? |
- Anonymous
