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
_______________________________________________ gmsh mailing list [email protected] http://onelab.info/mailman/listinfo/gmsh
