> On 14 Dec 2020, at 23:47, Banks, Stephen (Energy, Clayton North) > <stephen.ba...@csiro.au> wrote: > > Hi Christophe, > > I found gmsh/model/occ/addSurfaceLoop was still successful with sewing = > false after setting Geometry.OCCAutoFix to 0. My surfaces are all created > using gmsh/model/occ/addBSplineSurface, with trim wires > (gmsh/model/occ/addCurveLoop) created from closed loops in parametric space > (i.e. wire3D = false). The segments of the closed loop are > gmsh/model/occ/addBSpline curves in parametric space with boundaries that are > topologically different, but geometrically identical (to within a tolerance). >
Interesting. It's one of the mysteries of OpenCASCADE - I guess that they must check internally that the curves are actually "the same" in some sense. > On a side note, I'm still investigating the cause before raising an issue, > but to let you know, for some cases when I use wire3D = true, I get "Error: > OpenCASCADE exception" reported by the Gmsh logger. It's not very > descriptive, so intend to play around to try to identify what conditions > result in it, unless you are able to shed light? No idea: we report the exception thrown by OpenCASCADE as-is... Christophe > > Best, > Stephen > > > > -----Original Message----- > From: Christophe Geuzaine <cgeuza...@uliege.be> > Sent: Tuesday, 15 December 2020 4:04 AM > To: Banks, Stephen (Energy, Clayton North) <stephen.ba...@csiro.au> > Cc: gmsh@onelab.info > Subject: Re: [Gmsh] Silently created boundary entities > > Hi Stephen, > >> On 14 Dec 2020, at 13:44, Banks, Stephen (Energy, Clayton North) >> <stephen.ba...@csiro.au> wrote: >> >> I have partially addressed my issue. Whilst the GUI seems unable to add a >> volume for my geometry (i.e. after selecting the surfaces that would form a >> closed shell, it doesn’t give me the option to create the volume), the Gmsh >> API succeeds using the gmsh/model/occ/addSurfaceLoop and >> gmsh/model/occ/addVolume functions. Interestingly, the Gmsh API succeeds at >> creating the surface loop regardless of whether the sewing flag is true or >> false, which makes it puzzling why the Gmsh GUI fails. >> > > The Gmsh GUI currently only creates .geo scripts, so indeed you can't > currently "complete" a Python script using the GUI. We will at some point > enable to creation of other languages using the GUI, but that's not available > yet. See https://gitlab.onelab.info/gmsh/gmsh/-/issues/1002 > > >> I don’t think I understand sewing. None of my surfaces are connected by >> topologically identical boundary entities, which I presume to mean having >> common boundary entity tags (it is impossible since the surface boundary >> entities are created automatically, as discussed in my previous email), >> albeit they are connected by geometrically identical boundaries (to within a >> tolerance). If my understanding of “topologically identical” is correct, >> then the Gmsh documentation indicates that if sewing is false then it should >> fail, but it doesn’t. > > Indeed. My guess is that the "Geometry.OCCAutoFix" option (active by default) > manages to "fix" the surface loop in your case (maybe because the boundary > curves are actually bsplines of the same order, with the same control > points). Can you try to set Geometry.OCCAutoFix to 0 and see the result? > >> Moreover, even if I set the geometrical tolerance and Boolean tolerance to >> zero, it still succeeds. One difference I did find was that when the sewing >> flag is true, adding a surface loop appears to duplicate all the surfaces >> involved and their boundaries, whilst having the sewing flag set to false >> does not. Are you able to offer any further explanation to help clarify what >> it means to be “topologically identical”, and clarify whether the sewing >> behaviour I am observing is correct? >> > > The "sewing" option uses the BRepBuilderAPI_Sewing OCC api to explicitly sew > the surfaces together. It's not exactly clear to me when/if ShapeFix_Shell > (applied when when Geometry.OCCAutoFix is set) and BRepBuilderAPI_Sewing > provide the same result in some cases... > > Cheers, > > Christophe > > > >> Regards, >> Stephen >> >> >> From: Banks, Stephen (Energy, Clayton North) >> Sent: Monday, 14 December 2020 5:36 PM >> To: gmsh@onelab.info >> Subject: Silently created boundary entities >> >> Hello, >> >> I am using Gmsh v4.8.0. When I create a NURBS surface by calling the >> gmsh/model/occ/addBSplineSurface function in the Gmsh API, the function >> silently adds points and lines (presumably to create the boundary entities): >> • What is the recommended method to identify these silently added >> entities? Is it to call gmsh/model/occ/getEntities before and after calling >> addBSplineSurface to see what has been added? >> • Is it possible to replace these boundary entities (lines and points) >> so that I can get the topology correct? >> >> After reading the comments in the makeTrimmedSurface() function, found in >> the Gmsh source code file GModelIO_OCC.cpp, I suspect (2) has been attempted >> in the past, but abandoned in preference for relying upon Geometry.Tolerance >> and Geometry.ToleranceBoolean to allow operations to succeed for >> topologically different yet geometrically identical (to within tolerance) >> entities. Is this correct? >> >> My motivation for asking is I have been constructing geometry using the Gmsh >> API OpenCASCADE kernel functions, then synchronising, then >> callinggmsh/fltk/run to experiment with how I should control the Gmsh API. >> For some reason, the FLTK graphical user interface is not allowing me to >> successfully add a volume, which I have presumed to be due to incorrect >> topology (as my original approach for constructing a geometry resulted in >> lots of geometrically identical entities). As such, I have been put in >> effort to avoid geometrically identical entities to get the topology I want, >> but the addBSplineSurface is preventing me from being successful. >> >> Many thanks, >> Stephen >> >> _______________________________________________ >> gmsh mailing list >> gmsh@onelab.info >> http://onelab.info/mailman/listinfo/gmsh > > — > Prof. Christophe Geuzaine > University of Liege, Electrical Engineering and Computer Science > http://people.montefiore.ulg.ac.be/geuzaine > > > > — Prof. Christophe Geuzaine University of Liege, Electrical Engineering and Computer Science http://people.montefiore.ulg.ac.be/geuzaine _______________________________________________ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
