Python on ALICE and SHARK

There are different versions of Python available on ALICE and SHARK. Some have also been build with CUDA support. You can choose whatever version is available and suitable for you.

Preparations

It is always a good idea to start by looking at the load of the cluster when you want to submit a job. Also, it helps to run some short, resource-friendly tests to see if your set up is working and you have a correct batch file.

The “testing”-partition on ALICE or the “short” partition on SHARK can be used for such purpose. The examples in this tutorial are save to use on those partitions.

Here, we will assume that you have already created a directory called user_guide_tutorials in your $HOME from the previous tutorials. For this job, let's create a sub-directory and change into it:

Since this tutorial will go through different examples of Python jobs, further preparations are discussed for each example.

We will make use of the Numpy package in this tutorial. For demonstration purposes, this tutorial will show you how to install it in your user environment in Python virtual environment.

Setting up Numpy in a virtual environment

In most cases, it is best to setup your own Python environment and install all necessary packages manually from the command line and not make it part of the Slurm batch file. Or you can create a separate job that only takes care of installing the virtual environment. Here, we will make a manual install.

First, we have to a load one of the available Python modules:

Next, we will create the virtual environment in the directory of our test job (assuming that you have changed into this directory)

To activate the newly created virtual environment, we have to source it:

Note how the command line prompt changed from [me@<nodename> first_python_job] to (guide_venv) [me@<nodename> first_python_job] indicating the active virtual environment. You can also see this by retrieving the list of packages in the virtual environment which is quite different from when you run it outside the environement, e.g., it might look like this (version numbers will most likely have changed)

Before we install any packages, we update the existing pip and setuptools packages and install the package wheel by running

Now, we are ready to install the python packages that we need. In this case, we just need Numpy, so we run

If the installation was successful, you should see a message such as this: Successfully installed numpy-<version>.

You can also create a requirements file which includes all packages that you want to install. Then you tell pip to use this requirements file and it will proceed to install all packages. This helps with reproducibility because you can easily re-create virtual environment with the same package configuration. Conda has a similar feature.

You can leave the virtual environment by running:

A serial Python job

First, we will prepare and run a simple Python job that will calculates the median of a randomly generated array several times. Here, we will do this in a serial manner on a single core.

Preparations

The Python script

We will use the following Python script for this example and save it as test_python_simple.py.

For demonstration purposes, the script contains quite a few print statements. Since this is a very basic example, we will not use proper logging, but write everything out to the Slurm output file.

The Slurm batch file

The next step is to create the corresponding Slurm batch file which we will name test_python_simple.slurm. We will make use of the testing partition on ALICE or the short partition on SHARK. Make sure to change the partition and resources requirements for your production jobs. The running time and amount of memory have already been set in a way that fits to the resources that this job needs. If you do not know this, it is best to use a conservative estimate at first and then reduce the resource requirements.

where you should replace <your_email_address> by an actual e-mail address of yours.

The batch file will also print out some information to the Slurm output file. To separate the output from what the Python script will produce, we use [$SHELL] here.

Job submission

Let us submit this Python job to slurm:

Immediately after you have submitted this job, you should see something like this:

Job output

In the directory where you launched your job, there should be new file created by Slurm: test_Python_simple_<jobid>.out. It contains all the output from your job which would have normally written to the command line. Check the file for any possible error messages. The content of the file should look something like this:

The running time might differ when you run it. The process ID (PID) is printed out for demonstration purposes. Because this is a serial job, the PID does not change.

You can get a quick overview of the resources actually used by your job by running:

The output from seff will probably look something like this:

A parallel Python job

The simulations that you ran in the previous example are independent of each other. This makes it possible to make them parallel and use multiple cores.

Preparations

Parallel Python script

There are different ways to parallelize in Python. Here, we will make use of the Multiprocessing package which is a standard package in Python. This is just one example and not necessarily the best option for your case.

We will name the Python script test_python_mp.py and put in the same directory as the previous script. While this is fine for this tutorial, in a realistic case, it is probably best to use a separate directory in order to avoid having too many files in one directory.

Slurm batch file

The Slurm batch file will be named test_python_mp.slurm

where you should replace <your_email_address> with your e-mail address.

Note the changes that were made to the list of resources: The number of cores has been set to 10 (--cpus-per-task) and the amount of memory is specified as per core (--mem-per-cpu). We have also changed the name of the job to make it consistent.

Job submission

Let us submit this Python job to slurm:

Immediately after you have submitted this job, you should see something like this:

Job output

The job should have created test_python_mp_<jobid>.out. As before, check the .out-file for the output from the script any possible error messages. It should look something like this:

Note how the running time changed compared to the serial job as is expected from using multiple cores. You can also see the multi-processing at work because there different PIDs and the output is out of order.

You can get a quick overview of the resources actually used by your job by running:

It might look something like this: