CFMesh: feature definition or extraction in the .stl file
 

Dear all,
I am launching a stationary mono-phase incompressible optimization and, therefore, I need a robust and fast meshing process with a statistically acceptable first layer thickness no matter (almost) the changes in the CAD shape.
For the CAD I already have a parametric software that can export in the ASCII .stl format but unfortunately without information on patches or edges.

There's no way I am going to use a commercial CAD/mesher and/or more than one mesher per iteration...Therefore I landed to CFMesh.

I just have few simple questions:

1. [I am the only one that after the surfaceGeneratingBoundingBox and the surfaceFeatureEdge cannot pen the newly created .stl file (in paraview) because of missing EOF?
   After the cartesianMesh, the mesh is anyway visible with paraFoam.]

1. [Is there any way to combine surfaceFeatureExtract information (the .eMesh file) to the .stl to be meshed?]

1. [Which opensource CAD software can give me the .fms file? (Please don't answer Salome...it gets too much time for boolean operations on native .stl files)]

Hoping this is the right place where to post these questions,
Thanks a lot for your attention:

Ciao,
Gio

Dear Giovanni,

Sorry, for the late reply.
I have never had problems with the surface mesh after performing surfaceGenerateBoundingBox or surfaceFeatureEdges, and nobody else ever complained about it. Are you confident that your initial input surface is a valid one. Maybe you get some NaN or Inf values during the process, and this may cause unpredictable behaviour.

Currently, it is not possible to import the .eMesh into the meshing process. You can achieve similar by doing surfaceFeatureEdges <inputSurface> <outputSurfaceWithEdges.fms> -angle <angleInDegrees>. This will generate the feature edges, and save them together with the surface into a fms file. The advantage of using fms is that you can store all geometry-related information needed for cfMesh into a single file. We plan to roll out a release soon, with an additional utility which will enable you to export the data from fms into vtk to be able to view it in ParaView. Therefore, you do not need any third-party software to generate a fms file. Just use surfaceFeatureEdges. However, this operation will not generate patches, it only generates the feature-edges entry in the fms file. This option is intended to generate feature edges, and leave the patches intact.

I hope this helps you a bit! Feel free to ask if you need more help!

Kind Regards,

Franjo

Hi,

I hope that I am writing my problem in proper place. I have prepared a wedge shaped model having cyclic boundary at side (curved surface) from combining several surface files. when I am creating .fms file all patches are empty in .fms file and Cartesian mesh stops with error message at the beginning. I could not figure it out, how to solve this. I appreciate any help or advise.

Regards,

Ali

Hello Ali,

Can you please post the error message? I cannot guess what is going on from your description.
How did you generate the fms file?

Kind Regards,

Franjo

Hello Franjo,

Thank you very much for quick reply. I have upload the project file in my dropbox account from where you will find the necessary files. The error message exacly as

*** Error in `cartesianMesh': double free or corruption (!prev): 0x0000000004c50b70 ***

Link: https://www.dropbox.com/sh/8j7rr4nqy...B2xcJjaFa?dl=0

I made the .stl file just copying the individual .stl file content. Then I have used surfaceFeatureEdges to generate .fms file. I need to use cyclic/cyclicAMI boundary condition on both side of the model. I appreciate your help.

Regards,

Ali

Hello Ali,

There are some multi-line comments in the meshDict that are not Ok. The are some /* that are not matched with */.
The other problem is the surface file. I have noticed that the case runs when I use model.stl as the surface mesh. You have nicely defined patches, so you do not need to convert it to fms to preserve feature edges.
Third point, I do not sugest you to use minCellSize options for this geometry. It is not watertight, and it is not suitable for some algorithms in the automatic refinement procedure. I get quite a nice mesh with maxCellSize 0.05; and boundaryCellSize 0.0125;
I hope this helps.

Kind Regards,

Franjo

Hello Franjo,

Thank you very much for details explanation addressing each problem. I have followed your suggestion and got nice mesh. But when I am going to create cyclicAMI patch, both sides (left and right) can not match and failed to create patches. I need a watertight computational domain for analysis and rotational cyclic/cyclicAMI boundary condition on both sides. Is there any option in cfMesh that can be used to preserve the patches as cyclic?


Best Regards,
Ali

Hello Ali,

Unfortunately, there are no options directly applicable to your requirements. You might be able to get what you want by positioning the geometry such that it becomes symmetric to x-y, x-z or y-z planes. This may yield the desirable result if you are lucky.

Kind Regards,

Franjo

Dear Franjo,

Thank you so much for your time and advice. I will think about the computational domain for more simplification.

Best Regards,

Ali

Problems with featureEdges
 

Dear Franjo,

first thank you for making cfMesh an open tool.
I have been using it since its first release in July and I obtained nice results. However there still are some issues I'm not able to solve. In particular I'm speaking about some problems related to feature edge detection in correspondence of very "thin" surface (wing profile trailing edges, propeller blade trailing edge...). Also with very fine local meshes cfMesh is not able to conform to the feature edges (for simplicity I use separate STL files to clearly identify the features) and the mesh has locally a saw tooth shape. In the last release of cfMesh the "enforceGeometryConstraints" sounds like a solution of these kind of probllems. In fact, from a "graphical" point of view the resulting mesh is OK, but checkMesh finds tons of problems (cells with higher non-ortho, skewness, face pyramids problems ...), especially when also boundary layer cells are computed, and the solution seems prohibitive.
Do you have any suggestions?

Thank You,
Stefano

Dear Stefano,

These kind of problems appear when the mesher struggles to choose a patch for a boundary face. You can alleviate the problems by trying the following:
1. Align the edge with the main axes as much as possible.
2. Use cells smaller than the feature size.
3. Get rid of sharp angles at the trailing edge by cutting it off. Please check the page 25 of this tutorial http://www.dicat.unige.it/guerrero/o...rkflow_cad.pdf

enforceGeometryConstraints is an option implemented to stop the meshing process if all geometry constraints cannot be resolved properly. It writes the current state of the mesh before it failed to resolve all constraints.

Kind Regards,

Franjo

Dear Franjo,
thank you for your quick answer.
I know the work by Joel Guerrero on OpenFoam (he's a colleague of mine, just another Department at the University of Genoa) and I will try to defeature my geometries.
Sometimes I use to work with StarCCM+ and when I switch to snappyHex or similar tools I regret the simple and generally accurate capabilities of StarCCM+ (except the latest release!) to generate meshes conform to feature lines! (of course teh global quality of the mesh is awful, at least for openFoam standards, but the surfaces looks like wat you want!)

Thank You again,
Stefano