View Issue Details

IDProjectCategoryView StatusLast Update
0003602OpenFOAMBugpublic2020-12-02 11:11
ReporterrrossiAssigned Towill 
PrioritynoneSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
PlatformLinux 64bitOSCentosOS VersionCentos7
Product Version8 
Fixed in Versiondev 
Summary0003602: Potential degradation/issue/bug in snappyHexMesh when using cyclic patches
DescriptionI came across this (potential) change in behavior in snappyHexMesh when trying to mesh a pipe with some components inside where inlet and outlet patches have to be periodic.

The original mesh was created some years ago with the 2.1.1 release by specifying the inlet and outlet patches of the pipe as cyclic in blockMeshDict. The mesh was then created successfully by snappy including layers.

If the same procedure is used with the any higher version, including the latest 8.0, the mesh resulting from the snap phase is completely distorted.

The picture attached shows the castellated mesh and the snapped mesh, 2.1.1 on the left and 8.0 on the right.

Attached is the test case. To replicate:

1. foamCleanPolyMesh
2. blockMesh
3. snappyHexMesh
TagsNo tags attached.

Activities

rrossi

2020-11-26 15:16

reporter  

castellated.png (1,225,547 bytes)
snapped.png (1,156,811 bytes)
test.tgz (970,182 bytes)

henry

2020-11-26 15:27

manager   ~0011762

It looks like the snappyHexMeshDict settings are not appropriate for OpenFOAM-8/dev, have you tried refining the edges more?
We could look into this in detail and provide better settings but this would be user-support which requires funding.

rrossi

2020-11-26 15:53

reporter   ~0011763

This is the result with the snappyHexMeshDict from 8.0 motorbike tutorial.

Features refinement does not help.

In my humble opinion, with the 2.1.1 working with no issues (in serial execution) this is more likely a regression.

snappyDictLatest.png (722,610 bytes)

rrossi

2020-11-26 16:01

reporter   ~0011764

also meshQualityDict from 8.0 motorbike

henry

2020-11-26 16:08

manager   ~0011765

The motorbike snappyHexMeshDict is optimised for the motorbike, it is very unlikely to be optimal for your case.

> In my humble opinion, with the 2.1.1 working with no issues (in serial execution) this is more likely a regression.

Can you show which changes are causing the problem and what the consequence is of reverting them?

rrossi

2020-11-26 16:12

reporter   ~0011766

> Can you show which changes are causing the problem and what the consequence is of reverting them?

Not sure I understand what you mean. Which changes are you referring to?

henry

2020-11-26 16:15

manager   ~0011767

You suggest that the issue "is more likely a regression", what "regression", i.e. what changes between 2.1.1 and 8 do you think should be reverted and what is the consequence for other cases?

rrossi

2020-11-26 16:25

reporter   ~0011768

That I don't know of course because I'm not involved in the development of snappy and would be quite hard for me to debugging it and that's why I brought this to your attention.

The reason why I'm saying it could (conditional) potential regression (as mentioned in the title) it's just because the older release handles it regardless of the snappyHexMeshDict (flange, motorbike, etc) and optimal parameters, which again in my humble opinion is a step back.

henry

2020-11-26 16:34

manager   ~0011769

I think it will be possible to mesh your case correctly with the current snappyHexMesh with suitable handling of the edges and setting of the parameters. We could undertake this work for you as paid user-support.
Many other similar cases have been meshed successfully with the current snappyHexMesh.

> That I don't know of course because I'm not involved in the development of snappy and would be quite hard for me to debugging it and that's why I brought this to your attention.

You have access to the complete source code and could study the changes between 2.1.1 and 8 if you believe that a bug was introduced or if it would be better if one or more of the changes were reverted.

rrossi

2020-11-26 16:37

reporter   ~0011770

Well, I thought this was the purpose of reporting potential bugs, but I get you won't recognize this as such so feel free to close the ticket.

henry

2020-11-26 16:46

manager   ~0011771

I doubt this is a bug and it would be MUCH easier to mesh your case with the current snappyHexMesh rather than reverting developments.

However if you check the code and show which changes have caused the problem you see we can work on it.

tniemi

2020-11-27 13:59

reporter   ~0011774

Hi

I quickly checked this as I have sometimes seen similar issues (strange behavior with patches). If I changed the cyclic patches to walls, then snappy was able to produce a nice mesh. It seems that something goes wrong when the type of the patch is cyclic in the blockMesh phase. I vaguely remember having encountered these kind of problems, and personally in my workflow I have always created blockMesh and snappy with all patches as walls and then changed the types on the final mesh with createPatch and/or by editing the boundary file.

Don't know what change back in 2.1.1 would have changed this...

rrossi

2020-11-27 14:35

reporter   ~0011776

Hi tniemi.

Thanks for taking the time to look into this and for the valuable feedback.

Unfortunately I need to preserve a very strict tolerance between the cyclic patches because I can't switch to cyclicAMI in the solver I'm using, so the workflow you are suggesting is not an option for me.

henry

2020-11-27 14:39

manager   ~0011777

Someone would need to spend a lot of time checking the changes in the snappyHexMesh code between 2.1.1 and 8 to find the relevant ones and propose a correction.
Currently we have no funding to work on snappyHexMesh so we will either need sponsorship for the work or I can leave this open for a while in case you or someone else would like to work in it on your behalf.

tniemi

2020-11-29 19:09

reporter   ~0011782

I happened to have some old OFs still compiled and ran this with 2.2.x and 2.3.x out of curiosity. 2.2.x still worked, but 2.3.x did not. I looked at the release notes and there has been quite a lot of snappy improvements at that point, including improvements to handling cyclics. So probably some update does not play along well with this case.

For what it's is worth, I was able to get this working with OF-dev by setting "detectNearSurfacesSnap false;" and "keepPatches true;" (somehow deletion of zero sized boundaries causes segFault in this case). The produced mesh looks quite ok (cyclic boundary is sharp), but checkMesh tells that there are several regions so maybe it is not entirely valid.

rrossi

2020-11-30 09:32

reporter   ~0011783

Thanks for info tniemi.

I've tried to use the same flags with the current 8.0 release but the resulting mesh is still distorted.

However, now the layer mesh is written correctly to file whereas I was getting the following error/crash without the "keepPatches true" (I guess) flag:

Removing zero-sized patches:
    x0 type patch at position 0
    x1 type patch at position 1
    y0 type patch at position 2
    y1 type patch at position 3

#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigSegv::sigHandler(int) at ??:?
#2 ? in "/lib64/libc.so.6"
#3 Foam::globalPoints::reverseMeshPoints(Foam::cyclicPolyPatch const&) at ??:?
#4 Foam::globalPoints::receivePatchPoints(bool, Foam::Map<int> const&, Foam::List<int> const&, Foam::PstreamBuffers&, Foam::HashSet<int, Foam::Hash<int> >&) at ??:?
#5 Foam::globalPoints::calculateSharedPoints(Foam::Map<int> const&, Foam::List<int> const&, bool, bool) at ??:?
#6 Foam::globalPoints::globalPoints(Foam::polyMesh const&, Foam::PrimitivePatch<Foam::IndirectList<Foam::face>, Foam::Field<Foam::Vector<double> > const&> const&, bool, bool) at ??:?
#7 Foam::globalMeshData::calcGlobalPointSlaves() const at ??:?
#8 Foam::globalMeshData::globalPointSlaves() const at ??:?
#9 Foam::syncTools::getMasterPoints(Foam::polyMesh const&) at ??:?
#10 Foam::meshRefinement::printMeshInfo(bool, Foam::string const&) const at ??:?
#11 ? at ??:?
#12 ? at ??:?
#13 __libc_start_main in "/lib64/libc.so.6"
#14 ? at ??:?

Also, as mentioned in the original post, even with the 2.1.1 the mesh creation is successful in serial execution only.

When running in parallel with the same release and same snappyHexMeshDict, I get:

Surface refinement iteration 0
------------------------------

Marked for refinement due to surface intersection : 3058 cells.
Determined cells to refine in = 0 s
Selected for refinement : 3058 cells (out of 33880)
[1] Cannot find point in pts1 matching point 0 coord:(0.257289 0.257289 58.05) in pts0 when using tolerance 3.62299e-05
[1] Searching started from:16 in pts1
[1] Compared coord:(0.513473 10.7608 -12.4) with difference to point 71.2292
[1] Cannot find point in pts1 matching point 11 coord:(0.769658 0.257289 58.05) in pts0 when using tolerance 3.62299e-05

Do you have any feedback/guidelines on this?

tniemi

2020-11-30 10:41

reporter   ~0011784

> I've tried to use the same flags with the current 8.0 release but the resulting mesh is still distorted.

The "detectNearSurfacesSnap false;"-flag should be under "snapControls" for it to have an effect. If false, it reverts to 2.1.1 behaviour. At least for me it removes the distortion from the cyclic boundary in 8 and dev.

> However, now the layer mesh is written correctly to file whereas I was getting the following error/crash without the "keepPatches true" (I guess) flag:

Yes, that crash happens because by default snappy now removes 0-sized patches. This usually works without problems, but for some reason not here. Probably the cyclics don't play along well as that crash happens directly after removing the extra boundaries and when snappy starts to write the mesh to disk.

> Do you have any feedback/guidelines on this?

Unfortunately no, improvement to parallel operation is something that has been specially improved in eg. 2.3.0 release (https://openfoam.org/release/2-3-0/snappyhexmesh/).

rrossi

2020-11-30 17:36

reporter   ~0011785

> The "detectNearSurfacesSnap false;"-flag should be under "snapControls" for it to have an effect. If false, it reverts to 2.1.1 behaviour. At least for me it removes the distortion from the cyclic boundary in 8 and dev.

Got it. I've tried with the 8.0 as well and works as you suggested. I've also tried to run to case but crashed when starting to solve for pressure. Strange enough, the 4 regions are 4 isolated cells with size way smaller than the local grid resolution and completely detached from the boundary mesh (see attached).

> Unfortunately no, improvement to parallel operation is something that has been specially improved in eg. 2.3.0 release (https://openfoam.org/release/2-3-0/snappyhexmesh/).

Beside the 4 disconnected regions, given the overall good quality of the mesh I've tried to run in parallel on 4 cores with the 8.0 (to have all improvements you mentioned), but crashed with the following error during refinement:

After refinement surface refinement iteration 6 : cells:140823 faces:472212 points:192489
Cells per refinement level:
    0 287
    1 4433
    2 10952
    3 27031
    4 98120
Uncoupled 10 faces on coupled patches. (processorPolyPatch, cyclicPolyPatch)
Uncoupled 10 faces on coupled patches. (processorPolyPatch, cyclicPolyPatch)
[3] #0 Foam::error::printStack(Foam::Ostream&)[2] #0 Foam::error::printStack(Foam::Ostream&)[0] #0 Foam::error::printStack(Foam::Ostream&) at ??:?
[2] #1 Foam::sigSegv::sigHandler(int) at ??:?
[3] #1 Foam::sigSegv::sigHandler(int) at ??:?
[0] #1 Foam::sigFpe::sigHandler(int) at ??:?
[2] #2 ? at ??:?
[3] #2 ? at ??:?
[0] #2 ? in "/lib64/libc.so.6"
[2] #3 Foam::processorPolyPatch::updateMesh(Foam::PstreamBuffers&) in "/lib64/libc.so.6"
[3] #3 Foam::processorPolyPatch::updateMesh(Foam::PstreamBuffers&) in "/lib64/libc.so.6"
[0] #3 Foam::processorPolyPatch::updateMesh(Foam::PstreamBuffers&) at ??:?
[2] #4 Foam::polyBoundaryMesh::updateMesh() at ??:?
[3] #4 Foam::polyBoundaryMesh::updateMesh() at ??:?
[2] #5 Foam::polyMesh::resetPrimitives(Foam::Field<Foam::Vector<double> >&&, Foam::List<Foam::face>&&, Foam::List<int>&&, Foam::List<int>&&, Foam::List<int> const&, Foam::List<int> const&, bool) at ??:?
[0] #4 Foam::polyBoundaryMesh::updateMesh() at ??:?
[3] #5 Foam::polyMesh::resetPrimitives(Foam::Field<Foam::Vector<double> >&&, Foam::List<Foam::face>&&, Foam::List<int>&&, Foam::List<int>&&, Foam::List<int> const&, Foam::List<int> const&, bool) at ??:?
[2] #6 Foam::polyTopoChange::changeMesh(Foam::polyMesh&, bool, bool, bool, bool) at ??:?
[0] #5 Foam::polyMesh::resetPrimitives(Foam::Field<Foam::Vector<double> >&&, Foam::List<Foam::face>&&, Foam::List<int>&&, Foam::List<int>&&, Foam::List<int> const&, Foam::List<int> const&, bool) at ??:?
[3] #6 Foam::polyTopoChange::changeMesh(Foam::polyMesh&, bool, bool, bool, bool) at ??:?
[2] #7 Foam::fvMeshDistribute::repatch(Foam::List<int> const&, Foam::List<Foam::List<int> >&) at ??:?
[3] #7 Foam::fvMeshDistribute::repatch(Foam::List<int> const&, Foam::List<Foam::List<int> >&) at ??:?
[0] #6 Foam::polyTopoChange::changeMesh(Foam::polyMesh&, bool, bool, bool, bool) at ??:?
[2] #8 Foam::fvMeshDistribute::distribute(Foam::List<int> const&) at ??:?
[3] #8 Foam::fvMeshDistribute::distribute(Foam::List<int> const&) at ??:?
[2] #9 Foam::meshRefinement::balance(bool, bool, Foam::Field<double> const&, Foam::decompositionMethod&, Foam::fvMeshDistribute&) at ??:?
[0] #7 Foam::fvMeshDistribute::repatch(Foam::List<int> const&, Foam::List<Foam::List<int> >&) at ??:?
[3] #9 Foam::meshRefinement::balance(bool, bool, Foam::Field<double> const&, Foam::decompositionMethod&, Foam::fvMeshDistribute&) at ??:?
[2] #10 Foam::meshRefinement::refineAndBalance(Foam::string const&, Foam::decompositionMethod&, Foam::fvMeshDistribute&, Foam::List<int> const&, double) at ??:?
[0] #8 Foam::fvMeshDistribute::distribute(Foam::List<int> const&) at ??:?
[3] #10 Foam::meshRefinement::refineAndBalance(Foam::string const&, Foam::decompositionMethod&, Foam::fvMeshDistribute&, Foam::List<int> const&, double) at ??:?
[2] #11 Foam::snappyRefineDriver::surfaceOnlyRefine(Foam::refinementParameters const&, int) at ??:?
[0] #9 Foam::meshRefinement::balance(bool, bool, Foam::Field<double> const&, Foam::decompositionMethod&, Foam::fvMeshDistribute&) at ??:?
[3] #11 Foam::snappyRefineDriver::surfaceOnlyRefine(Foam::refinementParameters const&, int) at ??:?
[2] #12 Foam::snappyRefineDriver::doRefine(Foam::dictionary const&, Foam::refinementParameters const&, Foam::snapParameters const&, bool, Foam::dictionary const&) at ??:?
[0] #10 Foam::meshRefinement::refineAndBalance(Foam::string const&, Foam::decompositionMethod&, Foam::fvMeshDistribute&, Foam::List<int> const&, double) at ??:?
[3] #12 Foam::snappyRefineDriver::doRefine(Foam::dictionary const&, Foam::refinementParameters const&, Foam::snapParameters const&, bool, Foam::dictionary const&) at ??:?
[2] #13 at ??:?
[0] #11 Foam::snappyRefineDriver::surfaceOnlyRefine(Foam::refinementParameters const&, int) at ??:?
[3] #13 ?? at ??:?
[0] #12 Foam::snappyRefineDriver::doRefine(Foam::dictionary const&, Foam::refinementParameters const&, Foam::snapParameters const&, bool, Foam::dictionary const&) at ??:?
[0] #13 at ??:?
[2] #14 __libc_start_main at ??:?
[3] #14 __libc_start_main? in "/lib64/libc.so.6"
[2] #15 in "/lib64/libc.so.6"
[3] #15 ? at ??:?
[0] #14 __libc_start_main? at ??:?

rrossi

2020-11-30 17:37

reporter   ~0011786

Sorry. Here is the attachment.

Untitled.png (254,729 bytes)
Untitled.png (254,729 bytes)

will

2020-12-02 11:11

manager   ~0011787

The distortion problem is in `Foam::snappySnapDriver::avgCellCentres`. This is doing a `syncPointList` on a sum of point-adjacent cell centres. This operation is incompatible with transformed interfaces. We can transform vectors and positions, but there's no way of transforming a sum of positions like this. Instead, you sum up the point-cell-centre vectors, and synchronise those, rather than the cell-centres directly. This is just a position-less vector, and transforms/synchronises fine. Then, after synchronisation, you just add the point locations back on again. There are actually a few places in `snappySnapDriver.C` that I can spot where this fix applies. I've done as many as I can find, and pushed to dev. This means the meshing works OK with or without "detectNearSurfacesSnap false;". See commit:

https://github.com/OpenFOAM/OpenFOAM-dev/commit/983f77e19c82eb58a0fd3832bec858e5b8c30716

The segfault without "keepPatches true;" is caused by the patch removal process renumbering all the patches but not renumbering (or clearing) the stored neighbour patch indices in the coupled patches. This information needed propagating through couplings. This has been done in dev by the following commit.

https://github.com/OpenFOAM/OpenFOAM-dev/commit/f85dbc557f5ec42bcbd9ebce75391a5351bf3265

The parallel crash is due to `fvMeshDistribute` not ordering processor cyclics correctly. This has been fixed in dev by this commit.

https://github.com/OpenFOAM/OpenFOAM-dev/commit/685664b3ca399e04ad8d203686d7153698d985cd

The remaining issue for meshing this case in parallel is that `reconstructParMesh` does not seem to support cyclic patches. Adding that is a big job. For now, `redistributePar` does support cyclics, and it seems to do the job of reconstructing the mesh correctly in this case. It is far less convenient to use, however, and possibly also less efficient. Alternatively, you have the option of constraining the cyclics to a single processor, which will circumvent this issue. Or, just mesh it in serial. It's not a big case.

I do not see the multiple regions issue with this setup. In any case, the generation of multiple regions and associated solution failure is usually due to bad geometry, inappropriate settings, or just unrealistic expectations of what snappy can do. Helping you with that would constitute support, which is not provided on the bug tracking system.

Whilst there remains an issue with `reconstructParMesh` and it's support of cyclics, I think all of the issues raised in this report have now been resolved, so I'm closing this report. If you want to open another more specific issue relating to `reconstructParMesh` you are welcome to do so, though the response is likely to be "This is a significant development, can you fund it?".

Issue History

Date Modified Username Field Change
2020-11-26 15:16 rrossi New Issue
2020-11-26 15:16 rrossi File Added: castellated.png
2020-11-26 15:16 rrossi File Added: snapped.png
2020-11-26 15:16 rrossi File Added: test.tgz
2020-11-26 15:27 henry Note Added: 0011762
2020-11-26 15:27 henry Priority high => none
2020-11-26 15:27 henry Severity major => minor
2020-11-26 15:27 henry Description Updated View Revisions
2020-11-26 15:53 rrossi File Added: snappyDictLatest.png
2020-11-26 15:53 rrossi Note Added: 0011763
2020-11-26 16:01 rrossi Note Added: 0011764
2020-11-26 16:08 henry Note Added: 0011765
2020-11-26 16:12 rrossi Note Added: 0011766
2020-11-26 16:15 henry Note Added: 0011767
2020-11-26 16:25 rrossi Note Added: 0011768
2020-11-26 16:34 henry Note Added: 0011769
2020-11-26 16:37 rrossi Note Added: 0011770
2020-11-26 16:46 henry Note Added: 0011771
2020-11-27 13:59 tniemi Note Added: 0011774
2020-11-27 14:35 rrossi Note Added: 0011776
2020-11-27 14:39 henry Note Added: 0011777
2020-11-29 19:09 tniemi Note Added: 0011782
2020-11-30 09:32 rrossi Note Added: 0011783
2020-11-30 10:41 tniemi Note Added: 0011784
2020-11-30 17:36 rrossi Note Added: 0011785
2020-11-30 17:37 rrossi File Added: Untitled.png
2020-11-30 17:37 rrossi Note Added: 0011786
2020-12-02 11:11 will Assigned To => will
2020-12-02 11:11 will Status new => resolved
2020-12-02 11:11 will Resolution open => fixed
2020-12-02 11:11 will Fixed in Version => dev
2020-12-02 11:11 will Note Added: 0011787