Hi Peter,
I dug a bit deeper, and the issue is related to the "unification" of surfaces
that is performed after a BooleanUnion operation, through the OpenCASCADE
"ShapeUpgrade_UnifySameDomain" class.
This was added in Gmsh 4.5, and can be deactivated with
gmsh.option.setNumber("Geometry.OCCUnionUnify", 0)
With this your geometry behaves as in Gmsh 4.4.1. It would be nice to update
your report to the OCC folks to let them know that the bad surface is generated
by ShapeUpgrade_UnifySameDomain.
Thanks,
Christophe
import gmsh
import sys
import numpy as np
# set up parameters (eventually will read from file).
# Data from streeter (1977?)
d_epi = 3.77
d_endo = 3.75
l_epi = 0.69
l_endo = 0.49
mu_base = 120.0/180.8*np.pi
# create unit spheres
radius = 1.0
# set CharacteristicLengthMax
char_l_max = 0.2
#char_l_max = 0.06
# my parameters to create the RV
lr_epi = 1.1
lr_endo = 1.05
# derived quantities
a_epi = d_epi*np.cosh(l_epi)
b_epi = d_epi*np.sinh(l_epi)
c_epi = d_epi*np.sinh(lr_epi)
a_endo = d_endo*np.cosh(l_endo)
b_endo = d_endo*np.sinh(l_endo)
c_endo = d_epi*np.sinh(lr_endo)
ra_endo = 0.5*(a_epi+a_endo)
rb_endo = 0.5*(b_epi+b_endo)
# start of main code
gmsh.initialize(sys.argv)
gmsh.model.add("streeter")
# to print errors
gmsh.option.setNumber("General.Terminal", 1)
gmsh.option.setNumber("Geometry.ToleranceBoolean",1.e-4)
gmsh.option.setNumber("Mesh.MshFileVersion",2.2)
gmsh.option.setNumber("Geometry.OCCUnionUnify", 0)
# mesh parameters
gmsh.option.setNumber('Mesh.CharacteristicLengthMax',char_l_max)
# create spheres for left and right blood and blood+tissue regions
# create entire left ventricle
lv_bl = gmsh.model.occ.addSphere(0,0,0, radius, -1, np.pi/2-mu_base,
np.pi/2, 2*np.pi)
gmsh.model.occ.dilate([(3,lv_bl)],0.,0.,0.,b_epi,b_epi,a_epi)
#create left ventricle blood region
lv_bl_tiss = gmsh.model.occ.addSphere(0,0,0, radius, -1, np.pi/2-1.1*mu_base,
np.pi/2, 2*np.pi)
gmsh.model.occ.dilate([(3,lv_bl_tiss)],0.,0.,0.,b_endo,b_endo,a_endo)
# create right ventricle (half ellipsoid)
rv_bl = gmsh.model.occ.addSphere(0,0,0, radius,-1, np.pi/2-mu_base,
np.pi/2, np.pi)
gmsh.model.occ.dilate([(3,rv_bl)],0.,0.,0.,b_epi,c_epi,a_epi)
# create right ventricle blood region
rv_bl_tiss = gmsh.model.occ.addSphere(0,0,0, radius,-1, np.pi/2-1.1*mu_base,
np.pi/2, np.pi)
gmsh.model.occ.dilate([(3,rv_bl_tiss)],0.,0.,0.,rb_endo,c_endo,ra_endo)
# get lv tissue region
lv_tiss, _ = gmsh.model.occ.cut([(3,lv_bl)],[(3,lv_bl_tiss)], -1, True, True)
print('lv_tiss = ',lv_tiss)
# get rv tissue region
rv_tiss, _ = gmsh.model.occ.cut([(3,rv_bl)],[(3,rv_bl_tiss)], -1, True, True)
print('rv_tiss = ',rv_tiss)
# get rv tissue region not in lv
rv_tiss_fin, _ = gmsh.model.occ.cut([rv_tiss],[lv_tiss], -1, True, False)
print('rv_tiss_fin = ',rv_tiss_fin)
gmsh.model.occ.synchronize()
# merge lv and rv tissue regions
tissue, _ = gmsh.model.occ.fuse([lv_tiss],[rv_tiss_fin], -1, True, True)
gmsh.model.occ.synchronize()
#
## uncomment the following line to display the mesh
gmsh.fltk.run()
gmsh.finalize()
> On 12 Mar 2020, at 07:14, Peter Johnston <[email protected]> wrote:
>
> Dear Christophe,
>
> Thanks for your response.
>
> As suggested, I asked a question, using your data, on one of the OCC forums.
> I hope that was the correct thing to do?
>
> However, I do have one further question for you. The python scripts that I
> wrote that use these OCC commands were written about six months ago and I was
> able to produce sensible meshes under gmsh 4.4.1. At least these must have
> been sensible, otherwise my numerical simulations would not have run and
> produced sensible output. Are you using a newer version of OCC than, say,
> when you released gmsh 4.4.1? I don't upgrade my gmsh all that often.
>
> Thanks for your thoughts.
>
> Kind regards,
>
> Peter.
>
> Associate Professor Peter Johnston (FAustMS, FIMA)
> School of Environment and Science
> Griffith University | Nathan | QLD 4111 | Technology (N44) Room 3.19
> T +61 7 373 57748| F +61 7 373 57656 Email [email protected]
> From: Christophe Geuzaine <[email protected]>
> Sent: Wednesday, 11 March 2020 10:42 PM
> To: Peter Johnston <[email protected]>
> Cc: [email protected] <[email protected]>
> Subject: Re: [Gmsh] Strange meshing behaviour
>
>
> Hi Peter,
>
> Interesting. This seems to be a problem with the generation of the geometry,
> not the meshing.
>
> Attached is the .brep file of the buggy surface (debugSurface.brep):
>
> - the OpenCASCADE representation is wrong (see attached picture of the
> OpenCASCADE-produced STL triangulation), which seems to indicate that the
> parametric representation is wrong
>
> - the surface also leads to an incorrect mesh with Gmsh 4.4.1
>
> I would suggest to send the "debugSurface.brep" file to the OpenCASCADE
> developers for further analysis?
>
> Christophe
>
> <bug.png>
>
>
>
> > On 11 Mar 2020, at 12:40, Peter Johnston <[email protected]> wrote:
> >
> > Hello,
> >
> > I have just observed some strange behaviour with my python script running
> > gmsh. Attached is a cut down version of a larger script that used to work
> > under gmsh 4.4.1. This script creates a 3D volume using OCC and contains
> > multiple surfaces. When I mesh the surface (ie use the 2D meshing button on
> > the gui) surface number three gives some strange results; so strange that I
> > cannot create a volume mesh. I have also attached a picture of the mesh on
> > surface 3, indicating the places where the mesh is misbehaving. I am
> > currently using gmsh 4.5.4.
> >
> > (Please note that I had to change the file extension to escape
> > institutional spam filters. It is really a python script.)
> >
> > Any insights would be much appreciated.
> >
> > Thanks very much,
> >
> > Peter.
> >
> > Associate Professor Peter Johnston (FAustMS, FIMA)
> > School of Environment and Science
> > Griffith University | Nathan | QLD 4111 | Technology (N44) Room 3.19
> > T +61 7 373 57748| F +61 7 373 57656 Email [email protected]
> > <gmsh-prob.png><cap_cut.txt>_______________________________________________
> > gmsh mailing list
> > [email protected]
> > https://protect-au.mimecast.com/s/HChgCNLwQEiBWGQEumqCoN?domain=onelab.info
>
> —
> Prof. Christophe Geuzaine
> University of Liege, Electrical Engineering and Computer Science
> http://www.montefiore.ulg.ac.be/~geuzaine
>
>
>
—
Prof. Christophe Geuzaine
University of Liege, Electrical Engineering and Computer Science
http://www.montefiore.ulg.ac.be/~geuzaine
_______________________________________________
gmsh mailing list
[email protected]
http://onelab.info/mailman/listinfo/gmsh
