<div dir="ltr">Hi,<div><br></div><div>I am currently doing some tests with the OpenCascade kernel, which is VERY convenient to build complex geometries thanks to the boolean operations.</div><div><br></div><div>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.</div><div><br></div><div>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?)</div><div><br></div><div>>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?</div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>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 ?</div><div><br></div><div>Thanks for reading this (too) long email and for any input you can provide regarding splines in OCC.</div><div><br></div><div>Matthieu Lecouvez</div><div><br></div><div>PS: I can provide the script used for the plot, if anyone is interested.</div><div><br></div></div>