search

i-pi / i-pi

i-PI: a universal force engine
https://ipi-code.org/
218 stars 114 forks source link

Providing a lower level python interface #228

Open pabloferz opened 1 year ago

pabloferz commented 1 year ago

As mentioned here https://groups.google.com/g/ipi-users/c/JlWokLv0oe8, the https://github.com/SSAGESLabs/PySAGES development team is interested in interfacing with i-pi. For this, we would need to work with a lower level python interface instead of the current CLI one that i-pi provides.

Would it be of interest of the i-pi developers to provide support for such an interface? @ceriottm mentioned that it should not be that hard to do so, but I'm leaving this as an issue here so it can be better discussed here.

ceriottm commented 1 year ago

The most basic "call from python" setup should be easy - the executable is basically just doing 

simulation = Simulation.load_from_xml(fn_input, request_banner=True, custom_verbosity=options.verbosity)
simulation.run()

So we could very easily call these and possibly also have the xml in a string. Disentangling the simulation setup from the loading of the input file is tricky because the various objects are constructed as the input is parsed. Can you explain more clearly what you have in mind?

pabloferz commented 1 year ago

@ceriottm that's great! It sounds like it shouldn't be that hard to interface with I-Pi from pysages then.

The way pysages works in a backend-agnostic way is by grabbing the equivalent to the simulation object, getting a hold of the particle information after each time integration step, inserting a call to the enhanced sampling method's update function and adding a biasing force back to the the particle forces in the backend.

In principle it shouldn't be an issue that the simulation setup and the loading of the input are entangled as we usually start from fully initialized simulation objects. One of the main differences I can see so far though, is that the number of time steps is also part of the simulation attributes and not an input to the run method, which is the interface used by the other backends we support (openmm, hoomd-blue, ASE) (pysages was designed to in general behave as the driver for enhanced-sampling simulations). This is principle can also be worked around as far as I can see.

I guess the things that are not clear to me would be:

  1. how could we access the particle information form a simulation object? and
  2. how to intercept (or add a callback) to the integration steps in i-pi?
ceriottm commented 1 year ago

ah ok. so this is similar to how PLUMED works. then probably it's best to see i-PI as the engine and modify i-PI to call pysages and get the bias. you can have a look at how the interface with PLUMED is implemented, if I understand the concept it should not be hard to do the same with SSAGES. Have a look at examples/plumed and the FFPlumed class in ipi/engine/forcefields.py