|
|
|
|
|
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. |
|
|
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. |
|
|
also meshQualityDict from 8.0 motorbike |
|
|
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? |
|
|
> 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? |
|
|
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? |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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... |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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? |
|
|
> 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/). |
|
|
> 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 ??:? |
|
|
Sorry. Here is the attachment. Untitled.png (254,729 bytes) |
|
|
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?". |
- Anonymous
