The singular version addCurveLoop
is available in the occ
kernel (link to API reference). You'll have to build up your geometry using the occ
kernel instead of the geo
kernel if you want to do boolean operations.
Hello @MAHDIMMT,
I think the function you're looking for is called fuse
.
gmsh/model/occ/fuse
Compute the boolean union (the fusion) of the entities objectDimTags and toolDimTags in the OpenCASCADE CAD representation. Return the resulting entities in outDimTags. If tag is positive, try to set the tag explicitly (only valid if the boolean operation results in a single entity). Remove the object if removeObject is set. Remove the tool if removeTool is set.
There's a complete list of all the Gmsh API functions a few screens into this section: http://gmsh.info/doc/texinfo/gmsh.html#Gmsh-API and specific functions usually have links to where they are used in the tutorials.
Sincerely, Max
When element labels (Tools->Options->Mesh->3D element labels
) are used with Mesh
clipping planes, only visible element labels are shown:
This does not seem to be the case for post-processing clipping planes, but it would be nice to match what happens for the mesh ones:
The current workaround is to isolate the elements you want to check using a mesh clipping plane and toggle the view visibility back and forth.
File used for screenshots: label-repro.msh
Yes, that seems like a good workaround, thank you.
Hi Ali,
By default, if there are any physical groups defined, Gmsh will only write out those mesh elements that have a physical group. For t1
, some of the edges are assigned to a physical group and therefore written out:
gmsh.model.addPhysicalGroup(1, [1, 2, 4], 5)
https://gitlab.onelab.info/gmsh/gmsh/blob/gmsh_4_8_4/tutorial/python/t1.py#L115
Removing or commenting out this line will mean the edges do not get written out. There is more information in the nearby comment.
Sincerely, Max
When element labels (Tools->Options->Mesh->3D element labels
) are used with Mesh
clipping planes, only visible element labels are shown:
This does not seem to be the case for post-processing clipping planes, but it would be nice to match what happens for the mesh ones:
The current workaround is to isolate the elements you want to check using a mesh clipping plane and toggle the view visibility back and forth.
File used for screenshots: label-repro.msh
Hi Christophe, thanks for taking a look :)
About synchronize
, I didn't word my question very well. I wanted to ask your opinion on how to determine when the code generator should emit synchronize
calls. If the end goal is to output scripts with the exact same semantics as the geo
generator I think synchronize
becomes a problem.
Take addPoint
: these two scripts have different behaviour. The python one is what would be generated right now, pretending that addPhysicalGroup
is implemented:
// geo
SetFactory("OpenCASCADE");
Point(1) = {0.0, 0.0, 0.0, 1.0};
// point can be used correctly in all cases with no preconditions
Physical Point(1) = {1};
# python
import gmsh
gmsh.initialize()
gmsh.model.occ.addPoint(0.0, 0.0, 0.0, 1.0)
# error, synchronize must be called to use point with gmsh APIs outside of gmsh.model.occ
gmsh.model.addPhysicalGroup(0, [1])
gmsh.finalize()
$ python script.py
Warning : Unknown entity of dimension 0 and tag 1 in physical group 1
How could this be avoided? I think one straightforward way to ensure strict compatibility is to emit a synchronize call immediately after functions that need it. Keeping track of "which module" the API is in and emitting on boundaries might work but could be complex.
Fill in some non-geo script output strings (mostly mesh fields).
Here is some sample output:
py: gmsh.model.geo.addPoint(0.9, 0.9, 1, 1.0)
py: gmsh.model.mesh.field.setAsBackgroundMesh(3)
py: gmsh.model.mesh.field.setString(2, "F", "F2 + Sin(z) + Cos(z)")
py: gmsh.model.mesh.field.setNumbers(1, "ExcludedSurfacesList", [1, 2, 3])
py: gmsh.model.mesh.field.remove(3)
About gmsh.model.mesh.field.add
, for non-geo scripts, it will segfault after printing the output string. I believe this comes from not actually adding the Field in scriptAddCommand
but then attempting to access it afterwards here: https://gitlab.onelab.info/gmsh/gmsh/-/blob/45013d06bf8d7fdc631ad2b3b50a746ba0a3cb4b/Fltk/fieldWindow.cpp#L52. I don't think this can be fixed until scriptAddCommand
is adjusted for non-geo files.
I had a general question: when should synchronize
calls be emitted? As I understand it there is an implicit synchronize between every geo file command (https://gitlab.onelab.info/gmsh/gmsh/-/blob/45013d06bf8d7fdc631ad2b3b50a746ba0a3cb4b/Geo/scriptStringInterface.cpp#L105-109), but this would be very verbose. However I can't think of another way that guarantees the script will be correct (e.g. if you only synchronize when changing between modules, how do you ensure the final synchronize is correct?).
Can you also post the command you've tried and your geo
file? I think Gmsh prints this error if the output file doesn't have an extension.
Hi Francisco, Jeremy,
I think ONELAB is the right way forward, check out these pages on the wiki:
You can define parameters to pass to your existing script (i.e. your script will be a ONELAB client).
Sincerely, Max
Hi Jordan, I haven't tried myself but maybe gmsh.model.isInside
or gmsh.model.getBoundingBox
could work?
Sincerely, Max