These magics will automatically become available when you create a Client:

In [1]: fromIPython.parallelimportClientIn [2]: rc=Client()

The initially active View will have attributes targets='all',block=True,
which is a blocking view of all engines, evaluated at request time
(adding/removing engines will change where this view’s tasks will run).

In [28]: %px %pylab inline
Parallel execution on engine(s): all[stdout:0]Populating the interactive namespace from numpy and matplotlib[stdout:1]Populating the interactive namespace from numpy and matplotlib[stdout:2]Populating the interactive namespace from numpy and matplotlib[stdout:3]Populating the interactive namespace from numpy and matplotlib

And once in pylab mode with the inline backend,
you can make plots and they will be displayed in your frontend
if it supports the inline figures (e.g. notebook or qtconsole):

The default targets and blocking behavior for the magics are governed by the block
and targets attribute of the active View. If you have a handle for the view,
you can set these attributes directly, but if you don’t, you can change them with
the %pxconfig magic:

Engines are really the same object as the Kernels used elsewhere in IPython,
with the minor exception that engines connect to a controller, while regular kernels
bind their sockets, listening for connections from a QtConsole or other frontends.

Sometimes for debugging or inspection purposes, you would like a QtConsole connected
to an engine for more direct interaction. You can do this by first instructing
the Engine to also bind its kernel, to listen for connections:

In [50]: %px from IPython.parallel import bind_kernel; bind_kernel()

Then, if your engines are local, you can start a qtconsole right on the engine(s):

In [51]: %px %qtconsole

Careful with this one, because if your view is of 16 engines it will start 16 QtConsoles!

Or you can view just the connection info, and work out the right way to connect to the engines,
depending on where they live and where you are: