[seaspray]

Pete,

It might have got easier in the more recent versions. In a nutshell, you mesh your volume with a suitable algorithm (tets or hexa i,j,k) and viscous layers are added as an "additional hypothesis" in the 3D algorithm settings. In there, you have the option of excluding some faces in your geometry, like inlet, outlet, but also areas where you don't care as much about flow modeling like in some multiphase flow computations. Layers are not available with all meshing algorithms.

Otherwise you just set your 2D and 1D meshing parameters the normal way.

If you then submesh a face with different parameters (quadrangles for example) and this face has viscous layers, they should retain the structure of the face.

Salome can grow very nice viscous layers, but there is a known bug in the current version 7.3.0 that crashed the layer algorithm at the start for me. It is fixed in 7.4.0 due to come out any time now I was told.

Have a look, and I could put an example together for you if it helps.

Regards,

Eric

[bennn]

Hi Eric,

I'm using Salome a lot for 2D meshes with cfdmsh plugin, but I could never manage to get decent BL for 3D meshes. Can you give further explanation on your strategy ?

I also think Salome is a great software.

[seaspray]

Hello Benoit,

I obtained nice layers on some trivial 3D shapes when I was trying to assess whether I could use Salome, but when I introduced actual geometries, I ran into reliability issues with layers as well as most everything else in the meshing plug-in that essentially marked the end of any further attempts. Even the tet-meshers fail easily, there are huge issues with mapping interfaces to build hybrid meshes, etc.

I stripped down and simplified a first 5 bug cases I tried reporting on a Salome platform forum and also tried to contact someone who supports the meshing algorithms, but in the absence of any response I was forced to start looking at using a commercial meshing package instead. It is not workable.
It is a shame, because the potential of the Salome package is huge. The geometry module is very good and the Python scripting ability would place it well ahead of some of the biggest brand names out there stuck with ugly Tcl... if only it could mesh reliably.
Only way to make it work at present is licensing some of the MeshGems plug-ins I was told - this is the pathway for serious work. In my case, the package I would need is still being integrated for Salome.

The transition from 7.3.0 to 7.4.0 fixed a few issues, and only "modified" many others or left them unchanged.

The inability to mesh "real" geometries properly seems to be the #1 obstacle to advanced open-source engineering (and especially CFD) at present. There are outstanding solvers and post-processors and more effort seems to go into solvers all the time - but in the meanwhile you can't prepare a case for solving, so they are only useful to the few who can "borrow" a suitable commercial mesher to bridge the gap.

I also found it interesting to see that there are a few commercial algorithms out there achieving what OpenFOAM snappyHexMesh should with very few configuration parameters and hugely greater success. Sometimes I wish I had plenty of free time to have a crack at writing such a cut-cell mesher from the ground up, using IGES/NURBS geometry as an input - i.e. explicitly identified features, rather than a huge bag of triangular STL facets.

I wish I could be of more help, but this is where I got after fighting the meshing battle on and off for about 4 months. I can see it coming right shortly now, but it won't be open-source.

I will be keeping an eye on Salome however. I like it.

Best regards,

Eric

[bennn]

Thanks a lot for this thorough reporting.

May I ask what meshing tool you will most likely end up using ?

Also what do you have in mind : "there are a few commercial algorithms out there achieving what OpenFOAM snappyHexMesh should with very few configuration parameters and hugely greater success"

I used to work on Hexpress, which is an octree mesher and was very stable and efficient for BLs, which makes me believe there is a way for SHM to become a great tool some day.

[pbachant]

I am having reasonable success with snappy these days. It's very sensitive to its input parameters, the background mesh, etc., however, so I may not be able to do a grid dependence study... because I can't create enough grids!

I've tried SALOME a little, and it does seem promising, but the interface is a bit confusing.

I tried enGrid, which also seemed promising for creating prism boundary layers, but ultimately I gave up because I couldn't find enough documentation.

For commercial meshers, I did a trial of Pointwise. It seems that it can create any grid your heart may desire, but I don't think the interface is as polished as it should be for the price. I don't like that it has its own scripting language (based on Tcl) rather than Python. Native export to OpenFOAM is available, but to do a cyclicAMI case some things need to be modified after the fact. It's such a simple modification that it's strange it couldn't be built into Pointwise in short time. Their support was very good though, which makes me wish they would operate on the open source (e.g. OpenFOAM, Kitware) business model. Users could fix things like the AMI export, writing a Python wrapper to the Tcl scripting etc. There's also the fact that if you're working in academic research you want your work to be reproducible, and keeping expensive closed-source software out of the chain helps in that respect.

[seaspray]

Originally Posted by bennn

Thanks a lot for this thorough reporting.

May I ask what meshing tool you will most likely end up using ?

Also what do you have in mind : "there are a few commercial algorithms out there achieving what OpenFOAM snappyHexMesh should with very few configuration parameters and hugely greater success"

I used to work on Hexpress, which is an octree mesher and was very stable and efficient for BLs, which makes me believe there is a way for SHM to become a great tool some day.

I can only add a bit to Pete's reply. I was unable to do mesh convergence studies with SHM either, precisely because I couldn't produce enough meshes for that, the slightest change to anything caused the whole setup to fall to pieces.
Producing some meshes for non-trivial geometry can be successful, especially if no BLs are involved, but usually at the expense of considerable aggravation. Knowing SHM does help a lot, but it doesn't solve algorithm stability issues.

As you say, technically, there is no reason why SHM can't work much better than it does, based on the performance of other meshers operating on a similar principle. What I am wondering when I look at the unreal list of configuration parameters that developed over time (and the number of years the utility has been around) is whether it is a matter of continuing, backtracking or restarting from a clean slate. Take the obscure nGrow parameter for example, in all my cases, any value other than zero in there just wiped out all my layers. I can't make any sense of it.
The layers algorithm essentially needs to offset a 3D surface by a given distance to obtain the outer cell faces. Any 3D CAD package does that. It plays up in the most abject ways with a simple fully convex curved shape, the layer(s) collapse back into the wall, reappear a little further... improve, restart or walk away?
Besides this, unreleased work has been done with overset grids for OpenFOAM, with unknown results.

Because of the Python scripting ability, batch operation mode and UI already available in Salome, I would be tempted to say that writing a cut-cell mesher with BL capability for Salome could be a better investment in time and effort than trying to fix SHM.

I have investigated several commercial meshers in the last 5 weeks in terms of suitability for auto-meshing a hull geometry with viscous layers and anisotropic refinement of the free-surface region.
They generally were very good and stable meshers, but many were also unable to produce the mesh I want. Some could only grow viscous layers in a tetrahedral mesh for example. Some were able to generate a usable mesh, but typically with huge numbers of cells in regions completely devoid of any flow features (structured meshes with very visual geometry blocking approach, very common in hydrodynamic studies). Some would only handle isotropic cell refinement, which is not workable for capturing a free-surface. Some weren't practically scriptable, or documentation was abysmal.

The problem is in fact more demanding than it seems at a first glance.

I think that Hexpress could be an excellent bet if anisotropic free-surface refinement is possible. Star-CCM+ contains a powerful Java-scriptable mesher that can handle anisotropic refinement. MeshGems (Distene) in France have attractive algorithms, some being available for Salome, but not the one I would need. There is a powerful cutcell mesher in Fluent, but I am unsure about scriptability and other aspects. Several others were non-starters for the reasons mentioned above. Sometimes, gaining access to the product is problematic.

[bennn]

Hi everyone,

I just heard about cfMesh from creative fields, and I have to say that it is very impressive. It is an opensource octree algorithm and right now all the meshes that I could never figure out with SHM could be meshed with cfMesh at first try. I've been increasing boundary layer to 25+ layers. Almost too good to be true !

[pbachant]

Originally Posted by bennn

Hi everyone,

I just heard about cfMesh from creative fields, and I have to say that it is very impressive. It is an opensource octree algorithm and right now all the meshes that I could never figure out with SHM could be meshed with cfMesh at first try. I've been increasing boundary layer to 25+ layers. Almost too good to be true !

I just started playing around with cfMesh myself. It looks like the procedure is a bit different, i.e., all geometry (including patch names) goes in a single file (*.fms preferred?), rather than carving multiple triangulated surfaces out of a background mesh created with blockMesh. It that correct?

[bennn]

You can feed in a stl file with different elements in them. fms or ftr is preferred, and makes smaller files. ftr can be obtained with surfaceConvert.

the feature extraction is done with surfaceFeatureEdge. However I got better results when actually separating different faces in my stl file. That way every shared edge between faces is treated as a feature edge and forced to snap.

One other thing is that cfMesh needs a fluid domain, whereas SHM substracts the solid CAD from a pre-existing mesh. However you can use surfaceGenerateBoundingBox to get the fluid domain from the CAD of your solid.

[seaspray]

I have manually crafted a STL file this way indeed, by STL-meshing each patch in CAD, naming the solid-endsolid entities and concatenating the lot.
The mesher complains that the geometry is non-manifold if the vertices don't coincide at the patch boundaries and this doesn't help the volume meshing either afterwards.

If the STL mesh is watertight, meshing efficiency is phenomenal. It already uses SMP multi-threading without any explicit domain decomposition required and it loaded all the available cores to 100% on my i7 CPU. It gave acceleration factors of 4-5. Mesh quality is very high too.

I still need to find an efficient way of coming up with a good input file without manually splitting and fixing up a watertight STL mesh. As Benoit pointed out, preserving the topology into the STL also takes care of the feature lines and gives sharp corners.

One missing feature for me is anisotropic mesh refinement. Being able to specify 1D or 2D refinement only for cartesian meshes in the objectRefinements sub-dictionary would allow dealing with free-surface capture.
I have had a look into the sources and such a refinement pattern would violate the underlying octree structure, so my optimism in this direction is limited. If I was able to obtain thin flat cells in the free-surface region, I could probably leave the commercial meshers alone now.

It is very early days, but this code is incredibly promising.

[pbachant]

I ended up getting cartesianMesh to create an okay mesh by combining my device (vertical axis turbine) and an STL of a box-like domain using MeshLab. I then used surfaceFeatureEdge to extract the features. Unfortunately this creates a bunch of extra patches, so I identified these manually and ran createPatch to combine/rename them (there's probably a smarter way to do this). I successfully used snappy afterwards to carve out a cyclicAMI boundary. So... it can work for my application. However, after trying to up the layers to 18, the meshing takes about as long as snappy but with less success. The layers were all over the place in terms of thickness, and mesh quality was not so good. I've actually managed to get a couple snappy meshes to work--possibly enough for a grid convergence study, though, so maybe there is hope after all.

[franjo_j]

Hi everyone,

I am the author of cfMesh, and I want to thank you for trying the tool.
From my experience, boundary layer meshing is quite difficult, and it depends a lot on the quality of the input geometry. The problem get worse as the first layer get thinner. In cfMesh, there exists a possibility to specify an upper bound on the thickness of the first boundary layer. If you want to get Y++ value below a given threshold it is possible to calculate the first layer thickness as y = (Y+ * kinematicViscosity) / sqrt(shearSress). The rule of the thumb, the total thickness of the boundary layer is approximately equal to the cell size at the boundary.
cfMesh is agressive in getting rid of inverted face normals, high non-orthogonality and skewness, and it sometimes moves vertices inside the boundary layer to get rid of inverted faces. I would be grateful if you could provide me some cases and help to improve the layers further.
Regarding the anisotropic refinement, there are various possibilities to implement that feature. What is the preferred way of setting up an anisotropic interface? Primitive shapes (planee, box, etc)? Surface meshes?

Kind Regards,

Franjo

[pbachant]

Franjo,

Thanks for writing this software! I just put up a test case, which meshes a 3D airfoil, creating a boundary layer, at https://github.com/petebachant/foilInBox-cfMesh. As you can see, the layers march out from the surface in a jagged way. I have no idea how to fix this, but I hope this case can be useful for testing.

[seaspray]

Franjo,

Fantastic effort, many thanks for releasing your code as open source.

Regarding anisotropic refinement, basic shapes would be very adequate in my view. For my application, even just a hexagonal refinement box aligned with the coordinate system would be sufficient. The ability to perform successive refinements would be essential, like sequentially refining following the entries in a dictionary. It is also an easy way of achieving gradual refinement.

Boundary layers are also essential to me. I have caused the present algorithm to fail completely the other day by trying with a basic fuselage and wing geometry I had around. I should be able to recreate that case and upload it for you.
In all situations where attached flow cannot be guaranteed, the velocity profile assumed in wall function implementations can be violated and the use of wall functions becomes invalid. In those instances, the boundary layer must be meshed in many thin layers to be resolved. With ship geometries, I mesh to y+ = 1 to 2 near the stern where boundary layer thickness is maximum and risk of flow separation is highest. This leads a very thin first layer and it is also very important for resolving viscous forces. I can't place the entire boundary layer in the first cell.

For whatever it is worth, in the past I used a strategy where I only ever inflated a single thick layer of cells from the surface (total thickness of all layers), and then iteratively refined this layer rather than trying to grow consecutive layers. It was more successful because is it didn't compound problems and errors outwards.

I understand the temptation of dipping into a layer to resolve cell quality issues, but this is extremely harmful and destroys the boundary layer mesh. The other effect it has is that the outcome from the meshing becomes completely unpredictable and visual inspection is needed each time to verify that the layers are present and intact.
I tend to think that the offset surface should be "untouchable" no matter what, the algorithm needs to work within the layer by merging or reconfiguring baffles only. I would much rather have larger cells of the correct thickness in the layers than damaged layers.

Best regards,

Eric

[bennn]

Originally Posted by pbachant

Franjo,

Thanks for writing this software! I just put up a test case, which meshes a 3D airfoil, creating a boundary layer, at https://github.com/petebachant/foilInBox-cfMesh. As you can see, the layers march out from the surface in a jagged way. I have no idea how to fix this, but I hope this case can be useful for testing.

Hi Pete,

I just tried meshing your case. I suggest having the TE as a separate patch, which will make the mesh snap at the edge between the foil and the trailing edge. As far as I understood from Franjo explanations, every edge that is shared by two separately defined shape in the CAD file are treated as featured edges. This is actually what surfaceFeatureEdges does, split the initial CAD files several shapes. On my cases, I try defining separate solid whenever I can when building my CAD files, instead of relying upon surfaceFeatureEdges.

You will also need to Increase the refinement at trailing edge, either by box refinement or by patch refinement. This will improve the snapping step.

[seaspray]

I have uploaded here a stripped down test case showing how far I have got experimenting with cfMesh using the type of geometries I need to mesh.
Note the damaged hull boundary surface and uneven viscous layers. A smaller number of layers can prevent damage to the input geometry, but this would not be satisfactory for solving.

Controlling layers thickness seems to become more problematic if the cell size around the geometry changes; here I disabled automatic refinement near features and uniformly refined near the HULL patch to alleviate such issues.

Vertical refinement of the free-surface region is the other obstacle at present for pursuing. I have been considering schemes merging a cfMesh mesh around the hull with a blockMesh mesh with a refined free-surface for the rest of the domain, but I haven't progressed down this pathway and it would only be a workaround.

Still - it is not that far off the mark, cfMesh is only in its initial release state and only took two minutes to build the mesh!

Eric

[franjo_j]

Dear Eric,

Sorry for the late reply. I was offline for a couple of days due to a lightning struck.
Thank you for uploading your geometry.
I have found the cause of the problem and will start working on it soon. It is of high priority for me, and will try to resolve it as soon as possible.

Regards,

Franjo

[pbachant]

Originally Posted by bennn

Hi Pete,

I just tried meshing your case. I suggest having the TE as a separate patch, which will make the mesh snap at the edge between the foil and the trailing edge. As far as I understood from Franjo explanations, every edge that is shared by two separately defined shape in the CAD file are treated as featured edges. This is actually what surfaceFeatureEdges does, split the initial CAD files several shapes. On my cases, I try defining separate solid whenever I can when building my CAD files, instead of relying upon surfaceFeatureEdges.

You will also need to Increase the refinement at trailing edge, either by box refinement or by patch refinement. This will improve the snapping step.

Right now the trailing edge is rounded off. Would you recommend making it flat, so there's a defined edge between it and the remaining foil surfaces?

On a side note, what CAD software do you use that allows defining separate solids? I am using SolidWorks, and it seems I can only create a single body.

[seaspray]

Dear Franjo,

I certainly wouldn't expect you to drop everything to alter cfMesh. If you wish to improve and develop it further, I would be very happy to push further towards using it in my research and send back to you any issues as they arise.

Regards,

Eric

[vonboett]

dear all,

I had good experience with the refineWallLayerSmart utility, that yust refines based upon the wanted y+ value.