Parallel OCCT Meshing : how to identify the bad face ?

1 year 1 month ago #4782 by christopher
As far as I can remember there was a problem that some occ routines are not thread safe. They store some caching info in global variables for faster projection or so...
1 year 1 month ago #4823 by Olivier

In my spare time I would like to try to parallelize the 2D part of NetGen, as far as possible.
After some quick investigations into the code, it seams that several elements are obviously not suitable for parallelization.
Appart from OCCT itself, I'm quite sure the Mesh class is not ThreadSafe.

Do you have / can you share the last codebase version of parallelized 2D+3D (the very last one that was not working because of OCCT) ?
I do not want to reinvent the wheel :-)
Thanks !
1 year 1 month ago #4824 by joachim
I am happy to hear you like to help with optimization of parallel meshing. 

First step is profiling, you can easily use vite-tracer also for meshing, (see ) to detect non-parallel or badly scaling regions.


1 year 1 month ago #4825 by Olivier
Thanks for pointers Joachim.

My purpose in not (yet) to optimize the already parallised parts.
My intention is mainly to investigate parallelization of the OCCT surface meshing part in NetGen.
Your team has previously attempted to do such thing, and according to Matthias:

OCC Surface meshing is not parallelized because we had issues with thread-safety in OpenCascade

Being a long time user of OCCT myself, I would like to evaluate where the "thread-safety issues" of OCCT are, and possibly find workarounds, as far as my capabilities go.

The problem is that the current public GitHub version of NetGen, is obviously not the one your team was using when investigating OCCT parallelized surface meshing.
There are indeed several statements in the code, that are only valid in a mono-thread environment (Console outputs, Mesh updates, ...).
Time to create page: 0.121 seconds