Moving i-PI sampling to use FFDirect? #85
Replies: 2 comments 1 reply
-
Making the switch does seem like the best thing, if indeed If I have time I can definitely try some stuff out. |
Beta Was this translation helpful? Give feedback.
-
But I think I'm missing something. If not with sockets, how does FFDirect work exactly? How are particle positions passed into a PyTorch model, and how are the forces passed into the integrator, if not via sockets? Python multi-threading/processing? That might interact badly with PyTorch? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
In i-pi/i-pi#452, we are discussing ways to reconcile i-PI restructuring updates with our current framework. Bottom line is, if either i-PI keeps its
run_driver
function exposed, or we make a copy ourselves (preferably not), then everything can keep working as it is.We have been asked to implement an i-PI PES that connects Psiflow
functions
to the i-PI framework. This would allow us to use theirFFDirect
implementation, so we can skip the entire server-client socket model. I'm very much unfamiliar with the inner workings of i-PI, but ifFFDirect
offers similar functionality (i.e., any combinations offunctions
on specified hardware running asynchronously w.r.t. the main simulation), we could drastically simplify the way we handle MD simulations.Do we try to make the switch to using
FFDirect
?It could solve a lot of annoying bugs (#74 #72 etc.) we keep discovering and make things easier to maintain. On the other hand, it would require significant refactoring on our part and also restrict simulations to single nodes (but that is all we ever did, and probably all we will ever do).
Thoughts? Things I am missing?
@svandenhaute @armaet
Beta Was this translation helpful? Give feedback.
All reactions