Hi, I confirm that with the current snapshot available (3.0.7-git-299ed78), I do not have the issue (cf convergence plot of the error vs the number of points on the spline attached)
Thanks again. Matt. 2018-08-06 11:55 GMT+02:00 Christophe Geuzaine <[email protected]>: > > > > On 6 Aug 2018, at 11:50, Matthieu Lecouvez <[email protected]> > wrote: > > > > Hi, > > > > Thanks for you answer. Decreasing the Geometry.Tolerance has no effect > on the result (with the built-in kernel or the OCC kernel). > > > > I think the issue was in OCC_Internals::_addSpline of GMSH. In the > released versions of GMSH (3.0.5, which I use, and 3.0.6), we can only use > the Spline command in gmsh with OCC kernel (mode == 0 in the aforementioned > function). Then GMSH calls the OCC function > GeomAPI_PointsToBSpline(ctrlPoints), > with the default parameters DegMin=3, DegMax=8 (see OCC files > GeomAPI_PointsToBSpline.cdl:46 and GeomAPI_PointsToBSpline.cxx), which > probably lead to the accuracy problem I had. > > > > This is not the case anymore in the master branch of GMSH. The Spline > command now calls the OCC class GeomAPI_Interpolate, as you mentioned, > which is only degree 3 (see OCC file GeomAPI_Interpolate.cxx:711-728), > but we can now also use the BSpline gmsh command with the OCC kernel which > should create a general OCC Geom_BSplineCurve class. > > > > I cannot easily compile GMSH with OCC support, so I will wait for the > next release (do you have any estimated release date?) to check that the > problem is corrected. > > > > Just download the "latest automatic snapshot" from the web site : this is > rebuilt every time a change is made on the master branch. > > Christophe > > > > Anyway, thanks for your great work, it is greatly appreciated! > > > > Matthieu. > > > > > > 2018-07-26 17:46 GMT+02:00 Christophe Geuzaine <[email protected]>: > > > > Hi Matthieu - They are both cubic splines (the built-in kernel uses a > Catmull-Rom splines). Can you try descreasing Geometry.Tolerance to see if > it has an effect? We use that parameter as the tolerance passed to the > OpenCASCADE bspline construction routine (GeomAPI_Interpolate). > > > > Christophe > > > >> On 17 Jul 2018, at 23:44, Matthieu Lecouvez < > [email protected]> wrote: > >> > >> Hi, > >> > >> I am currently doing some tests with the OpenCascade kernel, which is > VERY convenient to build complex geometries thanks to the boolean > operations. > >> > >> However during these experimentation, I came up with a test case where, > for my application (electromagnetic simulations), using either the built-in > kernel or the OCC one leads to different results. Switching the kernel is > simply done by commenting or uncommenting the "SetFactory" command. The > geometry for the (2D) problem cannot be exported but makes use of only > simple elementary entities (Line, Circle, Plane Surface) and some splines > that are the results of optimization processes and thus cannot be described > analytically. > >> > >> After some research, I found that the Spline command leads to two > different type of spline in each kernel (nurbs in the built-in kernel, > bspline in OCC if I'm correct?) > >> > >> From what I understood for the OCC source code, the spline that GMSH > uses in the OCC kernel is simply a third order curve (and NOT a cubic > spline) ? Can someone confirm that? > >> > >> The main issue with this is that providing more points to describe the > spline in the OCC kernel does not improve the accuracy of the spline: > basically the interpolated spline just converges to some curve very quickly > and after only 5 or 6 points adding more points does not help for accuracy. > This is not the behavior of the Spline of the built-in kernel. > >> > >> To show this behavior, I have realized the 1D mesh of a quarter of a > circle described using a Spline (instead of Circle) and a variable number > of points, with both kernels. Then I compute the maximum error |x^2+y^2-1|. > The attached png file shows the evolution of this error versus the number > of points used to described the Spline for each kernel. For the built-in > kernel, the error converges to zero (using more points to describe the > Spline leads to a better accuracy of the geometry), which is not the case > for the OpenCascade kernel. > >> > >> I realize this issue seems to be the wanted behavior (as Spline in OCC > are bspline) but I was wondering if anyone had the same issue, and more > importantly if there is any plan in GMSH and/or OpenCascade to use more > accurate splines with the OCC kernel at some point ? > >> > >> Thanks for reading this (too) long email and for any input you can > provide regarding splines in OCC. > >> > >> Matthieu Lecouvez > >> > >> PS: I can provide the script used for the plot, if anyone is interested. > >> > >> <Max_error_of_R2.png>_______________________________________________ > >> gmsh mailing list > >> [email protected] > >> http://onelab.info/mailman/listinfo/gmsh > > > > — > > Prof. Christophe Geuzaine > > University of Liege, Electrical Engineering and Computer Science > > http://www.montefiore.ulg.ac.be/~geuzaine > > > > Free software: http://gmsh.info | http://getdp.info | http://onelab.info > > > > > > — > Prof. Christophe Geuzaine > University of Liege, Electrical Engineering and Computer Science > http://www.montefiore.ulg.ac.be/~geuzaine > > Free software: http://gmsh.info | http://getdp.info | http://onelab.info > >
_______________________________________________ gmsh mailing list [email protected] http://onelab.info/mailman/listinfo/gmsh
