Parallel computing using IPython: Important notes for naive scholars without CS background

Analysis of network and complex system requires too much computing resources. Although the learning curve is deep, the power of parallel computing must be utilized, otherwise, more time will be spent on waiting. Moreover, for exploratory academic research, we will not know what’s the next step until we finish the current analysis. So the research life-cycle becomes hypothesis -> operationalization -> LONG TIME coding and debugging -> LONG TIME waiting for result -> new hypothesis.

With IPython Notebook, parallel computing can be easily operated; however, like what I’ve said: We cannot understand the easiest programming skills unless we are able to operate them. I’ll not come to this post if I do not have to wait for a week only for one result. Playing parallel computing with IPython is easy, but for real jobs, it’s not. Scholars in social science area may be less skilled in programming – we are not trained to be. I’ve made great efforts and finally got some progress which may be laughed by CS guys.

While using IPython Notebook (now named Jupyter Notebook) for parallel computing, Jupyter will start several remote engines beside the local one we are using. These remote engines are blank which means that the variables and functions defined and modules imported on the local engine do not work on the remote ones. Specifically, the puzzle for me was (yes, was!): How to operate the variables, functions, and modules on the remote engines.

  • Operate Variables on Remote Engines

The locally defined variables cannot be directly used in remote engines, if we do, we will get error message like “Local variables *** is not defined.” Defining variables on remote engines is easy.

I start 4 engines in the Notebook (under IPython Clusters tab), so the result of above codes is:

Define variable a = 5 on all four engines.

This gives result:

Change the value of a variable on a specific engine, say engine#0:

This gives result:

We see the value of a on engine#0 is 10 now (line 1), different from the other three engines (line 2). Easy task.

  • Operate Functions on Remote Engines

“Remote functions are just like normal functions, but when they are called, they execute on one or more engines, rather than locally.” (Quote from Official Docs) IPython provides two decorators: @dview.remote(block=Boolean) and @dview.parallel(block=Boolean).

This gives result:

If we change the @dview.remote(block=True) to @dview.remote(block=False), the result will be (also refer to this post):

Obtain the result:

Result will be:

@dview.remote does not provide map function with which we can scatter a list of arguments to different engines. In the case above, we see the argument “1” is passed to all four engines. But @dview.parallel comes with map function.

This gives result:

The block=Boolean argument is the same with .remote.

  • Import Modules on Remote Engines

Two ways of importing modules on remote engines, we’ve already seen one in the above example (.execute), another way is using with loop.

The output is:

Attention should be paid here: the import * as * command does not work in this scenario. If we use np instead of numpy in defining the function, we’ll have the following error message (But it does work in .execute!):

With these three basic skills, i.e., operation of variables, functions, and modules on remote engines, we will be able to handle more complex tasks using IPython Notebook and parallel computing.