It sounds like your use case is exactly of the sort that gmxapi is intended to address.
Most such frameworks have performant and stable Python interfaces. Are there any specific C++ APIs you need to interact with, that I could assess for compatibility considerations?
Where possible, we just use Python as “glue” for C/C++ code. I think you will find that the Python interface does not affect simulation performance. As library I/O allows for optimizations (data transformations/exchange, short-circuiting of unnecessary I/O), optimizations specific to API use cases will probably be available in a stable form through the Python interface before the C++ API can be stabilized.
Two performance issues we hope to tackle this year are simulation input/output API handles and array data interfaces. Currently, the C++ library does not provide handling of input/output other than through the filesystem.
Buffer/reference access to array data and SimulationInput / SimulationOutput handles should be stabilized in Python for the next major release, and will continue to be optimized in future releases. (Stable C++ interfaces may take longer.) The exception is that some data from live simulations should become more accessible through the MD C++ extension interface as the library-internal MDModules framework evolves, so in some cases you will be able to get optimal access to, say, particle positions, by attaching a small C++ module. (Historically, we use Python to bind such code at run time as the simulation launches, then Python does not participate again until the simulation is over or it is explicitly called by the extension code.)
By the way, if there is a lib that only contains the algorithm part works better for me.
Unfortunately, the algorithms code is historically very intertwined. Efforts to separate them over the last few years have been only partly successful. For the foreseeable future, you will have to direct the library with a comprehensive description of the work to perform through some version of MDP / TPR / SimulationInput. It is unlikely that the dispatching code will be more directly exposed in the immediate future.
The source code about the distribution and devices in GMXAPI may need to be removed in the future in my scenario.
I’m hopeful that we will be able to better compartmentalize this soon. Performance on the primary code paths is the highest concern for GROMACS development, though, so we have to be careful as we disentangle the dispatching of computational work from the detection and assignment of computing resources. See, for instance, these near term resource management issues
Depending on the molecular systems that you want to study, you may find the C+±only NBLib library useful. It is being architected from the ground up instead of from the top down, so it does not include all libgromacs functionality, and reimplements other aspects as necessary to support its interface design or performance considerations. See Guide to Writing MD Programs — GROMACS 2022.1 documentation