Alternative communication mechanisms not relying on sockets

[OndrejMarsalek]

[from TODO file]

[OndrejMarsalek]

I have two suggestions for this and I would be interested in working on both.

I have implemented communication using IPython in my PyMD code. This needs Python on both ends, but is quite convenient and takes care of a lot of the low level stuff. I use it to interface to ASE calculators, which I think would be nice to have in i-PI, as it exposes some quantum chemistry as well as QM/MM infrastructure (currently limited to FHI Aims with GROMACS, I think).

As far as I can tell, it should be possible to use MPI in a way similar to the current socket setup, i. e. launch separately, exchange information on where to connect (through files on a shared file system) and then send messages at MPI speed. Possibly also add/remove processes dynamically. This would be useful for fast or fast-ish calculators. On the Python side, we could use MPI4Py, on the side of the driver, whatever it is written in.

[OndrejMarsalek]

Oh, and a third one is a direct Python wrapper. Again in PyMD, I can call LAMMPS or PINY directly through their Python interfaces and there is a noticeable speed gain over IPython or sockets.

This would also allow implementing the simple potentials from the included driver written either directly in Python (for things like a harmonic interaction) or as wrapped Fortran code that does not need socket communication.

This should be the fastest way to run anything up to the size of one node.

[ceriottm]

There is already a stub of a built-in potential, but I imagine you mean more a dynamical thing where one would not need to add potential evaluation routines to the i-PI codebase.

On 18 June 2015 at 04:15, Ondrej Marsalek notifications@github.com wrote:

Oh, and a third one is a direct Python wrapper. Again in PyMD, I can call LAMMPS or PINY directly through their Python interfaces and there is a noticeable speed gain over IPython or sockets.

This would also allow implementing the simple potentials from the included driver written either directly in Python (for things like a harmonic interaction) or as wrapped Fortran code that does not need socket communication.

This should be the fastest way to run anything up to the size of one node.

— Reply to this email directly or view it on GitHub https://github.com/ceriottm/i-pi-dev/issues/60#issuecomment-113012975.

[weifang2321]

I also think this is an interesting issue. The socket communication system works pretty well on many HPCs, however, it can be very tricky to set up on some HPCs. A few month ago, I was in China trying to set up i-pi for Xin-zheng's group on TianHe HPC, one of the major HPCs in China. It didn't work out after many trails and we suspect that the system does not allow exes to access internet sockets on computational nodes. So I guess alternative ways for communication can be useful.

[tomspur]

I had similar problems and even tunneling was difficult, so I ended up running i-pi directly on one of the nodes within the batch system. As long as the restart mechanism works and your job is not just killed without a flush on all files, this works ok-ish. An alternative way for communication is just faster in these cases, but the current socket should also work.

[ceriottm]

The main problem with the socket thing is that you need to be sort of a hacker. I have successfully run it between two machines, both behind a firewall, using a man-in-the-middle, forward-and-reverse ssh tunnelling approach. It is however not something we should ask a user!!

On 18 June 2015 at 11:30, Thomas Spura notifications@github.com wrote:

I had similar problems and even tunneling was difficult, so I ended up running i-pi directly on one of the nodes within the batch system. As long as the restart mechanism works and your job is not just killed without a flush on all files, this works ok-ish. An alternative way for communication is just faster in these cases, but the current socket should also work.

— Reply to this email directly or view it on GitHub https://github.com/ceriottm/i-pi-dev/issues/60#issuecomment-113089644.

[mahrossi]

:-) We may be helping form a generation of hackers in that case.

Jokes apart, agree with the above. I actually vote for the MPI support, since it would be more in line with the philosophy of the wrapper and do not require the client codes to have a python interface or some other extra machinery.

Can try to help if needed.

[OndrejMarsalek]

MPI will definitely only work on a subset of network configurations where sockets work. It will not let you tunnel through four different connections and a VPN in North Korea :-p What I am mostly after with that is low latency, though.

There will also have to be some extra machinery on the side of the calculator, it will just be in the same language as the rest of the program and will use MPI calls.

[OndrejMarsalek]

On second thought about IPython, I doubt it is worth it. While it has many nice features, in this case it would be limited in that it can only communicate with programs that already have some Python on their side. It might be better to use a socket client in Python instead, so that we don't have to maintain the infrastructure.

[OndrejMarsalek]

As for direct interaction evaluation in i-PI, I think it would be nice to be able to call anything that provides a specified Python API. Setting up such calculation would be much more natural when using a Python script instead of an input file with fixed structure, though. That way, settings specific to that interaction can be easily passed to it.

Example from PyMD:

interactions = pymd.interaction.Harmonic(k)

beads = pymd.system.PIBeadsStaging(
    m=m, x0=x0, P=P, T=T,
    interactions=interactions)