shared-library / driver API for GPUMD

[JaafarMehrez]

Hello, I would like to discuss a possible direction for interfacing GPUMD with PySAGES before preparing any PR.

I have been exploring how GPUMD could be coupled to PySAGES for enhanced sampling workflows. My initial thought was to use the MDI route, and I have also worked on GPUMD-MDI support before #1379 . That approach is functionally viable, but for this particular use case PySAGES needs very frequent interaction with the MD engine, so I found that a more tightly coupled interface may be better suited in practice.

Based on that, I started prototyping a library-driven approach in which GPUMD can also be used as a shared library, while keeping PySAGES-specific logic outside GPUMD itself.

The general idea is:

• keep the usual GPUMD executable workflow unchanged
• optionally build GPUMD as a shared library
• expose a small driver-style C API for initialization, stepping, cleanup, and a few basic queries
• allow an external driver to apply bias forces during the run
• leave the Python / PySAGES / DLPack bridge in a separate external repository

In other words, my intention is not to make GPUMD depend on PySAGES directly, but rather to make it possible for external tools to drive GPUMD in a low-overhead way when needed.

In a local prototype, the GPUMD-side changes that seemed necessary were mainly:

• adding a libgpumd.so target
• making the run loop accessible in a driver-controlled stepped mode
• adding a small C API around the run lifecycle
• supporting external force injection

The motivation is mainly to support tightly coupled enhanced-sampling workflows where the external method needs access to the system state and needs to feed forces back every step. For this type of workflow, an in-process interface appears to have lower overhead than a more general communication layer.

Before going further, I wanted to ask whether this general direction sounds acceptable from the GPUMD side.

In particular:

• would an optional shared-library / driver API be something you would consider upstreaming?
• would you prefer such support to remain behind a build option?

If this direction seems reasonable, I can then try to clean up the prototype changes and prepare them in a form that is
easier to review. I would be very interested in your thoughts on the design before turning it into a PR.

[brucefan1983]

Sounds a good plan. The major requirements for closely integration with GPUMD are:

• The users can compile the code with standard CUDA toolkit, by default. Otherwise, it should be under a compiling option.
• The creator can help to maintain in the future; an unmaintained feature might get removed in future versions.