Hybrid meshes with boundary layers
 

Dear all,

I am modeling a network of pipes, here is a simplified geometry that contains the issue:
https://www.cfd-online.com/Forums/me...-21-143523.jpg

I would like to mesh the three straight pipes with structured hexahedra and the Ts with unstructured thetrahedra. I have make a partition with 10 solids (3 Ts and 7 straight pipes) :
https://www.cfd-online.com/Forums/me...-21-143701.jpg

I start meshing using submeshes from the central T with Netgen 3D-2D-1D, applying boundary layers on walls, and propogating on pipes with 3D extrusion, everything seems to go smoothly
https://www.cfd-online.com/Forums/me...-21-144033.jpg
There is the boundary layer on the walls as wanted
https://www.cfd-online.com/Forums/me...-21-143900.jpg
However, when I try to export to OpenFoam (I use salomeToOpenFOAM.py because there are piramids in the mesh), the export fails
https://www.cfd-online.com/Forums/me...-21-143928.jpg
and some defaultPatches are generated in the mesh tree:
https://www.cfd-online.com/Forums/me...118-image1.jpg
I think those defaultPatches are generating the export error, and I think they are generated because the mesh is not conformal. I visualized these patches, here is where they are located:
https://www.cfd-online.com/Forums/me...119-image2.jpg
and here is the shape
https://www.cfd-online.com/Forums/me...-21-144051.jpg
So those patches are genereated at the interface pipe/T when the T mesh is generated AFTER the pipe mesh. Using a clip also it is clear the mesh is not conformal.

Before the T
https://www.cfd-online.com/Forums/me...-21-144507.jpg

After the T:
https://www.cfd-online.com/Forums/me...-21-144802.jpg

Does anyone know how to fix it and generate a valid mesh?
Thanks in advance

Hey, me again :D


I tried to mesh several junctions the way you tried, and failed too, it seems impossible to create an extrusion with boundary layers between two junctions.


After seeing the pictures you attached, I think you should give cfMesh a try. It can generate nice boundary layers everywhere, and you can apply a nonuniform stretching to cells in the straight pipes to lower the cell count.

Hey Alczem, thanks again :)
This problem is really giving me headhaches!
I'll try out cfMesh right away

You could try to separate your pipe geometry into two distinct entities: the pipe interior and the wall layer. In my experience, it is easier to generate matching meshes, when using tet and extrusion meshing, if you do not bother with boundary layers in the first step.


So, instead of meshing the T-sections using a tet meshing algorithm with a boundary layer hypothesis; you would mesh the interior of the T-section using tets, and then mesh the boundary layer region using an extrusion algorithm.


This increases the complexity of your geometry and the meshing workflow, but in my experience it is not possible to "inform" a boundary layer hypothesis from the outside.



I hope this makes somewhat sense.


Salome is very good at making meshes in a bottom-up approach. Hence, if you separate meshing of the interior and the creation of the boundary layers, you will be able to achieve nice meshes.

Thanks for your reply. It seems unnecessarily complicated. I don't even know how to extract the inner geometry (inside the boundary layer) at the intersection between the pipes.

I mean, this is a trivial geometry, it's unbelievable it cannot be done with a classic procedure...

If you dont mind sharing the Geometry (BREP) I can give it a quick go

Sure, here it is.

https://www.dropbox.com/scl/fi/una1c...kpspxm472x52fd

Hi


Here is the results after about 30min.
The trick is to mesh the Tee first, parallel project the inletFace of the Tee to the internalFace of the Tee.
Project each of the Mesh faces of the Tee to their own face from the geo.
Use the projected mesh to make an extrusion of the face into 3D along a 1D line Mesh.
Make a mesh compund of the Tee and the Vertical Mesh.
Copy that 2 times, copy the internal pipe 1 time and mirror the inlet mesh around the center.
Make a Compund mesh of all these meshes and that will automatically merge internal nodes/faces if they lie on top of each other.


I have provided a link to the Study and the resulting UNV file for you to look at.
checkMesh shows nice values.


https://drive.google.com/file/d/1Ddo...ew?usp=sharing

Dear linnemann,

Thank you for the explication and the link :) Indeed, your solution is very interesting, but it does not apply to my real case. In fact, this is a simplified geometry, and in your procedure you exploited the symmetry of it. In my real case I can't do that.

https://www.cfd-online.com/Forums/me...-26-131116.jpg

In my case, I cannot avoid to generate the mesh of a T imposing the mesh on one (or more) of the external faces connected to the pipes. In your procedure, you meshed one T (without constraints), and copied that mesh. This cannot be done in a real case where every T is different from the other.

However, seeing what you did, I think I understood some key ingredients I was missing in Salome. Maybe I can mesh a T imposing the mesh on the faces using the 1D projections as you did in this simplified case?

There is something I don't understand in your procedure: when I display the mesh called InletMesh it shows a 3D mesh, but when I try to edit I can only see a 2D algorithm, as you meshed only the face on the base:



How is it done exactly this 3d extrusion?

Thanks in advance

Sure, attached are the steps.


Regarding your real case.
You can do the same with "Extrusion along path" and the projecting the faces where they are in-line.
The face meshes need to match up in order for the merging of nodes on the compound mesh.
So its doable, just takes a bit of time.

Well, I am not sure. Every time I try, it fails. The problem resides on the fact that the Netgen 3D algorithms seems incompatible with the imposition of a face mesh. I am able to propagate the mesh from an unstructured to a structured (3d extrusion) one, but not the other way around.

See this example: I am extruding a mesh in a pipe, I get this

https://www.cfd-online.com/Forums/me...-27-144216.png

Now I need to mesh the next connected part (this cone):

https://www.cfd-online.com/Forums/me...-27-144106.png

I projet the 2D mesh from the pipe to the upper face of the cone

https://www.cfd-online.com/Forums/me...-27-144508.png

this goes well:

https://www.cfd-online.com/Forums/me...-27-144553.png

Now I want to mesh the cone with an unstructured mesh, keeping the mesh of the face on the top. Here I am not sure what algorithm to use.. If I use Netgen 3D-2D-1D, the final mesh looks like this

https://www.cfd-online.com/Forums/me...-27-144939.png

See what I mean? The mesh of the top face has changed! Why is it doing that is beyond my comprehension.

If I just mesh using Net 3D-2D-1D WITHOUT projecting the face mesh before, the mesh on the top face looks kind of OK, but the nodes are not matching (which is understandable since the two meshes are completely independent)

Hi


You are correct, doing it this way for you case breaks the face mesh when it is projected when it has boundary layers. Without BL it works fine.


There is a way to do it using the "Extrusion 3D" meshing strategy.


Here is a link to the case and the checkMesh output.


https://drive.google.com/file/d/1De3...ew?usp=sharing

Yes of course, but that was just an example. What I need is an unstructured mesh. What do you do if you have a T instead of a cone?

This observed behaviour is exactly why I suggested to split-off the geometric region which is to contain the boundary layer. So, that you can create your hybrid mesh of tets and extrusions without the hassle of boundary layers. And then in a second step, extrude your boundary layers radially from the surface of the interior region.


This is a lot of extra work; but Salome is really good at creating meshes in a bottom-up approach as long as the individual steps are simple.

I see your problem now. If I make a Tee after the cone, the project face trick does not work anymore as the BL will cause issues in that instance.

So the best approach IMO is either to make the connection between the parts with AMI and live with the small interpolation errors introduced.
It can be done in Salome, but it will be tedious and error prone.

Or, you do as previously suggested and use cfMesh and live with the higher cellcount. This would be my prefered method.
You will loose some time in solving, but you will gain it back manyfold by not having to deal with the mesh.

Do you want to share the complex shape in post #9? I can give it a quick cfMesh go.

Thank you Niels. Yes, here is the geometry:

https://www.dropbox.com/scl/fi/b7zpl...i9k426iwzt83gf

I have already tried cfMesh. Without anisotropic refinement, it produces a good mesh with about 500K elements. I believe this case could be done with a good resolution with less then 200K. Unfortunately, I think there is a bug in the anisotropic refinement in cfmesh. I posted the issue on a simplified case here:

https://www.cfd-online.com/Forums/op...t-working.html

and here

https://www.cfd-online.com/Forums/op...ent-fails.html

If you could take a look to it and tell me what you think it would be great.

Your help is really appreciated.
Giorgio

Dear Gerhard, your approach would certainly work. However, it is not useful to me. What I am doing here is to investigate the possibility of opening a CFD activity in my company using opensource codes. I am trying to find out procedures to approach real cases. These procedures must obviously be competitive with proprietary softwares. I think the approach you propose it's too involved to be competitive.

All in all this turns out to be a big limitation of Salome. The geometry is simple, the strategy is clear, and yet you can't do it. That's a pity since the software is appealing in so many other aspects.

Dear Giorgio,


Even if you need to use a different meshing software for meshing the geometry in question, take this episode as a vital learning experience. If you understand what Salome can easily do, and what not; you may benefit in the future.


Depending on your workflows, you may help your meshing efforts in the geometry creation stage prior to beginning meshing. Sometimes it is easier to accomodate the needs of the meshing software when creating the geometry, rather than working around issues within the meshing software.


The beauty of applying open source software is that you can use apply all of them. With expensive commerical software, you would likely select the most fitting one, and that would be it. With open source, you can simply use them all.

I honestly dont understand why you would want to deal with anisotropic elements here. I have 186k cells in 19s using a 6core virtual machine.
Its more hasle than its worth. I mean 19s for meshing!!


Regarding Paid vs Open Source, please keep in mind that there is no such thing as free beer.

I have used open source professionally since 2010.

The companies I have worked for/with have contributed back with either knowledge sharing or sponsoring to implement the features missing.

The cost for implementing something in an open source tool is a one-time cost vs. a yearly subscription/license fee for commercial.

Hello Niels, could you share the meshDict file please? I think I remember with my options I got 500K elements.

Well it works, no doubt, I can use it. Nonetheless, the bug in anisotropic meshing is there. I think stretching the elements along the pipe would be useful, but I don't care discussing about it.

I am not trying to drink beer for free here ;) . Just inquiring opportunities.
Obviously, if we open this activity with free softwares, my work will feed back the software I would use.

Sure, here you go.


To prepare the geometry I scaled the geometry to mm first then export to stl as in the attached image.


Ran these commands.


The "renameSTL.sh" is just a little utility to rename the boundary to the stl filename and join into one file called "joined.stl".

Makes more sense when you have many STL files.

This is just my normal workflow.

I tried cfmesh. In my opinion, cartesianMesh is not fit for this geometry. The mesh is relatively fine on the portion aligned with the cartesian axis, but on the diagonal ones is pretty bad.

I gave it a try nonetheless. I have a case with lagrangian particles that I am solving with MPPICFoam. The computation runs until the particles are injected, then it crashes with this error:

"No base point for face xxx, produces a valid tet decomposition." Again, the problem seems to be the mesh.

Indeed, checkMesh -allGeometry shows some problems. Following another post in this forum, the issues seems to be this one:

***Error in face tets: 60 faces with low quality or negative volume decomposition tets.

So, all in all, also the mesh generated with cfmesh is useless.

I tried another solution: I generated with Salome a mesh WITHOUT boundary layer, combining Netgen on Ts and 3D extrusion on straight pipes. The mesh is kind of ok, even thought non-orthogonality is kind of high (~80), but I think this could work with non-orthogonal corrections. The problem is, I would like to add a boundary layer to this, using generateBoundaryLayers . Guess what? After the generation of bl, the mesh is useless again ( highly skew faces ), the computation crashes at the first iteration (on the pressure loop).


What a nightmare! Bear in mind, I am not even trying to be perfectionist here, just trying to obtain 1 single solution to my problem.

No way.

Did you try to run your simulation on a straight pipe with no bends and a "perfect" mesh? Just to make sure the mesh is the culprit here. In my experience, cfMesh is one of the most robust meshing tools around.


Keep us posted :)

I ran a simulation with a mesh with no boundary layers (with a lower Re), generated with Salome. The simulation ran smoothly until the end.

I read in several places that Lagrangian solvers have problems with faces with low quality or negative volume decomposition tets.

This is the mesh on diagonal pipes. It doesn't look acceptable to me. I know the strategy of cartesianMesh, I am not blaming the code.
That's why I struggled to do it with Salome.

Did not know this is what you were simulating.
Could have saved you some time.


OpenFOAM, Lagrangian and boundary layers do really not match.
The Lagrangian stuff in OF needs some love to be really usable.


I've had luck in creating two meshes (mapping the flow results), one for the flow part, with BL, and one for the Lagrangia, without BL, using uncoupledKinematicParcelFoam.

You loose the two way coupling this way and really is only an option for diluted flows.


Also see here for similar issue for CFX, https://www.cfd-online.com/Forums/cf...cell-size.html


Leaving this here as well.
https://www.foamacademy.com/wp-conte...les_slides.pdf

Hello, after reading your post, I made some tests, and realized a couple of things. Indeed, as you said, the mesh is not the only problem.



In fact, the particles I have to simulate are very big, about 10mm in diameters (well, they are not sphere either, but let's forget that for a moment). The Re is about 1.6e5. There is really no way to make a mesh where the elements are bigger then the particles. If I understood correctly, for a Lagrangian solver, the particles have to be smaller then the mesh. I did a test with a straight pipe and a boundary layer (minimum thickness ~1mm, y+ ~200), it works only with small particles. If the particles are big, as soon as they approach the wall, the computation crashes.



I think I have to change solver, maybe an immersed boundary method. But in that case, maybe I will have the opposite problem, when the mesh is too big (far from walls).



Do you have suggestions?



ps. We are way out of topic from the original post, maybe I should open another thread?

You will not find any "normal" solver for what you need.


You need a full CFD-DEM solution.
This is true both for opensource and commercial.


For opensource you can go with https://www.cfdem.com/cfdemrcoupling...-dem-framework


They also have a commercial branch https://www.aspherix-dem.com/
They are quite proffesional and capabale and I would suggest setting up a meeting/demo with them.


For Commercial you have Rocky DEM which is now owned by Ansys.
https://rocky.esss.co/



None of them are cheap, but you are going into a niche of a niche branch of CFD.