[IPython-dev] ipython + MPI

Wed Oct 18 23:47:20 EDT 2006

Marek,

I *really* like how you are getting ipython to work with mpi4py
interactively.  This accomplishes what pympi and the interactive mode
of mpi4py provide, but you don't have to recompile python.
For those of you who want an extremely simple way of using mpi
interactively, I think this is the best way.  I will probably start to
use this for simple stuff and I might even talk to Fernando about
adding your idea to IPython itself.  Also, I really like mpi4py.

So, how does this relate to the parallel capabilities we are working
on with IPython1:

http://ipython.scipy.org/moin/Parallel_Computing

Most importantly, there are a number of huge limitations of your
approach (and that of pympi) that make it unsuitable for serious
interactive usage:

1.  Your interactive session must be part of the mpi world.  This is
not good because it forces you to do everything in a single
interactive session.  For instance, you can't start an mpi job
interactively on a cluster, disconnect, turn off your laptop go home
and then reconnect to the running mpi job.  If your mpi job lasts a
long time this is unworkable.  With IPython1, your interactive IPython
session is typically on your local workstation and is not an mpi
process.  But, it can connect to the mpi processes (the IPython
Engines in our language) through what we are calling the IPython
Controller (which manages the Engines).  This architecture allows you
to steer an mpi job interactively and to disconnect/reconnect to that
mpi job at any time (we even have a web interface).

2.  If you run a long running command (which you probably will if you
are using mpi) your parallel ipython will block until that command is
done.  With IPython1, mpi commands (any command for that matter) can
be sent to the Engines in either blocking or non blocking mode and we
maintain a queue for each Engine.  This allows you to fire off many
long running python commands - some of which may be mpi calls - and
your local IPython session won't block at all.

3.  Plotting/Visualization.  Try typing 'import matplotlib' in your
parallel Ipython session.  If all the processes are on your local
machine you will probably get 4 or 8 or 16 identical matplotlib
instances.  If you do this on a supercomputer you will get some wierd
error or something worse.  With IPython1, there is only one
interactive instance of IPython running (most often on your local
machine).  We make is easy to ring data back from a remotely running
mpi job to this local IPython instance for plotting and visualization.

4.  Your approach only supports SIMD (single instruction/multiple
data) style parallelism.  That is, each process will always execute
the same code.  With IPython1, you can easily send different commands
to different processes to achieve arbitrary MIMD parallelism (multiple
instruction/multiple data).  This is a little more academic, but I
think it is important for developing general parallel applications.

With all this said, don't let these limitations discourage you from
pushing your ideas further.  I am all for making IPython work in
parallel contexts in as many ways as possible.  I also like your
approach because it is sooo simple and easy to use.  I will probably
use it myself for this reason.
But, I think you will find that the IPython Engine/Controller in
IPython1 make interactive parallel work much more pleasant.

For more information about all the IPython1 stuff, check out the above
web page or the following page that has talks abot this stuff:

http://ipython.scipy.org/moin/About/Presentations

Also, feel free to check the code out from our repository and try it
out.  Also please bug us with questions if you have any.

Cheers,

Brian

> Hi!
> A while ago I have written a small patch to the last ipython (7.2) which
> consist mainly in writing the following function:
>
> def mpi_raw_input(prompt):
>      rank = 0; mpi = False; size = 1
>      try:
>          from mpi4py import MPI
>          mpi = True
>          COMM = MPI.COMM_WORLD
>          rank = MPI.rank
>           size = MPI.size
>           line = ''
>      except: pass
>      sys.stdout.flush() #Just to avoid messy output
>      if rank == 0:
>          line = raw_input(prompt)  # Command is read by first process only
>      if mpi and size > 1: line = COMM.Bcast(line, 0)  # And is broadcasted
> to all processes involved
>      return line
>
> Then at the top of iplib.py I made an assignment:  raw_input_original =
> mpi_raw_input
> instead of:  raw_input_original = raw_input
>
> I'm using mpi4py package here from http://www.cimec.org.ar/python, but any
> mpi port to python could be used here.
> This slight change allows to run ipython with simple:
>      mpirun -np 4 ipython (assuming you have modern enough MPI
> implementation)
> All commands are read by first process only and broadcasted to all others
> for execution. With this it is possible to follow plain MPI approach to
> parallel execution:
>
> [In]<1> 1+3
> [Out][Proc0]<1> 4
> [Out][Proc1]<1> 4
> [Out][Proc3]<1> 4
> [Out][Proc2]<1> 4
>
> [In]<2> from mpi4py import MPI
> [In]<3> if MPI.rank in [1, 3]: print "I'm process %i" %(MPI.rank)
> I'm process 3
> I'm process 1
>
> [In]<5> from math import sin
> [In]<6> bg sin(3)  # ipython magic works as well :)
> Starting job # 0 in a separate thread.
> Starting job # 0 in a separate thread.
> Starting job # 0 in a separate thread.
> Starting job # 0 in a separate thread.
>
> Obviously, there are problems with standard output of ipython processes,
> as we are not always interested in output of all of them. However this can
> be handled in a similar way as the input, and was partially done (i made
> for example help messages produced by ipython to be displayed at first
> process only).
>
> Now i observed that new ipython development introduces a parallel
> execution via "controllers" and "engines". Is the above very simple
> approach comparable in any way with this new development. How does it
> support MPI communication? What are the other advanteges of the new kernel
> above the current ipython?
>
> Thanks for any replay
>
> --
> Marek Wojciechowski
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/ipython-dev
>