|
[Sponsors] |
[snappyHexMesh] snappyHexMesh - cyclic boundaries |
![]() |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
![]() |
![]() |
#1 |
Senior Member
Join Date: Nov 2012
Location: Bavaria
Posts: 145
Rep Power: 14 ![]() |
Hi to All!
I've created a mesh of a simple channel with snappyHexMesh (in parallel). In principle meshing with SHM worked fine, simulation ran successfully. Primarily the model had these boundary regions: inlet, outlet : patch wallLeft, wallRight, top, bottom: wall Next I've changed the boundaries of LeftWall and RightWall to cyclic in blockMeshDict and I've adapted the 0/* files accordingly. ![]() log-file 'log.snappyHexMesh_par' discloses this error: Code:
nProcs : 8 Slaves : 7 ( "linux-0ze2.14255" "linux-0ze2.14256" "linux-0ze2.14258" "linux-0ze2.14259" "linux-0ze2.14260" "linux-0ze2.14261" "linux-0ze2.14262" ) Pstream initialized with: floatTransfer : 0 nProcsSimpleSum : 0 commsType : nonBlocking polling iterations : 0 sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE). fileModificationChecking : Monitoring run-time modified files using timeStampMaster allowSystemOperations : Disallowing user-supplied system call operations // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // Create time Create mesh for time = 0 Read mesh in = 0.14 s Overall mesh bounding box : (0 0 0) (3.14 1.57 1) Relative tolerance : 1e-06 Absolute matching distance : 3.65027e-06 Reading refinement surfaces. Read refinement surfaces in = 0.01 s Reading refinement shells. Refinement level according to distance to rod level 2 for all cells within 0.2 metre. Read refinement shells in = 0 s Setting refinement level of surface to be consistent with shells. Checked shell refinement in = 0 s Reading features. Read features in = 0 s Determining initial surface intersections ----------------------------------------- Edge intersection testing: Number of edges : 244200 Number of edges to retest : 244200 Number of intersected edges : 542 Calculated surface intersections in = 0.19 s Initial mesh : cells:80000 faces:244200 points:84240 Cells per refinement level: 0 80000 Adding patches for surface regions ---------------------------------- Patch Type Region ----- ---- ------ rod: 6 wall rod_region0 Added patches in = 0.01 s Selecting decompositionMethod hierarchical Refinement phase ---------------- [4] Found point (1 0.5 0.5) in cell 203 on processor 4 Surface refinement iteration 0 ------------------------------ Marked for refinement due to surface intersection : 718 cells. Marked for refinement due to curvature/regions : 0 cells. Determined cells to refine in = 0.07 s Selected for refinement : 718 cells (out of 80000) [0] Cannot find point in pts1 matching point 0 coord:(0.019625 0 0.02) in pts0 when using tolerance 0.0280204 [0] Searching started from:0 in pts1 . . . [7] Compared coord: (3.12038 0 0.98) at index 509 with difference to point 1.57051 [7] Cannot find point in pts1 matching point 485 coord:(3.12038 1.57 0.98) in pts0 when using tolerance 0.0280204 [7] Searching started from:509 in pts1 [7] Compared coord: (3.12038 0 0.98) at index 509 with difference to point 1.57 [7] processorPolyPatch::order : Writing faces to OBJ file procBoundary7to5throughwallLeft_faces.obj [3] processorPolyPatch::order : Dumping newly found match as lines between corresponding face centres to OBJ file "/home/lisa/OpenFOAM/lisa-2.2.2/run/modelle_2/Anfangsbedingungen_obstacle_rod/1_simpleFoam_cyclic/processor3/procBoundary3to1throughwallLeft_faceCentresConnections.obj" [3] --> FOAM Serious Error : [3] From function processorPolyPatch::order(const primitivePatch&, labelList&, labelList&) const [3] in file meshes/polyMesh/polyPatches/constraint/processor/processorPolyPatch.C at line 1014 [3] in patch:procBoundary3to1throughwallLeft : Cannot match vectors to faces on both sides of patch [3] masterCtrs[0]:(1.58963 0 0.02) [3] ctrs[0]:(1.58963 1.57 0.02) [3] Check your topology changes or maybe you have multiple separated (from cyclics) processor patches [3] Continuing with incorrect face ordering from now on [7] processorPolyPatch::order : Dumping newly found match as lines between corresponding face centres to OBJ file "/home/lisa/OpenFOAM/lisa-2.2.2/run/modelle_2/Anfangsbedingungen_obstacle_rod/1_simpleFoam_cyclic/processor7/procBoundary7to5throughwallLeft_faceCentresConnections.obj" [7] --> FOAM Serious Error : [7] From function processorPolyPatch::order(const primitivePatch&, labelList&, labelList&) const [7] in file meshes/polyMesh/polyPatches/constraint/processor/processorPolyPatch.C at line 1014 [7] in patch:procBoundary7to5throughwallLeft : Cannot match vectors to faces on both sides of patch [7] masterCtrs[0]:(1.58963 0 0.54) [7] ctrs[0]:(1.58963 1.57 0.54) [7] Check your topology changes or maybe you have multiple separated (from cyclics) processor patches [7] Continuing with incorrect face ordering from now on Thanks! Ayla |
|
![]() |
![]() |
![]() |
![]() |
#2 |
Member
Julian Langowski
Join Date: May 2011
Location: Bremen, Germany
Posts: 91
Rep Power: 15 ![]() |
Dear Ayla,
I recently had the same problem. I think, snappy often has problems with cylcic BCs, especially when snappy is workin ON the cyclic patches. If you use cyclic BCs, the single faces on the cyclic patches have to be exactly the same (except mirrored postion), which is not the case, when snappy changes them. What I recommend: -Use snappy on the blockMesh with standard patches. -After succesful snapping process use createPatch for subsequent redefinement of cyclicAMI patches. Here is my createPatchDict: Code:
FoamFile { version 2.0; format ascii; class dictionary; object createPatchDict; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // pointSync false; patches ( { // Name of new patch name rightWall; // Type of new patch patchInfo { type cyclicAMI; neighbourPatch leftWall; transform rotational; rotationAxis (1 0 0); rotationCentre (0 0 0); matchTolerance 0.01; } // How to construct: either from 'patches' or 'set' constructFrom patches; // If constructFrom = patches : names of patches. Wildcards allowed. patches (rightPatchWall); } { // Name of new patch name leftWall; // Type of new patch patchInfo { type cyclicAMI; neighbourPatch rightWall; transform rotational; rotationAxis (1 0 0); rotationCentre (0 0 0); matchTolerance 0.01; } // How to construct: either from 'patches' or 'set' constructFrom patches; // If constructFrom = patches : names of patches. Wildcards allowed. patches (leftPatchWall); } ); Best regards Julian
__________________
πάντα ῥεῖ - Heraclitus |
|
![]() |
![]() |
![]() |
![]() |
#3 | |
Senior Member
Join Date: Nov 2012
Location: Bavaria
Posts: 145
Rep Power: 14 ![]() |
Hello Julian!
![]() Code:
dimensions [0 1 -1 0 0 0 0]; internalField uniform (0 0 0); boundaryField { inlet { type fixedValue; value uniform (0.0256 0 0); } outlet { type zeroGradient; } leftWall { type cyclicAMI; } rightWall { type cyclicAMI; } top { type fixedValue; value uniform (0 0 0); } bottom { type fixedValue; value uniform (0 0 0); } } Code:
. . . rightPatchWall { type fixedValue; value uniform (0 0 0); } leftPatchWall { type fixedValue; value uniform (0 0 0); } . . . ![]() Quote:
-------------------------------------------------------------------------------------------------------------- ![]() http://www.openfoam.org/version2.1.0/ami.php -------------------------------------------------------------------------------------------------------------- ![]() case 1: heat exchanger Let's say I would like to simulate the behavior of an heat exchanger module. Instead of representing the whole module it would be cheaper, concerning computational cost, to restrict on a cutout of the whole geometry. Is, in the case, the correct setting for the BCs (green edge) cyclic - to achieve that the mass flow through the pipes is constant and the geometry of the whole module - compared to the small cutout - is supposed to be infinite? What is the correct setting for the other boundaries (red edges)? ![]() case 2: channel flow ![]() In the channel above the middle plane (x-z) is obviously a symmetry plane. But how to define boundaries shown in the following pic: ![]() In case I would like to examine transition from laminar to turbulent flow (in a channel) a reasonable approach would be for example an LES computation. To save cells near walls I would like to omit leftWall and rightWall by setting proper BCs. Is it reasonable to set cyclic boundaries for leftWall and rightWall or is it better to set symmetryPlane? Is it correct to define type cyclic if I assume that the geometry is not a channel constrained by leftWall, rightWall, top and bottom but only by two infinite plates (top and bottom)? Is it possible to equalize 'cyclic' with 'periodic'? Then I could define inlet, outlet, leftWall and rightWall as cyclic? According to what I've understood so far this would enable me to build a channel flow (a small cutting of the whole channel) with a comparatively small number of cells and the 'only' remaining near wall problem I still have to allow for are regions close to the walls top and bottom. Honestly speaking I haven't understood the meaning of periodic up to a full extent, described in books and papers, so far. Is periodic equatable with cyclic? What is the intent of the definition of periodic? Save computational cost? Sorry for this extensive novel but I really would like to improve my understanding and hope for your input. ![]() Thank you! Ayla |
||
![]() |
![]() |
![]() |
![]() |
#4 |
Member
Sebastian Trunk
Join Date: Mar 2015
Location: Erlangen, Germany
Posts: 60
Rep Power: 11 ![]() |
Hey Ayla,
It has been a while since yoru post... Do have a solution for your channel probleme since I am dealing with more or less the same setup at the moment! Thanks for your info |
|
![]() |
![]() |
![]() |
Thread Tools | Search this Thread |
Display Modes | |
|
|
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
[mesh manipulation] Problem with using createPatchDict to define cyclic boundaries | kaszt | OpenFOAM Meshing & Mesh Conversion | 0 | April 1, 2016 22:18 |
Possible createPatch/createBaffles bug? | simpomann | OpenFOAM Bugs | 2 | July 15, 2014 08:07 |
[snappyHexMesh] snappyHexMesh and cyclic boundaries | Ruli | OpenFOAM Meshing & Mesh Conversion | 2 | December 9, 2013 07:51 |
Wrong wall distance with cyclic boundaries | sebastian | OpenFOAM Bugs | 4 | October 31, 2012 11:24 |
[snappyHexMesh] snappyHexMesh with cyclic patches? | Axel_T | OpenFOAM Meshing & Mesh Conversion | 1 | October 12, 2010 11:03 |