Configuring KNIME to work with Python 2.7.x on Windows

Apparently it is tricky to get Python integration working in the KNIME Analytics Platform. If you read the official guide too quickly you can miss some critical information at the bottom of the page. I was getting an error complaining that the google.protobuf library was missing even though I thought that I had everything installed correctly:

Library google.protobuf is missing, required minimum version is 2.5.0

Here is the correct sequence of actions to fix this problem and get Python integration working in KNIME. It worked for me, so I hope it works for you too!

  1. If you don’t already have it on your system, download and install Anaconda Python. I use the Python 2.7 version of Anaconda. I recommend installing Anaconda in the folder “C:\Anaconda2”.
  2. Create a new conda environment by using the following code at the windows command prompt (or power shell):
    conda create -y -n py27_knime python=2.7 pandas jedi protobuf
  3. Create a new Windows batch file with the following contents:
    @REM Adapt the directory in the PATH to your system
    @SET PATH=C:\Anaconda2\Scripts;%PATH%
    @CALL activate py27_knime || ECHO Activating py27_knime failed
    @python %*

    Of course, you might have to change the path to your Anaconda2 installation if you installed it to a different path.¬†Save the batch file somewhere, like your user directory or the KNIME workspace folder. I named my file “py27.bat” and placed it in the knime-workspace folder.
    Just in case anyone reading this is confused…. a windows batch file is just a text file that is saved with the file extension “.bat”. You can create it in any text editor by creating a new empty text file, pasting the above four lines of text into it and saving the file as “py27.bat”.

  4. If you haven’t already, download and install KNIME Analytics Platform. At the time of writing, the latest version is 3.4.0, so that’s the one I used. You might as well get the installer with all the free extensions included, presuming you have enough disk space for it and your internet connection is decent enough. This will save having to install further packages later, although to be fair KNIME seems to do a fairly good job at installing packages on the fly (after asking you first) whenever you load a workspace that needs them.

    Downloading KNIME

  5. Start KNIME. Go to File>Preferences, then KNIME > Python scripting. In the “path to the local python executable” paste the full path to your batch file, e.g. “C:\Users\yourname\knime-workspace\py27.bat”. To be future-proofed, also do this for KNIME > Python (Labs).
    KNIME now calls our batch file instead of calling the system-wide Python executable directly. The batch file activates the “py27_knime” environment before calling Python. This makes sure that the additional libraries required by KNIME are available.
    I guess you could also get your usual Python environment working with KNIME by installing additional packages, but let’s just do what the knowledgeable guys at KNIME have suggested this time. ūüôā

    Python scripting preferences for KNIME Analytics Platform in Windows

  6. Now restart KNIME. Try opening or creating a workflow with a node that uses some Python code. It should work now!

Successfully clearing ports in Salome (Code ASTER)

Building a geometry in the Salome graphical user interface (GUI).

How Salome tracks ports

When Salome is starting up, it checks for free ports on your system using a few built-in Python scripts. Then when you close Salome those ports should be freed up again for the next one. This has a number of uses, but one reason is to stop multiple instances of Salome trying to use the same port at once.

Those Python scripts keep track of the port numbers that are currently in use by storing the numbers in some configuration files (*.cfg) that are saved on your system. When Salome exits, those configuration files should be updated to recognize that the current port is being freed up again.

A possible problem with port tracking

Sometimes, however, those configuration files do not get updated. For example, if you are running Salome using a script in batch mode you can¬†include a command to kill Salome properly, giving the correct port number. I have found in the past that this method has not been very reliable and so the configuration file keeps being updated with port numbers that are in use, but those numbers are never removed from the “in use” list even if they have actually been freed up on the system.

If you do a lot of scripting in salome you will find that when writing/testing your scripts, if salome crashes a lot then often the ports being used don’t get released and so stay as “being used” in the port log file.

The result is that after a while a maximum number of ports is reached and Salome thinks that there are no ports free, so it will not start successfully, giving the following error message:



Can’t find a free port to launch omniNames

Try to kill the running servers and then launch SALOME again.


Perhaps you will check for salome instances running using. There may or may not be lots of Salome processes running on your system. In this post I am going to assume that Salome has closed properly. You can check if salome is running:

ps -x | grep salome


Salome provides some Python scripts that should kill any running instances in a well-behaved way. For example, kills all of the instances running on your system, so you should use it with care:


But if you already know the port number of a specific instance, can be invoked to kill just that one, without affecting other instances that are currently running:

~/bin/SALOME-8.2.0-UB16.04/BINARIES-UB16.04/KERNEL/bin/salome/ 21116

As a last resort, you can kill all processes in your system that mention salome:
ps x | grep salome | awk ‘{print $1}’ | xargs -n1 kill
OK, so now the ports should be freed up, right? Well maybe not! Your problem might indeed be that Salome is not updating the port config files correctly. Just killing the processes does not help because the next instance of Salome you launch will still check those files and think that there are no free ports. If this describes your current situation, don’t worry! I will now explain how to fix it.

Clearing the port config files

For my version of Salome (see footnotes), hidden configuration files were being created in a number of locations.
For example, the .omniORB_PortManager.cfg file, which in my case is located in my home directory at ~/.omniORB_PortManager.cfg
However, deleting this file did not solve the problem.
I then searched through my home drive for all *.cfg files, but none of the ones that came back were related to ports.
$ find . -name *.cfg
… plus a load of non-salome-related stuff…
This would also have found any “.omniORB_*_2888.cfg” (where 2888 is the port number) as mentioned¬†here but those did not show up.¬†There is a USERS directory within my salome installation directory structure at¬†~/bin/SALOME-8.2.0-UB16.04/BINARIES-UB16.04/SALOME/USERS, however it is empty and so does not contain any such .cfg files.
~/bin/SALOME-8.2.0-UB16.04/BINARIES-UB16.04/SALOME/USERS$ ls -a
.  ..
Finally, I found that for my installation Salome was using /tmp to store these hidden *.cfg files. The /tmp/ directory (and maybe other directories – see below) contained the following files:
  • .omniORB_PortManager.cfg
    • Stores a list of the busy ports
  • .omniORB_PortManager.lock
    • Locks the¬†.omniORB_PortManager.cfg from being edited? I’m not sure exactly what it locks.
  • .omniORB_<username>_<hostname>_<port>.cfg
    • Should be deleted each time but if Salome is not doing this you will have many of these files with different port numbers.
  • .omniORB_<username>_last.cfg
    • I guess this probably stores the last port that was used, although I deleted it¬†already before confirming this hunch.

On one of my systems (a HPC cluster) Salome was not storing the .omniORB_PortManager.cfg file in /tmp/ . Instead it was located in /home/<username>/bin/salome/appli_V7_6_0/USERS
You can check which path is being used by looking in /home/<username>/bin/salome/appli_V7_6_0/bin/salome/¬† In there is a variable named “omniorbUserPath”, which is obtained from an environment variable that I could not see. Nonetheless, I modified to print this variable to screen, which told me that it was looking for /home/<username>/bin/salome/appli_V7_6_0/USERS/.omniORB_PortManager.cfg . Believe me, this was very frustrating to identify as I really thought I had deleted all necessary files, only for salome to continue not finding a free port!

You can delete all of these files, and now when you run Salome it will start fresh, creating new files as it needs. Problem fixed! But…

Stop it happening again

The above fix will only help if we don’t cause the problem again. If you are creating many models or running many simulations from a controller script you do not want to keep reaching a hard limit of consecutive salome calls you can make, only to have to manually delete the omniORB config files again. What we really want is to make sure that¬†Salome will¬†update the config files correctly in future.
In the past I tried many times to use¬† I did this by running salome with¬†the –ns-port-log argument and providing a log file to store the port number.
<salome_distro>/salome --ns-port-log="somefolder/salomePort.log" -t -b
port_file = open('somefolder/salomePort.log' , 'r')
killPort = int(port_file.readline())
<salome_distro>/bin/salome/ %s' % killPort
For some reason I could never get this to work successfully. I always ended up building a call to in my script, which kills all running Salome instances and meant that I had to build models consecutively, never in parallel. It also meant that if I had a script running I could not really use the Salome GUI because it too could be killed at any moment!
Here is the correct way to do it, which I only recently discovered through some trawling of the web (unfortunately I can no longer found the page where I saw it and so I can’t give credit to the author).
if not
    from killSalomeWithPort import killMyPort
The important part is inside the “if” clause.¬†killSalomeWithPort contains a function called killMyPort and the current port used in our Salome instance is stored in an environment variable named “NSPORT”. So by passing that port number to the function we can kill Salome cleanly!
The just returns True if we are in the Salome GUI. Because if we were, we would not want our script to kill Salome for us. We only want it to happen if we are running inside a batch script.
I’m wondering why I never found this solution before, as it would have saved me a lot of frustration, but there you go, that’s life! Now I am passing it onto you,¬†have fun!


  • I am using the Salome version¬†8.2.0 for¬†Ubuntu 16.04 x64 precompiled binaries. Different versions have different file structures and so your¬†binary folder path might be different. If you search on the command line for e.g., you should¬†be able to identify where your salome binaries and Python scripts are located.
  • A lot of this info was gleaned from the Salome user forum, particularly from this 2015 post:
  • In Linux, hidden files have a full stop (US: “period”) in front of their filename. To see them when listing a directory use “ls -a”.
  • For more information about why Salome needs to use ports, check out the Salome FAQ.

New Paper: Role of twin and anti-phase defects in MnAl permanent magnets

Our latest paper has just been published in the journal Acta Materialia. In it, we compare finite element micromagnetics simulations to experimental evidence in order to investigate the role of twin and anti-phase defects in the reduction of performance in MnAl permanent magnets.

Room temperature (BH) max as a function of approximate raw material costs for
the theoretical MnAl permanent magnet and experimental values for a selection of common
commercial permanent magnets. The raw material costs are a good indication of the relative cost of the manufactured magnets.

The preprint version is available on


Twin domain boundary nucleation field H nuc and de-pinning fields for left H depin,L
and right H depin,R initial positions as a function of twinning angle őł.


Parallelization in Python example with joblib

It can be ridiculously easy to parallelize code in Python. Check out the following simple example:

import time 
from joblib import Parallel, delayed 

# A function that can be called to do work:
def work(arg):    
    print "Function receives the arguments as a list:", arg
    # Split the list to individual variables:
    i, j = arg    
    # All this work function does is wait 1 second...
    # ... and prints a string containing the inputs:
    print "%s_%s" % (i, j)
    return "%s_%s" % (i, j)

# List of arguments to pass to work():
arg_instances = [(1, 1), (1, 2), (1, 3), (1, 4)]
# Anything returned by work() can be stored:
results = Parallel(n_jobs=4, verbose=1, backend="threading")(map(delayed(work), arg_instances))
print results


Function receives the arguments as a list: (1, 1)
Function receives the arguments as a list: (1, 2)
Function receives the arguments as a list: (1, 3)
Function receives the arguments as a list: (1, 4)
['1_1', '1_2', '1_3', '1_4']
[Parallel(n_jobs=1)]: Done   4 out of   4 | elapsed:    3.9s finished

As you can see, this simple program executed all four of our argument instances sequentially, because we chose n_jobs = 1, i.e. we¬†told it to use 1 CPU, which means it runs in series. The total time to run is reported as approximately 4 sec (it is actually less than 4 sec, but we won’t concern ourselves with this here!).

Now, we run it again in parallel, but this time with n_jobs = 4:

Function receives the arguments as a list:Function receives the arguments as a list: Function receives the arguments as a list:  Function receives the arguments as a list: (1, 1)(1, 2) (1, 4)

(1, 3)


['1_1', '1_2', '1_3', '1_4']
[Parallel(n_jobs=4)]: Done   4 out of   4 | elapsed:    0.9s finished

As you can see, the internal print commands from all four jobs are being printed to screen more-or-less simultaneously, and not in the original order. Whatever thread finished first gets printed first! The time to finish is now around 1/4 the original time, as expected.



The Fall of a Superhero

Recently I have been reading¬†through a newer¬†edition of Young & Freedman’s University Physics, the main course textbook when I was a physics undergrad. Chapter 2¬†contains the following basic problem concerning 1-dimensional motion with¬†constant acceleration. Since the book does not contain an answer or solution I decided to post a solution here. I highly recommend this book¬†for undergraduate physics students and anyone who wants an excellent overview of the subject.


The Green Lantern is standing at the top of a tall building with height h and steps off, falling freely from rest to the ground below. He falls half of the total distance in the last 1.0 seconds of his fall. What is the height of the building?

Tama66 / Pixabay


We can start by making a sketch of the problem. I personally find it preferable to re-formulate the problem into a very general timeline, with x the displacement from the starting position, as shown below. We know that he starts with zero velocity at time zero. Halfway down the building he has travelled h/2 metres but we do not yet know how long it took or his velocity at the halfway point. Finally, at the end point we know that the time is equal to the time at the halfway point plus one second, the total displacement is h. We do not yet know the final velocity.  The only force acting on the falling object is gravity so we have constant accleration of g = 9.8 metres per second squared.


First half of fall:

We have the following equation for motion with constant acceleration (see the text book for details):

v_{1}^{2} = v_{0}^{2} + 2a(x_{1} - x_{0})

Substituting the known values for v_{0} , a , x_{0} and x_{1}:

v_{1}^{2} = 0 + 2g(\frac{h}{2} - 0) = gh

v_{1} = \sqrt{gh}

Second half of fall:

Now for the second half of the fall: Another equation of motion derived in the text book is

x_{2} = x_{1} + v_{1}(t_{2} - t_{1}) + \frac{1}{2} a (t_{2} - t_{1})^{2}

Substituting known values gives us:

h = \frac{h}{2} + v_{1}(1) + \frac{1}{2} g (1) 

Subtracting h/2 from both sides and tidying up:

\frac{h}{2} = v_{1} + \frac{g}{2}

Combining by substitution:

We can then substitute our expression for v_{1} :

\frac{h}{2} = \sqrt{gh} + \frac{g}{2}  

h = 2\sqrt{gh} + g 

We now have an equation with only one unknown, for h (remember that the acceleration due to gravity, g, is known). This is almost in quadratic form if we recognize that it is equal to

h = 2 \sqrt{g} \sqrt{h} + g 

If we substitute \alpha = \sqrt{h}

then we have a quadratic equation be rearranging so that

\alpha ^{2} - 2 \sqrt{g} \alpha - g = 0

and we can solve for \alpha using the well-known equation:

\alpha = \frac{-b \pm \sqrt{b^{2} - 4ac}}{2a}

where a=1, b=-2\sqrt{g} and c=-1 .

\alpha = \frac{2\sqrt{g} \pm \sqrt{4g + 4g}}{2} = \frac{2\sqrt{g} \pm \sqrt{8g}}{2} = \frac{2\sqrt{g} \pm \sqrt{4}\sqrt{2}\sqrt{g}}{2} = \frac{2\sqrt{g} \pm 2\sqrt{2}\sqrt{g}}{2} = \sqrt{g} \pm \sqrt{2g}

This means that

\sqrt{h} = \alpha = \sqrt{g} \pm \sqrt{2g} = \sqrt{g}( 1 \pm \sqrt{2} )

The quadratic equation gives us two possibilities for the height of the building. The trick here is to recognize that, not only is it not possible for  the height of a building to be negative, but it is also not possible for the square root of the height of a building to be negative! So the only possible value for h ends up being

The quadratic equation gives us two possibilities for the total displacement h. The trick here is to recognize that, since it wouldn’t make sense for¬†the final displacement¬†to¬†be negative, it also wouldn’t make sense for the square root of the final displacement¬†to be negative. We clearly defined the acceleration¬†to be in the positive direction and since we are starting from zero velocity we cannot end up with negative displacement! So the only valid¬†value for h ends up being

h = g(1  + \sqrt{2} )^{2} = g( 1 + 2\sqrt{2} + 2) = g(3 + 2\sqrt{2}) = 9.8(3 + 2\sqrt{2}) = 57.1 m