[Artur]

Hi All,

I started using enGrid 1.4 recently for external hydrodynamics and found plenty of issues with lack of control of the prismatic boundary layer extrusion process, as I think many others have before me:
Prismatic boundary layer
Boundary layer using absolute height
Initial prism layer height

As I really need the functionality enGrid offers (and as there are few free alternatives), I spent some time digging through the code trying to narrow down on the issues and found a few quick *ekhem* fixes which helped me generate better grids for the kind of cases I'm dealing with. Here they are:

1. Modify src/libengrid/guicreateboundarylayer.ui to remove limits on BL extrusion parameters wherever they occur:

     <property name="minimum">
      <double>0.000000000000000</double>
     </property>
     <property name="maximum">
      <double>99.000000000000000</double>

2. Remove neighbour height limiter in src/libengrid/gridsmoother.cpp by commenting out lines 711 through to 747. This is arguably the largest modification and it messes with the original intent of the designers of the algorithm. If somebody has a bit more time and wants to understand the problem a bit better, I suggest starting here.

3. When extruding the mesh, use "relative height of first cell" and "ratio last last layer / far-field" equal to the same number; that number times the surface spacing will equal the height of the extruded layer (e.g. factor of 3 for surface spacing of 0.001 m yields a 3 mm thick layer).

Follow the process as described by the tutorials and you're done. I've attached example figures showing the best grids I could manage to create before and after the modifications.

EDIT: I also forgot to mention, it seems critical to me that the "create/improve surface mesh" routine gets executed several times before BL extrusion is attempted.

Hope this helps someone,

Artur

before.jpgbefore_zoomedIn.jpgafter.jpgafter_subdivided.jpg

[Artur]

I'm also posting a few pictures from the simulation (simpleFoam at a moderate Re) showing that the grid works just fine.


A


Ux.jpgyPlus.jpg

[ogloth]

Hello Artur,

thanks a lot for helping with this.

Did you try to compile the code form the master branch on GitHub. Some time ago we tried to improve the robustness of the boundary layer meshing, but the changes never made it into a proper release. Unfortunately we couldn't generate enough revenue from enGrid anymore to fund further developments and I would be more than happy if other people would pick things up and develop it further.

We are also considering to split the code into a library and a GUI and then provide the library under a more permissive licence (e.g. LGPL).

Cheers,
Oliver

[Artur]

Hi Oliver,


Yes, I did compile the master version first but I struggled to get it to extrude the layers properly. Maybe now that I've figured out the older version I could make better progress with it, I'll see about that when I get a bit more time.


It's a great shame the code has been abandoned as I think with not that much more work it could prove very useful to the community but of course funding is always an issue for such things. It certainly sounds reasonable to release it in two parts as then it might get incorporated into other pieces of software more easily. I'll make sure to stay up to date on this.


All the best,


Artur

[Artur]

Dear All,

I spent a bit more time on meshing a more complex geometry of an AUV fitted with an accelerating duct and its supports and found lots of issues with the surface remeshing algorithm in Engrid not being able to cope with CAD-exported surfaces. This prompted me to switch to Gmsh for surface meshing and importing the geometries into Engrid from there.The problem I faced then was the inability to locally adjust the size of the extruded boundary layer without remeshing the already satisfactory surface grid. I therefore adjusted the program to use the target surface sizes specified in "edit surface parameters/boundaries" as the characteristic face size on each patch. This allows me to control the size of the BL locally and better mesh fine geometric features.

It took a while but the final grid I obtained is fantastic, I couldn't improve much on it by using a commercial tool and it's certainly well beyond what snappyHexMesh can do in terms of resolving the inner boundary layer, see below:
improvedAlgorithm_mesh.jpg improvedAlgorithm_meshZoomedIn.jpg improvedAlgorithm_subdividedBlWithTets.jpg

I attached the modified gridsmoother.cpp file here hoping it would aid other people and uploaded my case as an example via Dropbox:
https://www.dropbox.com/s/bbch9mrewt...le.tar.gz?dl=0

The exact procedure I followed to get the mesh was:
1. Import iges into Gmsh
2. Mesh it and create external domain, paying attention to the orientation of normal vectors
3. Make sure physical types are defined properly for each surface
4. Export the .msh file
5. Edit the .msh file by hand to remove the physical type name definitions as those make Engrid complain ($PhysicalNames)
6. Import into Engrid using Gmsh v 2 option
7. Re-define boundary names and physical types, as well as flip orientation of the normals in the mesh volume where necessary (yellow side a should be pointing inside, use side B for green inside faces)
8. In "Edit surface parameters/boundaries" specify surface face size for each patch on the surface of the vehicle. DO NOT run surface meshing algorithm, leave Gmsh grid be
9. Proceed to "create prismatic boundary layer", selecting vehicle patches, the created volume, specifying 4 iterations, stretching factor to 1.15 and setting "relative height of first cell" and "ratio last layer / far-field" to 1.0 (NOTE: this may be adjusted to extrude arbitrary fractions/multitudes of surface mesh size specified in surface parameters)
10. Generate tetrahedras
11. Subdivide the boundary layer by specifying 20 layers, expansion ratio 1,15, and relative size equal to 0.015, which I calculated using the spreadsheet in the example case folder
12. Export to OpenFOAM (mesh only)
13. Scale the grid to metres from mm in which I had the geometry (note that the size of the AUV is not realistic at 120 mm, I just cared about the mesh structure and characteristic design features and was not working with any specific design)
14. Run potentialFoam and simpleFoam

gridsmoother.txt

The only thing I wish I could change about the current pipeline is to remove the manual part of meshing with Engrid by compiling a command line executable so that I could duct-tape it together with Gmsh and OpenFOAM, but that's a much bigger chunk of work so I feel it'll have to wait. Also, I tried switching to the master version but could not get it to work as intended so I stayed with 1.4. Anyway, hope this helps someone else make some nice grids.

All the best,

Artur


EDIT: I should point out I did not include volumetric refinement but this may be done by using the "sources" tab in "edit surface parameters", as described in the official tutorials on GitHub. Also, the uploaded Engrid projects have no mesh in file ending _1, and only the undivided BL in the file ending _2 for compactness.

[Artur]

And here are a few snapshots of the solution, indicating the really well distributed y+, well-resolved wake and propeller inflow which also allows the effect of the supports on separation on the outside of the duct to be discerned. The simulation is not fully converged as you can tell by the L1-norm residuals and the flow field, but it got far enough for me to be confident it won't crash or do anything silly.


All the best and happy foaming,


A


improvedAlgorithm_yPlus.jpg improvedAlgorithm_wake.jpg improvedAlgorithm_inflow.jpg residuals.jpg

[makaveli_lcf]

Hi Artur,


great topic, good meshing is always a topic for CFD simulations.
Did you try to convert your mesh to poly mesh? I got with my old Gambit tet meshes much better results after that.


Cheers,
Alex

[Artur]

Hi Alex,


No, I just relied on the raw export of tets and prisms. I didn't see the option in Engrid to convert to polys, or do you use an external tool for it?


All the best,


Artur

[makaveli_lcf]

Sorry for misleading you Artur, of course I mean polyDualMesh convertor in OpenFOAM. So what I had was nicely layered Gambit mesh but with a lot of tet elements in the part where the most of flow happens. As you see I got a nice polyhedral mesh which reduced my CFL number about 1 order.


Tet_mesh_@_SEN.png
Poly_mesh_@_SEN.png

[Artur]

Hi,


Thanks, that looks pretty neat. I've recently been experimenting a bit with polyhedral meshes exported from Star CCM+ and into OpenFOAM but it seems like the converter+Engrid combo could work just as well. I'll give it a go for sure!


All the best,


Artur

[guifon1000]

Artur,
First of all many thanks for this thread, which gave me a new hope of meshing a complex hydrofoil cfMesh could never handle. I was about to give up...
So I installed engrid (which I don't know at all) and am trying to follow your steps

Could you explain me this :

Originally Posted by Artur

5. Edit the .msh file by hand to remove the physical type name definitions as those make Engrid complain ($PhysicalNames)
Artur

In my case engrid complains about "$Nodes expected" at line 132 of gmshreader.cpp. Do I have to use gmsh 2 or can I continue with gmsh 3 ? My surface mesh generation process is automatic for the surface file (it used to be converted to cfMesh FMS format) and I have a physical group containing the feature edges, should I keep them ?

Best regards
Guillaume

[Artur]

Hi,

Great to hear my posting here is helping someone!

I use Gmsh 3 as well. What I meant by point 5 on the list was that in the file exported from Gmsh (I don't use any particular conversion, just hit export mesh in the file menu) the .msh file header will contain physical type name definitions which Engrid importer struggles with. I had to remove them by hand so that the file looks something like this before I can import it to Engrid:

$MeshFormat
2.2 0 8
$EndMeshFormat
$Nodes
110682
1 120 1.46957615897682e-14 0
2 115 -3.32532945573813 -1.16226472890446e-15
3 115 3.32532945573817 0
...

Hope this clarifies things a bit. Let me know if it works.

All the best

Artur

[guifon1000]

For me it does not work, I have the same kind of gmsh file as you just shown. The routine gmshreader.cpp looks for "$Nodes" and can't find it, although it is here, after "$EndMeshFormat". But I just saw that I was using the master version of the tool, which from what you wrote is not supposed to work correctly, so I swithed to 1.4 and have problems compiling it. Which version of netgen did you use ?
Regards
Guillaume

[Artur]

Yes, I did use version 1.4 rather than the master with netgen-5.3.1 compiled from source on Ubuntu 14.04. However, I just tried importing my Gmsh grid to the master release and it worked fine. Note - you need to go Import -> Gmsh v 2, even though you are actually using Gmsh 3. If you still can't get your file to work, download the example I posted above and compare my .msh file to yours, there's probably something amiss somewhere, like maybe a stray patch without a physical type or something similar.


As a separate note, the fix I posted was made to work with v 1.4 and I have not tried it with master. The menu layout changed a fair bit so I expect it won't work right off the bat. If you're having more trouble compiling I suggest starting a new thread and messaging me about it.


All the best,


Artur

[guifon1000]

I could finally load my MSH in the GUI, it was a stupid typo I did... I am going to try to extend your modifications to the master branch through your example, because investing some time in parcticing with such a tool's source code is definitely worth it for my projects, but unfortunately I am more a python/fortran guy than a c++ boss.

Also, I could compile the master on Ubuntu 16.04 but the recent versions of gcc which are in Ubuntu 18.04 are problematic and gave errors. If I could figure this out that would be cool, as this problem is redundant with 18.04...

[Artur]

Hi,


Glad to hear you managed to get it working. And definitely a good idea to play around with the master version if you have the time to spare on it. Once you manage to get it working OK please consider posting a summary of the changes you've made here for others to use as well


Best of luck,


A

[Dinlink]

Hi,


Nice thread!, when trying to compile the master branch on Ubuntu 18 i got stuck trying to downgrade cgal from 4.11 to 4.7... eventually i stopped trying and i compiled it on Ubuntu 16.04... But i struggle to make a prismatic boundary layer using the master branch. I have no problem re-meshing the surface, but it never gives me a prismatic layer.... Thats what i do:


- Make a surface mesh on gmsh
- Export the mesh in stl binary format
- Import the stl surface mesh to engrid

- Set the boundary codes with automatic option
- Edit surface parameters:

* If I check a boundary under the tab "boundaries" it remesh that boundary when "Create/improve surface mesh"
* I try to set the tab "prismatic layers" to different options using the "layer size calculator" section, but it does nothing when "Create/improve surface mesh"


In summary it ignores my settings on prismatic layers, if someone was able to make a prismatic layer it would be useful to explain how. Thank you all!

[ogloth]

Hello,

if you can make your geometry available, ideally with the enGrid files you have produced so far, I can try to have a look at it and point you in the right direction to create prismatic layers. No promises, however, because I only have a little bit of time to spare on enGrid at the moment.

Oliver

[Dinlink]

Hello!,


Thank you!!


I uploaded a .zip file to dropbox with:
- a "geo" subfolder with the geometry in .step format
- a "mesh" subfolder with the gmsh .geo, the .stl surface mesh and the engrid files (.egc and others)


.zip file:
https://www.dropbox.com/s/e9xzumau9d...d3005.zip?dl=0


I'm trying to create a prismatic layer for the boundary code 3: wall_003

[alp.tiken]

Hi all,

I’m a newbie enGrid user who tries to get experience on it. So, I’m working on a simple delta wing geometry in order to mesh and do a turbulent flow analysis, but I have some problems on boundary layer mesh generation on enGrid.

I’m working on Windows. At first, I generated a relatively coarse 2D surface mesh on Gmsh and then imported it to enGrid in order to generate 3D mesh. Problems began for me when switching to enGrid. Problems that I faced are:

1) As seen below, in the figures named BL-Result1 and 3, when I used “create prismatic boundary layer” command, I got this kind of a prismatic mesh layer.

- You can see my options when creating prismatic B/L mesh but changing those options did not change anything about B/L mesh, actually.

- Since B/L mesh is very confusing and makes nonsense, when I tried to divide this boundary layer it gave an error which states that "this seems to be a bug in enGrid. file: ..\..\..\libengrid\guidivideboundarylayer.cpp line:125"

- I think related to this bad mesh, when I tried to generate volume mesh on whole domain, in one case enGrid started with e+007 total badness and tried to improve it, and in another case gave an error which stated there occurred overlapping and stopped 3D meshing.

2) When I used only “extrusion” command on wing surface, without using “create prismatic B/L”, I got more reasonable results. You can see the result in figure named Extrusion2. But I’m not sure “extrusion” command can be used to boundary layer mesh instead of “create prismatic B/L” command.

Therefore, my questions are:

1) Is the extrusion command suitable to generate B/L mesh? Or should I still use “create prismatic B/L”?

2) Is there any way for creating a reasonable B/L mesh by using only “create prismatic B/L” command?

3) How can I solve the problem on “create prismatic B/L” command, which resulted that kind of a B/L mesh, as a Windows version user?

4) These problems I mentioned above, can they solvable in Linux (Ubuntu vs.) system if solution is not applicable by Windows version?

Best regards,
Alp Tikenoğulları