This was precisely the point of my example: if you embed the point after each point is created, you force a rebuild of the topology of the model. So the efficient script would be
SetFactory("OpenCASCADE"); Box(1) = {0,0,0, 1,1,1}; N=10000; For i In {1:N} Point(100+i) = {0.25 + 5e-5*i, 0.1,0.1}; EndFor Point{100+1:100+N} In Volume{1}; Christophe > On 31 Jan 2019, at 14:48, Al Sc <al.sc.g...@gmail.com> wrote: > > 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 > <cgeuza...@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.g...@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@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 > > > — Prof. Christophe Geuzaine University of Liege, Electrical Engineering and Computer Science http://www.montefiore.ulg.ac.be/~geuzaine _______________________________________________ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh