Some GEOM module operations are very slow with many surfaces

Hello! Similarly to my latest thread, I am working with a geometry which I have in STL format. I want to define groups of faces for this geometry, but every step takes very long. To reproduce this: Set-up 1. Open Salome and create a cube in the GEOM module [or anything] 2. Go to the MESH module and mesh that cube [triangles, surface only] so that you get around 20'000 faces 3. Export the mesh to STL 4. In the GEOM module load the exported STL Execution 5. Right-click on the loaded shell, select "Create group" 6. Under "Shape type", select faces Here Salome starts hanging, and the operation will take a long time to complete. I tried debugging/profiling this, please find a callgrind log at https://tinyurl.com/4hkkduva . From the log, and also from dumping the stack with eu-stack, it looks like most of the time is taken by SALOME_View:isplay [called by GroupGUI_GroupDlg::activateSelection] which, to my understanding, has to do with updating the OpenCascade viewer -- please correct me if I'm wrong. Even if I wait until this operation is over, all the following ones [selecting cells manually, adding them, removing them, applying...] still take very long. Is there any way to avoid this overhead? What can I do about it? Don't hesitate to let me know if I can provide any further information Thanks for your help!

Hello,

Unfortunately, GEOM does not well suit to work with meshes. Indeed, STL stores data as a set of triangles - it is in fact format to store mesh data, not geometry. It means that each triangle represents a separate face. When STL is imported to GEOM, resulting CAD model is a shell that consists of a large number of faces, even though they belong to the same (few) surfaces. GEOM is not optimized to work with the huge number of sub-shapes - some GUI operations (like creation/editing groups) automatically explode the shape to sub-shapes, to allow manipulating them (select, show/hide, etc). That's why the performance may be mad on such STL import.

Regards,
Vadim.

Hello Vadim, thanks for the reply. I do understand that that is the problem, my question was on whether there is an already implemented way around it. If there isn't any, I wanted to ask the developers if they would be willing to address this issue [by optimising GEOM to work with many sub-shapes]. I understand a thing or two of coding myself, so with some guidance I could try to fix it -- if there is an easy fix to try. Best regards, Massimiliano

No, currently no improvements in this direction. And it is not easy to solve mentioned problems. On the other hand, I believe there should not be many problems working with geometry imported from STL in batch mode - i.e. via scripting.