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.