Category: Uncategorized

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.

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:

 

RuntimeError:

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, killSalome.py kills all of the instances running on your system, so you should use it with care:

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

But if you already know the port number of a specific instance, killSalomeWithPort.py 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/killSalomeWithPort.py 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
./bin/SALOME-8.2.0-UB16.04/BINARIES-UB16.04/KERNEL/share/salome/resources/kernel/channel.cfg
./bin/SALOME-8.2.0-UB16.04/BINARIES-UB16.04/SMESH/share/salome/plugins/smesh/padder.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 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.

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 killSalomeWithPort.py. 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 script.py
port_file = open('somefolder/salomePort.log' , 'r')
killPort = int(port_file.readline())
<salome_distro>/bin/salome/killSalomeWithPort.py %s' % killPort
For some reason I could never get this to work successfully. I always ended up building a call to killSalome.py 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 salome.sg.hasDesktop():
    from killSalomeWithPort import killMyPort
    killMyPort(os.getenv('NSPORT'))
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 salome.sg.hasDesktop() 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!

Footnotes

  • 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. runSalome.py, 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: http://www.salome-platform.org/forum/forum_10/519093933
  • 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.



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...
    time.sleep(1)    
    # ... 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

Output:

Function receives the arguments as a list: (1, 1)
1_1
Function receives the arguments as a list: (1, 2)
1_2
Function receives the arguments as a list: (1, 3)
1_3
Function receives the arguments as a list: (1, 4)
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_41_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 new default colormap for matplotlib is called “viridis” and it’s great!

It’s probably not news to anyone in data visualization that the most-used “jet” colormap (sic) (sometimes referred to as “rainbow”) is a bad choice for many reasons.

  • Doesn’t work when printed black & white
  • Doesn’t work well for colourblind people
  • Not linear in colour space, so it’s hard to estimate numerical values from the resulting image

The Matlab team recently developed a new colormap called “parula” but amazingly because Matlab is commercially-licensed software no-one else is allowed to use it!
The guys at Matplotlib have therefore developed their own version, based on the principles of colour theory (covered in my own BSc lecture courses on Visualization 🙂 ) that is actually an improvement on parula. The new Matplotlib default colormap is named “viridis” and you can learn all about it in the following lecture from the SciPy 2015 conference (YouTube ):

Viridis will be the new default colour map from Matplotlib 2.0 onwards, but users of v1.5.1 can also choose to use it using the cmap=plt.cm.viridis command.
I don’t know about you, but I like it a lot and will start using it immediately!




Equations in Gmail with the “TeX for Gmail” Chrome extension

Science via email

One thing scientists and engineers have to do daily is discuss collaborative work via email exchanges. This often includes the need to share and discuss mathematical equations and to represent variables with subscripts and superscripts or special characters; something that is tricky when you are emailing in plain text.

WikiImages / Pixabay

Of course it is possible to work around this problem! Email was invented by scientists, and for decades they have been communicating in this manner, using various conventions to convey the correct information using plaintext. However, if you are a Gmail user there is a nice extension that will make your equations look proper good.

Tex for GmailGmail-logo

TeX for Gmail is a Chrome browser extension that checks a Gmail email that you are writing for LaTeX markup and converts the markup to a visually prettier equation, using one of two modes. In Simple Math mode, subscripts and superscripts are correctly formatted but the current font is maintained and text remains ediatble. In Rich Math mode, the equation is rendered into TeX and replaced by an embedded image.  The email recipient doesn’t need the extension installed on their browser in order to read your nice equations!

Example

Original markup:

$E = mc^{2}$

Simple Math mode:

E = mc2

Rich Math mode:
E = mc^{2}

Issues

One problem; once the extension has converted my markup to formatted text, I cannot get the markup back. So editing a small mistake usually means re-doing all the curly brackets and other stuff that a TeX equation requires. The only workaround seems to be to stay vigilant and use Undo (Ctrl-z), but this doesn’t work when you notice a mistake in an equation that you wrote a while ago. One improvement could be the option to restore any equation to the original markup.

Conclusions

Overall, a great little tool to improve the clarity of science and maths communications over email. With a few small improvements it could be even better but it is already very usable.




5 Tips for making finite element models with Salome

Salome is an open source software package used to create geometric models and finite element meshes for use in numerical simulations. It is also able to perform its own numerical simulations and has post-processing capabilities built in.

Here are my 5 tips for anyone who is interested in using Salome for model and mesh creation.

1. Practice manually first

This goes without saying. Although Salome has a powerful Python-based scripting capability, it is worth practicing with manual model generation. By that I mean, clicking with your mouse in the GUI. Manual practice lets you get familiar with the quirks of the Salome workflow, which has a different mentality to many other model generator programs.

2. Use the Notebook

In Salome the Notebook is a useful tool that allows you to set size parameters in the beginning as model variables. This means that later on you can edit the notebook variable values and re-build the model using different sizes; something that cannot be done normally, while typing size values in to construct geometric objects. The Notebook is like having some of the power of scripting while still making the model manually in the GUI. A great halfway step up to full scripting.

3. Learn to use scripting

Once you are familiar with Salome’s way of thinking, automation through scripting can become a critical component of being productive. Often it is necessary to compare many similar models where just one specific parameter (say the size of some part) is being changed.

In this recent paper we had to compare the effects of different soft magnetic defect thicknesses in a permanent magnetic grain.  By scripting the model generation I was able to rapidly generate similar models from one template script.

Reversal

4. Small size adjustments can get you out of a rut

Sometimes with Salome (and actually with other modelling software too) you find an annoying problem that makes no sense. For example, you made the model with no problems but now you increased the size of part A and it doesn’t want to build anymore. These kind of problems can occur because designing such a powerful piece of software to work universally is hard. You might be attempting something that the software designers did not anticipate.

One trick that often works for me goes like this. Change the parameter again by a small, arbitrary amount. If size A is 100 nm large, try changing it to 100.001. The simulation result will be virtually identical but you might find the model generation can now function without problems.

I remember in an earlier version of GiD, doing a boolean volume operation on two objects would fail if the edges of the objects overlapped perfectly. So I always had to make sure to translate one of the objects by a tiny amount. Then the Boolean operation would usually work. The makers of GiD fixed this in later versions and most good model software can handle such things.

The same problem often occurs with meshing algorithms. Depending on the type, an algorithm may be trying to fill a certain volume with elements but is being constrained for element size. This can cause the algorithm to fail, but a small change in the specified mesh size can get it to work again.

5. Check your dumped scripts

When making a model using the GUI it is really cool to be able to dump the model as a Python script, which can then be edited and run using the script mode. As I highlighted in another post, it helps to take care that Explode functions do not reorder the exploded entities. The default behaviour is to reorder, and it is easy to forget this when using the script, leading to confusion when the wrong objects are subject to later operations.

Exploding planet