|
[Sponsors] |
[Gmsh] Cannot transfer physical surfaces to patches inside the boundary file |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
November 14, 2019, 15:20 |
Cannot transfer physical surfaces to patches inside the boundary file
|
#1 |
Member
Join Date: Mar 2019
Posts: 86
Rep Power: 7 |
I create a box in Gmsh under Modules/Geometry. This is the .geo file:
// Gmsh project created on Wed Nov 13 14:12:11 2019 //+ Point(1) = {-0.3, -0.7, 0, 1.0}; //+ Point(2) = {0.2, -0.7, 0, 1.0}; //+ Point(3) = {0.2, -0.5, 0, 1.0}; //+ Point(4) = {-0.1, -0.5, 0, 1.0}; //+ Line(1) = {3, 4}; //+ Line(2) = {1, 4}; //+ Line(3) = {1, 2}; //+ Line(4) = {2, 3}; //+ Curve Loop(5) = {4, 1, -2, 3}; //+ Plane Surface(1) = {5}; //+ Extrude {0, 0, 1} { Surface{1}; } //+ Physical Surface("front") = {26}; //+ Physical Surface("back") = {1}; //+ Physical Surface("in") = {13}; //+ Physical Surface("out") = {21}; //+ Physical Surface("top") = {17}; //+ Physical Surface("bot") = {25}; //+ Physical Volume("vol") = {1}; In Gmsh, I click on 3D under Modules/Mesh and then export the .msh file as ascii version 2 (gmshToFoam cannot read version 4) checking Save all elements ( but not Save parametric coordinates since gmshToFoam complains about that) It resides in the case directory of openfoam. Here is its contents: $MeshFormat 2.2 0 8 $EndMeshFormat $PhysicalNames 7 2 1 "front" 2 2 "back" 2 3 "in" 2 4 "out" 2 5 "top" 2 6 "bot" 3 7 "vol" $EndPhysicalNames $Nodes 9 1 -0.3 -0.7 0 2 0.2 -0.7 0 3 0.2 -0.5 0 4 -0.1 -0.5 0 5 0.2 -0.7 1 6 0.2 -0.5 1 7 -0.1 -0.5 1 8 -0.3 -0.7 1 9 -0.02261904761904762 -0.6166666666666666 0.5357142857142857 $EndNodes $Elements 43 1 15 2 0 1 1 2 15 2 0 2 2 3 15 2 0 3 3 4 15 2 0 4 4 5 15 2 0 5 5 6 15 2 0 6 6 7 15 2 0 10 7 8 15 2 0 14 8 9 1 2 0 1 3 4 10 1 2 0 2 1 4 11 1 2 0 3 1 2 12 1 2 0 4 2 3 13 1 2 0 7 5 6 14 1 2 0 8 6 7 15 1 2 0 9 7 8 16 1 2 0 10 8 5 17 1 2 0 12 2 5 18 1 2 0 13 3 6 19 1 2 0 17 4 7 20 1 2 0 21 1 8 21 2 2 0 1 1 2 4 22 2 2 0 1 2 3 4 23 2 2 0 14 2 3 6 24 2 2 0 14 5 2 6 25 2 2 0 18 3 4 6 26 2 2 0 18 6 4 7 27 2 2 0 22 4 1 7 28 2 2 0 22 7 1 8 29 2 2 0 26 1 2 8 30 2 2 0 26 8 2 5 31 2 2 0 27 5 6 7 32 2 2 0 27 8 5 7 33 4 2 0 1 2 6 3 4 34 4 2 0 1 4 1 2 9 35 4 2 0 1 8 7 5 9 36 4 2 0 1 8 2 1 9 37 4 2 0 1 5 2 8 9 38 4 2 0 1 7 1 4 9 39 4 2 0 1 8 1 7 9 40 4 2 0 1 7 6 9 4 41 4 2 0 1 7 9 6 5 42 4 2 0 1 2 9 6 4 43 4 2 0 1 2 6 9 5 $EndElements Finally, after running gsmhToFoam, the boundary file resides in folder constant/polyMesh : /*--------------------------------*- C++ -*----------------------------------*\ | ========= | | | \\ / F ield | foam-extend: Open Source CFD | | \\ / O peration | Version: 4.0 | | \\ / A nd | Web: http://www.foam-extend.org | | \\/ M anipulation | | \*---------------------------------------------------------------------------*/ FoamFile { version 2.0; format ascii; class polyBoundaryMesh; location "constant/polyMesh"; object boundary; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // 1 ( patch0 { type patch; nFaces 12; startFace 16; } ) // ************************************************** *********************** // As you can see it creates a patch name patch0. So, totally disregarding the physical surfaces ! Can anybody see what is going on ? I am very curious about this. Thanks, Marc |
|
November 20, 2019, 16:31 |
|
#2 |
Member
Join Date: Mar 2019
Posts: 86
Rep Power: 7 |
Well, forget about Gmesh 4.3.0 and saving the mesh in version 2 format: I ran Gmesh 12.2.0 and now the physical surfaces were correctly transferred to patches for that particular convex shape. Unfortunately, only 2
out of 3 surfaces were transferred for another shape with a tiny dent: the 2 surfaces comprising the dent were successfully transferred but not the surface for the shape surface minus the dent surfaces. And for a multiply connected shape ( i.e. having a hole inside) the outcome is a lot worse: gmshToFoam complains that the mesh has no cells (volumes) even though after clicking Mesh/3D in Gmesh but before saving the mesh, the bottom command window would clearly state that there are a positive number of volumes in the mesh ! So at this point, I don't know which Gmesh version since 2002 (if any) fits the bill. |
|
November 22, 2019, 19:05 |
|
#3 |
Member
Join Date: Mar 2019
Posts: 86
Rep Power: 7 |
Well, I cried wolf too fast for the shape with a tiny dent: it was simply a typo
Physical Surface("airwing") += {3, 2, 1, 5, 4}; The += should have been just = And sorry I meant Gmsh 2.12.0 all along not 12.2.0 obviously Now I will try to tackle the more serious problem that remains and I will keep you posted. Thanks for viewing Last edited by celestial; November 22, 2019 at 19:08. Reason: a different kind of typo in previous reply |
|
November 25, 2019, 16:58 |
|
#4 |
Member
Join Date: Mar 2019
Posts: 86
Rep Power: 7 |
How careless and sloppy one can be.
It was again a typo with the + sign: Physical Volume("vol") += {1}; I meant of course Physical Volume("vol") = {1}; So there is nothing special about multiply connected regions: Now gmshToFoam will yield the right constant/polyMesh files i.e. I now have a 3D mesh and all physical surfaces were correctly transferred to the corresponding patch names in the boundary files My most sincere apologies for wasting everybody's time viewing this post. |
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
[swak4Foam] funkyDoCalc with OF2.3 massflow | NiFl | OpenFOAM Community Contributions | 14 | November 25, 2020 04:30 |
Radiation in semi-transparent media with surface-to-surface model? | mpeppels | CFX | 11 | August 22, 2019 08:30 |
[OpenFOAM] Annoying issue of automatic "Rescale to Data Range " with paraFoam/paraview 3.12 | keepfit | ParaView | 60 | September 18, 2013 04:23 |
Version 15 on Mac OS X | gschaider | OpenFOAM Installation | 113 | December 2, 2009 11:23 |
OpenFOAM on MinGW crosscompiler hosted on Linux | allenzhao | OpenFOAM Installation | 127 | January 30, 2009 20:08 |