Getting momenta in requests

[Pablo Zubieta]

Hi,

I'm trying to write a custom force filed that inherits from `FFEval` but that uses the momenta information in its call to `evaluate`. I have a custom `queue` overload that does this

```

    def queue(self, atoms, cell, reqid=-1):
        return super().queue(atoms, cell, reqid, template={"momenta": dstrip(atoms.p).copy()})

```

But it doesn't seem to be working, I'm getting zeros always when I call `request["momenta"] within `evaluate`.

Is there anything I'm doing wrong here?

Best,

Pablo Zubieta

[Michele Ceriotti]

uhm. think a bit about what you want to achieve. i-PI was designed with a strongly opinionated structure that tries to keep things relatively "logical" in its own way, and passing momenta to a forcefield clashes quite hard with the intended role of a forcefield. it might be best to try another route, e.g. to formulate what you're trying to do as a new integrator. for that there is quite a powerful pattern you can use with the scripting interface, see e.g. what we do for flashmd https://github.com/lab-cosmo/flashmd. otherwise, what you are doing seems sensible and the best way to help might be to share more details in an issue on github, and providing a pull request with access to the code you have written.

Cheers

Michele

[Pablo Zubieta]

We're trying to couple PySAGES to i-PI, and we have a (hacky/testing) branch for the implementation https://github.com/SSAGESLabs/PySAGES/blob/pz/ipi/pysages/backends/ipi.py. Some of the ABF related methods in PySAGES use Darve's estimate for the gradients of the free energy which rely on the atoms momenta (https://doi.org/10.1063/1.282986, eq. 9). Our MetaD implementation works fine and is able to reproduce the benchmarks you have for the Zundel pair system with MetaD (both for MD and PIMD). So we want a biasing force, which we would naturally expect to implement it through the ForceField interface. We're using the scripting interface already anyway, but I'll take a look at the FlashMD code in case that helps us somehow.

Best,

Pablo

[Pablo Zubieta]

Looking at the code in FlashMD it seems that you get access to the beads like so: `sim.syslist[0].motion` (which assumes a single-system simulation, and would also be the case for us for the time being). Since we hold a reference to the simulation in the ForceField itself when we initialize it, we could access the momenta as `simulation.syslist[0].motion.beads.pc`. Two questions here, 1) is this a reasonable approach?, and 2) it looks like `simulation.syslist[0].motion.beads` and `simulation.syslist[0].beads` are the same object, is this correct?

Best,

Pablo

[Michele Ceriotti]

Yes, there is a "base" object, which is system.beads, and references to it in the various classes that need access to it. 

If you want to do a quick and dirty implementation for your own use of course feel free to proceed along the path of maximum hackiness, but overall I would recommend you do not add a reference to forcefields from a component of system. forcefields are meant to be _called_ from system during simulations, going through the machinery defined in forces.py. This is the only way you'll have access to stuff like ring polymer contraction, and all the stuff you need if you want to run path integral simulations. 

Have a look at how metadynamics is implemented - there of course we don't need access to momenta, but there is a trick to use the energy as CV that I suspect could give some ideas for a more canonical way to achieve your goals.

Best,

M

[Pablo Zubieta]

For now we're just hacking away to get something that works, but plan to clean up things eventually. I understand the overall idea, how things where designed, and why it is expected for the forces machinery to call the forcefields methods for each system instance.

From the MetaDyn implementation I can see that we're bundling everything into a ForceField, whereas what we actually want is actually an SMotion derivative class or a mix of ForceField + SMotion (as done for FFPlumed + MetaDyn).

Thanks for the pointers.

Best,

P