Sat, 09/28/2024 - 09:02
Forums:
In Gmsh I create one point and apply a translate operation 10000 times.
It takes 15 GB memory and 20 seconds. The Gmsh-5-lines script is attached (extension is changed from .geo to .txt). Gmsh 4.13.1 (OCC 7.7.2), Windows 10.
Would you clarify, please, is it a problem of OpenCascade or Gmsh?
Thank you in advance.
Attachments:
Sat, 09/28/2024 - 12:30
Hello, could you please somehow incorporate the code by python or draw or c++?
The issue is strangle and probable related to bug with scope and life time. Probably the translated variable exist on dynamic memory and creates more and more during the loop. And free only after loop breaks.
But that should be not on OCCT Side, on c++ it is a challenge to create bug like that.
Best regards, Dmitrii.
Mon, 09/30/2024 - 19:59
Hello, Dmitrii!
Idea to run C++ code was fruitful. Thanks.
I ran code in VS and got Stack Overflow error. An increase of stack size allows to make more number of translate operations (with huge memory consumption). Will prepare debug library of Gmsh and will trace workflow.
Thank you,
Michael.
Mon, 09/30/2024 - 08:22
Thank you, Dmitrii!
I wrote two small test codes in c++: one uses c-kind functions, other one uses c++-kind functions. Both tests produces the same behaviour. Which, however, is a bit different from previous gmsh's script. But these tests also demonstrate rather large memory consumption and fail silently. Test codes names are occ-c.cpp and occ-cpp.cpp. Also there are two similar tests geo-c and geo-cpp which differ only by using gmsh's built-in kernel. Gmsh functions work without remarks in this test.
The text files are attached to the comment.
All directory with libraries and executables could be downloaded from here: https://disk.yandex.ru/d/GmW0OcwMwMLeZw
Best regards, Michael.
Mon, 09/30/2024 - 08:56
Michael,
This forum is about OCCT - most users have no idea how these gmsh calls are translated to OCCT. I guess you better post your question on GMSH forum first, and maybe then roll-back with more OCCT-related scenario.
And please share code samples directly on the forum rather than through some external service.
Sun, 11/03/2024 - 08:58
Large memory and time consumptions in Gmsh using OCC GK has been disappeared unexpectedly. Nothing special has been made in PC except latest Gmsh 4.13.1 source code installation and debugging in VS2022 and an installation of a precompiled OCC 7.7.0 (instead of 7.6.0). Also, I have traced Gmsh-OCC interface, it looked rather sofisticated (for me). Thank you for advices. Hope, I'll not meet this problem again.Mon, 11/04/2024 - 08:28
The problem of huge time and memory consumption does still exist.
It exists with gmsh.exe and gmsh script:
and with c++ test linked with shared gmsh library:
Both gmsh.exe and c++ test were debuged in VS2022 (Windows 10). The Task Manager shows memory consumption of about 20 GB with large stack size reserved (no any memory leaking were observed). If to reduce stack size both codes meet unhandled exception : Stack Overflow (ntdll.dll). The smaller stack size - the stack overflow occurs sooner (with smaller consumption memory).
Stack Frames are as following:
Gmsh flow execution is as following:
I do not have enough qualification to trace all memory allocations. However, I have noticed that
_attributes->_all
vector ofOCCAttributes
growths with each cycle iteration. It is provided by_attributes->insert(new OCCAttributes(0, transformed, lc));
and_attributes->insert(new OCCAttributes(0, vertex));
.Corresponding codes are
and
I hope it will encourage Gmsh maintainers/developers with possible support of OCC developers (if needed) to fix this behaviour. Sorry for being lazy to build OCC from sources.
P.S. This minimalistic example was discovered trying to draw dynamics of a cloud of particles (what are not at all a CAD purpose). Just trying to avoid other kind of software learning. I have overcome the problem just by switching to gmsh geometrical kernel.
Below is an example of particles cloud.
Wed, 11/06/2024 - 23:51
A use of Debug version of OCC showed a deep (hundreds stack frames) recursion of the
TopLoc_Location TopLoc_Location::Multiplied(const TopLoc_Location& Other) const
inTopLoc_Location.cxx
.Why it could happened for a single geometrical point under simple translation is a deep mystery.
Stack frames picture is attached.
Thu, 11/07/2024 - 00:58
Now it is obvious for me that the program makes a lot of nested locations when it translates the same shape with new and new matrices.
If you don't want the locations to be nested you need to pass the option theCopyGeom of the method Perform of BRepBuilderAPI_Transform as true instead of false.
Fri, 11/08/2024 - 07:32
Great! I just changed in the
OCC::Internals::_transform
in the linetfo->Perform(c,Standard_False)
theStandard_False
to theStandard_True
and the bad behaviours (huge time and memory consumption) have disappeared. Really Great!Possibly, in
gfto->Perform(c,Standard_False)
the second argument is also have to be changed toStandard_True
.I hope, now the OCC branch of Gmsh will be less lazy as it seemed earlier. It is a time to wake-up Christophe.