[Gmsh] Spline with built-in kernel versus OpenCascade kernel
matthieu.lecouvez at gmail.com
Tue Aug 7 18:41:21 CEST 2018
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)
2018-08-06 11:55 GMT+02:00 Christophe Geuzaine <cgeuzaine at uliege.be>:
> > On 6 Aug 2018, at 11:50, Matthieu Lecouvez <matthieu.lecouvez at gmail.com>
> > 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.
> > Anyway, thanks for your great work, it is greatly appreciated!
> > Matthieu.
> > 2018-07-26 17:46 GMT+02:00 Christophe Geuzaine <cgeuzaine at uliege.be>:
> > 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 <
> matthieu.lecouvez at gmail.com> wrote:
> >> Hi,
> >> I am currently doing some tests with the OpenCascade kernel, which is
> VERY convenient to build complex geometries thanks to the boolean
> >> 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
> >> 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
> >> 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
> > Free software: http://gmsh.info | http://getdp.info | http://onelab.info
> Prof. Christophe Geuzaine
> University of Liege, Electrical Engineering and Computer Science
> Free software: http://gmsh.info | http://getdp.info | http://onelab.info
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 64555 bytes
Desc: not available
More information about the gmsh