some ideas for improving the interface
Because it's Friday, I thought I'd open a larger issue here, listing some gripes I have with gmsh (and it's Python interface). Background: I'm currently converting pygmsh to use the gmsh Python interface, mostly to be able to use user-defined cell size functions. Given my background in Python and programming in general, I feel that I can contribute an idea or two, but of course feel free to ignore the suggestions, too.
I noticed that some things have improved over the geo "language": First of all Python is a proper language. I think this should be the default way of specifying meshes, not geo files. At least I don't see any advantage of using geo files right now.
-
Looking at gmsh-python, I think it was very much designed with geo files as a template. It looks very much the same. One annoying thing that thankfully got removed is the fact that the user had to assign an integer identifyer to each object. Now,
addPoint
and friends return the identifier. Perfect. I don't understand though why the user still specify the ID. What for? It just makes the user code more messy, and should be removed.pt = gmsh.model.geo.addPoint(*coords)
-
All the
add*
functions returnint
s. This is a bit weird, but probably rooted in the fact that there's some global register that associates the ints with actual objects. My suggestion: Return a richer object, e.g.,Point()
,Curve()
etc. that each have anid
property. This way, you could do exactly what you do in the background withpt0.id
, and in addition add various sanity checks. For example, you could check ifLine
has twoPoint
objects as input (and notLineLoop
or whatever), if you store the points within theLine
object, you could check thatCurveLoop
arguments are in the correct order and so on and so forth. -
Everything happens in some global object that needs to be treated just right. For example, you have to
gmsh.initialize()
it, andgmsh.synchronize()
before you do certain operations. If you forget to do so, you don't get an error message, things simply won't work. A better idea would be require the user to intiantiate a "geo" object, e.g.,geo = gmsh.get_geo()
The
__init__
method could take care ofinitialize()
, the__del__
method could take care offinalize()
, and that's already two calls saved.print(geo)
could tell you something about the geometry (e.g., so many points, so many beziers, so many loops). It could have a
generate_mesh()method and you could get rid of the
dimargument by checking which kind of geometry objects have been added. Heck, one could even get rid of
synchronize()` by registering methods to be called after sync. -
I noticed that for boundary layers, it's quite unclear what variable influence the generation. There used to be
hfar
andhwall_n
, but setting those (as global variables) didn't do anything. Weird. Ah wait! It's calllcmin
,lcmax
anddistmin
,distmax
now! To avoid this kind of confusion, there should be a one (or more) methods that add boundary layers, with a clear set of arguments. No othersetVariable
s should influence how the boundary is built. Perhaps there are other similar cases.
My dream would be that one day I can obsolete pygmsh because gmsh-python has become super user-friendly. Perhaps one of the above ideas is a step towards it.
(Feel free to immediately close this issue if you don't see anything that's actionable for you.)