CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Meshing & Mesh Conversion

[snappyHexMesh] Problem using refineMesh, topoSet and snappyHexMesh

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   October 3, 2019, 05:33
Default Problem using refineMesh, topoSet and snappyHexMesh
  #1
Member
 
Rasmus Iwersen
Join Date: Jan 2019
Location: Denmark
Posts: 81
Rep Power: 8
Rasmusiwersen is on a distinguished road
Hi all,

Working on ubuntu 18.14 in OpenFOAM version 7 (openFoam.org), I am having trouble refining a case with waves passing a cylinder.

To get a proper resolution of the solution, I need to refine the mesh around the cylinder as well as in the free surface area. My strategy is to use snappyHexMesh to refine around the cylinder, and use refineMesh & topoSet to resolve the free surface properly.

Having used the DTCHullWave tutorial as a standpoint, I have created some different topoSetDictionaries and using a single refineMeshDict, since all topoSets needs to be refined in the same directions.

running the sequence:

# Source tutorial run functions
. $WM_PROJECT_DIR/bin/tools/RunFunctions

runApplication surfaceFeatures

runApplication blockMesh

for i in 1 2 3 4
do
runApplication -s $i \
topoSet -dict system/topoSetDict.${i}

runApplication -s $i \
refineMesh -dict system/refineMeshDict -overwrite
done

runApplication snappyHexMesh -overwrite

i cannot get past the error message:
--> FOAM FATAL ERROR:
cell 1590 of level 0 uses more than 8 points of equal or lower level
Points so far:8(2024 2025 2035 2036 2134 2135 2145 2146)

I've established that this happens at the interface between the initial mesh created in blockMeshDict and the first refinement region, topoSet 1 (please see attached .zip case)

Also, a screenshot is taken to visualize what the "physical" problem is. The problem cell is not a hexahedron as it is connected to more than 8 (10) vertices. How do i get past this? I've tried enabling "useHextopology" in the refineMeshDict (and then disabling the geometric cutting), with no luck. Also I've tried to refine the initial mesh, which is purely hexahedrons i might add. My domain is 30 meters in x direction, and subdivided into 80 cells, i.e. one cell is 37.5 cm. This is exactly the length of the cell in the attached picture, hence i know the problem occurs in the transition from initial mesh to the region defined in the topoSetDict.1.

In addition, I've tried to reduce the size of nCellsBetweenLayers, change the refinement levels in snappy as well as the regions specified in topoSet (in case they were exceeding the bounding box by the order of computational accuracy). Nothing helps, and the same cell is the problem each time.

Any suggestions?

Thanks
/Rasmus
Attached Images
File Type: jpg snip.jpg (65.8 KB, 109 views)
Attached Files
File Type: zip Dicts.zip (8.2 KB, 16 views)
Rasmusiwersen is offline   Reply With Quote

Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
[snappyHexMesh] TopoSet does not select all faces Mondal131211 OpenFOAM Meshing & Mesh Conversion 3 July 24, 2019 10:39
Parallel snappyHexMesh problem: Cannot find patchField entry for procBoundary2to7 hconel OpenFOAM Pre-Processing 0 October 5, 2018 18:22
[snappyHexMesh] snappyHexMesh problem shengqiming OpenFOAM Meshing & Mesh Conversion 0 December 15, 2016 09:35
[snappyHexMesh] does SnappyHexMesh allows intersection of refinement regions douglasx OpenFOAM Meshing & Mesh Conversion 2 April 2, 2014 10:30
[snappyHexMesh] refineMesh + snappyHexMesh s_braendli OpenFOAM Meshing & Mesh Conversion 1 July 26, 2013 10:32


All times are GMT -4. The time now is 13:42.