View Issue Details

IDProjectCategoryView StatusLast Update
0000295OpenFOAM[All Projects] Bugpublic2015-01-29 23:27
ReporterwyldckatAssigned Tohenry 
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
PlatformLinuxOSOpenSuseOS Version11.3
Product Version 
Fixed in Version 
Summary0000295: Defects appear when using snappyHexMesh with castellated+snap on partially fin volumes
DescriptionThe geometry is a thick wall tube that constricts its wall shape when it's reaching the outlet. The mesh is generated inside the wall of the tube.

The problem occurs only when running the two meshing stages of "castellatedMesh" and "snap" in the same run. It does not occur when each stage is executed separately.

This tube like structure was part of a larger geometry, but due to its dimensions, I've "chopped off" only the part of the geometry that has issues and was able to reproduce the problem, needing only to further increase mesh resolution in the tube walls.

Attached are various files:
  disc_castellated_and_snap_*.png - pictures of the damaged area in the original geometry, when doing the two stages in the same run;
  disc_castellated_only*.png - pictures of the same area as above, but when the two stages are done in separate runs.
  single_pass_*.png - pictures of the generated mesh on the reduced geometry, when running the two stages in a single run.
  dual_pass_*.png - the same as the previous, but when running the two stages in separate runs.
  disc_*_pass.tar.gz - the cases used to reproduce these results.
Steps To Reproduce1. Unpack both cases;
2. Execute Allrun in both cases;
3. Visual check of the resulting meshes, seeing the time instances that were generated for each meshing stage (because "-overwrite" isn't being used).

The only differences between each case:
  - The "disc_single_pass" case uses:
           castellatedMesh true;
           snap true;
           addLayers false;
  - The "disc_dual_pass" uses:
      - snappyHexMeshDict first run:
           castellatedMesh true;
           snap false;
           addLayers false;
      - snappyHexMeshDict second run:
           castellatedMesh false;
           snap true;
           addLayers false;
Additional InformationI don't know enough of the snappyHexMesh code to do a proper debugging of this problem, nor to figure out if this is an intended functionality - i.e. if this is associated to a control parameter in snappyHexMeshDict that only works when doing the two stages in the same run.
TagsNo tags attached.

Activities

wyldckat

2011-09-19 13:40

updater  

wyldckat

2011-09-19 13:40

updater  

wyldckat

2011-09-19 13:40

updater  

disc_castellated_only.png (25,450 bytes)
disc_castellated_only.png (25,450 bytes)

wyldckat

2011-09-19 13:40

updater  

wyldckat

2011-09-19 13:41

updater  

disc_dual_pass.tar.gz (81,129 bytes)

wyldckat

2011-09-19 13:41

updater  

disc_single_pass.tar.gz (80,677 bytes)

wyldckat

2011-09-19 13:41

updater  

dual_pass_01.png (57,338 bytes)
dual_pass_01.png (57,338 bytes)

wyldckat

2011-09-19 13:41

updater  

dual_pass_02.png (112,348 bytes)
dual_pass_02.png (112,348 bytes)

wyldckat

2011-09-19 13:41

updater  

single_pass_01.png (58,319 bytes)
single_pass_01.png (58,319 bytes)

wyldckat

2011-09-19 13:41

updater  

single_pass_02.png (118,937 bytes)
single_pass_02.png (118,937 bytes)

wyldckat

2011-09-19 13:43

updater   ~0000658

I forgot to mention:
   Using: OpenFOAM-2.0.x (see www.OpenFOAM.org)
   Build: 2.0.x-222e193db8bc

user4

2011-09-20 09:49

  ~0000662

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.

wyldckat

2011-09-20 14:19

updater   ~0000663

Last edited: 2011-09-20 14:19

View 2 revisions

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...

wyldckat

2011-09-22 10:35

updater   ~0000664

Last edited: 2011-09-22 10:36

View 2 revisions

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

wyldckat

2011-09-22 10:35

updater  

wyldckat

2011-09-22 10:35

updater  

wyldckat

2011-09-22 10:35

updater  

problems_on_one_edge.png (80,505 bytes)
problems_on_one_edge.png (80,505 bytes)

wyldckat

2011-09-22 10:36

updater  

problems_on_underside.png (84,610 bytes)
problems_on_underside.png (84,610 bytes)

wyldckat

2011-09-24 14:01

updater   ~0000671

Last edited: 2011-09-24 14:04

View 2 revisions

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.

wyldckat

2011-09-24 14:01

updater  

user4

2012-01-19 14:48

  ~0000936

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

wyldckat

2012-01-21 20:16

updater   ~0000948

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

user280

2012-01-23 01:58

  ~0000949

Last edited: 2012-01-23 02:02

View 3 revisions

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

henry

2015-01-29 15:19

manager   ~0003614

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.

wyldckat

2015-01-29 15:26

updater   ~0003616

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.

wyldckat

2015-01-29 15:30

updater   ~0003617

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

henry

2015-01-29 15:39

manager   ~0003620

Already fixed in OpenFOAM-2.3.?

Issue History

Date Modified Username Field Change
2011-09-19 13:39 wyldckat New Issue
2011-09-19 13:40 wyldckat File Added: disc_castellated_and_snap_01.png
2011-09-19 13:40 wyldckat File Added: disc_castellated_and_snap_02.png
2011-09-19 13:40 wyldckat File Added: disc_castellated_only.png
2011-09-19 13:40 wyldckat File Added: disc_castellated_only_then_snap.png
2011-09-19 13:41 wyldckat File Added: disc_dual_pass.tar.gz
2011-09-19 13:41 wyldckat File Added: disc_single_pass.tar.gz
2011-09-19 13:41 wyldckat File Added: dual_pass_01.png
2011-09-19 13:41 wyldckat File Added: dual_pass_02.png
2011-09-19 13:41 wyldckat File Added: single_pass_01.png
2011-09-19 13:41 wyldckat File Added: single_pass_02.png
2011-09-19 13:43 wyldckat Note Added: 0000658
2011-09-20 09:49 user4 Note Added: 0000662
2011-09-20 14:19 wyldckat Note Added: 0000663
2011-09-20 14:19 wyldckat Note Edited: 0000663 View Revisions
2011-09-22 10:35 wyldckat Note Added: 0000664
2011-09-22 10:35 wyldckat File Added: flange_res2x_single_vs_dual.png
2011-09-22 10:35 wyldckat File Added: flange_single_vs_dual_pass.png
2011-09-22 10:35 wyldckat File Added: problems_on_one_edge.png
2011-09-22 10:36 wyldckat File Added: problems_on_underside.png
2011-09-22 10:36 wyldckat Note Edited: 0000664 View Revisions
2011-09-24 14:01 wyldckat Note Added: 0000671
2011-09-24 14:01 wyldckat File Added: normal_resolution_new_missing_cell.png
2011-09-24 14:04 wyldckat Note Edited: 0000671 View Revisions
2012-01-19 14:48 user4 Note Added: 0000936
2012-01-21 20:16 wyldckat Note Added: 0000948
2012-01-23 01:58 user280 Note Added: 0000949
2012-01-23 01:59 user280 Note Edited: 0000949 View Revisions
2012-01-23 02:02 user280 Note Edited: 0000949 View Revisions
2015-01-29 15:19 henry Note Added: 0003614
2015-01-29 15:26 wyldckat Note Added: 0003616
2015-01-29 15:30 wyldckat Note Added: 0003617
2015-01-29 15:39 henry Note Added: 0003620
2015-01-29 15:39 henry Status new => resolved
2015-01-29 15:39 henry Resolution open => fixed
2015-01-29 15:39 henry Assigned To => henry