Roadmap for GEL and PyGEL

[janba]

It seems worthwhile to be a bit more principled about the future development of GEL/PyGEL. In this post I share some thoughts on how we move forward. The plan is to update this post and ultimately it will be a roadmap for getting to version 1.0.

Consolidation efforts

Work is on the way on several efforts that do not add many new features but which aims to improve the existing code base and add some functionality which has been present but poorly exposed. Highlights:

• Curvature computation was always part of GEL but the C++ functions are now being exposed also in PyGEL.
• Computing the genus of a shape or a class of shapes is simple and now supported by the API.
• Rotation System Reconstruction (courtesy of @cuirq3 ) is being optimized by @cakarsubasi . This touches many other parts of GEL which are then also improved as we go.
• A testing framework has been added and tests are now part of the GitHub Action when the code is committed (@cakarsubasi)
• Several of the demos have been improved, and demos are being added. This effort is ongoing, and I hope to make videos showcasing the demo in order to improve the general level of introductory material.

Introduce subpackages

Currently, we use a simple structure where pygel3d contains several submodules: hmesh, graph, gl_display, jupyter_display, and spatial. While this is appropriate most of the time, the hmesh submodule contains a fairly long list of functions some of which could be grouped meaningfully into submodules. For instance, a smooth submodule might contain the handful of existing smoothing functions. This would be a breaking change, though, and perhaps the original API should be left in place but deprecated before fully transitioning.

Switch to pybind11 for PyGEL bindings.

Passing data back and forth between C++ and Python is the main difficulty associated with creating the PyGEL bindings. Currently, we use ctypes which constrains the interface between C++ and Python to consist of plain C functions. This is not in itself problematic: classes are passed back and forth as raw pointers which works well, and it is usually best not to directly expose the class interfaces. However, any data has to be passed as POD types to the functions in the C API. With pybind11 it would be possible to use a C++ API to bridge between GEL and PyGEL and simply return STL data structures from this API and also convert Python data structures to STL data structures when calling. The benefits of this enormous flexibility in transferring data seem to outweigh the added header-only dependency.