Hello Christophe, thanks for the remarks.
I do use Gmsh inside a larger toolbox. Inside this tool I assign numbers to the geometry to be able to re-assign the finite element entities created by Gmsh back to the geometry after the meshing. Therefore, I cannot really use “newp”, “newl”, … as I need to know/assign the tags in advance. For the moment I could try to use a larger increment for the geometric object numbers to avoid the numbering issues. However, this is a little dirty and also does not solve the problem with “Surface” and that the line progression is not considered. In the mean time I’ll consider your side note on mixing CAD kernel commands, models commands and mesh constraints. Best regards Martin Von: Christophe Geuzaine [mailto:cgeuza...@uliege.be] Gesendet: Montag, 9. Juli 2018 21:05 An: Rädel, Martin Cc: gmsh@onelab.info Betreff: Re: [Gmsh] Error when switching from Built-In to OpenCascade Factory Hi Martin, "Surface" with OpenCASCADE is a bit tricky - and we are not quite yet happy yet about the implementation. It uses the OpenCASCADE "N-side filling" algorithm to create a BSpline surface using curve and/or point constraints. We could not manage to make this work without applying some fixes (see the addSurfaceFilling function in Geo/GModelIO_OCC.cpp), which (sometimes?) duplicates internal wires. Any help from OpenCASCADE folks with this would be welcome... To work around the numbering issues, I would recommend not numbering entities explicitly: in .geo files you can use "newp", "newl", etc.; with the API you would just let the API return a tag for you. As a side note, you should avoid mixing CAD kernel commands (Line, Surface, ...), model commands (Physical Surface, ...) and mesh constraints (Transfinite Surface, ...) : the last two trigger a synchronization between the CAD kernel and the internal Gmsh model. Doing this repeatedly will degrade performance. It's better to create all CAD entities, then apply model and mesh commands. Christophe On 8 Jul 2018, at 21:18, martin.rae...@dlr.de<mailto:martin.rae...@dlr.de> wrote: Hello, I want to add some information. Yes, for the test case I could simply switch to “Plane Surface” and everything is working. But in reality, my models also consist on non-planar surfaces. I added another test as an attachment to this mail. I found that if I increment the Line Loop and Surface numbers by 2 instead of 1, e.g. from the attached example: Line Loop(1) = {10,2,11,3}; Surface(1) = {1}; Transfinite Surface(1) = {}; Recombine Surface(1) = 60.0; Physical Surface(1) = {1}; Line Loop(3) = {12,4,13,5}; Surface(3) = {3}; Transfinite Surface(3) = {}; Recombine Surface(3) = 60.0; Physical Surface(3) = {3}; no errors occur as well. This matches the error message. It seems that with the OpenCASCADE Factory, additional line loops are created internally. Changing this in my code would be possible but work I would rather avoid. Can someone explain to me what where the different treatment of “Plane Surface” and “Surface” with respect to the line loops comes from? The documentation<http://gmsh.info/doc/texinfo/gmsh.html#Surfaces> says “Surface” is a “surface filling”. What does that mean exactly? Best regards Martin Von: gmsh [mailto:gmsh-boun...@ace20.montefiore.ulg.ac.be] Im Auftrag von martin.rae...@dlr.de<mailto:martin.rae...@dlr.de> Gesendet: Sonntag, 8. Juli 2018 17:01 An: gmsh@onelab.info<mailto:gmsh@onelab.info> Betreff: [Gmsh] Error when switching from Built-In to OpenCascade Factory Hello, I just recently tried to switch from the built-in Factory to OpenCascade to use Boolean operations. However, all of my tests involving more than one surface crash after the switch with the same error: OpenCascade wire or line loop with tag 2 already exists The same error occurs for all other surfaces except the first. I added a simple brick geometry example. In case I comment out “SetFactory("OpenCASCADE"); “ everything works fine. If I use the line, the errors occur. Can someone please point out what causes these errors and how I can fix them? Best regards Martin Rädel ———————————————————————— Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR) German Aerospace Center Institute of Composite Structures and Adaptive Systems | Structural Mechanics | Lilienthalplatz 7 | 38108 Braunschweig | Germany Dipl.-Ing. Martin Rädel Telephone +49 (0)531 295-2048 | Telefax +49 (0)531 295-2232 | martin.rae...@dlr.de<mailto:martin.rae...@dlr.de> www.DLR.de<http://www.dlr.de/> <unplanebrick.geo>_______________________________________________ gmsh mailing list gmsh@onelab.info<mailto: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 Free software: http://gmsh.info | http://getdp.info | http://onelab.info
_______________________________________________ gmsh mailing list gmsh@onelab.info http://onelab.info/mailman/listinfo/gmsh
