|
[Sponsors] |
SnappyHexMesh: Inappropriate orientation of boundary cells |
![]() |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
![]() |
![]() |
#1 |
Member
sirLentschi
Join Date: Nov 2010
Posts: 87
Rep Power: 15 ![]() |
Hello everyone,
I'm encountering an issue with SnappyHexMesh. When I double the number of cells in each direction using blockMesh, SnappyHexMesh generates a mesh with cells at the boundary that do not follow the STL file but align with the Cartesian coordinate system instead. I've already tried different numbers of refinement stages (feature refinement and surface refinement) without any improvement. Any suggestions or hints from your side? Last edited by lentschi; April 24, 2024 at 13:56. |
|
![]() |
![]() |
![]() |
![]() |
#2 |
Senior Member
Yann
Join Date: Apr 2012
Location: France
Posts: 1,169
Rep Power: 27 ![]() |
Hello,
It looks like castellatedMesh. If you're not using snappyHexMesh with the -overwrite option, make sure you are visualizing the last timestep in ParaView. Yann |
|
![]() |
![]() |
![]() |
![]() |
#3 |
Member
sirLentschi
Join Date: Nov 2010
Posts: 87
Rep Power: 15 ![]() |
Great hint! I'll check this out!
SnappyHexMesh created a time folder, which I converted using foamToVTK -latestTime. However, this conversion could have included a mixture of the constant/polyMesh and the time step/polyMesh. |
|
![]() |
![]() |
![]() |
![]() |
#4 |
Senior Member
Yann
Join Date: Apr 2012
Location: France
Posts: 1,169
Rep Power: 27 ![]() |
When running snappy without the -overwrite option, it will write each meshing step in a new time directory so you will have:
You don't need to use foamToVTK, but when loading your mesh in ParaView (using paraFoam or the paraview native reader with a .foam file), make sure to go to the last time step (see attached screenshot) Yann |
|
![]() |
![]() |
![]() |
![]() |
#5 |
Member
sirLentschi
Join Date: Nov 2010
Posts: 87
Rep Power: 15 ![]() |
Ich ran snappyHexMesh with the option -overwrite, but this caused the same inappropriate result. The cells are still not alligned according to the STL file.
|
|
![]() |
![]() |
![]() |
![]() |
#6 |
Senior Member
Yann
Join Date: Apr 2012
Location: France
Posts: 1,169
Rep Power: 27 ![]() |
Alright then it seems there is something else going on.
Could you share your files here so we can have a look? |
|
![]() |
![]() |
![]() |
![]() |
#7 |
Member
sirLentschi
Join Date: Nov 2010
Posts: 87
Rep Power: 15 ![]() |
What data would you need? I need to ask my PM if it's allowed.
|
|
![]() |
![]() |
![]() |
![]() |
#8 |
Senior Member
Yann
Join Date: Apr 2012
Location: France
Posts: 1,169
Rep Power: 27 ![]() |
Ideally, a minimal example allowing to reproduce the problem.
If not possible, at least the exact commands you are running, with associated dict (blockMeshDict, snappyHexMeshDict, ...) and log files. |
|
![]() |
![]() |
![]() |
![]() |
#9 |
Member
sirLentschi
Join Date: Nov 2010
Posts: 87
Rep Power: 15 ![]() |
log_snappy_fine_mesh.txt
log_snappy_coarse_mesh.txt log_block.txt Here are logs for blockMesh and snappyHexMesh. The only difference between both snappyHexMeshDicts is the maxGlobalCells to be set to 60000000 for the coarse mesh in order to avoid any refinement. Commands: blockMesh -dict system/blockMeshDict > log_block 2>&1 & snappyHexMesh > log_snappy 2>&1 & foamToVTK -latestTime Then downloading VTKs to my local machine. The coarse mesh is aligned to the STL at the 2nd timestep created with snappyHexMesh. The first time step looks aligned to the Catesian coordinate system such as the fine mesh does. The fine mesh is aligned according to the Cartesian coordinate system at BOTH time steps! So there is no alignment to the STL between first and second time step. |
|
![]() |
![]() |
![]() |
![]() |
#10 |
Senior Member
Yann
Join Date: Apr 2012
Location: France
Posts: 1,169
Rep Power: 27 ![]() |
Thanks for the files.
I'm not sure what is going on with your mesh. What kind of geometry are you trying to mesh? It is surprising to start with a 126 millions cells blockMesh to end up with a 30 millions cells mesh. By the way, why don't you mesh in parallel? 30h of meshing is insane! ![]() |
|
![]() |
![]() |
![]() |
![]() |
#11 |
Member
sirLentschi
Join Date: Nov 2010
Posts: 87
Rep Power: 15 ![]() |
I am allowed to share the case. I will have acess to the data on Sunday.
Typically, I mesh in parallel, but on these days there were no free cores left. Unfortunately, I am not the only one using the cluster ![]() |
|
![]() |
![]() |
![]() |
![]() |
#12 |
Member
sirLentschi
Join Date: Nov 2010
Posts: 87
Rep Power: 15 ![]() |
My case is now ready for sharing. If there is someone who is willing to support, please just PM me and I will share the case (constant + system folder) via OneDrive.
Thanks and best regards, Markus Last edited by lentschi; May 7, 2024 at 15:23. |
|
![]() |
![]() |
![]() |
![]() |
#13 |
Member
sirLentschi
Join Date: Nov 2010
Posts: 87
Rep Power: 15 ![]() |
No one out there who wanna help?
|
|
![]() |
![]() |
![]() |
![]() |
#14 |
Member
sirLentschi
Join Date: Nov 2010
Posts: 87
Rep Power: 15 ![]() |
OK, I solved it by myself. I just kept all refinement levels on 3 and skipped further refinement by reducing the maximum number of cells (maxGlobalCells).
|
|
![]() |
![]() |
![]() |
|
|
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
[snappyHexMesh] snappyHexMesh does not work | Siassei | OpenFOAM Meshing & Mesh Conversion | 8 | September 28, 2023 04:01 |
[snappyHexMesh] SnappyHexMesh running killed! | Mark JIN | OpenFOAM Meshing & Mesh Conversion | 7 | June 14, 2022 01:37 |
[snappyHexMesh] SnappyHexMesh for internal Flow | vishwa | OpenFOAM Meshing & Mesh Conversion | 24 | June 27, 2016 08:54 |
Error finding variable "THERMX" | sunilpatil | CFX | 8 | April 26, 2013 07:00 |
[snappyHexMesh] external flow with snappyHexMesh | chelvistero | OpenFOAM Meshing & Mesh Conversion | 11 | January 15, 2010 19:43 |