Attach an own mesher to OCC

Dear all,

is it possible to reprogramm the internal mesher or attach a completely new mesher to OCC?

I would like to generate meshes for each TopoDS_FAce with more control on edge size, aspect ratio and so on.

For OCC versions prior to 6.3 I just changed the internal call to triangle but since triangle was removed I am no longer sure how it is currently working.

Thank you in advance for any feedback,

Regards,
Joachim

Roman Lygin's picture

Joachim,

Yes, you can provide your own mesher to substitute BRepMesh_IncrementalMesh (which is default).
As of 6.3.0, Open CASCADE provides a plugin architecture for that. Release Notes do mention that but apparently User's Guide does not uncover details.

Here is what you should do:
1. Subclass you meshing algorithm from BRepMesh_DiscretRoot and redefine its Perform() method using already saved shapes and parameters (deflection, angle, etc + optionally your own). This class must be located in a library (not executable)
1a. For convenience, it must also contain a static method
static Standard_Integer Discret (const TopoDS_Shape& theShape,
const Standard_Real theDeflection,
const Standard_Real theAngle,
BRepMesh_PDiscretRoot& theAlgo);

that will create an instance of your mesher using specified parameters. For instance:
Standard_Integer ExchangerLib_Mesher::Discret (const TopoDS_Shape& theShape,
const Standard_Real theDeflection,
const Standard_Real theAngle,
BRepMesh_PDiscretRoot& theAlgo)
{
theAlgo = new ExchangerLib_Mesher (theShape, theDeflection, theAngle);
return 0;
}
Alternatively, you must have another class with such static method.

2. Use DISCRETALGO macro defined in BRepMesh_PluginMacro.hxx to create a C function and export it. Its argument is a class that has above Discret() static method.

DISCRETPLUGIN(ExchangerLib_Mesher)

3. In your application, before it starts tessellating any shape specify your mesher as a new default using BRepMesh_DiscretFactory::SetDefaultName(). For example:
BRepMesh_DiscretFactory::Get().SetDefaultName (ExchangerLib_Mesher::LibName());
where argument is a name of the dynamic library that exports your function defined at step 2 above, without prefix and suffix (e.g. MyLib for libMyLib.so or MyLib.dll).

This will make it work.

However internal implementation is not optimal and has several issues (these are only those I noticed, in the order of decreasing severity):
a. It reveals big performance problems. If you have to visualize many individual shapes you will definitively notice that. The root-cause is that every time the framework employs OSD_SharedLibrary trying to load the library and resolve the symbol.
b. It does not provide a way to pass your own extra arguments to the mesher. The code assumes that only parameters available in Prs3d_Drawer will be used (deflection and angle) which is not a valid assumption.
c. Only one mesher at a time - you cannot tessellate shapes using different meshers in one AIS_InteractiveContext.

Alternative, more flexible solution would be to have Factory use some cache (as hash table or data map) that would store registered meshers and could dynamically select between them. The mesher would provide either a copy constructor or a Factory method (see Design Patterns) in order to fastly clone itself. But I have not really deeply thought of it (and I currently switched off a custom mesher).

Hope this helps.
Roman
---
opencascade.blogspot.com - the Open CASCADE blog
www.cadexchanger.com - CAD Exchanger, your 3D data translator

dvdjimmy's picture

Good morning Roman,

thank you for your detailed reply. Now its clear how to implement the mesher.

I think we will still do it a little bit different. Maybe you can tell me your opinion on it.

For the open source project FreeCAD we would like to implement a FE workbench. We use the CAD surfaces to allow the user to directly apply boundary conditions or forces on TopoDS_Faces or Topo_Edges. Afterwards we want to use netgen to generate a high quality mesh for us. This is something that should already work with nglib. Now comes the tricky part to map the generated mesh vertices and triangles to the corresponding TopoDS_FAces and Edges. The result of the mapping could be a struct where the ID of the TopoDS_Face and all the Nodes and triangles from the mesh which belong to it are referenced.

This way we wont have to dig into cascade too much and still can use a high quality mesh for our purposes.

Do you have a good idea how to do a fast and reliable mapping of the mesh nodes and triangles back to the TopoDS_Shape structure?

Best regards,
Joachim

dvdjimmy's picture

Hello again,

I am still stuck with my mesher problem. Roman, I have seen in your blog that your File Conversion utility also has an option to vary the visualisation mesh quality. Could you please share some information how you did it? Is everything done with OCC6.3 tools or did you develop own tools or algos for it? Of course, if anybody else can give some helpful feedback I would appreciate it a lot.

For the beginning this would at least help me to generate a high quality representation on screen. Of course the fine mesh is also much better suited to use it for FE calculation purposes.

Maybe I have to take special care of the deflection parameter which is required for the mesh as this seems to be the only input paramter available for the mesher.

thank you in advance for any kind of help.

With best regards,

Joachim

StefanKunze's picture

Hi... I´m currently doing also research on the mesher. As far as I can say you can directly call
BRepMesh_FastDiscret like that f.e.

BRepMesh_FastDiscret lFastDiscretise(MESHING_DEFLECTION,lFace,lBoundingBox,MESHING_ANGLE,0,1,0,0);

BRepMesh::Mesh(shape,deflection) does interally the same but with fast discret you have more options.

Pierre Juillard's picture

Hi all!

I don't know if it can help, but maybe you should have a look at GMSH documentation or sources, or ask to its mailing list.

GMSH: http://www.geuz.org/gmsh/
documentation: http://www.geuz.org/gmsh/#Documentation
sources: http://www.geuz.org/gmsh/src/

This open source mesher is based on the OCC library, and implements its own meshing algorithms, as well as netgen (would I know that it is feasible, I would recommend to integrate GMSH directly into FreeCAD as their data model are both based on OCC's BREP to handle geometries).

Also, it can then output MED files to be used in Code_Aster...

Regards,

Pierre Juillard's picture

... also it can read them back and offers thus a pre/post processing interface for Code_Aster without having all the dependcy troubles with Salome...

dvdjimmy's picture

Hello together,

@Stefan: Thank you for the suggestion within OCC. I think for the visualisation this might be a good way to control the quality a little bit better. Maybe Roman can also comment on this as he had to solve this problem as well :)

@yohplala: I already thought of GMSH and maybe this is really a good option for our FE integration. Especially the Code Aster integration and the netgen integration makes it very convenient. Are you already using GMSH?

Best regards,
Joachim

Pierre Juillard's picture

Hi Joachim,

I tried GMSH just a bit, but in the end, as it is to carry out computations within Code_Aster, I jumped directly to "SALOME-MECA-2009.1.GPL" (release available on CAELinux: http://caelinux.com/CMS/index.php?option=com_content&task=category&secti...).

The integration with Code_Aster goes a step further.
Once you have a MED file (containing a mesh), before starting a Code_Aster computation, you still need a .comm file which is an ASCII file and which describes your material data, boundary conditions, loadings and basically what you want to do (implicit or explicit integration scheme, modal analysis, thermal anlysis, mechanical analysis...)

In GMSH, you can draw simple CAD and mesh them and finally have a MED file.
In SALOME_MECA, in addition to the GEOM module to draw CAD, the SMESH module to mesh (also including netgen, as well as other modules and GMSH algorithms are also foreseen there), there directly is the Code_Aster module in which you setup:
- the .comm file through the EFICAS utility: it basically has a dictionary of all the keywords a .comm file may contain, but also the description of the arguments these keywords may wait for, and so on.. It checks the validty of the .comm file you write. Writing a .comm with EFICAS is thus much easier than writing it in a text editor.
- the arguments to start the computation (memory, number of CPUs) and you can finally click on "Solve the Code_Aster case"...

As everything is packed in SALOME_MECA, I thus jumped to SALOME_MECA.

I already asked this in the FreeCAD forum and had negative answers from the FreeCAD team, but it really seems to me that it is much more interesting to integrate FreeCAD in SALOME_MECA (and benefiting from the exiting meshing algorithms, and Code_Aster, and YACS (to oneday achieve parameteric CAD optimization!) and Code_Saturne, and so on... than the other way integrating everything in FreeCAD...

Jürgen answered me that everything was in french and non-understandable with which I don't completely agree.

In this power point focusing on the component model for computation (integration of Code_Aster, Code_Saturne and so on...), you can have a sketch of the Salome organization p.12 (http://www.compframe.org/cbhpc2008/CBHPC08_Presentation/content/slides/0...)

One notices that one should focus on the Salome GUI and Salome Kernel to integrate a new CAD module.
The interesting points are that Salome makes use of OCC, Qt and python, just like FreeCAD, so it is all the more encouraging.

And documentation for GUI and Kernel are in english:
- GUI: http://www.salome-platform.org/ex/doc5.1.2/GUI/doc/salome/gui/GUI/index....
- Kernel: http://www.salome-platform.org/ex/doc5.1.2/KERNEL/doc/salome/gui/KERNEL/...

Regards,

Yoh

Pierre Juillard's picture

Thinking of it, I don't criticize the FreeCAD Workbench facility.

It is for sure a very convenient tool to create additional modules such as:
- a module to fold a geometry
- a module easing the task of drawing stamping tools for press
- a module easing the taske of drawing a auto skins
... modules that are related to CAD and are based on a CAD model data.

But once getting interested in FE computation, the needed model data gets far more complcated and finally it takes years of engineers to build an integration platform such as Salome...

Regards,

Yoh

Pierre Juillard's picture

And also one of Jürgen's argument was that in FreeCAD, the FE Workbench would only target basic FE applications.

However, I see a contradiction.

FreeCAD will as I understand it, be a key open source CAD application to handle assemblies (building of assemblies through a tree, use of a constraint solver, use of python to manage parametric CAD properties, and so on...), which is not the GEOM module...

However, you simply can't have "basic" FE applications with assemblies.

I work mainly in this field (evaluation of automotive assembly behaviours (manufacturing and evaluation of in-use properties)) and I can tell you that setting up an FE model for an assembly needs some specific tunings that I don't see achievable in a CAD interface:

- tuning of the contacts between the parts (you can easily spend 80% of the time of building a FE model on this step, and it will be in 99% percent of the cases why your model doesn't converge, more particularly in implicit simulations)

- building of the "assembly elements": spotwelds, linewelds, rivets, bolt... the kind of things you don't re-use from the CAD model because it has to be simplified by for instance beams linking nodes in the mesh... This you really need a specific interface to manage these entities.

This is why the integration of a FE Workbench in a CAD software seems very complex to me.
Dassault never succeeded correctly in Catia V5...

dvdjimmy's picture

Good evening yohplala,

thank you for your comprehensive comments about GMSH, SALOME and your experiences with FE.

I will try to explain in detail the main idea behind the FreeCAD FE workbench and also a little bit my background.

FreeCAD is in fact planned to be an open source alternative to CATIA V5 sometime in the future. This includes mainly workbenches for Part Design, Assembly, Meshing Tools, FE, Drawing and CAM functionality.

Until today we are proceeding quite well for the Part, Meshing Tools, Drawing and CAM modul. A lot of the already implemented functions like surface reconstruction, tool path generation for milling in different variations are yet not covered by the GUI but are already used in production from myself. Also springback compensation algorithms can be found in the code but have to be made visible to the users. In FreeCAD we implemented an own Mesh-Kernel which is very fast and provides a bunch of useful functions like OpenMesh is also offering.
Up to now we use the internal OCC meshing capabilities to generate a visualisation in conjunction with COIN3D. This visualisation does sometimes not look very good and therefore we wanted to tweak our code a little bit to get better visualisation results. So, for this case, its just a matter of viewing quality and performance.
For our algorithms like springback compensation, surface reconstruction its completely different. For these algorithms we need a high quality, homogeneous mesh to let our algorithms do a good job. This is currently not possible with the internal mesher, even if we generate more elements. Therefore a meshing alternative is heavily needed!!

As we reached this point we also spoke about implementing an FE Workbench which offers nearly the same convenience like CATIA V5 but up to now just for simple Part geometrys. NO ASSEMBLYS will be covered in the early steps. As I work with FE tools like Hypermesh, Medina, ABAQUS, LSDYNA everyday I know how much time it costs to really build up a high quality input deck. This of course is not the focus of FreeCAD. FreeCAD is more like ABAQUS CAE: Provide the user a convenient way to mesh its geometry, apply boundary conditions, define loads and generate an input deck which can be detailed further within Hypermesh or any other Pre-Processing tool. Also the solver integration will be limited to CAlculix at the beginning as I use it quite often. Code_Aster should just be an option and as I already used the CAELINUX stuff with Salome I know that FreeCAD should not attempt to rebuild Salome as this is not in the scope of the project.

To really implement a good way to mesh our geometries we also should be able to provide a quad mesher. Does anybody know if GMSH offers something like that. Triangles are good, of course but for FE Quad-Meshers are the tools of choice, even if its still hard for the professional programs to generate Quad-Meshes correctly.

I hope I was able to show you a litte bit the focus of the FreeCAD Team and that some of you are encouraged now to support us and also take part in the project :)

With best regards,
Joachim

Roman Lygin's picture

As usual, be careful with licensing terms.
GMSH is GPL-licensed which makes software linked to it GPL'ed (viral nature of GPL). This should not be an issue for Free CAD which is itself GPL'd. But if, for instance, CAD Exchanger wants to use it as alternative mesher I will have to make special pre-cautions - e.g. to implement it via a special plug-in to avoid the whole application being linked to it. The plug-in itself would have be GPL'ed while CAD Exchanger itself not.

---
opencascade.blogspot.com - the Open CASCADE blog
www.cadexchanger.com - CAD Exchanger, your 3D data translator

dvdjimmy's picture

Hello Roman,

of course, this would be the same issue for FreeCAD, as FreeCAD is LGPL and some people are already using it for production and own inhouse code development which would no longer be possible if we integrate the GMSH code into FreeCAD.

Regards,
Joachim

Roman Lygin's picture

In CAD Exchanger the options dialog allows the user to change the precision which is then translated into deflection parameter which is passed into BRepMesh_IncrementalMesh.

Of course, there is always a trade-off - the more fine your mesh is the larger memory footprint is and the longer it takes to compute. The latter can be specially an issue given that the OCC mesher today is single-threaded and cannot take advantage of multi-core systems :-(.

Beware that nice visualization mesh can be not suitable for FE at all. Most FE algos are sensitive to triangle shapes, and may fail on very elongated triangles visualization mesh produces. As an example, take a cylinder, produce the finest mesh in CAD Exchanger and view it in Triangulation display mode.

Roman
---
opencascade.blogspot.com - the Open CASCADE blog
www.cadexchanger.com - CAD Exchanger, your 3D data translator

dvdjimmy's picture

Good evening again,
as I already wrote in my last post, a collection of different meshing algorithms would be the best solution for us. In ABAQUS CAE for example, based on the CAD data you can do a partitioning of your geometry to identify areas which are possible to mesh with Quad-Meshers or not. Everything else can still be meshed with triangles. The idea is to implement something like this also in FreeCAD to allow the user a sort of algo selection. The problem is that I dont know of any open source quad-mesher yet :(

Best regards,
Joachim

Roman Lygin's picture

Hi Joachim,

I don't see particular problem of mapping TopoDS_Face/_Edge and mesh nodes and elements. In your meshing algorithm that accepts TopoDS_Shape you still likely iterate over faces (and edges) and sample points which are then passed to the mesher. If so, you can record this information into a hash table (map) having TopoDS_Shapes as keys and data structures referring to mesh elements as values.

Open CASCADE itself hard-codes this relationship into BRep_TEdge and BRep_TFace. For instance, the latter contains a handle to Poly_Triangulation data structure that is a tessellated representation itself. You may even reuse these structures and populate them with points produced by your mesher. This will give you possibility to reuse them downstream, e.g. in visualization.

Hope this helps.
Roman
---
opencascade.blogspot.com - the Open CASCADE blog
www.cadexchanger.com - CAD Exchanger, your 3D data translator

dvdjimmy's picture

Dear Roman,

if it would be the case like you write it is possible to do it with a map. Unfortunately we wanted to avoid the Face by Face approach and focus more on the overall approach.
The idea is like this: We transfer our Shape to Netgen for example. Netgen is then doing the meshing with all the optimizations and afterwards of course we will no longer have a nice glue between TopoDS_Face and the mesh nodes and elements :(

We dont want to set any constraints for netgen to allow him generate the best possible mesh with the total geometry. The only constraints necessary from our point of view are the region boundaries of the areas to which we apply load or boundary conditions. Of course, NetGEn should not "erase" these boundaries e.g. TopoDS_Wire as otherwise the mapping will never generate good results.

So did you already try some kind of open source mesher in your application?

With best regards,
Joachim

Pierre Juillard's picture

Hi Joachim,

I thank you very much for our very detailed answer.

Regarding your need of quad meshes, GMSH has some capabilities in this field.

If you see the changelog, you will see that it disappeared for a while but was brought back in the code since 2.3.0.

"2.3.0 (Jan 23, 2009): major graphics and GUI code refactoring; new
full-quad/hexa subdivision algorithm (removed Mesh.RecombineAlgo);
improved automatic transfinite corner selection (now also for
volumes); improved visibility browser; new automatic adaptive
visualization for high-order simplices; modified arrow size, clipping
planes and transform options; many improvements and bug fixes all over
the place."

Now I have to say that when I checked the "full-quad" option in the option windows, and tried to mesh an IGS, it didn't really worked, and then crashed...

Maybe my geometry was not really correct, and I didn't really insisted...

I have an additional question regarding the springback compensation algorithm.
How do you evaluate the springback, i.e. do you carry out a stamping simulation in CalculiX (I'm sorry to be off-topic)?

Regards,

Yoh

dvdjimmy's picture

Hello again,

thank you for the hint with the quad-mesh. At least we can give it a try then :) You are welcome to help us introduce GMSH within FreeCAD :)

Concerning the springback: We have currently implemented a new contact formulation into Calculix and the Hughes-Liu Shell element will also be ready at the end of this week and then we can use calculix directly to evaluate the springback. Until now I did the calculations in LSDYNA and transfered the results back to FreeCAD to do the actual best-fit, measurement, overbending stuff! But my process is up to now not deep drawing, its a process called Incremental Sheet Forming. The springback characteristics are therefore a little bit different but the algo is more or less the same.

Best regards,
Joachim

Pierre Juillard's picture

Hi Joachim,

Ok sure.
But I'm not a developper.
What would you think if I was trying to define correct GMSH configuration to have quad meshes (which parameters on which playing? what values? best meshing step (hierarchy in surface meshing?)?)?

Tell if it can help.
If so, I can work on test cases then.

Regards,

Yoh

dvdjimmy's picture

Good morning yohplala,

this would be just perfect and would help me a lot. What would also be interesting is a partitioning step. To see if its possible to partition a geometry in certain areas for which we can apply different meshing algos within GMSH!

Feel free to contact me to exchange some more detailed informations about the "test" procedures!

Best regards and thanks a lot for your offer!

Joachim