Category: Opinion

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!




Still no viable 13.3 inch eReader…. hurry up!

Netronix and, purportedly also Onyx International, are developing 13.3 inch screen eReaders using eInk’s Mobius screen, as rivals to Sony’s expensive, PDF-only DPT-S1 Digital Paper. A new video shows the Netronix device prototype being displayed at a recent trade show:

Unfortunately, it seems that without a major company to put up the money to manufacture, market, distribute and sell it the device won’t become available to consumers. That is a real shame! Many people, myself included, would love to have such a device for taking notes or reading scientific papers, magazines and textbooks that don’t display well on, say, a Kindle.

However, I think there is one weakness of the device. Although I haven’t had the privilege of demoing one, the problem also exists on my Onyx Boox M96. Writing with the stylus is not actually that good! Because there is a delay in the line/text appearing as you write it is very hard to write accurately. This seems to make writing small text very difficult since the required stylus strokes are shorter and writing is quicker. The lady in the above video seems to avoid writing small, maybe subconsciously since she already knows that it doesn’t really work well! The manufacturers should really try to improve this aspect of their devices. Perhaps a faster refresh mode while writing would help. Accurately writing with the stylus is essential when notating articles or books, perhaps between the lines of text.

Maybe the resolution of my M96 screen is too low, so that the drawing line cannot be made thinner for more precise drawing and writing. The Mobius screen is supposed to be higher resolution, so that could fix it.

Another crucial problem with eReaders for textbooks is the navigation inside the book, being able to quickly jump between different parts of the book and back again. Think of working on some problems in a Maths textbook and trying to jump to the back for the solutions every few minutes! The software on the device is therefore of utmost importance.

Having stated these problems, I would probably buy one immediately anyway. Please make it available soon!

Update: It looks like Onyx were serious about their 13.3 inch device! It is expected for release in Spring 2016!




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




Accidental spam from Mega.nz to *ALL* of my contacts

This week I decided to check out the new Mega.nz website, the newer version of Mega.co.nz the cloud storage that purports to be built from the ground up for maximum security, that will include a chat feature.

MEGA logo

Here is something that left me feeling quite embarrassed, angry and apologetic; on importing my Gmail contacts (to check if they are already using the service) Mega.nz proceeded to email every contact in my address book an invitation to join the service, something that I am sure I was not warned about! This included friends, people I knew more than ten years ago, companies I have dealt with recently and in the past and so on. This is a very ill-thought action.

I have written some feedback to the service and hope that they will stop this happening in future, and I would like to apologize to anyone who received such spam in my name.




Arsene Wenger unit conversion fail

“If six points is a ‘million miles away’, I don’t know what the translation of a mile into a point is.” – Arsene Wenger

According to reports, Arsene Wenger is not great at simple mathematics. He was quoted today responding to criticism by Paul Scholes that Arsenal were “a million miles away” from winning the Premier League. Wenger said in response “If six points is a ‘million miles away’, I don’t know what the translation of a mile into a point is.” Well, I couldn’t pass up the chance to help old voyeur out with that.

Solution

If 1 million miles is equivalent to 6 points

1,000,000 miles = 6 points

So, to work out the number of points equivalent to a mile we have

1 mile = 6/1,000,000 points = 0.000006 points

But how many miles to a point, goddamit?

It’s 1 million divided by six, innit.

1 point = 1,000,000/6 miles = 166666.667 miles (to 3.d.p.).