Gmsh has released version 4.11.0 which officially includes a new Object Oriented Fortran API.
This brings Fortran usage in Gmsh up to par with C++, Python and Julia.
Excellent API work! I see there’s a customized Python script in the gmsh repository that does the heavy lifting of converting to Fortran API. I’m interested to hear your comments about these couple things:
did you choose a custom script because it was faster, say, than using a more automated tool like SWIG? I’m no expert in that but I think it would be a choice to consider with such a long API
You’re wrapping C commands to empty classes, is that because GMSH completely hides memory allocation? I usually wrap stuff using an opaque C pointer, so I can know at least whether the object is allocated on the C side, e.g.:
type :: fortran_wrapper
type(c_ptr) :: c_memory = c_null_ptr
contains
procedure :: is_allocated
end type fortran_wrapper
! really dumb example
logical function is_allocated(this)
class(fortran_wrapper), intent(in) :: this
is_allocated = c_associated(this%c_memory)
end function is_allocated
but maybe GMSH hides all the memory stuff behind the API, I don’t know.
Thanks, I’m glad that some might find this work useful.
The choice of Python for the API generation predates me, but I suspect it was because it is relatively easy to add new languages. Both Python and Julia call the C API under the hood, which in turn calls the C++ API. Using our own interface generator as opposed to SWIG makes things simpler and gives us greater control over the types of APIs that can be generate.
Yes, Gmsh’s API has a “static-only functions” approach so every call is meant to be “independent” in the OOP sense. All memory management is done on the C/C++ side. For Fortran I think the API can be greatly improved by using some non-static OOP to cache certain values and make the return arguments a bit more straightforward. If you pay close attention some of the intent(out) arguments in subroutines are mixed with intent(in) arguments. That is an unfortunate side effect of Fortran not having tuples and the Fortran API having to obey the argument order of the main libgmsh.
I have been toying with the idea of writing a v2 of the Fortran API either on the Gmsh repo or fpm-exclusive but I don’t think there is any demand for it.
I’ve looked into SWIG-Fortran once but never dug deeper into its workflow - one problem with those automatically-generated interfaces is they tend to be full of bloat that makes them hardly readable. So I keep wondering that I should find some time to better automate my API generation processes, and do it in Fortran. At the end of the day, I believe Python here is the choice just because it’s got easy string handling features…
Nice work. Unfortunately, the restrictive license for the GMSH API means I can’t use it in any of the work I’m currently involved in (and I have a couple of applications where I have an immediate need for something like the GMSH API)
Last time I used gmsh was over 15 years ago. Nice to see it now has a Fortran API.
(Indeed, I recommend open source projects to use permissive licenses (MIT, BSD, …) to maximize the potential users who could use them. I’ve personally met so many potential users who couldn’t use a GPL licensed software inside a company. All great people.)
For anyone that wants to use Gmsh commercially and does not want to license their work under GNU GPL v2 please contact the Gmsh author to obtain a commercial license Christophe Geuzaine
I am more than happy to re-license the fpm package with a more permissive license just know that you will still need to have libgmsh installed in your system to actually perform any meshing tasks. The fpm package is meant to serve as a quick access to the Gmsh Fortran API.