Category: Uncategorized

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.


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

Deutschsprachige Artikel auf dieser Website

Heute, nach einer personlichen Diskussion wobei mein Deutch leider sehr schwach war, kam ich auf der Idee um mein Blog ins Deutsch zu übersetzen.

Mittlerweile, gibt es viel mehr auf dem englishsprachigen Netzplatz. Wilkommen!

Paper “Hard Magnet Coercivity” published in proceedings of REPM2014

This August Prof. Dominique Givord of Institut Néel – CNRS presented our paper titled “Hard Magnet Coercivity” during the 23rd International Workshop on Rare earth and Future Permanent Magnets and Their Applications (REPM2014) in Annapolis, Maryland.

The manuscript was included in the conference proceedings and we would now like to make the reprint available to the wider public: Please click here for the PDF file.

Abstract: Based on a critical analysis of the experimental coercive properties, general considerations on the reversal mechanisms in RFeB magnets are recalled. By plotting together the experimental parameters obtained in various magnets, common features of the reversal processes are demonstrated. Modeling provides an almost quantitative description of coercivity in these materials and permits connecting the defect characteristic properties to reversal mechanisms.


Annapolis, Image in Public Domain

Annapolis, Image in Public Domain

Aligning qhost output on the commandline when hostnames are too damn long

qhost is a UNIX command line tool to print the status of nodes on a Grid Engine system.

The output is normally quite readable and is sorted by columns to give information on the hostname (“HOSTNAME”), architecture (“ARCH”), no. of CPUs (“NCPU”), processor load (“LOAD”), total available memory (“MEMTOT”), current memory usage (“MEMUSE”), swap memory size (“SWAPTO”) and current swap usage (“SWAPUS”) of each node on the cluster.

Unfortunately, when the hostnames are too long, instead of truncating them to keep the columns aligned the row gets shunted along, making the output messy and much harder to read quickly. Example ( in this case you probably also get wrapping because the main frame of this WP template is too narrow, sorry!):

global                  -               -     -       -       -       -       - lx26-amd64      8  2.99   15.6G    7.0G    7.5G   74.1M lx26-amd64      8  1.05   11.7G    2.7G    7.5G     0.0 lx26-amd64     12  0.01    7.8G  229.9M   16.0G     0.0 lx26-amd64      4  0.51   15.5G  847.8M    7.9G   48.4M lx26-amd64      8  2.88   11.7G    5.0G    7.5G  158.6M lx26-amd64      8  1.99   23.5G    2.8G    7.5G     0.0
localhost               lx26-amd64      4     -    7.7G       -    7.9G       - lx26-amd64      8  3.57   11.7G    4.1G    7.5G  324.0K lx26-amd64     32 20.40  125.9G   18.4G   16.0G     0.0 lx26-amd64     32 24.80  125.9G   21.6G   16.0G     0.0

I am going to pipe the output to awk and see if I can fix it by trimming the first column while leaving the rest as they are.

First, let’s start by reviewing how to print certain columns only, using awk, To print just columns 2 and 3 from the qhost output we use.

$ qhost | awk '{print $2, $3}'

The comma makes sure that awk puts a space between the columns.

But using printf gives us more formatting options. The following command gives output with all columns aligned. The formatting part is in the “quotation marks” and the arguments given to it follow the commas. We can truncate the first column string (“s”) to 8 characters and specify tabs (“\t”) between each column and a newline (“\n”) at the end of each row:

qhost | awk '{printf("%.8s \t%s \t%s \t%s \t%s \t%s \t%s\n", $1, $2, $3, $4, $5, $6, $7)}'

And actually I don’t need the architecture column, so the following gave me the best results:

qhost | awk '{printf("%.8s \t%s \t%s \t%s \t%s \t%s\n", $1, $3, $4, $5, $6, $7)}'

There are, surely, more advanced and perhaps more elegant solutions but this is a simple way to get the job done to a satisfactory degree.

Class of 2014

Congratulations to our Industrial Simulation bachelor students who graduated today.

Sponsion 2014

Sponsion 2014