[Gmsh] "Re: GMSH parsing is very slow"

[Al Sc]

Dear Christophe,

my example files are scientific data, however originate from processing
certain proprietary 3D models that were shared with me under certain
restrictions. Therefore, it's difficult to share my original file with you.
However, I was indeed able to reproduce the issue using only a slight
modification of your example file!

Compare  the following two files:
test1.geo:
%%% %%% %%% %%% %%% %%% %%% %%% %%% %%%
SetFactory("OpenCASCADE");
Box(1) = {0,0,0, 1,1,1};
For i In {1:1000}
  Point(100+i) = {0.25 + 1e-4*i, 0.1,0.1};
  Point{100+i} In Volume{1};
EndFor
%%% %%% %%% %%% %%% %%% %%% %%% %%% %%%

test2.geo:
%%% %%% %%% %%% %%% %%% %%% %%% %%% %%%
SetFactory("OpenCASCADE");
Box(1) = {0,0,0, 1,1,1};
For i In {1:10000}
  Point(100+i) = {0.25 + 1e-5*i, 0.1,0.1};
  Point{100+i} In Volume{1};
EndFor
%%% %%% %%% %%% %%% %%% %%% %%% %%% %%%

The first file contains 1000 internal pts, and the second one contains 10
times as much.
Now run:
  $ time gmsh -1 test1.geo
    -> Takes 0.88 sec
  $ time gmsh -1 test2.geo
    -> Takes 75 sec
This is a nearly 100 (!!!) times increase in parsing run time, when the
model size is increased by only a factor of 10.
This nicely illustrates what I meant by "quadratic growth of the parsing
run time as a function of the number of internal pts."
As a consequence of this "quadratic growth", the run time for larger models
quickly becomes enormous.

Best regards

A.S.

Am Do., 31. Jan. 2019 um 14:31 Uhr schrieb Christophe Geuzaine <
cgeuzaine at uliege.be>:

>
> Can you send a test file?
>
> I tried this, i.e. adding 1000 embedded points in a volume, and it is
> quite fast (< 2 seconds):
>
> SetFactory("OpenCASCADE");
> Box(1) = {0,0,0, 1,1,1};
> For i In {1:1000}
>   Point(100+i) = {0.25 + 5e-4*i, 0.1,0.1};
>   Point{100+i} In Volume{1};
> EndFor
>
> Maybe you modify the model after each insertion of an embedded point,
> which would force a rebuild of the topological model?
>
> Christophe
>
>
> > On 31 Jan 2019, at 13:04, Al Sc <al.sc.gmsh at gmail.com> wrote:
> >
> > Dear Sir or Madam,
> >
> > some more details on the previously-reported case of extremely slow
> parsing of a gmsh file:
> > The file contains 34795 points -- of which 23041 points are "Point In
> Volume" (e.g. embedded_vertices of a GRegion?). Moreover, it contains 4998
> "Plane Surface"s and one single "Volume". Almost all plane surfaces are
> triangles and quads -- except for <10 facets, which each have a very high
> vertex count (typ. 7000).
> >
> > I found out that if I remove all "Point In Volume" objects, then the
> parsing takes only 20 seconds. However, if all the "Point In Volume"
> objects are not removed, parsing takes around 3000 seconds. This led me to
> the hypothesis that there is some huge inefficiency with parsing gmsh files
> with "Point In Volume" (probably quadratic run time in N(PointInVolume)??).
> >
> > Furthermore, I analyzed the runs using "perf" (linux utility).
> > Run 1 (about 3000 seconds):
> >   $ time perf record ./gmsh-3.0.6-Linux64/bin/gmsh -1 input_orig.geo
> > Run 2 (about 20 seconds):
> >   $ time perf record ./gmsh-3.0.6-Linux64/bin/gmsh -1
> input_no_point_in_volume.geo
> > In Run 1, "perf report" yields the following top-scoring functions:
> >   11.57%  gmsh     gmsh                 [.] GModel::getEdgeByTag
> >    7.73%  gmsh     gmsh                 [.] GEO_Internals::synchronize
> >    6.80%  gmsh     libc-2.12.so         [.] _int_free
> >    6.31%  gmsh     gmsh                 [.] GModel::getVertexByTag
> >    4.91%  gmsh     libc-2.12.so         [.] malloc
> >    4.53%  gmsh     gmsh                 [.] InterpolateCurve
> >    4.40%  gmsh     libstdc++.so.6.0.22  [.] std::_Rb_tree_increment
> >    3.88%  gmsh     libc-2.12.so         [.] memcpy
> >    3.69%  gmsh     gmsh                 [.] List_Nbr
> >    3.35%  gmsh     libc-2.12.so         [.] _int_malloc
> >    3.24%  gmsh     gmsh                 [.] GEntity::GEntity
> >    3.13%  gmsh     gmsh                 [.] avl_lookup
> >    2.63%  gmsh     gmsh                 [.] gmshFace::resetNativePtr
> >    2.53%  gmsh     gmsh                 [.] GEdge::addFace
> >    2.52%  gmsh     gmsh                 [.] CompareVertex
> >    1.97%  gmsh     gmsh                 [.] std::_List_base<GEdge*,
> std::allocator<GEdge*>
> >    1.88%  gmsh     gmsh                 [.] GModel::getFaceByTag
> >    1.76%  gmsh     gmsh                 [.] Tree_Action
> >    1.74%  gmsh     gmsh                 [.] gmshEdge::degenerate
> >    1.63%  gmsh     gmsh                 [.] CompareCurve
> >    1.53%  gmsh     gmsh                 [.] std::_List_base<int,
> std::allocator<int> >::_M
> >    1.38%  gmsh     gmsh                 [.] GModel::deletePhysicalGroups
> >    1.23%  gmsh     gmsh                 [.] std::_List_base<GEdgeSigned,
> std::allocator<GE
> >    1.10%  gmsh     gmsh                 [.] GVertex::addEdge
> >    0.85%  gmsh     gmsh                 [.] List_Read
> >    0.75%  gmsh     gmsh                 [.] GEdge::getBeginVertex
> >    0.73%  gmsh     gmsh                 [.] GFace::computeMeanPlane
> >    0.73%  gmsh     libc-2.12.so         [.] free
> >    0.67%  gmsh     gmsh                 [.] CTX::instance
> >    0.65%  gmsh     gmsh                 [.] gmshEdge::resetMeshAttributes
> >
> > This suggests that maybe GModel::getEdgeByTag is eventually called a
> quadratic number of times in the number of PointInVolume-objects -- and
> this causes the drastic slow-down.
> >
> > Could you please investigate this? Thanks a lot!
> > (As already mentioned, this issue also occurs with gmsh-4.x.x)
> >
> > Best regards
> > A. S.
> > _______________________________________________
> > gmsh mailing list
> > gmsh at onelab.info
> > http://onelab.info/mailman/listinfo/gmsh
>
> —
> Prof. Christophe Geuzaine
> University of Liege, Electrical Engineering and Computer Science
> http://www.montefiore.ulg.ac.be/~geuzaine
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://onelab.info/pipermail/gmsh/attachments/20190131/f860fc47/attachment.html>