Parallel OCCT Meshing : how to identify the bad face ?

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...

Christopher,

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 !

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
docu.ngsolve.org/latest/i-tutorials/unit...ger/taskmanager.html ) to detect non-parallel or badly scaling regions.

Joachim

 

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, ...).