[Gmsh] Silently created boundary entities

Mon Dec 14 23:47:38 CET 2020

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).

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?

Best,
Stephen

-----Original Message-----
From: Christophe Geuzaine <cgeuzaine at uliege.be> 
Sent: Tuesday, 15 December 2020 4:04 AM
To: Banks, Stephen (Energy, Clayton North) <Stephen.Banks at csiro.au>
Cc: gmsh at onelab.info
Subject: Re: [Gmsh] Silently created boundary entities

Hi Stephen,

> On 14 Dec 2020, at 13:44, Banks, Stephen (Energy, Clayton North) <Stephen.Banks at 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 at 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 at 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