Re: [Gmsh] Bug?
> On 10 Apr 2020, at 00:12, Jensen, Aaron J. wrote: > > Hi, > > I believe that there is a bug in the coloring algorithm. When I import and > mesh a step file containing colored faces the resulting mesh cannot be > colored by Physical Group. The mesh is instead colored based on the geometry > surface color. > Actually that's the expected behavior in Gmsh - explicit coloring supersedes the other coloring schemes. As a workaround you can set "Mesh.OCCImportLabels" to 0 before loading the STEP file, which will skip the import of labels and colors. > Also, I read that 3D boundary layer meshing may be available in GMSH v5.0. > Is that still the plan and if so when do you expect GMSH v5.0 might be > released? > Hopefully by the end of 2020. Christophe > Thanks for all your hard work on GMSH. It's a fantastic tool. > > Best, > Aaron > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Parallelepiped with hole in the middle
Physical Surface('bottominclined1') = {34};
> Physical Surface('bottom2') = {36};
> Physical Surface('bottominclined2') = {38};
> Physical Surface('bottom3') = {40};
>
> Physical Volume('fluid') = {41};
>
> //
>
> I would be very grateful if you can answer my question!
>
> Kind regards,
> Robert Atanasiu
> Imperial College London, Aeronautics Undergraduate Student
> ___
> gmsh mailing list
> gmsh@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
___
gmsh mailing list
gmsh@onelab.info
http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Geo edges missing after rotation operation
> On 20 Apr 2020, at 14:42, Fahad Sarfraz Butt > wrote: > > Hello GMSH Team: Fahad here > > > > I have built a wind-turbine blade in GMSH using following steps: > > 1. Point coordinates of airfoils distributed along span > > 2. Connecting points using splines to first make airfoils > > 3. Then connecting airfoils through splines running through points along > airfoil surfaces > > I have two questions: > > Question 1) how can I make this blade a solid? I only want the surface of the > blade as a plane or ruled surface and not the individual airfoils. Please > suggest how can I create a solid and a volume in my case? > > Question 2) I rotate and duplicate this blade to generate a rotor of two > blades. Original blade has 259 lines and now after rotation with duplication, > I should have 518 lines but I get 480 lines only as shown by statistics and > also by hovering over the splines I see that tags are missing. Kindly help. > Maybe send an example so we can have a look? Christophe > Thanks > > > > Thanks. > > > > > > > > > _______ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] geo from msh
> On 2 Apr 2020, at 17:46, Octavio Castillo Reyes > wrote: > > Dear gmsh users, > > I hope this question is not too obvious, in which case I apologize. > > I have received a .msh file that I must share as part of some experiments > (especially to reproduce them), however, I do not want to share such a large > file (200mb). the question is: is it possible to generate a .geo file (which > I don't have access to) from a .msh file? > You can't generate a .geo file. If your goal is to remesh the model, you could reparametrize the surface/curve mesh though - see tutorial/t13.geo. Christophe > thanks for your support > > O. > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Saving msh in several parts defined by lists of physical
> On 5 Apr 2020, at 00:32, Michel Cassagnes wrote:
>
> Dear all,
>
> It seems that the option does not exist yet but maybe it has something to do
> with partitioning. Here is my question :
>
> I would like to save mesh (in med format) in several parts that are defined
> by lists of physicals. Some physicals may belong to more than one part.
>
> What I do for now :
> 1 - I prepare a text file that describes a geometry from a cad software (list
> of entities, each entity being described by a list of point coordinates, its
> type and its cad layer)
> 2 - another text file describes the different parts of the geometry, by sets
> of layer names. Some physicals may belong to several parts.
> 3 - then I make geo files from 1 and 2, each geo file contains all geometry
> but only physicals which are to be saved as mesh.
> 4 - Gmsh mesh each geo.files (so I repeat exactly the same meshing for each
> geo file) then I save only mesh entities with physical tag in med format
>
> What I would like to do: Instead of meshing all geo files as in point 3
> above:- mesh in only one time the geo file, containing all geometry
> - then save the mesh in several steps, giving at each step a list of
> physicals that are to be saved.
>
Hello Michel,
You can exploit the fact that by default, when physical groups are defined,
Gmsh only saves the entities that belong to physical groups. So you can just
mesh once, define your physical groups in turn, and save each time. Here's an
example:
---
SetFactory("OpenCASCADE");
Box(1) = {0,0,0, 0.1,1,1};
Box(2) = {0.1,0,0, 0.3,1,1};
Box(3) = {0.4,0,0, 0.6,1,1};
BooleanFragments{ Volume{1,2,3}; Delete; }{}
Mesh 3;
Physical Volume("Left", 1) = {1};
Save "m1.med";
Delete Physicals;
Physical Volume("Middle", 2) = {2};
Save "m2.med";
Delete Physicals;
Physical Volume("Right", 3) = {3};
Save "m3.med";
---
Cheers,
Christophe
> Exemple :
> geo file :
> surfaces : "s1", "s2", "s3"
> points : "p1", "p2"
>
> meshes to save :
> first med file :
> - meshed surfaces : "s1", "s2"
> - points : "p1"
> second med file :
> - meshed surfaces : "s2", "s3"
> - points : "p2"
>
> I hope it is clear !
>
> Best regards,
>
> Michel Cassagnes
>
>
> ___
> gmsh mailing list
> gmsh@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
___
gmsh mailing list
gmsh@onelab.info
http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Mesh error
> On 5 Apr 2020, at 11:25, Sabrina Zacarias > wrote: > > You’re absolutely right, thank you. I’d like to make a follow up question, if > I may (hopefully not as stupid as the previous one): > > In my model I merge several volumes using BooleanUnion. The difficulty is > that after this command, the tags of the surfaces are lost. (And I need them > to define physical surfaces). Is there a workaround or a way of forcing the > tags to not change? Unfortunately no. The best solution for now is to use a combination of 'Boundary', 'CombinedBoundary' and the 'In BoundingBox' command to retrieve the surfaces. Christophe > > What I would like in the end is to have a physical surface which is the group > of all surfaces in the same plane. Is there maybe a smarter way or a built-in > command in which I can achieve this without needing to make a list the list > of all the surfaces by hand? > > Thank you so much for your support, > > Sabrina > -- > Sabrina Zacarias > Institut für Kernphysik > Technische Universität Darmstadt > S2|14 / office 319 > Schlossgartenstr. 9 > > 64289 Darmstadt > > Office: +49 6151 16 23589 > >> On 29. Mar 2020, at 22:28, Christophe Geuzaine wrote: >> >> >> >>> On 29 Mar 2020, at 12:24, Sabrina Zacarias >>> wrote: >>> >>> Dear all, >>> >>> I am a bit confused with the output of the meshing of my model and would >>> really appreciate a piece of advise: >>> >>> My geometry consists of an axial section of a cylinder (which plays the >>> role of the air surrounding my model ) containing several (sections of) >>> rings, which are electrodes, plus two (sections of ) disks, which are the >>> cathode and anode. The fact that these are sections and not complete >>> cylindrical pieces is to make the meshing faster. And the post processing >>> software can handle it. >>> >>> Anyway, In the real model I need to use ~200 electrodes. So far I have >>> not been able to achieve a mesh without errors. I get ‘Unable to recover >>> the edge XX on curve XX (on surface XX )’, and also ’No elements in >>> volume XX’. >>> >> >> With Nel = 200 your geometry is invalid (it auto-intersects), whereas with >> Nel = 20 it is correct. >> >> Christophe >> >> >>> What I find confusing is that when I reduce the number of electrodes x10 >>> lower, without changing anything else, the meshing is correct. >>> >>> I am obviously missing something or not approaching the problem the right >>> way. I attach the .geo files if someone could please take a look. >>> >>> Best regards, >>> >>> Sabrina >>> >>> <3d_main.geo> >>> >>> >>> >>> >>> — >>> Sabrina Zacarias >>> Institut für Kernphysik >>> Technische Universität Darmstadt >>> S2|14 / office 319 >>> Schlossgartenstr. 9 >>> >>> 64289 Darmstadt >>> >>> Office: +49 6151 16 23589 >>> >>> ___ >>> gmsh mailing list >>> gmsh@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 > — Prof. Christophe Geuzaine University of Liege, Electrical Engineering and Computer Science http://www.montefiore.ulg.ac.be/~geuzaine ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Problem meshing a spur gear
> On 31 Mar 2020, at 19:30, Carlos Fernandes > wrote: > > Dear Gmsh community, > > I am Carlos from Portugal. > > I am working with Gmsh API in order to generate the geometry and > automatically mesh spur and helical gears (with a structured mesh). To do so, > I make use of setTransfiniteCurve which works perfectly for a 2D situation > (see attachement 2D). However, when I extrude the geometry using extrude, one > particular area on the tooth doesn't mesh properly (3D_wrong in attachment). > The weird thing is, if I use any other gear geometry or even helical gears, > the mesh works perfectly both on 2D and 3D. If someone could provide me some > hint... > > Another tricky thing that I am facing is making a rotating pattern of the > mesh already done. My ideia is to be able to generate the amount of gear > teeth according with the type of simulation needs. In certain simulations I > use 1 tooth, in others a variable number of tooth up to all the gear (360º). > Is there a particular tool in Gmsh API that is efficient in perform this kind > of pattern? > In your second picture one can see that the middle-right surface has been split in 2 pieces: you will thus need to adapt the number of nodes on the two-part boundary of the middle surface to make sure that the number of nodes match on the left and right sides. And you will need to specify the corners of the transfinite interpolation manually, as the middle surface has more than 4 points on its boundary. See tutorial/python/t6.py for an example. Christophe > Thank you all. > > Best regards, > Carlos Fernandes > <2D.png><3D_wrong.png>___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Variable thickness surface
> On 30 Mar 2020, at 12:57, Julian wrote: > > Hello, > > I am using gmsh for modelling 2D components and I am trying to find out how I > can set a thickness to the plate/shell elements. First I was thinking about > assigning regions of different thicknesses to different physical groups but > by this approach I can specify only a constant value which is not what I need. > > According to this conversation from the mailing list it should be possible. > You can indeed interpolate a function on the 2D mesh; the API allows you to create a "post-processing view" for this quite easily (see e.g. demos/api/view.py). Christophe > Hi Mathieu, > Have a look at the Gmsh Tutorial 7: > http://geuz.org/gmsh/doc/texinfo/gmsh.html#t7_002egeo > HTH > Ruth > Dr. Ir. Ruth V. Sabariego > University of Liege, Electrical Engineering & Computer Science, > Applied & Computational Electromagnetics (ACE), > phone: +32-4-3663737 - fax: +32-4-3662910 - http://ace.montefiore.ulg.ac.be/ > > On 13 Oct 2011, at 12:27, Mathieu ARQUIER wrote: > > Hello, > > First of all, thank you very much for developing GMSH !!! I used it for > several years now as pre-processor to create meshes for my structural > calculation software and it works very well :). > Now, I want to go further and would like to create variable thickness shell > elements. So, I was wondering if there is a way to interpolate a scalar field > inside a 2D meshed surfaced (i.e. the thickness) ? Basically, I want to > define a surface with a variable thickness (let's say I know the value at > some nodes of its border), and, once the meshing has been done, I want to > retrieve the value of the interpolated thickness at each new created nodes > inside the surface in order to define variable thickness shell elements. > Do you see any way to do so ? > Thank you in advance ! > > Best regards, > > Mathieu ARQUIER > Structural Engineer > mathieu.arquier at gmail.com > > I checked the tutorial 7 he referred to. In my opionion this examples > controls the size of the elements by using a *.pos file and not controlling > the thickness. So my question is how I can assign a thickness for example to > a rectangle area as a linear function from 1 to 10 in x-direction and > constant in y-direction? > > Best regards > Julian > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Python API and Spyder
> On 31 Mar 2020, at 11:59, paul francedixhuit wrote: > > Hi > > One would say this is not the "normal" use of the Gmsh API, but for my > developments under Python, I'm always coding under Spyder IDE (and I would > like to continue if possible). > > I've been noticing that when Gmsh GUI needs to be opened (t8.py case for > example), then it becomes not possible to close it and it's necessary to > close Spyder as well (of course it works fine in commande line). > > Can we imagine something like gmsh.close()? > > In addition as I've ever said in a previous post, Gmsh API can be used: > • either by defining the PYTHONPATH as described in the doc (I've > defined it in the .bashrc file) > • either by explicitly implementing it at the beginning of the Python > file (see sys.path.append) > Find some screenshots in attachment > When you call gmsh.fltk.run(), FLTK basically runs a while(1) loop waiting for graphical interface events. To break the loop simply close the Gmsh window. You can also run the event loop yourself in Python: don't call gmsh.fltk.run(), but gmsh.fltk.wait() each time to want to wait for an event. See demos/curstom_gui.py for a complete example. Christophe > Stay at home > > Paul > > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Rotation of Surface in Gmsh
> On 1 Apr 2020, at 12:56, Razon kumar wrote:
>
> Hi Gmsh Community,
>
> Hope you are doing well. I am quite new in Gmsh. I was trying to make a
> geometry as same in the attached picture. I am able to create both surfaces
> but was not able make an inclination of the upper surfaces. It can be a silly
> trick for someone who is well familiar with Gmsh environment.
> For more information please see the attached picture and geo file. I am kind
> of stacked here. I would be very grateful to you if I get the solution of
> that. Please suggest me what can be done to do that. I tried rotate option in
> the Gmsh but couldn't find any solution so far.
Add
Rotate{{0,0,1}, {0,2,5}, -Pi/3}{ Surface{2}; }
Before the extrude command.
I would advise to read the tutorials before sending questions to the list...
Christophe
> Cheers,
>
> Razon
>
>
> ___
> gmsh mailing list
> gmsh@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
___
gmsh mailing list
gmsh@onelab.info
http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Structured grid for triangular domains
> On 25 Mar 2020, at 20:46, Murilo Henrique Campana Bento
> wrote:
>
> Hi everyone,
>
> I am trying to create a structured mesh for a simple triangular domain.
> However, the generated mesh is not the one I expected.
>
> The input script (geo) I am using is the following.
>
> "
> Point(1) = {0.0, 0.0, 0.0, 1.0};
> Point(2) = {1.0, 0.0, 0.0, 1.0};
> Point(3) = {1.0, 1.0, 0.0, 1.0};
>
> Line(1) = {1, 2};
> Line(2) = {2, 3};
> Line(3) = {3, 1};
>
> Line Loop(1) = {1, 2, 3};
> Plane Surface(1) = {1};
>
> Transfinite Line {1, 2, 3} = 5;
> Transfinite Surface {1} Right;
> "
>
> The mesh I am obtaining is illustrated in Fig01.
> The mesh I would expect to obtain is one similar to that presented in Fig02
> (with little right triangles).
>
Indeed, the transfinite algo does not have this decomposition coded. It should
be quite easy to add though: look at Mesh/meshGFaceTransfinite.cpp. Don't
hesitate to send a patch or a merge request with the code on our gitlab.
Christophe
> Thank you all for your help!
> Best regards,
>
> Murilo Bento
> _______
> gmsh mailing list
> gmsh@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
___
gmsh mailing list
gmsh@onelab.info
http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Extrusion of one element that is split into multiple regions
> On 31 Mar 2020, at 00:15, Bucksot, Jesse Edward
> wrote:
>
> Hi all,
>
> I’m pretty new here. I’ve had good success with gmsh so far, but I just ran
> into an issue when extruding surfaces that have been split into multiple
> separate regions due to boolean operations. When I just do one extrude, it
> seems to come out right, but then if I try to label the extrusion (e.g.
> “Physical Volume("part") = {ex1[]};”) or try to extrude again by extruding
> ex1[0], it only does one single part of the surface.
> Basically, if I take a rectangle and cut it into two smaller rectangles using
> BooleanDifference and then extrude it, the created extrusion (ex1[0],ex1[1])
> only contains one of the smaller rectangles and not both of them.
>
> Does anyone have any solutions or workarounds to this?
> Also, my real geometry is pretty complicated, so I’m not sure how feasible it
> is for me to manually check for any instances of surfaces being split apart
> before extruding.
>
To get something conformal you indeed need to extrude the different parts at
the same time. Here's how I would do it:
SetFactory("OpenCASCADE");
s2858 = news;
Rectangle(s2858) = {-1, -1, 0, 2, 2};
s2859 = news;
Rectangle(s2859) = {-0.1, -1, 0, 0.2, 2};
bo1[] = BooleanDifference{ Surface{s2858}; Delete; } { Surface{s2859}; };
If(0) // your code
ex1[] = Extrude {0,0,1} {Surface{s2859}; Layers{1}; };
ex2[] = Extrude {0,0,1} {Surface{bo1[]}; Layers{1}; };
ex3[] = Extrude {0,0,1} {Surface{ex1[0]}; Layers{1}; };
ex4[] = Extrude {0,0,1} {Surface{ex2[0]}; Layers{1}; };
Physical Volume("tool") = {ex1[1], ex3[1]};
Physical Volume("cut") = {ex2[1], ex4[1]};
Else // new way
ex1[] = Extrude {0,0,1} {Surface{s2859,bo1[]}; Layers{10}; };
ex2[] = Extrude {0,0,1} {Surface{ex1[0],ex1[6]}; Layers{10}; };
Physical Volume("tool") = {ex1[1], ex2[1]};
Physical Volume("cut") = {ex1[7], ex2[7]};
EndIf
Christophe
>
> Thanks in advance!
> Jesse
> ___
> gmsh mailing list
> gmsh@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
___
gmsh mailing list
gmsh@onelab.info
http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] 3D meshing gmsh
> On 29 Mar 2020, at 16:17, Aggraj Gupta wrote: > > Hi , > I am new to gmsh software. I am using the software for meshing the sphere > within the cube. I have attached the file below. As will be understood from > the geo file that I have first created a cube and then made a sphere inside > it. I did not delete volume as size of the sphere within the cube. I am > giving two different material property to the cube as well as the sphere. > Will it create a problem in this case? (as I am not getting my FEM results > correctly!). If yes, can you please help me how to create the desired > geometry so that it can get meshed in properly. I will be thankful to you if > you could please pull me out of this. Looking forward for your reply. > Your second volume has a hole, and should thus be defined using two surface loops. I recommend reading the tutorials before sending questions to the list. Christophe sphere_cube_fix.geo Description: Binary data > Thanks > > > Regards, > Aggraj Gupta, > Research Scholar | Electrical Engineering, > Indian Institute of Technology Madras > (M) +91 8427789957 | (P) +91 7376265173 > > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Question regarding values of boundingBox and General.MaxX/Y/Z and Geometry.Tolerance
> On 27 Mar 2020, at 11:21, Tobias Lichti Fraunhofer ITWM > wrote: > > Hello all, > > I have a question regarding the values of above variables/function output. > > If my model is a cube of e.g. [Xmin , Ymin , Zmin , Xmax , Ymax , Zmax] = > [0,0,0,5,5,5] and I calculate the boundingBox of the model I will obtain > [0-1e-7 , 0-1e-7 , 0-1e-7 , 5+1e-7 , 5+1e-7 , 5+1e-7]. > The variables General.MinX/Y/Z and General.MaxX/Y/Z as well have an offset of > 1e-7. > > This offset seems to be independent from Geometry.Tolerance. Indeed, this is the internal tolerance of OpenCASCADE. To be on the safe side, OCC always adds this tolerance to its bounding boxes. Moreover, OCC bounding boxes are not guaranteed to be tight - they are sometimes actually completely unusable because they are much larger than the actual geometry. To mitigate this issue, the latest development snapshot introduces a new option: "Geometry.OCCBoundsUseStl". If you set it to 1, the bounding boxes of OCC shapes are computed using to the STL mesh. They might be too small compared to the true shape (for curved surfaces), but this way you can at least choose your poison ;-) See e.g. https://gitlab.onelab.info/gmsh/gmsh/-/blob/master/tutorial/t18.geo for an example. Christophe > > Can anyone tell me how the offset can be controlled or how it is defined? > I am also grateful for every hint about how is the best way to get the exact > bounding box of the model. > > Best regards and thanks in advance! > Tobias > > > > -- > Tobias Lichti > Fraunhofer-Platz 1, 67663 Kaiserslautern, Germany > Telefon: +49 631 31600-4974, Fax: +49 631 31600-5974 > mailto: tobias.lic...@itwm.fraunhofer.de > www.itwm.fraunhofer.de > > > > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Mesh error
> On 29 Mar 2020, at 12:24, Sabrina Zacarias > wrote: > > Dear all, > > I am a bit confused with the output of the meshing of my model and would > really appreciate a piece of advise: > > My geometry consists of an axial section of a cylinder (which plays the role > of the air surrounding my model ) containing several (sections of) rings, > which are electrodes, plus two (sections of ) disks, which are the cathode > and anode. The fact that these are sections and not complete cylindrical > pieces is to make the meshing faster. And the post processing software can > handle it. > > Anyway, In the real model I need to use ~200 electrodes. So far I have not > been able to achieve a mesh without errors. I get ‘Unable to recover the edge > XX on curve XX (on surface XX )’, and also ’No elements in volume XX’. > With Nel = 200 your geometry is invalid (it auto-intersects), whereas with Nel = 20 it is correct. Christophe > What I find confusing is that when I reduce the number of electrodes x10 > lower, without changing anything else, the meshing is correct. > > I am obviously missing something or not approaching the problem the right > way. I attach the .geo files if someone could please take a look. > > Best regards, > > Sabrina > > <3d_main.geo> > > > > > — > Sabrina Zacarias > Institut für Kernphysik > Technische Universität Darmstadt > S2|14 / office 319 > Schlossgartenstr. 9 > > 64289 Darmstadt > > Office: +49 6151 16 23589 > > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Questions on 4.1 format
> On 30 Mar 2020, at 16:51, paul francedixhuit wrote:
>
> Hi All
> I'm currently having a look to the new 4.1 gmsh format.
>
> Compared to the previous 2.2 legacy one:
> • I guess $Nodes and $Elements for example use now blocs (or it has
> been splitted in blocs) in order to take advantages of parallelization,
> hasn't it?
It allows that, yes. It also allows for much more efficient reading
from/writing to disk.
But more fundamentally, the new format reflects the underlying Gmsh data model
(http://gmsh.info/doc/texinfo/gmsh.html#Gmsh-API), and it contains all the
information needed by Gmsh to save/reload a model without information loss.
> • $Entities and $PhysicalNames are used to define specific groups of
> elements to apply on specific features (typically sub-parts)
Entities contain the underlying (topological) boundary representation of the
Gmsh model. Physical groups are just groups of entities. They are defined even
without a mesh. Mesh nodes/elements are stored in the model entities.
Note that the only two fields that are necessary in a simple MSH file are
$Nodes and $Elements. All the rest is useful for Gmsh - but can be omitted by
other codes if they don't need the additional topological model information.
> Nonetheless concerning $NodeData (and $ElementNodeData), I've not tested it
> so far but I feel the structure remains identical to the 2.2 one: am I right?
> if so I can imagine improvements will be provided in a next future, won't be?
>
Yes indeed. See the end of the
http://gmsh.info/doc/texinfo/gmsh.html#MSH-file-format section.
> The next steps will be to use it through the Python API
The Python tutorial is now on par with the GEO and C++ ones:
https://gitlab.onelab.info/gmsh/gmsh/-/tree/master/tutorial
New extended ("x") tutorials will be added in the near future to help new users
with features that are only available through the API (and not in GEO files).
Don't hesitate to contribute your feedback on
https://gitlab.onelab.info/gmsh/gmsh/-/issues/795 : we will use it to track
suggestions or corrections.
Cheers,
Christophe
>
> Bye
>
> Paul
> ___
> gmsh mailing list
> gmsh@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
___
gmsh mailing list
gmsh@onelab.info
http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] export .step file without duplicated geometry
Hi Kelal, Indeed it's a known issue with the STEP exporter. Let's continue the discussion here: https://gitlab.onelab.info/gmsh/gmsh/-/issues/624 We currently create a single compound for the model, and use the "STEPControl_AsIs" OpenCASCADE option to export STEP files. It's maybe not what we should do... Christophe > On 28 Apr 2020, at 12:30, Kelal Raschket wrote: > > Hello gmsh community, > > I found the following discussion in the gmsh mailing archive: > http://onelab.info/pipermail/gmsh/2018/012233.html. > There they discussed how to export a geometry in gmsh using the OpenCASCADE > kernel. I used the .geo file attatched there and exported it as .step file as > well. When I then loaded the resulting .step file into gmsh again to see if > everything worked like expected I recognized that points, curves and surfaces > are loaded multiple times. What can I do to only save all my geometry once? > And a second, related question: Is there a similar function in gmsh for > deciding to either save all the created geometry or only the ones also in a > physical group? Something identical like the "Mesh.SaveAll" function just for > geometry. > > Thank you, > Kelal Raschket > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Restrict Field
Hello Nicolas, > On 27 Apr 2020, at 12:47, Karin wrote: > > Dear Gmsh gurus, > > I would like to assign some size fields depending on some mathematical > expressions *and* depending also on regions. > To this end, I used the Restrict field but my use seems to be inappropriate. > Unfortunately, there are no test or example. > cf. https://gitlab.onelab.info/gmsh/gmsh/-/blob/master/benchmarks/2d/field_restrict.geo > Could you please provide me with some help? > Since you restrict all the fields to the volumes only, the 1D and 2D meshes have no mesh size constraint - hence the very coarse mesh boundary mesh. Here's your example with sizes on the boundaries as well: script_Domaine.geo Description: Binary data Cheers, Christophe > My example is attached to this email. > > Best regards, > NiKo > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] BooleanFragments on tiny scale
> On 28 Apr 2020, at 17:49, Mathias Scheunert > wrote: > > Dear developers and users, > > is there a way, to apply BooleanFragments (and others?) also on a very tiny > scale? > > -> Please find attached a MWE, illustrating that this operation fails on a > small scale even with reducing BooleanTolerance (ln 17/18). > No, unfortunately OpenCASCADE has a fixed tolerance and does not work for very small values of coordinates. The solution is e.g. to work close to 1, then rescale the coordinates when saving the mesh with Mesh.ScalingFactor. Christophe > Best regards, > Mathias > > -- > Dr. Mathias Scheunert > Institute of Geophysics and Geoinformatics, TU Bergakademie Freiberg > Gustav-Zeuner-Str. 12, D-09596 Freiberg > Tel.: +493731393630 > > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Refine mesh via Gaussian rim inside disk
Hi Lars,
The default algorithm (Frontal-Delaunay) sometimes still has trouble with size
fields with small features. You might want to use the Delaunay algorithm in
such cases:
Mesh.Algorithm = 5;
(I will add a note in the documentation about this.)
For 3D meshes, the latest development snapshot includes mesh size field support
in the new 3D algorithm HXT (Mesh.Algorithm3D = 10). Your feedback on this
experimental support will be very welcome!
Cheers,
Christophe
> On 23 Apr 2020, at 17:54, Lars Hubatsch wrote:
>
> Hi all,
>
> I’m trying to create a disk mesh with a given background and, within a rim
> around the center, a local decrease of the characteristic length that follows
> a Gaussian (see attached image 1).
>
> Code:
>
> SetFactory("OpenCASCADE");
> Disk(1) = {0, 0, 0, 4};
> Physical Surface("surfacedomain") = {1};
>
> Field[3] = MathEval;
> Field[3].F = ".5 - (.5-0.01)*exp(-(1./0.1)
> *((sqrt(x*x+y*y)-1))*((sqrt(x*x+y*y)-1)))";
>
> Background Field = 3;
>
> However, for the parameters above the rim is not closed, what am I getting
> wrong?
> If I change parameters slightly, e.g. 0.1 to 0.2 or 0.01 to 0.005 I get the
> correct representation. My problem is, that I eventually would like to do
> this in 3D within a sphere instead of a disk. However, this is visually
> harder to inspect (or is there a good way to do this?), so I would like to
> make sure that things work in principle in 2D.
>
> Thanks,
> Lars
>
>
> _______
> gmsh mailing list
> gmsh@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
___
gmsh mailing list
gmsh@onelab.info
http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Bisecting Subdomains of Imported Geometry/Mesh
Dear Randal, If you can import the geometry as e.g. a STEP file in Gmsh, you can indeed split it with cutting planes. See t20 : http://gmsh.info/dev/doc/texinfo/gmsh.html#t20 If you cut the tetrahedral mesh in a brute-force way you will end up with polyhedra, and generally very poorly shaped elements. Christophe > On 24 Apr 2020, at 06:49, Andress wrote: > > Background > > I am doing Finite Element Analysis to study the flow of electric current in > persons and animals due to stray electric current in bodies of water. I am > using FEAtool(a MATLAB plugin) which employs gmsh to generate grids from > geometries. > > Part of my analysis involves the calculation of the total current through > (perpendicular to) the cross section of a sub-domain which is bordered by the > intersection of a cut plane and the subdomain surface. This current is the > integral of current density over the area of the cross section. > > FEAtool does this integration but only over a surface that is a boundary of > the subdomain. > > Here is an example (See attached illustrations.): > > Geometry: a 1m cube (subdomain 2) containing a component (subdomain 1) made > of 4 joined cylindrical sections. > > Boundaries: 5V/0V on the opposite faces of the cube that are perpendicular to > the axes of the cylinders and zero current on the other cube faces. > > Solution: current density is plotted and a YZ plane is cut through it in the > center (at x = 0.5). > > I want to calculate the current flowing through each of the small connecting > cylinders by integrating the current density over the two circular, planar > intersections of the cut plane and the two small cylinders. > > In order to do this wholly within FEAtool, I must create (geometry) the small > cylinders so that they are in two pieces and simply share a face/boundary. > That way there is a pre-defined boundary over which FEAtool can do the > integration. > > Sometimes this is not possible/convenient because the model geometry has been > imported and/or is quite complex (such as that of a human body) or because > the decision to make such a measurement/cut-plane is made only after the > model and mesh is completed and the solution is being examined. > > Question > > If I export the model geometry and/or the mesh from FEAtool to gmsh can the > model/mesh be split by a designated plane within gmsh so that, when exported > and imported back into FEAtool, the sub-domains intersected by the plane > would have true faces/boundaries so they could be designated in an > integration? > > If possible, but not required, I would like to be able to designate the > sub-domains to be split by the cut plane in gmsh so as to not split a > sub-domain over which integration is not needed. > > From the FEAtool perspective, see: > http://forum.featool.com/Integration-of-Current-Density-over-Slice-Intersection-td180.html > > Kind regards, > Randal > > > > > > > > > > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Point In Edge - a workaround with issues
Dear Mathias,
Just add the point in the fragment as well:
// Gmsh project, tested with Gmsh 4.5.6
SetFactory("OpenCASCADE");
// Problem parameter
size_at_point = 1; // fails!
//size_at_point = 10; // works!
domain_w = 1e6;
box_w = 1e2;
// Set Volumes
Box(1) = {-box_w, -box_w, -box_w, box_w, box_w, box_w};
Box(2) = {0, -box_w, -box_w, box_w, box_w, box_w};
boxes() = {1, 2};
Box(3) = {-domain_w, -domain_w, -domain_w, 2*domain_w, 2*domain_w, domain_w};
// Add point on edge that should be vertex of mesh
crit_pt_id = newp;
Point(crit_pt_id) = {0, -0.5*box_w, 0};
BooleanFragments{Volume{3}; Delete;} {Volume{boxes()}; Point{crit_pt_id};
Delete;}
// Cell sizes at point
pad = 0.5;
Field[1] = Distance;
Field[1].NodesList = {crit_pt_id};
Field[10] = Threshold;
Field[10].IField = 1;
Field[10].LcMin = size_at_point;
Field[10].DistMin = 2*size_at_point;
Field[10].LcMax = pad*domain_w;
Field[10].DistMax = pad*domain_w;
// Set background field
Field[100] = Min;
Field[100].FieldsList = {10};
Background Field = {100};
Mesh.CharacteristicLengthFromPoints = 0;
Mesh.CharacteristicLengthFromCurvature = 0;
Mesh.CharacteristicLengthExtendFromBoundary = 0;
Christophe
> On 24 Apr 2020, at 11:49, Mathias Scheunert
> wrote:
>
> Dear developers and users,
>
>
>
> *** The goal
>
> We want to create a checkerboard model to run some resolution studies with
> our FE software.
>
> For that, we construct a geometry consisting of a large box which includes an
> arbitrary amount of small boxes at an arbitrary position using the
> OpenCascade kernel features.
>
> Subsequently, we add some arbitrary points to that geometry which we need to
> be part of the 3D mesh, i.e. which should be contained in mesh as mesh
> vertices.
>
> In case of these points are located within any face or volume of the
> geometry, `Point | Curve { expression-list } In Surface { expression };` or
> `Point | Curve { expression-list } In Volume { expression };` does it's job
> very well!
>
> However, if points are accidentally located on edges, making them part of the
> mesh vertex list is not possible as unfortunately there is no `Point | Curve
> { expression-list } In Line { expression };` so far.
>
>
>
> *** The workaround
>
> We tried to force Gmsh adding that points to the edges by defining small
> lines which we add to the surface that belongs to the respective edges.
>
> -> Please have a look on the attached MWE, that illustrates our approach.
>
>
>
> *** The problem
>
> We are controlling the cell sizes by using a combination of filter.
>
> When changing the scales of our geometry or changing the parameter set of our
> filters, meshing sometimes fails without any - at least for us -
> understandable reason.
>
> -> Please try using line 6 instead of line 5 in the MWE.
>
>
>
> Does somebody have a hint how to fix that?
>
> Or, does somebody have an even better workaround for subsequently adding
> points to edges?
>
>
> Best regards,
> Mathias
>
> ps: We are using Gmsh 4.5.6.
>
> --
> Dr. Mathias Scheunert
> Institute of Geophysics and Geoinformatics, TU Bergakademie Freiberg
> Gustav-Zeuner-Str. 12, D-09596 Freiberg
> Tel.: +493731393630
>
> ___
> gmsh mailing list
> gmsh@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
___
gmsh mailing list
gmsh@onelab.info
http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Problem meshing imported STEP file
> On 28 Apr 2020, at 12:20, Michael Enders wrote: > > Hello everyone, > > I would like to mesh a .STEP file (a picture is attached). But just running > > Merge "part.STEP"; > Mesh 3; > > gives me the following errors: > > Error : No tetrahedra in region 1 > Info: 3D refinement terminated (274 nodes total): > Info: - 0 Delaunay cavities modified for star shapeness > Info: - 0 nodes could not be inserted > Info: - 0 tetrahedra created in 0.000178 sec. (0 tets/s) > Error : No elements in volume 1 > > I tried to define new volumes and I managed to mesh some parts of the object, > but I was never able to mesh everything. Do you have some ideas what I could > do? > Can you send the .step file ? Christophe > Thanks, > Michael > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] 3D Mesh for Box with Inclusions
> On 13 Apr 2020, at 18:34, Maurice Rohracker wrote: > > Dear GMSH developer, > > I prepared some .geo-file where I want to mesh a box with spherical > inclusions, which we need for some RVE and homogenization modelling. The mesh > should be fully hexahedral. Right now, the shape of the hexahedrons is not > very in that way in which we would like to have them (see in the attached > picture). Our goal would be, having more cubed like hexahedrons. > > The .geo-file adds spherical inclusions into the box by adding the centre and > the radius of the inclusions to the list of bubbles in the beginning. Later > on, we would not just have only one or two inclusions, but for a small test > example, this should be enough. > > Is there a good way to set the mesh configuration parameters such that the > mesh has more general shaped hexahedrons, like cubs. > > How about the parameter "Mesh.Recombine3D = 1", because in the documentation > it's mentioned as experimental; should one use it, if one would like to have > a fully hexahedral mesh, as we prefer to. > Automatic high-quality full-hex mesh generation is an open problem: see https://www.hextreme.eu/publications/ for some advances by people contributing to Gmsh. (Mesh.Recombine3D is currently not functional anymore - you can it a try with Gmsh 3. A new version based on new developments will eventually be merged in Gmsh. Hopefully we'll see something by the end of the year.) Christophe > Thank you very much for your reply in advance. > > Kind regards, > Maurice Rohracker > Master Student Computational Engineering > FAU > Erlangen-Nuremberg___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Mesh renumbering to MED format
> On 15 Apr 2020, at 12:05, Miguel Segade wrote: > > Hi > > I need to do some operations involving meshes in .bdf and .med format. One > problem that I faced was that after exporting a .med file to .bdf a > renumbering was done, but this was solved in this gitlab issue: > https://gitlab.onelab.info/gmsh/gmsh/-/issues/601. > > Now I'm facing the opossite problem, I need to export a .bdf file to .med > while mantaining the element numbering scheme. But apparentely, .med does not > allow arbitrary node numbering. Is this correct? If yes, is there any way to > generate a relation table between the two mesh numbering? > > For example, elements 80044, 80054 and 80064 in the .bdf correspond to 1, 2 > and 3 in the MED file. > Indeed currently Gmsh does not try to write node/element tags in MED files. It is probably possible though, as we make sure to assign tags when reading MED files. I suggest that you open an issue with this, so we can keep track. Christophe > Thanks > > > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] meshing partitions
> On 9 May 2020, at 18:09, Hansjoerg Seybold wrote: > > Hello, > I am trying to mesh a model consisting of several physical groups each > group at a time and then merge the meshes for the different physical > groups afterwards. The reason why I am trying to perform this "domain > decomposition" is that the meshing of the full model takes over 5 days > and exceeds the runtime limit of the queuing system. > > However I could not find a simple way to apply the "Mesh 2" to a > specific physical group. Gmsh always tries to mesh the whole model. > You could either delete the parts you don't want to mesh; or hide the parts you don't want to mesh (cf. the `Show` and `Hide` commands in .geo script, or `setVisibility()` in the api) and use the `Mesh.MeshOnlyVisible` option. > My question would be if anybody has a hint how to perform this meshing > in parts and how to combine the resulting meshes into a single final > model. > That's trickier as each mesh will be independent. The development snapshot allows you to set the starting node/element tag (Mesh.FirstNodeTag, Mesh.FirstElementTag), which will help. Removing duplicate nodes when you merge things together can be done with Coherence Mesh (in .geo files) or removeDuplicateNodes() in the api. PS: 5 days to perform a 2D mesh ? Anything special in the geometry/size field? If you don't do this already at least recompile Gmsh with OpenMP enabled, and mesh in parallel? Christophe > Thank you very much. > > Best, > hansjoerg > > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Zero volume tets
> On 12 May 2020, at 11:49, Karin wrote: > > Dear Gmsh Gurus, > > I am facing some troubles with a brep CAD I am trying to mesh with Gmsh. > If I try the meshing default settings, the mesh is being built and Gmsh is > proud to announce that no illegal tet stand in the mesh. *But* if I simply > run "gmsh -check", Gmsh admits that zero volume tets stay in the mesh. So it > is unusable for computation. There maybe too many messages, but the optimizer indeed reports that there are 6 tets below the quality threshold in volume 2 with the default algo (we should issue a warning if the quality is indeed approaching zero): Info: Optimizing volume 2 Info: Optimization starts (volume = 3.52969e+07) with worst = 0 / average = 0.757222: Info: 0.00 < quality < 0.10 : 212 elements Info: 0.10 < quality < 0.20 : 362 elements Info: 0.20 < quality < 0.30 : 166 elements Info: 0.30 < quality < 0.40 : 222 elements Info: 0.40 < quality < 0.50 : 287 elements Info: 0.50 < quality < 0.60 : 765 elements Info: 0.60 < quality < 0.70 : 3802 elements Info: 0.70 < quality < 0.80 : 7720 elements Info: 0.80 < quality < 0.90 : 4721 elements Info: 0.90 < quality < 1.00 : 4214 elements Info: 321 edge swaps, 0 node relocations (volume = 3.52969e+07): worst = 0 / average = 0.765757 (Wall 0.022079s, CPU 0.022s) Info: 338 edge swaps, 0 node relocations (volume = 3.52969e+07): worst = 0 / average = 0.765884 (Wall 0.0357411s, CPU 0.035583s) Info: 339 edge swaps, 0 node relocations (volume = 3.52969e+07): worst = 0 / average = 0.765909 (Wall 0.0503662s, CPU 0.050068s) Info: 6 ill-shaped tets are still in the mesh > I have succeeded in producing a correct mesh by using the Frontal 3D > algorithm (Mesh.Algorithm3D = 4;). > Perhaps a check of the presence of zero volume elements could be an > interesting enhancement. You can also try Mesh.Algorithm3D = 10; which is (here a bit) faster. Christophe > You'll find all necessary files in the attached archive. > > Regards, > Nicolas > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] BUG (??) in version 4.5.6
Dear Miguel, The over-refinement was due to an overly strong hypothesis on the 1D mesh that was made when refactoring the code in Gmsh 4.5.4. The next development snapshot will fix this little regression. Thanks for the report, Christophe > On 5 May 2020, at 15:36, miguel.ar...@artorg.unibe.ch wrote: > > Dear Dr Geuzaine, > > Please, find enclosed the test files. > > Just as a summary of what I did: a tested the same surface and meshing > conditions in two Python environments (one with GMSH 4.5.6 and another one > with GMSH 4.5.3). In the case of 4.5.3, we have ~70k elements (see > log-453.txt) and in the case of 4.5.6, we have ~ 1m elements (see > log-456.txt). BESIDES, there is an error regarding the discretization of the > curves (see lines 20-24 in log-456.txt). This error is not present in the > previous version. > > Hopefully, this will help you to isolate the origin of this behavior ;-D > > > Best, > > MA > > -Original Message- > From: Christophe Geuzaine > Sent: Tuesday, 5 May 2020 14:03 > To: Ariza Gracia, Miguel Angel (ARTORG) > Cc: gmsh@onelab.info > Subject: Re: [Gmsh] BUG (??) in version 4.5.6 > > > >> On 5 May 2020, at 12:34, miguel.ar...@artorg.unibe.ch wrote: >> >> Dear all, >> >> I was using a code I developed in version 4.4 for meshing spheres with >> tetrahedron. I could modify the characteristic length (max. and min.) and it >> worked perfectly. >> >> Moreover, I’ve been using this code in different incremental updates and it >> worked perfectly until version 4.5.3. Yesterday, I updated to version 4.5.6 >> and the code continues working but with a strange behavior. >> >> Let’s say that I was using a characteristic length of 0.2 for meshing a >> sphere, in version 4.5.3 this resulted in ~70k elements. Now, with the same >> characteristics, this results in 1.000.000 elements! >> >> No matter what I tried, it seems that GMSH’s response was invariant: >> • Activate/deactivate the optimization of the mesh (it did not change >> anything) >> • Modify the characteristic length up to 2 or 4 (it did not change >> anything). Also, I debugged to be sure that these were the actual values >> that GMSH received >> • Try to use a bias in the mesh. Nothing >> >> Perhaps, I missed a major modification in the code from 4.5.3 to 4.5.6 and I >> need to re-code my libraries… but… Could it be a bug in the code? If so, >> where? In the meantime, I downgraded to version 4.5.3. >> > > Could you send a simple example so that we can test? > > Christophe > >> Tested in: >> • W10 >> • Ubuntu 18.04 in WSL (W10) >> • Ubuntu 18.04 >> >> Best, >> >> MA >> ___ >> gmsh mailing list >> gmsh@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 > > > > — Prof. Christophe Geuzaine University of Liege, Electrical Engineering and Computer Science http://www.montefiore.ulg.ac.be/~geuzaine ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] How to use the plugin crack from the command line
> On 4 May 2020, at 23:04, Rosicley Júnio Rodrigues Rosa > wrote: > > Hello, > > I'm a Master student and I use Gmsh to solve fracture mechanic problems. From > the interactive mode, I have used the plugin crack to generate a crack in a > surface, but I need to use this plugin from the command line. Is it possible? > > I usually use the script bellow: > gmsh -2 -clscale 1.0 temp.geo -o temp.msh -algo auto -order 3 > > I tried to add the following lines to the temp.geo file, but it didn't work. > Plugin(Crack).Dimension = 1; > Plugin(Crack).PhysicalGroup = 11; > Plugin(Crack).Run; > > What can I do to solve this problem? > Here's an example: ok.geo Description: Binary data Christophe > Thank you for your help. > > Best regards, > Rosicley > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] How to create Surface from Discrete surface ?
> On 7 May 2020, at 01:01, Kenneth Assogba wrote: > > Dear GMSH developer, > > I'm using Gmsh Python API in version 4.5.6. I have some .msh file (with just > points and line who define a surface) and I a want to create a 2D mesh on it. > As it is not directly possible, i'm triying the > gmsh.model.mesh.createGeometry() method and after that, doing > gmsh.model.geo.synchronize() > gmsh.model.mesh.generate(2) createGeometry() creates a geometry for discrete curves and surfaces. If your mesh only contains points and line elements you don't have any surface, so createGeometry() will only create a geometry (a parametrization) for curves. If you know that your surface is plane, just create a standard plane surface with the built-in kernel, that takes the discrete curves as boundaries. See this tutorial for an example: http://gmsh.info/dev/doc/texinfo/gmsh.html#x2 Christophe > > The result in the console is : > Info: Creating geometry of discrete curves... > Info: Done creating geometry of discrete curves (8e-06 s) > Info: Creating geometry of discrete surfaces... > Info: Done creating geometry of discrete surfaces (1e-06 s) > > But the 2D mesh isn't create. Do you have any idea of how I can do ? > I see here (t13) that you recreate surface loop and volume before mesh, but > in my case it is not possible since Gmsh return the error : Error : GEO > surface with tag 1 already exists. > > By reading information about the file (explore), I can see: > Entity (2, 1) of type Discrete surface > - Mesh has 0 nodes and 0 elements > - Boundary entities: [(1, 1), (1, 2), (1, 3), (1, 4)] > > Please see attached the original .geo and the exported .msh. > > Thank you in advance, > Best regards, > > Kenneth Assogba > Master 2 Ingénierie Mathématique Pour l'Entreprise > Sorbonne Université - Faculté de Sciences et Ingénierie > > > > _______ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Making an animation from non-uniform time steps
> On 5 May 2020, at 16:09, Jeremy Theler wrote:
>
> Hi all
>
> Say I have a set of $NodeData$s with a temperature distribution from a
> transient heat conduction problem but due to adaptivity the times are
> not equally spaced. Each set has the real tag as a the real time and
> the first integer tag as the time index.
>
> Any (scalable) idea of how can I get an animation that shows the real
> time advancement?
>
You can simply set "View.Time" at the desired value at regular intervals, as
setting "View.Time" will automatically select the appropriate time step.
Say time in your view goes from 0 to tmax; you could do
For time in {0:tmax:0.01}
View[0].Time = time;
Sleep 0.1;
Draw;
EndFor
in a .geo file. You can use the same idea with the Python API.
Christophe
> Python and linear interpolation between the two closest sets of data
> are fine. I would like to get the general idea, I can work out the
> details.
>
>
> Regards
> --
> jeremy theler
> www.seamplex.com
>
>
>
> ___
> gmsh mailing list
> gmsh@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
___
gmsh mailing list
gmsh@onelab.info
http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] meshing partitions
> On 11 May 2020, at 16:32, Hansjoerg Seybold wrote:
>
> Hello,
> Thanks a lot for the reply. Using the visibility filter worked. I
> created a simple test case (attached)
> which creates the two mesh pieces. So now I have two meshes
> multizone_1.msh and multizone_2.msh
> which I can load in a geo file
> --
> Merge "multizone_1.msh";
> Merge "multizone_2.msh";
> Coherence Mesh;
> Save "multizone_merged.msh";
> Save "multizone_merged.bdf";
> Exit;
> --
> I understood that the coherence mesh removes the duplicate nodes on
> the common edge and the above
> script displays the mesh in the gui correctly.
> However the export is distorted as the node ordering is not updated.
> I would get the development snapshot to try to use the mesh tag
> suggestion, but how would I do the reordering
> starting from the script above?
>
You would do:
Mesh.FirstNodeTag=1;
Mesh 2;
Save "multizone_1.msh";
...
Mesh.FirstNodeTag=Mesh.NbNodes + 1;
Mesh 2;
Save "multizone_2.msh";
> regarding openmp:
>
> We (the IT cluster staff at ETH Zurich and myself) tried to get the
> openmp version of gmsh running on the cluster (CentOS 6), but without
> success.
> I managed to compile and run it on my ubuntu PC, but with very little
> speedup for the selected meshing algorithm.
> I tested openmp with two physical groups active and -nt 2, on a finer
> LC as in the attached geo for speed measurements and Mesh.Algorithm =
> 9; gmsh-4.4.1,
> a significant speedup could only be observed for del2d, but quality
> tests showed that the 'pack' algorithm gave the best meshing result
Ok I see. The "pack" algorithm has not been worked on for a while and is indeed
currently sequential. We are working on updating this algorithm, so hopefully
it will get much faster (and parallel) soon.
> BTW, is it possible to apply different meshing algorithms to different
> physical groups?
>
Yes. In .geo files: MeshAlgorithm Surface {...} = ...;
Christophe
> Regarding the 5 days meshing: I am using quad meshing (algo 9) with a
> not too sophisticated sizing function but with a very large domain,
> del2d is orders
> of magnitudes faster.
>
> Thanks a lot for the help.
>
> Hansjoerg
>
>
>
>
>
>
>
> On Sun, May 10, 2020 at 9:05 AM Christophe Geuzaine
> wrote:
>>
>>
>>
>>> On 9 May 2020, at 18:09, Hansjoerg Seybold wrote:
>>>
>>> Hello,
>>> I am trying to mesh a model consisting of several physical groups each
>>> group at a time and then merge the meshes for the different physical
>>> groups afterwards. The reason why I am trying to perform this "domain
>>> decomposition" is that the meshing of the full model takes over 5 days
>>> and exceeds the runtime limit of the queuing system.
>>>
>>> However I could not find a simple way to apply the "Mesh 2" to a
>>> specific physical group. Gmsh always tries to mesh the whole model.
>>>
>>
>> You could either delete the parts you don't want to mesh; or hide the parts
>> you don't want to mesh (cf. the `Show` and `Hide` commands in .geo script,
>> or `setVisibility()` in the api) and use the `Mesh.MeshOnlyVisible` option.
>>
>>> My question would be if anybody has a hint how to perform this meshing
>>> in parts and how to combine the resulting meshes into a single final
>>> model.
>>>
>>
>> That's trickier as each mesh will be independent. The development snapshot
>> allows you to set the starting node/element tag (Mesh.FirstNodeTag,
>> Mesh.FirstElementTag), which will help. Removing duplicate nodes when you
>> merge things together can be done with Coherence Mesh (in .geo files) or
>> removeDuplicateNodes() in the api.
>>
>> PS: 5 days to perform a 2D mesh ? Anything special in the geometry/size
>> field? If you don't do this already at least recompile Gmsh with OpenMP
>> enabled, and mesh in parallel?
>>
>> Christophe
>>
>>> Thank you very much.
>>>
>>> Best,
>>> hansjoerg
>>>
>>> ___
>>> gmsh mailing list
>>> gmsh@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
>>
>>
>>
> ___
> gmsh mailing list
> gmsh@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
___
gmsh mailing list
gmsh@onelab.info
http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Adding a boundary surface on a STL model
> On 17 May 2020, at 15:00, Dimitrios Stoupis wrote: > > Hi, > > I want to run brain simulations with models from the PHM repository > (not relevant to the problem but suits the narrative) which are > shipped in STL format. The meshes of the STL have been fixed using > MeshFix and the attached .geo file has been used to generate the 3D > mesh. > > [file: brain_mesh.geo] > > The script successfully meshes the model and the generated mesh is > correct. The problem is how can I add electrodes on the head > (cylindrical volumes) so that later I use those as the boundary > surfaces to add the boundary conditions in the FEM solver. > Illustration > > I have tried creating a cylinder and applying boolean operation with > the STL, but obviously this did not work. How can I create such a > thing on the STL surface? There is no CAD available just the STL > files. For copyright reasons I am not able to share the STL, but I > will try to illustrate below the problem using a sphere in paint. You'll need to preprocess the STL with an external tool first: currently there is nothing in Gmsh to modify STLs - only remesh them. Christophe > > [image: electrode.png] > > I want the electrode (red volume) to be tangent with the surface of > the skin (black sphere). The black sphere is only in STL format. > Triangle position problem > > Finally the next problem that will arise is how can I get the > individual triangle positions on the STL surface through the file in > order to be able and add the electrode perpendicular to the surface > and to the right spot, without doing trial and error work to find the > location. > > Thank you! > _______ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] meshing partitions
> On 15 May 2020, at 15:04, Hansjoerg Seybold wrote:
>
> Hello,
> Thanks a lot for the support. Meshing in two steps and noting the
> NbNodes and elements (NbTriangles, Nbquads) worked. I get a correct
> mesh in gmsh and also saving the result is correct.
> I still have some problems importing the final BDF mesh into ansys
> fluent (gmsh reads and displays the BDF correctly)
>
> The BDF contains the diagonal edges twice although I use Coherence Mesh.
Ok that's normal: currently we only remove duplicate nodes, not elements (cf.
https://gitlab.onelab.info/gmsh/gmsh/-/issues/19 for tracking this.)
Christophe
>
> after deleting
> CBAR1 ...
> ...
> CBAR 16 ...
>
> by hand I can read the combined BDF mesh into ansys.
>
> I attached all three sample geo files for all three steps (mesh_1.geo,
> mesh_2.geo and mesh_combined.geo) for reference
>
>
> Thanks a lot again.
>
> Cheers,
> hj
>
>
>
>
>
>
> On Mon, May 11, 2020 at 5:30 PM Christophe Geuzaine
> wrote:
>>
>>
>>
>>> On 11 May 2020, at 16:32, Hansjoerg Seybold wrote:
>>>
>>> Hello,
>>> Thanks a lot for the reply. Using the visibility filter worked. I
>>> created a simple test case (attached)
>>> which creates the two mesh pieces. So now I have two meshes
>>> multizone_1.msh and multizone_2.msh
>>> which I can load in a geo file
>>> --
>>> Merge "multizone_1.msh";
>>> Merge "multizone_2.msh";
>>> Coherence Mesh;
>>> Save "multizone_merged.msh";
>>> Save "multizone_merged.bdf";
>>> Exit;
>>> --
>>> I understood that the coherence mesh removes the duplicate nodes on
>>> the common edge and the above
>>> script displays the mesh in the gui correctly.
>>> However the export is distorted as the node ordering is not updated.
>>> I would get the development snapshot to try to use the mesh tag
>>> suggestion, but how would I do the reordering
>>> starting from the script above?
>>>
>>
>> You would do:
>>
>> Mesh.FirstNodeTag=1;
>> Mesh 2;
>> Save "multizone_1.msh";
>>
>> ...
>>
>> Mesh.FirstNodeTag=Mesh.NbNodes + 1;
>> Mesh 2;
>> Save "multizone_2.msh";
>>
>>
>>> regarding openmp:
>>>
>>> We (the IT cluster staff at ETH Zurich and myself) tried to get the
>>> openmp version of gmsh running on the cluster (CentOS 6), but without
>>> success.
>>> I managed to compile and run it on my ubuntu PC, but with very little
>>> speedup for the selected meshing algorithm.
>>> I tested openmp with two physical groups active and -nt 2, on a finer
>>> LC as in the attached geo for speed measurements and Mesh.Algorithm =
>>> 9; gmsh-4.4.1,
>>> a significant speedup could only be observed for del2d, but quality
>>> tests showed that the 'pack' algorithm gave the best meshing result
>>
>> Ok I see. The "pack" algorithm has not been worked on for a while and is
>> indeed currently sequential. We are working on updating this algorithm, so
>> hopefully it will get much faster (and parallel) soon.
>>
>>> BTW, is it possible to apply different meshing algorithms to different
>>> physical groups?
>>>
>>
>> Yes. In .geo files: MeshAlgorithm Surface {...} = ...;
>>
>> Christophe
>>
>>
>>> Regarding the 5 days meshing: I am using quad meshing (algo 9) with a
>>> not too sophisticated sizing function but with a very large domain,
>>> del2d is orders
>>> of magnitudes faster.
>>>
>>> Thanks a lot for the help.
>>>
>>> Hansjoerg
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Sun, May 10, 2020 at 9:05 AM Christophe Geuzaine
>>> wrote:
>>>>
>>>>
>>>>
>>>>> On 9 May 2020, at 18:09, Hansjoerg Seybold
>>>>> wrote:
>>>>>
>>>>> Hello,
>>>>> I am trying to mesh a model consisting of several physical groups each
>>>>> group at a time and then merge the meshes for the different physical
>>>>> groups afterwards. The reason why I am trying to perform this "domain
>>>>> decomposition" is that the meshing of the full model takes over 5 days
>>>>> and exceeds the runtime limit of th
Re: [Gmsh] Zero volume tets
Hello Nicolas,
The issue is that you do "Point ... In Volume" for a point that is actually on
the boundary of the volume - actually on a curve.
Quick solution: add a global fragment operation on the volumes and the points -
it will automatically embed the point in all the required entities. (Here it
will need to split a curve + redefine all the surfaces/volumes touched...)
Cheers,
Christophe
script_Domaine_frag.geo
Description: Binary data
> On 13 May 2020, at 08:44, Karin wrote:
>
> Christophe,
>
> I see that the mesh contains duplicate nodes :
> Info: Checking for duplicate nodes...
> Warning : Vertex 79 (0, 0, 999.9) already exists in the
> mesh with tolerance 4.66905e-05: Vertex 17 (0, 0, 1000)
> Error : 1 duplicate node: see `duplicate_node.pos'
>
> I am quite sure that it comes from the point I define and ask the mesh to
> embed (lines 21-26 of the script - if I remove it, the script doesn't
> complain anymore) :
> c0[] = Point{4}; // c0 contains the coords in indexes 0,1,2
> c1[] = Point{3};
> p=newp; // newp is command to generate a new point number - we store it in p
> Point(p)={0,0, (c1[2]-c0[2])/2};
> Point{p} In Volume{1};
> Physical Point("PGHM") = {p};
>
> Is there a way to set a sharper value to some parameter to avoid this? I
> tried to Coherence Mesh but it causes me trouble in the computation based on
> this mesh (it seems to become invalide in some sense).
>
> Nicolas
>
>
> Le mar. 12 mai 2020 à 14:06, Karin a écrit :
> Thanks for the tip Christophe!
> "Mesh.Algorithm3D = 10;" is indeed faster and produces less elements.
>
> Nicolas
>
> Le mar. 12 mai 2020 à 13:28, Christophe Geuzaine a
> écrit :
>
>
> > On 12 May 2020, at 11:49, Karin wrote:
> >
> > Dear Gmsh Gurus,
> >
> > I am facing some troubles with a brep CAD I am trying to mesh with Gmsh.
> > If I try the meshing default settings, the mesh is being built and Gmsh is
> > proud to announce that no illegal tet stand in the mesh. *But* if I simply
> > run "gmsh -check", Gmsh admits that zero volume tets stay in the mesh. So
> > it is unusable for computation.
>
> There maybe too many messages, but the optimizer indeed reports that there
> are 6 tets below the quality threshold in volume 2 with the default algo (we
> should issue a warning if the quality is indeed approaching zero):
>
> Info: Optimizing volume 2
> Info: Optimization starts (volume = 3.52969e+07) with worst = 0 / average
> = 0.757222:
> Info: 0.00 < quality < 0.10 : 212 elements
> Info: 0.10 < quality < 0.20 : 362 elements
> Info: 0.20 < quality < 0.30 : 166 elements
> Info: 0.30 < quality < 0.40 : 222 elements
> Info: 0.40 < quality < 0.50 : 287 elements
> Info: 0.50 < quality < 0.60 : 765 elements
> Info: 0.60 < quality < 0.70 : 3802 elements
> Info: 0.70 < quality < 0.80 : 7720 elements
> Info: 0.80 < quality < 0.90 : 4721 elements
> Info: 0.90 < quality < 1.00 : 4214 elements
> Info: 321 edge swaps, 0 node relocations (volume = 3.52969e+07): worst =
> 0 / average = 0.765757 (Wall 0.022079s, CPU 0.022s)
> Info: 338 edge swaps, 0 node relocations (volume = 3.52969e+07): worst =
> 0 / average = 0.765884 (Wall 0.0357411s, CPU 0.035583s)
> Info: 339 edge swaps, 0 node relocations (volume = 3.52969e+07): worst =
> 0 / average = 0.765909 (Wall 0.0503662s, CPU 0.050068s)
> Info: 6 ill-shaped tets are still in the mesh
>
>
> > I have succeeded in producing a correct mesh by using the Frontal 3D
> > algorithm (Mesh.Algorithm3D = 4;).
> > Perhaps a check of the presence of zero volume elements could be an
> > interesting enhancement.
>
> You can also try
>
> Mesh.Algorithm3D = 10;
>
> which is (here a bit) faster.
>
> Christophe
>
>
> > You'll find all necessary files in the attached archive.
> >
> > Regards,
> > Nicolas
> > _______
> > gmsh mailing list
> > gmsh@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
>
>
>
> ___
> gmsh mailing list
> gmsh@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
___
gmsh mailing list
gmsh@onelab.info
http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Gmsh binary with OpenMP enabled
> On 14 May 2020, at 23:12, Tian Xia wrote: > > Hi, > > I am using the Python API of Gmsh, which depends on the dynamic link library. > If I'd like to enable OpenMP, I will need to rebuild from the source after > installing a few dependencies. Would it be possible to release the library > with OpenMP under http://gmsh.info/bin/? Thanks! We don't know yet how to do that and still ship the Gmsh binary and/or the Gmsh library without shipping the actual openmp dynamic library as well... Any help with this is clearly welcome! Christophe > > -- > Tian > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Adding second-order nodes to tet4
> On 19 Mar 2020, at 12:56, Jeremy Theler wrote: > > Yes, but the difficult part here is to know if a new node needs to be added > or another element already added it, and in such case what is the > already-added node id. > > Maybe Gmsh already has this somewhere near the "refine by splitting" tool. > In a .geo file: Merge "file.msh"; SetOrder 2; Save "file2.msh"; Similar in the API, with the gmsh/model/mesh/setOrder function. Christophe > -- > jeremy theler > www.seamplex.com > > On Thu, Mar 19, 2020, 08:51 Max Orok wrote: > Hi Jeremy, > > Going through the API shouldn't be too bad.. > • going over the triangle elements > • find midpoint nodes > • either use addElements or find the element format and make them on > the fly > Could you maybe send a small piece of the mesh file to try out? > > Max > > On Thu, Mar 19, 2020 at 7:10 AM Jeremy Theler wrote: > Hi All > > Say I have a .msh file with first-order tetrahedra and triangles. How > can I ask Gmsh to convert these tet4 and tria3 to tet10 and tria6 by > adding mid-edge nodes? Something like "refine by splitting" but for p > instead for h. > > I only have the .msh file, not the original geometry. > > Any ideas? > > Regards > -- > jeremy theler > www.seamplex.com > > > > > ___ > gmsh mailing list > gmsh@onelab.info > http://onelab.info/mailman/listinfo/gmsh > > > -- > Max Orok > Contractor > www.mevex.com > > > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Can I turn an STL or the Created Geometry in Gmsh?
> On 18 Mar 2020, at 13:48, Baltasar Rüchardt > wrote: > > Hello everyone, > > > While working with gmsh and importing stls in order to create FEM-meshes > I was confronted with a question I wasn't able to solve on my own so far: > > Can I merge a stl file in gmsh and rotate the stl data afterwards? It's a bit convoluted in a .geo file (because you need to create a post-processing view) but you can do it as follows: dev_test_rotation_cg.geo Description: Binary data With the API you can directly modify the node coordinates. Christophe > Alternatively, can I rotate the geometry that was created by > CreateGeometry; such that the fem mesh will be rotated as well? > > I attached an example script (dev_test_rotation.geo) where I try the > second approach: Create the volume from the stl and then I try to rotate > the geometrical entities. See the part "Try rotate volume" in the > script. I also attached a simple stl geometry to test it. > > Do you have any ideas? > > The alternative that came to my mind is to rotate with e.g. meshlab > before merging to gmsh. Is this the best / only solution? > > I am looking forward to your answers! > > Thank you and stay well > > > Baltasar Rüchardt > > > > > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] surface mesh coarsening
> On 18 Mar 2020, at 08:56, Hans Dierckx wrote: > > Dear all, > > Can someone explain me how to use gmesh to coarsen a closed surface mesh? I > attach a simple geometry as test data. > I tried in vain in the GUI to put ‘options > mesh > element size’ to a value > bigger than one. > The data I want to apply it to is a heart geometry which has originally 10^6 > vertices and 5 10^5 faces, which should be reduced to approx. 500 faces. > You should save your initial model as a mesh, not a CAD model; for example you can save your input mesh as a STL file. (Beware that your mesh should be correctly oriented - it's not the case for the CAD you sent.) You can the reparametrize the mesh, which will create a multi-patch, discrete geometry that you can remesh. On the command line: > gmsh file.stl -reparam 180 > gmsh file.msh -clcurv 10 -2 See tutorial/t13.geo for the same workflow in a .geo script, or tutorial/python/t13.py or demos/api/remesh_stl.py for the same using the Python API. Christophe > Thank you very much for your assistance. > > Hans Dierckx > Leuven University > > > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Reduce number of digits in key-format file
> On 19 Mar 2020, at 20:13, Xingsheng Sun wrote: > > Hello All, > > I am using Gmsh to generate the mesh file for Ls-dyna. The problem is that in > the key-format file generated by Gmsh, the coordinates of nodes have too many > digits. For instance, in the node information: > > *NODE > 22, 0, 0.0124976, -0.001 > 23, 0, 0.024995, -0.001 > 24, 0, 0.0374926, -0.001 > 25, 0, 0.0499907, -0.001 > > the y-coordinates of nodes 22-25 have 15 digits that cannot be read by > Ls-dyna. > What floating point number format should be used in KEY files? Is there a specification of the format somewhere that we could follow? Christophe > So could any people shed light on how to reduce the number of digits in Gmsh? > I am using command lines, not GUI. Thank you so much in advance. > > Best regards, > Xingsheng > > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Reduce number of digits in key-format file
> On 20 Mar 2020, at 07:59, Winfried Boxleitner > wrote: > > dear Xingsheng, > if you are used to commandline you can modify my awk-script to fit your needs. > > to format the mesh file use the following command: > awk -f pretty_print_msh.awk input.msh > output.msh > Do you mean that we should use %12.6g in our KEY export? Christophe > the awk-script is attached > > best regards, > Winfried > > > On Thu, 19 Mar 2020, Xingsheng Sun wrote: > >> Hello All, >> >> I am using Gmsh to generate the mesh file for Ls-dyna. The problem is that >> in the key-format file generated by Gmsh, the coordinates of nodes have too >> many digits. For instance, in the node information: >> >> *NODE >> 22, 0, 0.0124976, -0.001 >> 23, 0, 0.024995, -0.001 >> 24, 0, 0.0374926, -0.001 >> 25, 0, 0.0499907, -0.001 >> >> the y-coordinates of nodes 22-25 have 15 digits that cannot be read by >> Ls-dyna. >> >> So could any people shed light on how to reduce the number of digits in >> Gmsh? I am using command lines, not GUI. Thank you so much in advance. >> >> Best regards, >> Xingsheng >> > > > __ > / > | Winfried Boxleitner > | Scientist > | AIT Austrian Institute of Technology GmbH > \_____ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Reduce number of digits in key-format file
> On 20 Mar 2020, at 22:54, Xingsheng Sun wrote: > > Dear Christophe and Winfried, > > Thank you so much for your help. The problem has been solved. > > The reason is that LS-DYNA can only read 16 digits, while in the output file > of Gmsh some numbers have 17 digits. For example, in my previous email > 0.0124976 has 17 digits including the dot, which cannot be read by > LS-DYNA. I also found that the 17-digit numbers only happen when its value is > close to zero. Then I moved the entire mesh by 1 in all x-, y- and > z-coordinates. Then the output file by Gmsh works well for LS-DYNA. > Can you give the latest dev snapshot a try and let us know if it fixes the problem? Thanks, Christophe > Hope the solution helps the people who might have the same problem. > > Best wishes, > Xingsheng > > On Fri, Mar 20, 2020 at 4:23 AM Winfried Boxleitner > wrote: > dear Christophe, > my awk-script is meant as an example only, howto modify the msh-file > after creation. for users not familiar to commandline tools however, this > is not useful. I personally have no problems with the current format. > remark: until now I only used msh version 2, because this can be used > together with FreeFem. > > > Winfried > > On Fri, 20 Mar 2020, Christophe Geuzaine wrote: > > > > > > >> On 20 Mar 2020, at 07:59, Winfried Boxleitner > >> wrote: > >> > >> dear Xingsheng, > >> if you are used to commandline you can modify my awk-script to fit your > >> needs. > >> > >> to format the mesh file use the following command: > >> awk -f pretty_print_msh.awk input.msh > output.msh > >> > > > > Do you mean that we should use %12.6g in our KEY export? > > > > Christophe > > > > > >> the awk-script is attached > >> > >> best regards, > >> Winfried > >> > >> > >> On Thu, 19 Mar 2020, Xingsheng Sun wrote: > >> > >>> Hello All, > >>> > >>> I am using Gmsh to generate the mesh file for Ls-dyna. The problem is that > >>> in the key-format file generated by Gmsh, the coordinates of nodes have > >>> too > >>> many digits. For instance, in the node information: > >>> > >>> *NODE > >>> 22, 0, 0.0124976, -0.001 > >>> 23, 0, 0.024995, -0.001 > >>> 24, 0, 0.0374926, -0.001 > >>> 25, 0, 0.0499907, -0.001 > >>> > >>> the y-coordinates of nodes 22-25 have 15 digits that cannot be read by > >>> Ls-dyna. > >>> > >>> So could any people shed light on how to reduce the number of digits in > >>> Gmsh? I am using command lines, not GUI. Thank you so much in advance. > >>> > >>> Best regards, > >>> Xingsheng > >>> > >> > >> > >> __ > >> / > >> | Winfried Boxleitner > >> | Scientist > >> | AIT Austrian Institute of Technology GmbH > >> \_ > >> gmsh mailing list > >> gmsh@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 > > > > > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Hdf5 files and gmsh
> On 22 Mar 2020, at 16:50, paul francedixhuit wrote: > > Hi All > > Recently I found interesting discussions about hdf5 and gmsh (see > https://gitlab.onelab.info/gmsh/gmsh/issues/552). On my side I had to look to > xmdf format 2 years ago that seemed to be interesting to my applications > (mechanical engineering). Finally I gave up because of difficulties and xdmf > developments not really active. > > I'm using hdf5 files through h5py Python library to deal with huge amount of > data, in either static conditions or transitory ones. > > In the meantime gmsh team has developed the format 4.1 and I've to dig into > it; I saw about Python API and I'm not familiar with, but not sure that's > I'm looking for. In my opinion it'll be very useful and powerful to be able > to import datasets from hdf5 files directly from the gmsh native file, > especially for post-processing purposes; let me developing: > - by import I mean calling, not intending to write it in an ascii format; > similar to "h5.get" for people who are familiar to h5py library The Gmsh Python API is one way to go here: it allows you to both get and set the mesh and post-processing data, so you could easily use the data store of your choice, e.g. HDF5 through h5py. > - I'm not speaking about HPC modelings where huge meshes and models can be > post-processed using dozens or hundreds of cores, but about a common PC or a > working station having limited resources compared to HPC servers, > - When working on models having a million of 2nd order elements, and dozens > of time steps, dealing with different variables (up to 3 displacement > components, up to 6 for the stress ones, and so on), all results cannot be > loaded in a single native .pos file due to obvious computing limitations > You shouldn't indeed use parsed .pos files. But you can clearly use .msh files, which can contain post-processing data and have nice features for very large datasets: - the mesh can be stored in one or more files - post-processing data can be stored along with the mesh, or separately - each step (e.g. time step) in a multi-step post-processing view can be stored in a separate file - moreover, each step can be split into arbitrary partitions, each in a separate file Hope this helps, Christophe > While using hdf5 in native gmsh file, I've been thinking it may answer to > this because: > - hdf5 files are optimized for I/O in terms of speed and memory; for example > only datasets you need are loaded and not the entire file: it's fast > accordingly > - data can be compressed in hdf5 file > - a dataset is a block of data (typically a matrix) > - in practice in gmsh, only some data are plotted at the same time and not > all: for example not relevant to plot Von Mises stress and equivalent strain > at the same time, or as well initial time step and final one > - in other word, only what you need is "uploaded" through something like > import "myhdf5\dataset129" (is slicing will be possible?) > - each dataset is built following gmsh format > - as many import as necessary will be done due to different dataset sizes: > one per element type (triangles, quads, tets, hex, wedges, and so on) > - 1 dataset per element = elements ordering might be a limitation I think > (speed down), except if it can be anticipated > - if slicing not possible, well data must be duplicated (higher file size), > but fast reading in practice > - and so on > > I've been using hdf5 files for some time, and it's now an essential part of > my data management: I'm sure gmsh will take huge advantages to integrate it. > > I'll be happy to discuss further about it > > Thanks to gmsh team for their works > > Paul > > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] How to set MSH file format to 2
> On 24 Mar 2020, at 05:33, Andress wrote:
>
> Is it possible to set MSH file format to 2 as an option for the later
> versions (4.5.4) of Gmsh, so that when the .msh is saved from the GUI, it
> will produce MSH2 instead of MSH4 ascii files?
>
Sure. With the GUI, select File->Export, enter a .msh filename, then select the
format you want in the dropdown menu. Then use File->Save Options as Default.
This will save your options in ~/.gmsh-options.
See also FAQ 17 in http://gmsh.info/doc/texinfo/gmsh.html#Mesh-module-questions:
```
How can I save a mesh file with a given (e.g. older) MSH file format version?
• In the GUI: open ‘File->Export’, enter your filename.msh and
then pick the version in the dropdown menu.
• On the command line: use the -format option (e.g. gmsh
file.geo -format msh2 -2).
• In a .geo script: add the line Mesh.MshFileVersion = x.y; for
any version number x.y. You can also save this in your default options.
• In the API: gmsh::option::setNumber("Mesh.MshFileVersion",
x.y).
As an alternative method, you can also not specify the format explicitly, and
just choose a filename with the .msh2 or .msh4 extension.
```
Christophe
> Kind regards,
> Randal
>
> ___
> gmsh mailing list
> gmsh@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
___
gmsh mailing list
gmsh@onelab.info
http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Save all nodes but not 2D shell meshes in the physical surfaces
> On 23 Mar 2020, at 22:51, Xingsheng Sun wrote: > > The output file is in the key format. > > On Mon, Mar 23, 2020 at 2:27 PM Xingsheng Sun wrote: > Hi All, > > I am using Transfinite commend to generate 3D hex meshes. Now I want to save > all the 3D meshes, and only the nodes, but NOT the 2D shell meshes, in the > predefined physical surfaces. I used "Mesh.SaveGroupsOfNodes = 1", but the 2D > shell meshes are always in the output file. Could any people tell me how to > resolve the problem? Thanks in advance. > The KEY format exporter has a couple of undocumented features. They will probably be modified in the future, but for now you can set Mesh.SaveAll = 32; in your script to disable the saving of 2D element sets. Christophe > Best, > Xingsheng > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Increase number of nodes
> On 24 Mar 2020, at 08:07, Silvia Ceccacci (HDR)
> wrote:
>
> Dear all,
>
> You can find attached the mesh I am working on (sphere.png). Is it possible
> to increase the number of nodes of the mesh (manually)? In particular, around
> the inner sphere (which seems to be not as well defined as the outer one)?
>
Of course: see
http://gmsh.info/doc/texinfo/gmsh.html#Specifying-mesh-element-sizes
In your case you could e.g. do
Characteristic Length{ PointsOf{ Volume{1}; } } = 0.1;
Characteristic Length{ PointsOf{ Volume{2}; } } = 0.01;
I would recommend looking at the documentation and the numerous examples (in
particular the tutorials) before sending questions to the mailing list.
Christophe
> Thank you.
>
> Kind regards,
> Silvia
>
>
> ___
> gmsh mailing list
> gmsh@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
___
gmsh mailing list
gmsh@onelab.info
http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] The Control of OCC BSpline points on the intersection edge
> On 10 Mar 2020, at 17:55, Jun Fang wrote: > > Dear GMSH users, > > By applying the BooleanIntersection between a volume and a curved surface, I > can get a decent BSpline intersection curve loop on the surface. The problem > I am facing is that the BooleanIntersection by default gives me an “extra” > point on the intersection edge, which I don’t want (for good reasons). Can you elaborate? > A screenshot is posted below. The ‘Cylinder 23(OCC)’ is the outcome of > Boolean intersection. What I need are the four points (22, 23, 24, 25) and > four associated BSpline curves on the Surface. Somehow, I couldn’t get rid of > the extra point (26), which is located at the z max position of Surface > 23(OCC). My guess is that the additional point is kinda of a reference point > created by the BooleanIntersection function. > > Is it possible to workaround this issue? I know Compound BSpline could > potentially merge curves (i.e. connecting BSplines 27 and 28 here into one), > but it only works for the built-in CAD kernel. Is there an equivalent > function for OCC kernel? Any comments/suggestions are appreciated. > If you don't want the point in the 1D mesh, can't you just use the "Compound Curve" meshing constraint? Christophe > > > Thanks very much, > > Jun > > -- > Jun Fang, Ph.D. - Argonne National Laboratory - (630)252-4561 > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Help with surface visibility
> On 10 Mar 2020, at 19:52, Andress wrote: > > Hello Christophe, > << > The default surface representation mode is a cross of dashed lines. > > With OpenCASCADE you can have other representations: cf. > Tools->Options->Geometry->Aspect->Surface display. > > To save your preferred options: File->Save options as default. > > Christophe >>> > Thank you for taking the time to help. Just what I was missing. > > I am very new to gmsh, and I have a few questions about the learning aids > that are available: > > 1. Where is the user interface defined besides the reference manual 3.4 & 3.5 > (for example all the windows/tabs accessible from > Tools->Options->Geometry->...) > There's no formal description: I would encourage you to simply use it and look around to discover the various possibilities. > 2 The video tutorials at http://gmsh.info/screencasts will be very helpful > in learning the UI - it was in attempting to repeat the first one that I got > stumped when my results differed from that of the video. Are there other > screencast tutorials besides the ones collected at > http://gmsh.info/screencasts ? https://www.youtube.com/results?search_query=gmsh+tutorial > > 3. Are the demos at http://gitlab.onelab.info/gmsh/gmsh/tree/master/demos any > help in learning the UI? Do the demos proceed step-by-step or do they > simply execute at once the construction commands that they contain? The repository contains many examples; some were written using the GUI (when you create stuff with the GUI, a .geo file is automatically constructed). But for most complex cases you'll want to learn how to either use the built-in scripting language (.geo files), or the Gmsh API - e.g. in Python or Julia. > > 4. Finally, Are there other forums where I may interact with experienced gmsh > users besides this list? > Most of the technical discussions about features and issues are now happening in the gitlab (https://gitlab.onelab.info/gmsh/gmsh/issues). At some point I think this could actually replace the mailing list. Christophe > Kind regards, > Randal — Prof. Christophe Geuzaine University of Liege, Electrical Engineering and Computer Science http://www.montefiore.ulg.ac.be/~geuzaine ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Using OpenCASCADE Boolean to create transfinite surfaces (Boundary) which maintain Transfinite mesh
> On 10 Mar 2020, at 15:57, William Logie wrote:
>
> Dear Gmsh Members,
>
> I was wondering if anyone can recommend a way for me to create Transfinite
> Surfaces with the OpenCASCADE kernel which then can be relocated in space
> (translated/rotated) while maintaining the Transfinite Mesh defined on
> original curves/surfaces or created through extrusion?
That's not supported (at least not yet).
The meshing constraints for OpenCASCADE shapes are actually stored as
attributes linked to the geometrical location of the entities (and their
bounding box). We could move/modify the attributes when a shape is transformed,
but it's going to be at best a partial solution (like
Geometry.CopyMeshingMethod for the built-in kernel, which only deals with
transfinite constraints - extrusions cannot be copied, as the geometrical
transformation is provided explicitly.)
Christophe
>
> My reasons for using OCC is to piece together volumes (various pipe
> extrusions), then remove internal surfaces between them with BooleanUnion,
> and finally delete the Volume (and ends) to leave a surface shell.
>
> Here, a MWE:
>
> // UNITS mm
> SetFactory("OpenCASCADE");
> Geometry.CopyMeshingMethod=1;
> Mesh.CharacteristicLengthMin=0.1;
> Mesh.CharacteristicLengthMax=0.3;
>
> theta = Pi*30/180;
>
> // Create OCC disk, define circumference as Transfinite Curve and Extrude
> Disk(1) = {0, 0, 0, 0.5};
> Transfinite Curve{1} = 30;
> Extrude {{1, 0, 0}, {0, -10, 0}, theta} {
> Surface{1}; Layers{20}; Recombine;
> }
> Extrude {{1, 0, 0}, {0, 10, 0}, theta} {
> Surface{1}; Layers{20}; Recombine;
> }
>
> // Transfinite Cyclinder Surface Mesh is lost with Translate, Rotate or
> Affine, despite Geometry.CopyMeshingMethod=1 being set, e.g.:
> Affine {Cos(theta),Sin(theta),0,0, -Sin(theta),Cos(theta),0,0, 0,0,1,0}
> {Volume{1,2};}
>
> Many Thanks,
> Will.
> --
> William Logie
> PhD Candidate
> Research School of Engineering
> The Australian National University
> Canberra ACT 2601
> ___
> gmsh mailing list
> gmsh@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
___
gmsh mailing list
gmsh@onelab.info
http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] BUG (??) in version 4.5.6
> On 5 May 2020, at 12:34, miguel.ar...@artorg.unibe.ch wrote: > > Dear all, > > I was using a code I developed in version 4.4 for meshing spheres with > tetrahedron. I could modify the characteristic length (max. and min.) and it > worked perfectly. > > Moreover, I’ve been using this code in different incremental updates and it > worked perfectly until version 4.5.3. Yesterday, I updated to version 4.5.6 > and the code continues working but with a strange behavior. > > Let’s say that I was using a characteristic length of 0.2 for meshing a > sphere, in version 4.5.3 this resulted in ~70k elements. Now, with the same > characteristics, this results in 1.000.000 elements! > > No matter what I tried, it seems that GMSH’s response was invariant: > • Activate/deactivate the optimization of the mesh (it did not change > anything) > • Modify the characteristic length up to 2 or 4 (it did not change > anything). Also, I debugged to be sure that these were the actual values that > GMSH received > • Try to use a bias in the mesh. Nothing > > Perhaps, I missed a major modification in the code from 4.5.3 to 4.5.6 and I > need to re-code my libraries… but… Could it be a bug in the code? If so, > where? In the meantime, I downgraded to version 4.5.3. > Could you send a simple example so that we can test? Christophe > Tested in: > • W10 > • Ubuntu 18.04 in WSL (W10) > • Ubuntu 18.04 > > Best, > > MA > _______ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] GMsh python API: all all point tags of volume
> On 5 May 2020, at 06:15, Tian Xia wrote: > > Hi, > > First of all, I'd like to thank you for the great software. It saved me a lot > of time. > > I am trying to define a mesh size field based on the distance to the volume. > I knew that there is a command "PointsOf(volume #)" for geo file. Is there a > similar function in the python API? Thanks! You can use gmsh.model.getBoundary(volume, recursive=True) Christophe > > -- > Tian > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] STL Mesh generation surfaces with inward normalnot meshed?!
> On 12 May 2020, at 17:50, Zuheyr Alsalihi wrote: > > Dear colleagues, > > I could not easily describe the problem. > > A rectangular slab step file that I have generated, attached CG1.step, shows > the top and bottom surfaces inward normal. > I am not able to reverse this. > But the surface is there, see Pic1.png. When I create an STL mesh with GMSH > gmsh-4.5.6-Linux64/bin/gmsh > these 2 surfaces are not meshed. Can you please help me understand and solve > this problem? Somehow OpenCASCADE badly translates surface 5 in the STEP file. See attached .brep of the offending surface: all point evaluations within the surface are (wrongly) evaluated on a plane parallel to the surface, but translated. You should report this bug to the OpenCASCADE developers and attach the STEP file. Christophe debugSurface.brep Description: Binary data > Many thanks for reading. > Kind regards, > Zuheyr > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Scaling all the entities of a step file
> On 23 May 2020, at 09:26, Zuheyr Alsalihi wrote: > > Dear Christophe, Dear GMSH users, > > I need to create a script, or commandline option to read a step file, and > scale the complete model with the purpose of converting the model from mm to > m. > Set Geometry.OCCTargetUnit = "M"; before merging the step file. Christophe > I tried to do transform all the geometrical entities with dilate command, > save it to a .geo file but run into error message, such as: > Error : Unknown GEO point with tag 5 > Error : Unknown GEO point with tag 3 ... > > practically all points. I attach the step file, the written out incomplete > geo file (I used duplicate option), and the errors generated. > > I can mesh the step file and generate an STL grid perfectly well. > > Many thanks for reading! > > Best regards, > Zuheyr > > > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Transfinite Line & SetSize with API on Python
> On 3 May 2020, at 01:55, Michel Cassagnes wrote: > > Dear all, > > I need some help to make a transfinite line and set size at points work with > the API on Python. > > I made many tests and many looks in examples and doc but I don't find how to > handle all this. > > Please find enclosed an example that doesn't give anything for the line > entered as transfinite with 10 points (take care to change the working folder > at the begining of the script). > > Maybe there is a conflict with other definitions of mesh size (filelds, > characteristic length at points, etc). > Your last call to gmsh.model.geo.synchronize() resets the meshing attributes of the curve. Either remove it (it's useless anyway), or set your meshing contraints within the "geo" kernel, with "gmsh.model.geo.mesh.setTransfiniteCurve()" instead of "gmsh.model.mesh.setTransfiniteCurve()". Christophe > Thank you. > > Best regards, > > Michel Cassagnes > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Transfinite Line & SetSize with API on Python
> On 3 May 2020, at 12:09, Michel Cassagnes wrote: > > Hi Christophe, > > I have modified the script, see attached. > > What works for TransfiniteCurve is : > - remove geo.synchronize > - keep gmsh.model.mesh.setTransfiniteCurve() > > But setSize is not affected by removing geo.synchronize. Is this command > ignored if Mesh.CharacteristicLengthFromPoints is set to 0 ? Yes. This is exactly the same behavior as in .geo files. Christophe > > What is wrong in my script ? > > Thank you! > > Michel > > > > > > Le dim. 3 mai 2020 à 11:04, Michel Cassagnes a > écrit : > > Ok! Thank you very much Christophe. > > Best regards, > > Michel Cassagnes > > Le dim. 3 mai 2020 à 08:45, Christophe Geuzaine a écrit > : > > > > On 3 May 2020, at 01:55, Michel Cassagnes > > wrote: > > > > Dear all, > > > > I need some help to make a transfinite line and set size at points work > > with the API on Python. > > > > I made many tests and many looks in examples and doc but I don't find how > > to handle all this. > > > > Please find enclosed an example that doesn't give anything for the line > > entered as transfinite with 10 points (take care to change the working > > folder at the begining of the script). > > > > Maybe there is a conflict with other definitions of mesh size (filelds, > > characteristic length at points, etc). > > > > Your last call to gmsh.model.geo.synchronize() resets the meshing attributes > of the curve. Either remove it (it's useless anyway), or set your meshing > contraints within the "geo" kernel, with > "gmsh.model.geo.mesh.setTransfiniteCurve()" instead of > "gmsh.model.mesh.setTransfiniteCurve()". > > Christophe > > > > > Thank you. > > > > Best regards, > > > > Michel Cassagnes > > ___ > > gmsh mailing list > > gmsh@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 > > > > — Prof. Christophe Geuzaine University of Liege, Electrical Engineering and Computer Science http://www.montefiore.ulg.ac.be/~geuzaine ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Scripting multiple views in one picture
> On 27 Aug 2020, at 21:26, Max Orok wrote: > > Hi Zuheyr, > > I assume you're talking about the Window->Split Horizontally command in the > GUI? > I took a quick look, it's possible this command is either undocumented or not > exposed (yet) through the scripting interface. Indeed, this was missing. It has been added in the latest development snapshot: see https://gitlab.onelab.info/gmsh/gmsh/-/blob/master/benchmarks/misc/split_window.geo https://gitlab.onelab.info/gmsh/gmsh/-/blob/master/demos/api/split_window.py for examples. Christophe > As a workaround, you could perhaps create view snapshots one at a time and > paste them together with some image processing tool. > > Tutorial 8 (also available in C++ and Python) shows how to rotate the camera > in a view. > http://gmsh.info/doc/texinfo/gmsh.html#t8 > > Sincerely, > Max > > On Thu, Aug 27, 2020 at 1:54 PM Zuheyr Alsalihi wrote: > Dear Gmsh creators, experts, > > How can I script to split the view in 2 like a technical drawing, view from > right on the left side, view from left on the right side, in a split view? Or > can I embed a previous view to a small frame somewhere in the main view? > Many thanks for reading! > > Best wishes. ___ > gmsh mailing list > gmsh@onelab.info > http://onelab.info/mailman/listinfo/gmsh > > > -- > Max Orok > Contractor > www.mevex.com > > > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Question about adding new solver in onelab
> On 27 Aug 2020, at 03:15, cean wang wrote: > > Sorry last post seems not working. It says An HTML attachment was > scrubbed..., So I try to post with another email program. Here it is. > > > > > > I opened myinput.dat with gmsh and clicked on my solver to solver it, got a > message saying: > > > Calling ‘“d:\mysolver.exe” -onelab “mysolver” 127.0.0.1:53927’ > > Abnormal server termination(Socket listening timeout on socket 127.0.0.1:0) > > > I was expecting something like Calling ‘“d:\mysolver.exe myinput.dat”. Like > run in an terminal. > > > Just wondering does a normal solver exe could be called directly? Or have to > be modified like the Double pendulum in C++ demo solver? But my solver is an > Fortran program. > The goal of the ONELAB interface is to provide a simple communication layer between the solver(s) and Gmsh. You could e.g. take the simple Python solver example, and call your Fortran code from there with a simple system call. Since the Python code will have access to the ONELAB parameters, you could use it to generate the input file for your Fortran solver. Christophe > > > From: Max Orok > Sent: Tuesday, August 25, 2020 8:18 PM > To: cean wang > Cc: Gmsh > Subject: Re: [Gmsh] Question about adding new solver in onelab > > > It's in the options list, to get to the list: > > Open Gmsh -> Help -> Current Options and Workspace > > Edit the value > > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Negative Jacobians in 2nd Order Mesh
> On 4 Sep 2020, at 13:49, Nikhil Vaidya wrote: > > Hello, > > I have a geometry for which 1st order tetrahedral meshing works fine (with no > negative jacobians). For the 2nd order case, I get a few negative jacobians. > This problem does not go away even when I try to regularize the mesh or > reduce mesh sizes in certain regions with small geometric features. > > Does someone have a suggestion? Try the high-order mesh optimizer: "-optimize_ho" on the command line. Christophe > > Best regards, > Nikhil > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Points not used by tetrahedrons
> On 7 Sep 2020, at 16:05, Tian Xia wrote: > > Dear all, > > I am generating 3D tetrahedron mesh using gmsh Python API. I found some > points are not used by the tetrahedrons. Is there a simple way to remove > these points when exporting the *msh file? Yes: define a physical group (here a physical volume) for the entities you want to save, and Gmsh will only save nodes/elements discretizing those entities. Christophe > > Best Regards, > Tian > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] [Gmsh ]One layer of solid elements through thickness instead of two
> On 8 Oct 2020, at 08:37, Pawel Kudela wrote: > > Dear Gmsh community, > > Do you know how to force gmsh to produce only one layer of hexahedral > elements through the thickness of the thin-walled structure like in the > attached example? I want to have only one layer of linear elements which will > be than converted to higher order spectral element type. > > 3D meshing always produces two elements even though 1 layer is set in extrude > operation. > You get 2 elements in the layer because of the Mesh.SubdivisionAlgorithm = 2; // 1: all quadrangles; 2: all hexas command, which subdivides the mesh (to get a full quad/hex mesh). There's active work on new quad meshing tools, so hopefully this limitation will disappear in the future. Christophe > Regards, > > Pawel > > -- > > Polish Academy of Sciences > Institute of Fluid-Flow Machinery > Centre for Mechanics of Machines > Mechanics of Intelligent Structures Department > Fiszera 14 St, 80-231 Gdansk > tel. +48 58 5225 251 > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Transfinite 3D meshing
Wd/2+tol, Ld/2+tol, dim = 2)
> p = model.addPhysicalGroup(2, [s[i][1] for i in range(len(s))])
> model.setPhysicalName(2, p, "outlet")
> print("outlet = ", len(s))
> for co in c_out:
> gmsh.model.geo.mesh.setTransfiniteCurve(co[1], 20)
> p = model.addPhysicalGroup(1, [c_out[i][1] for i in range(len(c_out))])
> model.setPhysicalName(1, p, "outlet_curve")
>
> for si in s_no_slip:
> gmsh.model.geo.mesh.setTransfiniteSurface(si)
>
> # VOLUME
> s = model.getEntities(3)
> p = model.addPhysicalGroup(3, [s[i][1] for i in range(len(s))])
> model.setPhysicalName(3, p, "air")
>
> for vi in [s[i][1] for i in range(len(s))]:
> gmsh.model.geo.mesh.setTransfiniteVolume(vi)
>
> gmsh.model.geo.synchronize()
>
> # MESH 3D
> model.mesh.generate(3)
> #model.mesh.recombine()
>
> gmsh.write("SquareDuct.msh")
> gmsh.finalize()
>
>
> Best regards
>
> Bruno Agostini
>
>
> ___
> gmsh mailing list
> gmsh@onelab.info
> http://onelab.info/mailman/listinfo/gmsh
>
>
> --
> Max Orok
> Contractor
> www.mevex.com
>
>
> ___
> gmsh mailing list
> gmsh@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
___
gmsh mailing list
gmsh@onelab.info
http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] How are set up U and V vectors for elements ?
> On 5 Oct 2020, at 07:05, bi...@netc.it wrote: > > Hello. I'm trying to parse a mesh.msh generated by gmsh. > > I work with 9-quad elements. I see in documentation that inside of the > elements, nodes are ordered like this : > >v >^ >| > 3---6---2 > | | | > | | | > 78---5 --> u > || > || > 0---4---1 > > I made a 2D mesh (all surfaces normals are oriented in the same direction) > > When i look at my 2D mesh (in plan XY) the element 265 : > 265 2 44 1047 533 49 1102 1103 544 1104 > > is oriented like this related to the golbal X and Y axis > > ie, when looking at the screen i see: > 44---49---2 > | | | Y > | | | ^ > 1102 1104544| > | | | | > | | | | > 1047--1103533x--> X > > it seems that u anv v vectors are oriented like this : > 1-4-0 > || | > || | > u <---5-8 7 > || | > || | > 2-6-3 > | > V > v > > > How are V and U vectors defined for each element ? It depends on the definition of the surface and the meshing algorithm. > Is there a way to orient them along the natural X and Y axis ? With the transfinite algorithm you could force the elements to be generated in a certain order by specifying the interpolation corners. But in general you won't know the correspondance - Gmsh produces unstructured meshes! So you would use the (u,v,w) -> (x,y,z) mapping (through e.g. Lagrange basis functions) to make the connection. Christophe > > Thanks > > > > > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Question about adding new solver in onelab
> On 21 Aug 2020, at 02:44, cean wang wrote: > > Hi, > > I am using gmsh 4.5.6 win version. > > I have a fea program (myfea.exe), it runs in a DOS Terminal with the > following command: > > c:/myfea myinput.dat > > myinput.dat includes mesh and boundary conditions. It could be opened by gmsh > and show the mesh correctly. myfea.exe will save the result in an msh file. I > added a new solver in gmsh and specified where myfea.exe is. When I run the > solver, gmsh seems to try to mesh the domain and overwrite myinput.dat file. > The result is myfea.exe can't myinput.dat anymore . > > Wondering how do I disable the meshing, just do the solve? > Set the "Solver.AutoMesh = 0" option. Christophe > Regards, > > Cean > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] $NodeData in msh file ver 4.1
Dear Cean, > On 23 Aug 2020, at 03:59, cean wang wrote: > > Hi, > > Here is a test msh file which has 9 Vector values in $NodeData section. > > When opened with gmsh 4.6.0, it shows 6 vector arrows in element center. I > thought it should show 9 arrows at the 9 nodes. What I have done wrong? By default Gmsh draws vectors at the barycenter of the elements. To draw the arrows at the nodes: Tools->Options->View->Aspect->Glyph location->Node. > > And in Option - View[0] window, Visibility tab, Fields, at the bottom, I > could switch to Force Scalar, the result looks weird - not cover the whole > domain. What's the number (0-8) on its right used for? This option allows to draw any component(s) of the field as a scalar, a vector or a tensor. If you select "Force scalar" and select 0 for the first (and only relevant, for a scalar field) component, you will thus draw the first component (index 0, i.e. the "x" component) of your vector field as a scalar field. The scalar field will be displayed with the same range bounds as the vector field (computed from its norm); hence the "truncation" that you observe. Just set the "min" and "max" values of the range in Tools->View->General->Range mode->Custom. (You can click on the "Min" and "Max" button to automatically recompute the min/max for your particular choice of values to display.) Christophe > > Regards, > > Cean > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] joining arrow tips
> On 23 Jul 2020, at 16:25, mepl wrote:
>
> Dear Prof
>
> We have much fun using gmsh for our work. Tq.
>
> I have a question. How to join a line at the tip of the arrow end of two
> vector points.
>
> VP(154838.900,411610.900,22293.990) {5.0,0.0,0.0};
> VP(153031.800,431557.500,27910.500) {-2.0,0.0,0.0};
> SL(154843.900,411610.900,22293.990,153029.800,431557.500,27910.500) {5.0,
> -2.0};
>
> When I change the arrow size, the line should still connected at the arrow
> tip.
>
Tools->Options->View->Aspect->Glyph location: "Right aligned" should do what
you want. (In a script: View.CenterGlyphs = 2)
Christophe
> Thank you in advance for your advice.
>
> Best Regards,
> Dr. YP Phang
> Managing Director
>
> Multimedia Engineering Pte. Ltd.
> 50 Bukit Batok Street 23#05-15, Midview Building, Singapore 659578.
> T(65) 6765 6288
> F(65) 6765 1588
> E m...@me.com.sg
> W www.me.com.sg
>
>
> ADAS® Tensile Membrane · ETFE Skylight· Fabric Façade · Spaceframe ·
> Specialized Systems
>
>
> Virus-free. www.avast.com
> _______
> gmsh mailing list
> gmsh@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
___
gmsh mailing list
gmsh@onelab.info
http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] question
> On 20 Jul 2020, at 10:28, Jean-François Remacle > wrote: > > hello > > gmsh has not (yet) that capability > Note that for geometries created with the built-in geometry kernel, you can extrude the geometry along the surface mesh normals. This can provide an alternative for simple geometries: see e.g. https://gitlab.onelab.info/gmsh/gmsh/-/blob/master/benchmarks/extrude/sphere_boundary_layer.geo Christophe > JF > >> Le 18 juil. 2020 à 19:05, George Bourantas a >> écrit : >> >> Hi All, >> >> How to generate a tetrahedral mesh with boundary layers? >> >> Thank you in advance. >> >> G. >> ___ >> gmsh mailing list >> gmsh@onelab.info >> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fonelab.info%2Fmailman%2Flistinfo%2Fgmshdata=02%7C01%7Cjean-francois.remacle%40uclouvain.be%7C293104fe733efcd008d82b3fb908%7C7ab090d4fa2e4ecfbc7c4127b4d582ec%7C0%7C0%7C637306900442035546sdata=YfhIzsSyiaf7BQx3Her0gU0IauD7BuCD8Q4NVfTb9NI%3Dreserved=0 > > -- > Prof. Jean-Francois Remacle > Universite catholique de Louvain (UCL) > Ecole Polytechnique de Louvain (EPL) - Louvain School of Engineering > Institute of Mechanics, Materials and Civil Engineering (iMMC) > Center for Systems Engineering and Applied Mechanics (CESAME) > Tel : +32-10-472352 -- Mobile : +32-473-909930 > > > > > > > > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Questions about parallelization using python API
> On 19 Jul 2020, at 20:15, Kadry Abdelmeguid Karim Hesham Ahmed > wrote: > > Hello, > I'm a new user to Gmsh > I am a bit confused on how to enable parallelization when I am using the > Python API for Gmsh. > I see on the documentation that I am supposed to compile with Enable OpenMP > and compile using Cmake but since I have installed gmsh through the pip > command I'm not sure if I should try and build in my anaconda directory > directly. Indeed currently our binary builds are compiled without OpenMP support (we haven't yet found a good way to distribute those in a simple way). So you'll have to recompile Gmsh from source : see e.g. https://gitlab.onelab.info/gmsh/gmsh/-/wikis/Gmsh-compilation Christophe > Thank you! > Karim, > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Periodic Surface Error: Different number of points for periodic correspondance between surfaces.
> On 22 Jul 2020, at 12:26, lucia.cobian wrote:
>
> Dear all,
>
> I am trying to build a periodic mesh for a complex geometry, made by
> cylinders, which is bounded by a cube (Boolean intersection). To do the
> periodic mesh I have used Periodic Surface {} = {} Translate {} command to
> make it periodic in the three opposite surfaces (xy,xz,yz) of the intersected
> cube, as indicated in the attached .geo file.
>
> However, I receive the following errors:
>
> “No corresponding point x for periodic connection of surface xx to yy” or
> “Different number of points (a vs b) for periodic correspondence between
> surfaces aa and bb”.
>
> I have tried to fix the error without any success. I would like to know why
> is this happening and how can the .geo file be modified to fix the problem.
>
> I would appreciate if someone could help me with this issue.
Nothing guarantees that the surfaces you get by querying by bounding box (e.g.
topx() and bottomx()) will be returned in the same order.
See the solution proposed in tutorial 18
(https://gitlab.onelab.info/gmsh/gmsh/-/blob/master/tutorial/t18.geo).
Christophe
>
> Thank you very much,
>
> Lucia___
> gmsh mailing list
> gmsh@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
___
gmsh mailing list
gmsh@onelab.info
http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] 2D Mesh (P2) has some reverse ordering, negative determinants
> On 15 Aug 2020, at 10:52, Marc wrote:
>
> Hello all,
>
>
>
> Not sure if this is a bug, but I have been trying to figure out where some
> weird results are coming from and I think it is because some elements in the
> meshes are ordered in reverse, some of the time. Here is a simple example:
One of your surfaces is oriented along +z, the other along -z. The mesh follows
the orientation of the geometry, so the result is correct.
Change the definition of Plane 2 as follows
Plane Surface(2) = {2, 1};
to get something coherent.
Christophe
>
>
>
> // Gmsh project created on Fri Aug 14 22:33:15 2020
> //+
> Point(1) = {0, 0, 0, 0.5};
> //+
> Point(2) = {0.4, 0.2, 0, 0.5};
> //+
> Point(3) = {0.6, 0.2, 0, 0.5};
> //+
> Point(4) = {1., 0, 0, 0.5};
> //+
> Point(5) = {1., 1., 0, 0.5};
> //+
> Point(6) = {0., 1., 0, 0.5};
> //+
> Point(7) = {0.4, 0.4, 0, 0.5};
> //+
> Point(8) = {0.6, 0.4, 0, 0.5};
> //+
> Line(1) = {1, 4};
> //+
> Line(2) = {4, 5};
> //+
> Line(3) = {5, 6};
> //+
> Line(4) = {6, 1};
> //+
> Line(6) = {2, 3};
> //+
> Line(7) = {3, 8};
> //+
> Line(8) = {8, 7};
> //+
> Line(9) = {7, 2};
> //+
> Curve Loop(1) = {9, 6, 7, 8};
> //+
> Plane Surface(1) = {1};
> //+
> Curve Loop(2) = {4, 1, 2, 3};
> //+
> Plane Surface(2) = {1, 2};
> //+
> Physical Curve("zero") = {4};
> //+
> Physical Curve("one") = {9, 8, 7, 6};
> //+
> Physical Surface("main") = {2, 1};
>
>
>
> In my case, I am doing this with second order triangles. The following
> elements are reverse ordered:
>
> 25
> 26
> 27
> 28
> 29
> 30
> 31
> 32
> 33
> 34
> 35
> 36
> 37
> 38
> 39
> 40
> 41
> 42
> 43
> 44
> 45
> 46
>
> According to the documentation in section "9.2.2 High-order elements": The
> orientation of a face is such that the computed normal points outward; the
> starting point is the node with the lowest index.
>
> But if the mesh is strictly 2D and all on one plane, I would expect the code
> to give all elements the same normal direction. In my example the hole and
> the main square have different normal directions. I think this is unexpected
> behaviour.
>
> I am using 4.6.0
>
> Thanks for all your great work!
>
> Regards,
>
> Marc
>
>
>
>
>
>
>
>
>
> ___
> gmsh mailing list
> gmsh@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
___
gmsh mailing list
gmsh@onelab.info
http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Coherence 'could not find extruded vertex' error
Dear Bart,
What are you trying to achieve? As Jeremy explained, your geometry is
non-conformal. Do you want to create a conformal mesh? If so you'll need to
have a conformal geometry first.
Christophe
> On 17 Aug 2020, at 10:16, Bart Deschoolmeester
> wrote:
>
> Hello,
> Sorry to bother everybody again.
> I’m a beginner and I seem to run in on one error after another. I’m using
> GMSH 4.7.0 (I came across GMSH trough the onelab website) on Windows 10.
>
> See the script below (from a bigger 3D project where I try to narrow down the
> errors I get).
> I get a good 3D mesh but at the curve where the two objects meet, the mesh is
> not aligned.
> Using the coherence command I get a large list of errors of the type:
> Error : could not find extruded vertex (0.08443279255020152,
> -0.053826794978966, 0).
>
> Yet, if I change the point y-coordinates to a positive number:
>Point(23) = {0, 0.1, 0};
> Point(24) = {0, 0.05, 0};
> Point(25) = {0, 0.05, WanD};
> Point(26) = {0, 0.1, WanD};
>
> All works as expected.
>
> Thanks for the help.
> Bart
>
>
> ---
>
> KanR = DefineNumber[ 0.1, Name "Parameters/KanR" ];
> WanD = DefineNumber[ 0.2, Name "Parameters/WanD" ];
> KanMeshsize = DefineNumber[ 0.01, Name "Parameters/KanMeshsize" ];
> SetFactory("OpenCASCADE");
> Rectangle(1) = {-2.5, -2.5, 0, 5, 5, 0};
> Circle(5) = {0, 0, 0, KanR, 0, 2*Pi};
> Curve Loop(2) = {5};
> Plane Surface(2) = {2};
> BooleanDifference{ Surface{1}; Delete; }{ Surface{2}; Delete; }
> Extrude {0, 0, WanD } {
> Surface{1};
> }
>
> Point(23) = {0, -0.1, 0};
> Point(24) = {0, -0.05, 0};
> Point(25) = {0, -0.05, WanD};
> Point(26) = {0, -0.1, WanD};
> Line(32) = {23, 24};
> Line(33) = {24, 25};
> Line(34) = {25, 26};
> Line(35) = {26, 23};
> Curve Loop(30) = {34, 35, 32, 33};
> Plane Surface(14) = {30};
> Extrude {{0, 0, 1}, {0, 0, 0}, Pi} {
> Surface{14}; Layers{25};
> }
>
> Field[1] = Distance;
> Field[1].EdgesList = {5};
> Field[1].NNodesByEdge = 50;
> Field[2] = Threshold;
> Field[2].DistMax = 2.5;
> Field[2].DistMin = 0;
> Field[2].IField = 1;
> Field[2].LcMax = 0.25;
> Field[2].LcMin = KanMeshsize ;
>
> Background Field = 2;
>
> Mesh.CharacteristicLengthExtendFromBoundary = 0;
> Mesh.CharacteristicLengthFromPoints = 0;
> Mesh.CharacteristicLengthFromCurvature = 0;
> ___
> gmsh mailing list
> gmsh@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
___
gmsh mailing list
gmsh@onelab.info
http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Comparison of different meshes
> On 14 Aug 2020, at 16:16, Rohracker, Maurice wrote: > > Dear GMSH user and developer, > > I created two meshes for a box with a spherical inclusion around the origin, > one with tetrahedra and one with hexahedra. For both, I created a simple load > case in Abaqus and compared both results in a short report (see attached). In > the report, a more detail explanation of the load case is given as well. > > Do you have any idea, why in the hexahedral case, the stress results are not > that smooth like in the tetrahedral case? Could it be that I missed some > option while creating the hexahedral mesh? Are there any options which could > improve the mesh and such also the results? Or are these things related to > the simulation I am doing? > A hex mesh generated by subdivision of of course of very poor quality... For a simple geometry like the one you tested, you should create your hex mesh using a structured approach (see e.g. gmsh/benchmarks/3d/sphere_hexa.geo). Christophe > Do you have any similar experience with such behaviour? > > We are using GMSH 4.4.1. > > If you need more information, please let me know. > > Thank you very much in advance. > > Best regards, > Maurice Rohracker > Master Computational Engineering > FAU > Erlangen-Nürnberg___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] integration, spikes
> On 5 Aug 2020, at 10:12, t.esch...@dokom.net wrote: > > Dear all, > > trying to get acquainted with gmsh/getdp, I stumbled upon two problems that I > am not able to resolve. > > I am trying to model a simple conductive cell with two electrodes, a simple > one and a structured one. To me, the results look quite realistic so far (I > am still in the stage of checking), with two exceptions: > > The first: When I try to calculate the overall current by calling > plugin(Integrate) on views slightly above the simple electrode, I get two > different results (for the vector view -8,88 and the x-component view -39,9), > and neither is close enough to the expected value of -2x(4,94..4,99). Be careful with brute-force integration. If you use GetDP would recommend using global quantities, which define such integrals in the "variationally correct" way: see e.g. https://gitlab.onelab.info/doc/tutorials/-/wikis/Electrostatics-with-floating-potentials > > The second: The current density field has few spiky values that I do not know > how to cure. Their position seems to be constant, the values seem to change > with the grid parameters, and it might be getdp-related. With a (scalar) potential formulation your current density is defined through the gradient, whose accuracy will depend quite strongly on the mesh quality. You can give the new "HXT" 3D algorithm a try, whose optimizer produces slightly better elements, and see if this improves things. Christophe > > Please, have a look and give me a hint on how to correct/proceed. Thank you. > > Kind regards, Thomas > > > > > > _______ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] GRegion meshsize
> On 22 Sep 2020, at 08:27, Steffè Walter > wrote: > > Hello Christophe, now I have a doubt about the implementation of the Netgen > interface. > > Lc is computed with : > SPoint3 pt = gr->bounds().center(); > double lc = BGM_MeshSize(gr, 0, 0, pt.x(), pt.y(), pt.z()); > > But what happens if the region has a hole in the center and the center point > does not belong to the region ? It shouldn't matter, as it will fallback on gr->getMeshSize(). > > Walter > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] building of gmsh on mingw64
Hi Walter,
ENABLE_OCC_STATIC should actually not be needed anymore. Can you try the latest
Git master, in which CMAKE_FIND_LIBRARY_SUFFIXES and PATH_SUFFIXES have been
modified? If it doesn't work let's try to understand why and open an issue in
our Gitlab about it.
Christophe
> On 22 Sep 2020, at 20:03, walter wrote:
>
> Hello,
> I am used to build my application (EmCAD) and gmsh on Msys2/MINGW64 platform.
>
> Today I made a small change to the main CMakeLists.txt file of
> gmsh-4.6.0-source.
> This change fixes the following problem:
> cmake/configure is not able to find the OCC libraries on Msys2/MINGW64
> platform even if CASROOT is properly set.
>
> This problem arises because:
> 1) on Msys2/MINGW64 platform the OCC libraries are located in the following
> folders
>
> $CASROOT/${OCC_SYS_NAME}/gcc/lib >> dll.a libraries
> $CASROOT/${OCC_SYS_NAME}/gcc/bin >> dlllibraries
>
>
> So I made the following small changes:
>
>
> line 12179 to 1273
>if(ENABLE_OCC_STATIC)
> set(LIBNAME lib${OCC}.a)
>else()
> set(LIBNAME ${OCC})
>endif()
>
> is replaced by:
>if(ENABLE_OCC_STATIC)
> if(MINGW)
> set(LIBNAME lib${OCC}.dll.a)
> else()
> set(LIBNAME lib${OCC}.a)
> endif()
>else()
> set(LIBNAME ${OCC})
>endif()
>
>
> line 1284 to 1285:
>find_library(OCC_LIB ${LIBNAME} HINTS ENV CASROOT PATH_SUFFIXES
> lib ${OCC_SYS_NAME}/lib ${OCC_SYS_NAME}/vc8/lib)
>
> is replaced by:
>find_library(OCC_LIB ${LIBNAME} HINTS ENV CASROOT PATH_SUFFIXES lib bin
> lib ${OCC_SYS_NAME} ${OCC_SYS_NAME}/vc8
> ${OCC_SYS_NAME}/gcc )
>
>
> line 1306 to 1307:
>find_library(OCC_CAF_LIB ${OCC} HINTS ENV CASROOT PATH_SUFFIXES
>lib ${OCC_SYS_NAME}/lib ${OCC_SYS_NAME}/vc8/lib)
>
> is replaced by:
>find_library(OCC_CAF_LIB ${OCC} HINTS ENV CASROOT PATH_SUFFIXES lib bin
>lib ${OCC_SYS_NAME} ${OCC_SYS_NAME}/vc8
> ${OCC_SYS_NAME}/gcc)
>
>
> -bin has been added to PATH_SUFFIXES in both calls to find_library.
> -${OCC_SYS_NAME}/gcc subfolder explitely added to ${OCC_SYS_NAME}/vc8
> -lib was removed from some explicit subfolders because it is already appended
> by PATH_SUFFIXES
>
> With this change, when the option ENABLE_OCC_STATIC is activated on a
> Msys2/MINGW64 platform, gmsh is linked with libTKernel.dll.a ...
>
> libTKernel.dll.a is an import library in the microsoft world.
> I think that this kind of library is meant to import the libTKernel.dll
> library placed in the gcc/bin folder.
> I do not know if it make any difference with direct linkage to the dll.
>
>
> Walter
>
>
>
>
>
> ___
> gmsh mailing list
> gmsh@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
___
gmsh mailing list
gmsh@onelab.info
http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Remeshing of deformed meshes and tracking of subdomains
Hi Tim, > On 29 May 2020, at 17:30, Tim Furlan wrote: > > Dear gmsh users and developers, > > i am dealing with high-deformation FEM simulations involving contact. I would > like to replace the deformed mesh with a new one after a certain number of > steps (potentially many times during one simulation). I use Abaqus as the FEM > solver if it matters, and use the python api of gmsh. > > For the remeshing, i create geometrical surfaces for all faces of my elements > on the boundary of the domain. This means also creating lines for all element > edges and keeping track of them, since they might occur more than once and > with different directions. > > I need to track certain subdomains (e.g. parts of the surface) to impose the > boundary conditions, and the solution i came up with is to compound the > corresponding surface faces and their respective boundaries (to allow both > refinement and coarsening). To do this, i need to split the boundaries of the > subdomains in a lot of segments (so that they end when a domain ends). > > Tracking the subdomains only through physical tags seems unfeasible since the > subdomain boundaries are then only preserved inaccurately. > It's indeed a "classical" problem. I don't think there's a definitive answer about whether it's better to change/reconstruct the CAD and/or deform/untangle/adapt the mesh. > I feel that i might be missing an easier way to do what i want. I looked into > the tutorials and found the following options: > > - The createGeometry() command is able to create geometry from a mesh > (basically doing what i do by hand i guess?). However, i did not find an easy > way to track boundary conditions using this, as i can not rely on identifying > them by feature angles. Is there any way to obtain the elements the resulting > entities are derived from? > > - The tutorial on meshing of discrete curves looks like it follows a similar > approach. However, i was unable to extend this approach to 3d surfaces. Is it > possible to define discrete entities for the different parts of the body > surface i want to remesh instead of using compounds? I was especially > confused with how to handle e.g. element edges that belong to multiple > surface parts. > You should be able to do this indeed, i.e. define discrete surfaces after deformation and remesh those. Maybe send a small example? It might be better to open an issue on the gitlab for this, so that we can track progress. Christophe > I would appreciate any input on a more elegant/efficient way to solve the > problem. > > > Kind regard and thanks in advance > > Tim > > > > > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Forcing all jacobians to be positive
> On 29 May 2020, at 20:48, Carole-Anne Daunais > wrote: > > Hi, > I am using GMSH 4.5.6 to generate a 3d mesh. I used the following 2 lines in > the .geo file to ensure that no element would have a jac.<0. > > Mesh.ElementOrder = 2; > Mesh.HighOrderOptimize = 1; > > It unfortunately didn't work for me. The mesh is generated, but the software > failed (froze). Is there another way I can force all jacobians to be positive > when creating my mesh? > It works fine here. However you should remove "Mesh.SubdivisionAlgorithm = 2;" (and set the sizes you want directly), as this makes it harder for the optimizer. You can also use "Mesh.HighOrderOptimize = 2;", which will apply a global elastic smoothing step before the brute-force optimization. Christophe > Thank you, > > Carole-Anne > > > > > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] GRegion meshsize
Sear Walter,
Indeed, good idea. This has been merged, but with a different implementation
for the Netgen interface, directly calling the overall mesh size evaluation.
Let me know if it behaves as expected.
Christophe
> On 20 Sep 2020, at 17:37, walter steffe wrote:
>
> In order to better support my application (see
> hierarchical-electromagnetics.com) I made the following small changes to gmsh
> sources (version 4.6.0):
>
> 1) File GRegion.h : Added a "double meshSize" field into the
> "GRegion:meshAttributes"
>
> class GRegion : public GEntity {
>
> struct {..
>double meshSize;
> } meshAttributes;
> ...
> }
>
>
> 2) File GRegion.cpp: added "meshAttributes.meshSize = MAX_LC;" into the
> function "void GRegion::resetMeshAttributes()"
>
> void GRegion::resetMeshAttributes()
> {
> ...
> meshAttributes.QuadTri = NO_QUADTRI;
> meshAttributes.meshSize = MAX_LC;
> }
>
> 3) File meshGRegionNetgen.cpp: changed following lines:
>
> line 320:
> -- Ng_GenerateVolumeMesh(ngmesh, CTX::instance()->mesh.lcMax);
> ++ Ng_GenerateVolumeMesh(ngmesh, std::min(gr->meshAttributes.meshSize,
> CTX::instance()->mesh.lcMax));
> line 345:
> -- Ng_OptimizeVolumeMesh(ngmesh, CTX::instance()->mesh.lcMax);
> ++ Ng_GenerateVolumeMesh(ngmesh, std::min(gr->meshAttributes.meshSize,
> CTX::instance()->mesh.lcMax));
>
>
>
>
> I would like to ask, if possible, to accept these changes in the official
> gmsh sources.
>
> The motivation is that, in an electromagnetic simulation, the mesh size need
> to be more refined in regions where the dielectric permittivity is high.
> The mesh refinemnet applied on the boundary of these regions may not be
> sufficient because the mesh size of tetrahedrons which are distant from the
> boundary is
> defined by the global lcMax.
>
>
> Thanks
> Walter
>
>
>
>
>
> ___
> gmsh mailing list
> gmsh@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
___
gmsh mailing list
gmsh@onelab.info
http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] GRegion meshsize
> On 21 Sep 2020, at 11:51, Steffè Walter > wrote: > > Hello Christophe, thanks for merging. > > I will check but I am sure that your implementation of the Netgen interface > (I have seen the commit) will work as well. > > I am wondering if your implementation, thanks to the redefinition of function > the " virtual double GRegion::getMeshSize()", > works also with ALGO_3D_DELAUNAY. Yes that was the idea. It will also work with the new ALGO_3D_HXT. Christophe > > > Walter > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Unable to select surfaces using GUI
> On 6 Jul 2020, at 21:51, A Chaube wrote: > > Hello, > > I have a complicated 2D mesh with lots of elements (which I cannot reduce in > number), and I am extruding this into a 3D mesh. Upon extrusion, it becomes > extremely challenging to keep track of new surfaces (needed for creating > sidesets) - the easiest way seems to be to select them using the GUI. > > However, the geometry model has no opacity for surfaces (just a wireframe > marker), so everything looks really busy and it is impossible to click on the > surface that I wish to select. Making mesh elements visible makes the model > visually opaque and less busy, but some surface markers (the dotted crosses) > simply disappear, making it impossible to select the right surface without a > lot of effort (tracking common curves to deduce surface ID etc). > > Could you please suggest a way to select physical surfaces when you have lots > of different surfaces (12-20 per physical surface, and about 10 physical > surfaces)? You could use Tools->Visibility to hide/show only parts of the model, or Tools->Clipping. Once you have a mesh you can also only display mesh edges, which will allow to "see through". Christophe > > Thank you. > Ash. > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Points seem to move on transfinite surface after the recombination
> On 8 Jul 2020, at 12:46, Bojan Niceno
> wrote:
>
> Dear all,
>
> I have a problem when trying to mesh planar structured surfaces. Although
> points seem to be uniformly placed on a transfinite surface, they move a bit
> when recombining the mesh to change triangles to quadrilateral cells.
>
> Here is a simple script which demonstrates it:
>
> // Define points
> Point(1) = {0.0, 0.0, 0.0};
> Point(2) = {0.5, 0.0, 0.0};
> Point(3) = {0.0, 0.5, 0.0};
> Point(4) = {0.7, 0.0, 0.0};
> Point(5) = {0.0, 0.7, 0.0};
>
> // Define connectors from points ...
> Line (1) = {2, 4};
> Circle(2) = {4, 1, 5};
> Line (3) = {5, 3};
> Circle(4) = {3, 1, 2};
>
> // ... and set them as transfinite
> Transfinite Curve {1, 2, 3, 4} = 11 Using Progression 1;
>
> // Define surface ...
> Curve Loop(1) = {1, 2, 3, 4}; Plane Surface(1) = {1};
>
> // ... and set it as transfinite too
> Transfinite Surface {1};
>
> So, as I said, generating a 2D mesh over the surface places points properly,
> but command recombine moves them a bit :-/ Is there a way to prevent these
> movements of points?
>
> I am also attaching a screenshot of a mesh before and after recombination, to
> illustrate my problem better.
>
Indeed, recombination a posteriori applies some smoothing. You should add
Recombine Surface{1};
after "Transfinite Surface {1};", which will directly create a quad mesh.
Christophe
> Best regards,
>
> Bojan
>
> P.S. I am not sure if attachments go to the mailing list, I've never used a
> mailing list before.
>
> ___
> gmsh mailing list
> gmsh@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
___
gmsh mailing list
gmsh@onelab.info
http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Create gmsh 2D.
> On 3 Jul 2020, at 17:10, Keith Sloan wrote: > > Okay I am trying to add certain gmsh functionality to a FreeCAD work bench. > > I can deal with FreeCAD Shapes by writing out a temp brep file and reading > using gmsh. > Not very elegant but it works. > > I am trying to also handle Meshes. Now there are no export options on a > FreeCAD mesh . > > I have access to Edges, Facets, Points > > see print(dir()) > > Create Tetrahedra Mesh from Mesh > Facets : 4900 > ['Area', 'BoundBox', 'Content', 'CountEdges', 'CountFacets', 'CountPoints', > 'Facets', 'Matrix', 'MemSize', 'Module', 'Placement', 'Points', 'Topology', > 'TypeId', 'Volume', '__class__', '__delattr__', '__dir__', '__doc__', > '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', > '__init__', '__init_subclass__', '__le__', '__lt__', '__ne__', '__new__', > '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', > '__str__', '__subclasshook__', 'addFacet', 'addFacets', 'addMesh', 'clear', > 'coarsen', 'collapseEdge', 'collapseFacet', 'collapseFacets', 'copy', > 'countComponents', 'countNonUniformOrientedFacets', 'countSegments', > 'crossSections', 'cut', 'decimate', 'difference', 'dumpContent', > 'fillupHoles', 'fixDeformations', 'fixDegenerations', 'fixIndices', > 'fixSelfIntersections', 'flipNormals', 'foraminate', 'getAllDerivedFrom', > 'getEigenSystem', 'getFacesFromSubelement', 'getFacetSelection', > 'getInternalFacets', 'getNonUniformOrientedFacets', 'getPlanarSegments', > 'getPointNormals', 'getPointSelection', 'getSegment', > 'getSegmentsByCurvature', 'getSegmentsOfType', 'getSelfIntersections', > 'getSeparateComponents', 'harmonizeNormals', 'hasInvalidPoints', > 'hasNonManifolds', 'hasNonUniformOrientedFacets', 'hasSelfIntersections', > 'inner', 'insertVertex', 'intersect', 'isDerivedFrom', 'isSolid', > 'meshFromSegment', 'nearestFacetOnRay', 'offset', 'offsetSpecial', > 'optimizeEdges', 'optimizeTopology', 'outer', 'printInfo', 'read', > 'rebuildNeighbourHood', 'refine', 'removeComponents', > 'removeDuplicatedFacets', 'removeDuplicatedPoints', 'removeFacets', > 'removeFoldsOnSurface', 'removeInvalidPoints', 'removeNonManifoldPoints', > 'removeNonManifolds', 'restoreContent', 'rotate', 'setPoint', 'smooth', > 'snapVertex', 'splitEdge', 'splitEdges', 'splitFacet', 'swapEdge', > 'transform', 'transformToEigen', 'translate', 'trim', 'unite', 'write', > 'writeInventor'] > > I get the impression, maybe wrong that I have to create a surface with > boundary curves and then add nodes and coordinates, > but not sure how I could create boundary curves given that I am trying to > handle generic cases where I have no control > over the mesh I get passed. > > Any ideas? > It would help if you explained what you actually want to do... Christophe > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] There was eventually a crash report
system_pthread.dylib 0x7fff708e6b8b thread_start + 15 > > Thread 12:: JavaScriptCore::Marking > 0 libsystem_kernel.dylib0x7fff7082a882 __psynch_cvwait + 10 > 1 libsystem_pthread.dylib 0x7fff708eb425 _pthread_cond_wait + > 698 > 2 libQt5WebKit.5.6.2.dylib 0x000118d3c017 0x117c87000 + > 17518615 > 3 libQt5WebKit.5.6.2.dylib 0x000118d3c0a3 0x117c87000 + > 17518755 > 4 libQt5WebKit.5.6.2.dylib 0x00011901926f 0x117c87000 + > 20521583 > 5 libsystem_pthread.dylib 0x7fff708eb109 _pthread_start + 148 > 6 libsystem_pthread.dylib 0x7fff708e6b8b thread_start + 15 > > Thread 13:: JavaScriptCore::Marking > > > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Getting rid of small faces and features
Dear Hannes, Indeed the best way would be to clean up the CAD. But the "Compound" feature can also help: see e.g. https://gitlab.onelab.info/gmsh/gmsh/-/blob/master/benchmarks/step/part_compound_curved_mesh.geo Christophe > On 29 Jun 2020, at 16:21, Hannes Kröger wrote: > > Hi All, > > I created the mesh (2D) shown below from some CAD model. > > The CAD model has a lot of strip-like faces which gmsh meshes very brave and > treats their boundaries as feature curves. Unfortunately, the surface is > later one side of a contact zone in FEM and I suspect these tiny faces to > cause trouble. > > The specified minimum mesh size is larger than these strips so this setting > is obviously not enough. Is there a way to make the cells span these tiny > strip faces? > > PS: I'm aware there is a repair feature in OpenCASCADE. Although this removes > the strip faces visually, I can no longer mesh the geometry after repair and > only error appear. > > > > Thanks for any hint. > > Regards, Hannes > > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] parallel meshing?
Dear Sabrina, Most algorithms in Gmsh are indeed multi-threaded, but not all of them. In particular, in 2D, the experimental "Frontal-Delaunay for Quads" and "Packing of Parallelograms" algorithms are single-threaded: your exceptionally long meshing times maybe indicate that you are using these algorithms to generate quads? There is active work on improving "Packing of Parallelograms" in the "quadMeshingTools" branch, but it not ready yet for merging in master. Christophe > On 1 Jul 2020, at 19:48, Sabrina Zacarias > wrote: > > Dear all, > > I am very interested in meshing in parallel since my 2d model takes ~8hs to > mesh. It is a 8-node quad (which is rather slow in itself, from what I have > experienced so far) but the main issue is that there is one special surface > that is very large and has to be very finely meshed. I saw that it is > possible to do something with OpenMP (I compiled gmsh enabling that option), > but setting the multithread option to a number >1 did nothing (when it starts > meshing, there is a message saying 'max number of threads = 1'). I am afraid > I am missing something. > > Could I please ask for some insight? > > Best, > > Sabrina > > -- > Sabrina Zacarias > Institut für Kernphysik > Technische Universität Darmstadt > S2|14 / office 319 > Schlossgartenstr. 9 > 64289 Darmstadt > Office: +49 6151 16 23589 > > > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Getting lines' nodes
> On 8 Jul 2020, at 18:48, Bojan Niceno
> wrote:
>
> Dear all,
>
> Is there a way to fetch curves' (lines' in particular) points? Something like:
>
> c[] = Point{1}; // c[] contains the coordinates 1,2,3
>
> which is used to get point's coordinates, but I would need lines' points.
>
Use "Boundary" first to get the curve bounding points.
Christophe
> Kind regards
>
> Bojan
>
>
> ___
> gmsh mailing list
> gmsh@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
___
gmsh mailing list
gmsh@onelab.info
http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] number of gauss point per element
> On 16 Jun 2020, at 19:48, Panagiotis Kotronis > wrote: > > Is it possible to choose the number of Gauss points in an element when > creating a mesh, and then to print this information for each element in the > generated msh file? Gauss point choice is independent from mesh generation. You can use the API (cf. getIntegrationPoints) to get quadrature points and perform integration (cf. getJacobians) on a mesh. Christophe > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Meshing Looping how to debug.
> On 17 Jun 2020, at 13:00, Keith Sloan wrote:
>
> I have code as below
>
> def initialize() :
> gmsh.initialize()
> gmsh.option.setNumber('Mesh.Algorithm3D',1)
> gmsh.option.setNumber("Geometry.OCCFixDegenerated", 1)
> gmsh.option.setNumber("Mesh.SaveGroupsOfNodes", 1)
> gmsh.option.setNumber("Mesh.CharacteristicLengthMax", 2)
> gmsh.option.setNumber("Mesh.CharacteristicLengthFromCurvature", 0)
> gmsh.option.setNumber("Mesh.CharacteristicLengthFromPoints", 1)
> gmsh.option.setNumber("Mesh.SaveAll", 0)
> gmsh.option.setNumber("Mesh.OptimizeNetgen", 1)
> gmsh.option.setNumber("Mesh.MaxNumThreads3D", 4)
> gmsh.option.setString("Geometry.OCCTargetUnit", 'mm');
> gmsh.option.setString("General.ErrorFileName", '/tmp/error.log');
>
>
>
> def meshObj(obj, dim) :
> obj.Shape.exportBrep("/tmp/Shape2Mesh.brep")
> ab = gmsh.open('/tmp/Shape2Mesh.brep')
> gmsh.model.occ.synchronize()
> print(dir(ab))
> gmsh.model.mesh.generate(dim)
> print('Mesh Generated')
> gmsh.model.mesh.renumberNodes()
>
>
>
> I am passing 3 as the value of dim.
>
>
> One object a Cube works just fine, but another Cube
> which seems the same just loops.
>
> Suggestions on how to debug please?
>
Set
gmsh.option.setNumber('General.Terminal',1)
to see the messages.
>
>
> ___
> gmsh mailing list
> gmsh@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
___
gmsh mailing list
gmsh@onelab.info
http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] 7-node second order triangle
> On 15 Jun 2020, at 21:02, Panagiotis Kotronis > wrote: > > Hi > Is it possible to mesh using a 7-node second order triangle (3 nodes > associated with the vertices and 3 with the edges + 1)? No, that's not supported. Christophe > Panagiotis > > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] 3d Delaunay Mesh
Hi Juan, This is expected: to get a 3D mesh that satisfies the Delaunay criterion we would need to modify the surface mesh - this is something we try hard to avoid. Christophe > On 14 Jun 2020, at 20:17, Juan Sanchez wrote: > > Hello, > > I am having a hard time getting a 3d delaunay mesh, so that the circumcenters > of the tetrahedra are inside the element. > > In my simulator, I am seeing that about 50% of the elements are not delaunay > if: > Mesh.CharacteristicLengthExtendFromBoundary = 1; > > and about 90% are not Delaunay if: > Mesh.CharacteristicLengthExtendFromBoundary = 0; > > Is there a way to improve this when running the tool from the command line or > with an option in the geo file? > > I am using: > /Applications/Gmsh.app/Contents/MacOS/gmsh -format msh2 -3 3dblock.geo > > with version 4.5.6 on macOS 10.14.6 (Mojave). > > Regards, > > Juan > <3dblock.geo>___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] gmsh 4.5.6: Creating a mesh from .vtk files - Surface is not remeshing but only the Volume
> On 22 Jun 2020, at 19:14, Lisa Pankewitz wrote:
>
> Dear Christophe,
>
> thanks so much for your helpful and fast response. It is really appreciated!
>
> Just to double check: Does that mean that the assignment of surface names
> with the syntax I used before does not work any longer in gmsh ?
>
It does of course. But when new surfaces are created (by ClassifySurfaces)
you'll need to identify them as well.
> Thanks so much and have a great day :)
> Kind regards,
>
> Lisa
>
> --
> Lisa Pankewitz
> PhD student
> Simula Research Laboratory
> Martin Linges vei 25
> 1364 Fornebu
> Office 329
> l...@simula.no
>
>
>
> On Mon, 22 Jun 2020 at 18:10, Christophe Geuzaine wrote:
> Hi Lisa,
>
> Your script seems quite complicated. Here's a simple one that produces a
> decent mesh:
>
> Merge "File_1.vtk";
> Merge "File_2.vtk";
> Merge "File_3.vtk";
> Merge "File_4.vtk";
> Merge "File_5.vtk";
> Merge "File_6.vtk";
> Merge "File_7.vtk";
>
> Coherence Mesh; // remove duplicate mesh nodes
>
> ClassifySurfaces{21 * Pi/180, 1, 0 /* or 1 */, 40 * Pi / 180};
> CreateGeometry;
>
> Mesh.CharacteristicLengthMax = 10;
> Mesh.CharacteristicLengthMin = 0.1;
> Mesh.CharacteristicLengthFromCurvature = 1;
> Mesh.MinimumElementsPerTwoPi = 20;
>
> s() = Surface{:};
> Surface Loop(1) = s();
> Volume(1) = 1;
>
> We still need to add some tools to automate the identification of
> curves/surfaces created by ClassifySurfaces. For now you'll need to tag them
> manually (or use some geometrical tests, e.g. using the Gmsh API).
>
> Christophe
>
>
>
>
>
>> On 22 Jun 2020, at 17:25, Lisa Pankewitz wrote:
>>
>> To whom it may concern,
>>
>> I am trying to remesh a geometry based on .vtk files.
>> I merge 7 .vtk files. 4 vtk files are used to create a surface that consists
>> of 4 compounds. All 7 surfaces together define the volume. I assign tags
>> (names) to the physical surfaces, which I need in later steps.
>> Unfortunately, I realized the surface does not remesh. I checked several
>> tutorials and parameters but could not yet find a possibility to keep the
>> tags and remesh the surface and the volume in the assigned characteristic
>> length in gmsh version 4.
>> I tried
>> '''
>> RefineMesh
>> '''
>> but this only splits the elements instead of performing an optimal
>> refinement.
>>
>> Do you by chance know what I could assign in order to remesh the surface AND
>> the volume and not only the volume?
>>
>> Thanks so much for your time and have a wonderful day!
>> Kind regards,
>>
>> Lisa
>>
>> --
>> Lisa Pankewitz
>> PhD student
>> Simula Research Laboratory
>> Martin Linges vei 25
>> 1364 Fornebu
>> Office 327
>> l...@simula.no
>>
>> ___
>> gmsh mailing list
>> gmsh@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
>
>
>
> ___
> gmsh mailing list
> gmsh@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
___
gmsh mailing list
gmsh@onelab.info
http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] gmsh 4.5.6: Creating a mesh from .vtk files - Surface is not remeshing but only the Volume
> On 23 Jun 2020, at 10:16, Lisa Pankewitz wrote:
>
> Hi Christophe,
>
> Thanks for the clarification, I misunderstood.
>
> Could you maybe point me to a tutorial or an example that elaborates a bit
> more on how I would now tag the surfaces manually based on the vtk providing
> the boundaries?
> I assume you tagged the surfaces and volume afterwards in order to create
> the nice figure you sent?
No I just used the script and set nice colors. After looking at your file in
more detail though, we could actually do without reclassifying the input mesh if
1. we improve the VTK reader to create one surface per file (instead of loading
all the triangles in a single surface)
2. you fix File_2.vtk (which has triangles oriented inconsistently)
I just coded 1. and manually fixed 2. Here's the resulting script, nice and
easy ;-)
complex.geo
Description: Binary data
File_2_fix.vtk
Description: Binary data
You'll need the latest development snaphot to test it.
Christophe
>
> Thanks!
>
>
> Kind regards,
>
> Lisa
>
> --
> Lisa Pankewitz
> PhD student
> Simula Research Laboratory
> Martin Linges vei 25
> 1364 Fornebu
> Office 329
> l...@simula.no
>
>
>
> On Tue, 23 Jun 2020 at 08:30, Christophe Geuzaine wrote:
>
>
> > On 22 Jun 2020, at 19:14, Lisa Pankewitz wrote:
> >
> > Dear Christophe,
> >
> > thanks so much for your helpful and fast response. It is really appreciated!
> >
> > Just to double check: Does that mean that the assignment of surface names
> > with the syntax I used before does not work any longer in gmsh ?
> >
>
> It does of course. But when new surfaces are created (by ClassifySurfaces)
> you'll need to identify them as well.
>
> > Thanks so much and have a great day :)
> > Kind regards,
> >
> > Lisa
> >
> > --
> > Lisa Pankewitz
> > PhD student
> > Simula Research Laboratory
> > Martin Linges vei 25
> > 1364 Fornebu
> > Office 329
> > l...@simula.no
> >
> >
> >
> > On Mon, 22 Jun 2020 at 18:10, Christophe Geuzaine
> > wrote:
> > Hi Lisa,
> >
> > Your script seems quite complicated. Here's a simple one that produces a
> > decent mesh:
> >
> > Merge "File_1.vtk";
> > Merge "File_2.vtk";
> > Merge "File_3.vtk";
> > Merge "File_4.vtk";
> > Merge "File_5.vtk";
> > Merge "File_6.vtk";
> > Merge "File_7.vtk";
> >
> > Coherence Mesh; // remove duplicate mesh nodes
> >
> > ClassifySurfaces{21 * Pi/180, 1, 0 /* or 1 */, 40 * Pi / 180};
> > CreateGeometry;
> >
> > Mesh.CharacteristicLengthMax = 10;
> > Mesh.CharacteristicLengthMin = 0.1;
> > Mesh.CharacteristicLengthFromCurvature = 1;
> > Mesh.MinimumElementsPerTwoPi = 20;
> >
> > s() = Surface{:};
> > Surface Loop(1) = s();
> > Volume(1) = 1;
> >
> > We still need to add some tools to automate the identification of
> > curves/surfaces created by ClassifySurfaces. For now you'll need to tag
> > them manually (or use some geometrical tests, e.g. using the Gmsh API).
> >
> > Christophe
> >
> >
> >
> >
> >
> >> On 22 Jun 2020, at 17:25, Lisa Pankewitz wrote:
> >>
> >> To whom it may concern,
> >>
> >> I am trying to remesh a geometry based on .vtk files.
> >> I merge 7 .vtk files. 4 vtk files are used to create a surface that
> >> consists of 4 compounds. All 7 surfaces together define the volume. I
> >> assign tags (names) to the physical surfaces, which I need in later steps.
> >> Unfortunately, I realized the surface does not remesh. I checked several
> >> tutorials and parameters but could not yet find a possibility to keep the
> >> tags and remesh the surface and the volume in the assigned characteristic
> >> length in gmsh version 4.
> >> I tried
> >> '''
> >> RefineMesh
> >> '''
> >> but this only splits the elements instead of performing an optimal
> >> refinement.
> >>
> >> Do you by chance know what I could assign in order to remesh the surface
> >> AND the volume and not only the volume?
> >>
> >> Thanks so much for your time and have a wonderful day!
> >> Kind regards,
>
Re: [Gmsh] Meshing fails without apparent reason
> On 23 Jun 2020, at 18:53, Bruno Agostini wrote:
>
> Dear Gmsh community,
>
> I am trying to 3D mesh the here attached Schwarz-D surface, but the meshing
> fails complaining about boundaries not being recovered, which does not help
> me to solve this problem. I think there are no overlapping facets, and the
> geometry is not particularly complicated, so I am stuck here. Any ideas?
1) the STEP file already contains a volume, so
Surface Loop(1) = Surface{:};
Volume(1) = {1};
in your .geo file will lead to overlapping volumes
2) The volume in the STEP file is made of surfaces that do intersect: see
attached picture
So there's no hope in trying to mesh the volume as-is...
Christophe
>
> Best regards
>
> Bruno
> <7_x_fin_T.msh><7_x_fin_T.zip>___
> gmsh mailing list
> gmsh@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
___
gmsh mailing list
gmsh@onelab.info
http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Bounding Box of an imported STL Smaller than geometry?
Hi Baltasar, Indeed we sub-sampled discrete entities to compute bounding boxes. I just changed this to a "brutal" bounding box computation in the latest dev snapshot: give it a try (If it's really too slow we should consider storing the information.) Christophe > On 23 Jun 2020, at 18:41, Baltasar Rüchardt > wrote: > > Dear everyone, > > I hope you are dealing as good as possible with the pandemic. > > I am puzzled because the bounding box that I obtain from a stl geometry > is smaller than the volume defined by the surface. > > The procedure used is as follows: > > 1. Import stl > 2. Use Bounding Box on surface > 3. Create Points by coordinates obtained from Bounding Box > 4. Connect points to make a volume. > > This is done in create_to_small_box.geo [which should have rather be > named create_too_small_box.geo ...]. > > Background: The stl shows the surface of a heart obtained from a mrt > scan. I first shrink / expand it using the Plugin(Transform) and then I > want to translate it (again using the Plugin(Transform).Tz) such that > the tip of the heart is at the same height as the edge of an electrode > (small example in show_application_of_transforms.geo). My approach was > to use the bounding box zmin- value to compare the heights and then > calculate the necessary transformation by calculating tz= zmin_electrode > - zmin_heart . > > Does someone have a suggestion? Or any help? The alternative would be to > move the stl with meshlab such that the heart tip is at heigh zero, then > I could apply the shrinking and transform in gmsh without problems. > > Thank you very much in advance! > > Best regards > > Baltasar Rüchardt > > > Gmshinfo: > > Version : 4.6.0 > License : GNU General Public License > Build OS : MacOSX > Build date: 20200622 > Build host: gmsh.info > Build options : 64Bit ALGLIB Ann Bamg Blas[custom] Blossom Cgns > DIntegration Dlopen DomHex Fltk Gmm Hxt Jpeg[fltk] Kbipack > Lapack[custom] MathEx Med Mesh Metis Mmg3d Mpeg Netgen ONELAB > ONELABMetamodel OpenCASCADE OpenCASCADE-CAF OpenGL OptHom PETSc Parser > Plugins Png[fltk] Post QuadTri Solver TetGen/BR Voro++ Zlib[fltk] > FLTK version : 1.4.0 > PETSc version : 3.9.3 (real arithmtic) > OCC version : 7.4.0 > MED version : 4.0.0 > Packaged by : geuzaine > Web site : https://gmsh.info > Issue tracker : https://gitlab.onelab.info/gmsh/gmsh/issues > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Single element normal
> On 23 Jun 2020, at 19:44, Sabrina Zacarias > wrote: > > Dear all, > > I am working on a 2D model in which I would like all the mesh normals to be > pointing in the same direction. As I visualize them, I noticed that there is > a single element from a single surface pointing in opposite direction to the > rest. Does anyone know what it means and if there is a way to fix it? > Difficult to say without a test case... > > An additional point, if I may, is that after setting the boundary conditions > and physical surfaces of my model and solving the electrostatic field with > Elmerfem, the result I get is either right or wrong (in terms that not even > the boundary conditions have the values that they should) depending on the > type of mesh that I use (either 2nd order triangles, which gives me the right > solution, or 8-node quadrangles, which doesn't and unfortunately this one is > the one that I must use). > Idem. Christophe > I would appreciate any help or suggestion that you may have. > > Best regards, > > Sabrina > > -- > Sabrina Zacarias > Institut für Kernphysik > Technische Universität Darmstadt > S2|14 / office 319 > Schlossgartenstr. 9 > 64289 Darmstadt > Office: +49 6151 16 23589 > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Error: Cannot reparametrize a mesh node in high order meshing
> On 24 Jun 2020, at 10:38, Mathias Scheunert > wrote: > > Dear developers and users, > > > > *** The goal > > we want to do some finite element convergence studies on a given set of > models. > > These typically consist of large volumes containing small 'anomalies', i.e. > volumes. > > (Please note the attached MWE) > > *** The problem > > In order to ensure valid boundary conditions we need to enlarge the > surrounding volume, leading to huge contrasts between the sizes of the > involved volumes. > > Using Gmsh 'RefineMesh;' will throw the above mentioned error. > > -> Please try using line 6 instead of line 5 in the MWE. > > > > What does that error message mean and how could we deal with that? OpenCASCADE does not seem to appreciate the large aspect ratio during interpolation. As a workaround, set Mesh.SecondOrderLinear = 1; which will create the refinement by linear interpolation. (Note that if you increase domain_r further to 1, OpenCASCADE simply seem to bail out...) Christophe > > > Best regards, > > Mathias > > > > ps: We are using Gmsh 4.5.6 > > -- > Dr. Mathias Scheunert > Institute of Geophysics and Geoinformatics, TU Bergakademie Freiberg > Gustav-Zeuner-Str. 12, D-09596 Freiberg > Tel.: +493731393630 > > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] transfinite algorithm limitation for structured meshes
> On 19 Jun 2020, at 07:10, BRAHMACHARY SHUVAYAN > wrote: > > Dear prof. Geuzaine, > > Good morning! > > First of all thank you for the wonderful meshing tool you and your team has > developed: Gmsh. It is very useful indeed. > > I was wondering if you could help me answer a query related to Gmsh. > > I am trying to create a structured mesh using the Transfinite command in Gmsh > (image attached). As you may notice, due to the curvature of the upper curve, > the vertical lines are not quite vertical (I want them to be perfectly > vertical). This is possible if I were able to alter the position of the nodes > suitably, which is possible in Gmsh using Points in Surface command. However, > this Points in Surface command fails when Transfinite command is used and > only works for unstructured meshes in Gmsh. So my question is : > > > 1. How to constraint the lines to be vertical? An easier way perhaps? No there's nothing for this. > > 2. Is it possible to adjust the nodes when Points in Surface and Transfinite > commands are used in conjunction? No: you'll need to split the surface into parts that have 3 or 4 sides... Christophe > > Kind regards, > Shuvayan > > > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Problem with physical groups to label surface in GMSH
> On 21 Jun 2020, at 06:24, Quang Ha wrote:
>
> Hi all,
>
> I'm having some troubles setting the ID for the physical group of the
> boundary and then extract them later in Python. Here's my main.geo file:
>
> // Gmsh project created on Sat Jun 20 11:28:19 2020
> Mesh.Algorithm = 6;
> Mesh.CharacteristicLengthMin = 0.4;
> Mesh.CharacteristicLengthMax = 0.4;
>
> SetFactory("OpenCASCADE");
> //+
> Box(1) = {-2, -2, -2, 4, 4, 4};
> // Surface for Box
> box_bnd[] = Boundary{Volume{1};};
> Physical Surface("boundary", 1) = box_bnd[];
> //+
> Sphere(3) = {0, 0, 0, 1.0, -Pi/2, Pi/2, 2*Pi};
> sphere_bnd[] = Boundary{Volume{3};};
> Physical Surface("boundary", 1) += sphere_bnd[];
> // Cut
> BooleanDifference(5) = {Volume{1}; Delete;}{Volume{3}; Delete;};
> Physical Volume("internal", 2) = {5};
>
> Having run this inside Gmsh and generate main.msh, I try to explore this mesh
> inside Python and extract out the coordinates on the boundary for checking.
The boolean operation with OpenCASCADE will change the surfaces, so your
Physical Surface definition becomes invalid (and should be done afterwards).
Improving the surface tag persistence is on our TODO list, but OpenCASCADE does
not make this easy (or more probably we don't use OpenCASCADE intelligently
enough ;-).
Christophe
> Here is my extract.py:
>
> import matplotlib.pyplot as plt
> import gmsh
>
> # Mesh characteristic length
> char_length = 0.4
> # Some reference dimension
> max_coord, min_coord = -2.0, 2.0
> # Sphere radius
> a = 1.0
> # Tolerance allowed in the mesh point
> tol = 1e-12
>
> gmsh.initialize()
> gmsh.option.setNumber("General.Terminal", 1)
> gmsh.open("main.msh".format(char_length))
>
> # all mesh node coordinates
> nodeTags, nodeCoords, _ = gmsh.model.mesh.getNodes()
>
> # just the boundary coordinates
> bTags, bCoords, = gmsh.model.mesh.getNodesForPhysicalGroup(3, 1)
>
> gmsh.finalize()
>
> which seems to give me empty arrays of bTags and bCoords, i.e.:
>
> In [7]: run extract.py
> Warning : Gmsh has aleady been initialized
> Info: Reading 'main.msh'...
> Info: 33 entities
> Info: 1260 nodes
> Info: 6524 elements
> Info: Done reading 'main.msh'
> /usr/local/lib/python3.7/site-packages/numpy/ctypeslib.py:523:
> RuntimeWarning: A builtin ctypes object gave a PEP3118 format string that
> does not match its itemsize, so a best-guess will be made of the data type.
> Newer versions of python may behave correctly.
> return array(obj, copy=False)
>
> In [8]: bTags
> Out[8]: array([], dtype=uint64)
>
> In [9]: bCoords
> Out[9]: array([], dtype=float64)
>
> Any suggestions on where I have made a mistake?
>
> Thanks,
> Quang
> ___
> gmsh mailing list
> gmsh@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
___
gmsh mailing list
gmsh@onelab.info
http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Appendage Mesh
> On 19 Jun 2020, at 09:17, Diogo Nunes wrote: > > Hello gmsh Users, > > This is a question about modelling 2D surfaces with arbitrary shapes and > sharp angles within the geometry. > The mesh is then used by a radiation-diffraction solver to obtain the > hydrodynamic potential. > It is a specific application to a ship hull but must be similar to many other > applications. > > So we are using gmsh to create a 2D structured mesh of a ship hull with a > geometry looking like the one below (note the appendage in red): > > > Meshing the overall hull shape has been fairly straightforward and gmsh did > exactly what we expected, yielding a good quality mesh with minimal efforts. > We created my 3 and 4 edges surfaces from lines and B-Splines curves. For > each surface, we defined Transfinite Curves, Surfaces and Recombined each > surface them to get the 2D Structured Mesh: > > > The issue is related to the appendage on the stern of the hull (called > “skeg”) as shown on the first picture. If we include this as the same surface > as the hull, the sharp angle would never be captured by the B-spline. > > So far we have tried a couple of things based on processes commonly applied > in other packages: > First we have made a contour of the skeg using B-splines and lines (Line 16, > Line 17, Line 18, Nurb 12, Nurb 13) and split the forward B-spline into 2 > (Nurb 7 and Nurb 8) as shown below. > > This has either resulted in endless loops of “Warning: Wrong control point > index in bspline” or in meshing errors in the appendage and surrounding > regions. > > Next we have tried to approximate the contour of the skeg with Nurb 17 to > generate Surface 2 (made of Nurbs 7,8,5,17) and then add 3 separate lines to > produce the side surface of the skeg (Surface 5 made of Nurb 14, 15 and Line > 16) > > This resulted in an error message and the Surface 5 meshed with 1 element > only as shown above. > > Have you got any suggestion on how one should proceed to get a 2D structured > mesh of such a geometry with sharp angles (here, the hull and the skeg) and > capture those discontinuities within the mesh, as depicted in the first > figure? > Can you share a script? It should be doable of all surfaces have 3 or 4 sides. Christophe > > Many thanks, > Diogo Nunes. > > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Installation of jointforces, with GMSH
> On 4 Jun 2020, at 11:10, Emma Stubbs wrote: > > Hi, > > I am installing joint forces, which utilizes GMSH, and the installation seems > to just be paused here: > > Building wheels for collected packages: gmsh-sdk, dill, roipoly > Building wheel for gmsh-sdk (setup.py) … | > > Do you have any idea as to why it is pausing at this stage and what can be > done to rectify? > We have anecdotal evidence that it might be related to a firewall issue preventing in some cases the download to finish. Can you try the pypi package "gmsh" instead of "gmsh-sdk"? The "gmsh" package will eventually replace "gmsh-sdk", and uses https instead of http for the download. Christophe > Kindest, > Emma > Disclaimer - University of Cape Town This email is subject to UCT policies > and email disclaimer published on our website at > http://www.uct.ac.za/main/email-disclaimer or obtainable from +27 21 650 > 9111. If this email is not related to the business of UCT, it is sent by the > sender in an individual capacity. Please report security incidents or abuse > via https://csirt.uct.ac.za/page/report-an-incident.php. — Prof. Christophe Geuzaine University of Liege, Electrical Engineering and Computer Science http://www.montefiore.ulg.ac.be/~geuzaine ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
Re: [Gmsh] Mesh & Topshape, Brep
> On 8 Jun 2020, at 20:05, Keith Sloan wrote: > > I am looking at using Gmsh in a FreeCAD Workbench. > > I see > > "Actually gmsh::model::occ::importShapeNativePointer() was originally only > designed to work with the C++ and C APIs, and has been removed from the > Python and Julia APIs in Gmsh 4.4. > > If a Python specialist can help in making a new version of the function that > actually works in Python, we would be happy to re-add it (even if of course > such a function is intrinsically "unsafe"). > > Christophe" > > So it looks like I would have to export the Shape I wish to work on as a Brep > file and > import that into Gmsh. Exact. > After meshing is there any easy option to create a Brep file or TopShape > version of the mesh? A Brep file is not designed to hold a finite element mesh. The Gmsh API gives you full access to the mesh, so you can transfer it in any form you wish. Christophe > > Thanks Keith > > ___ > gmsh mailing list > gmsh@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 ___ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
