I’ve built gmsh artifacts with
BinaryBuilder and copy pasted the gmsh Julia API, such that everyone can use now the gmsh api without caring about a local gmsh installation.
Further, I included a docs page with commented tutorials.
Most of this is a simple copy paste of the original gmsh repo, just everything packed together nicely. All credits go to the gmsh devs. I hope this package will help to boost reproducibility of scientific computing projects who need some more complicated meshing.
GUI Features and the OpenCASCADE kernel is not supported (as of now). However, OpenCASCADE support will be added in future.
Here it is: GitHub - koehlerson/gmsh.jl: Julia interface for Gmsh: a three-dimensional finite element mesh generator software
Note that software design decisions were exclusively made by the gmsh devs. If you want something more julian, feel free to build it on top.
Is there a way this could be merged with Gmsh.jl?
If you check out this issue, then you’ll see that this was my initial plan. Since I don’t have access to the repo settings I cannot set repo secrets and other stuff which is needed for deploying docs. My spare time is limited and I don’t want to sound cocky by any means, but I don’t want to wait a couple of days only to get a repo secret added. Further, I don’t want to contribute to a repo which is still under the hood of an almost dead organization. Additionally, I decided to prioritize the gmsh devs decision over blue style convention to name things in a non-julian way, i.e. gmsh.jl instead of Gmsh.jl. By this the API is consistent with other language’s api, e.g. python and c++. In fact the commented tutorial in the
gmsh.jl docs is a glorified copy paste of the python tutorial. As far as I understood renaming is not supported by the registrator, is it?
Maybe one useful trick you could use if you change the name but want to keep the tutorials as they are is:
const gmsh = YourGmsh
# rest of the tutorial as you had it
but maybe you knew this already
@giordano I saw your comments in the PR. It’s not a big deal for me if it isn’t registered, but it was good to see the procedure of registering it.
@tlienart good to know that it is even possible with modules. I used it to rename the lib here. Beside the tutorials, I decided to keep it lower case because in this way it’s consistent in its incosistency (if that makes sense)
Do I understand correctly that you initiated a discussion on this over the holiday season and expected it to be resolved in less than a couple of days? Even during normal times, a couple of days is a speedy turn-around time, IMO. Package maintainers have other things to resolve in life than just Github issues.
I seriously thought intensively about not posting it, because it was a matter of time until a comment like this comes up.
I want to note that we are speaking about a repo, which has 12 commits from a single person, which is as unmaintained as it could be. I didn’t expect to be resolved in the holiday season but I gave it a try. However, I have deadlines and so this was the only time I could make up for this.
I need a working version with documentation in the middle of this week for an assistant and I think it’s worth to share with everyone. If you don’t think so, just leave it, but I’d highly appreciate if you don’t try to put me in a bad light.
Anyhow, if more people feel that this is offensive in any way, I just delete this whole announcement and everyone is good to go.
Edit: it’s not like I don’t want to merge it in
Gmsh.jl I just won’t have the time from tomorrow on, thats all
Yes, re-implementing something because you cannot wait for the maintainer of another package is just fine (but that is not what your original post (3# in this thread) read to me). In particular, if Gmsh.jl and gmsh.jl can be merged at some point.