Roy and Niels

Roy and Niels

Wednesday, October 6, 2010

Monte Carlo Programs in Particle Therapy Research

- a note on software design.

In my research, I use Monte Carlo particle transport codes a lot in order to simulate the interactions of a particle beams with matter.  There are several of these particle transport codes which are available for free, but if I have to simulate ions heavier than protons, then there are only few codes available which are capable of simulating the physics processes at clinical relevant energies. The four most common codes are FLUKA, Geant4, MCNPX and SHIELD-HIT.

Each of these transport codes have their scope of applicability, advantages and disadvantages. Here, in our research group APTG we work with FLUKA, Geant4 and SHIELD-HIT. In fact, we are actively developing the SHIELD-HIT code (visit our SHIELD-HIT developer page). Recently, I had a discussion with a colleague (and non-programmer) where I wanted to clarify why we put so much effort into SHIELD-HIT, now that basically all functions are more or less available in FLUKA or can be build in Geant4. I found it difficult to explain him the reasons.

That is why I came up with the idea of comparing the particle transport codes with cars. I am not particularly fond of cars, on the contrary, but in the spirit of particle transportation (pun intended) I could not resist the temptation.

A FLUKA car, Fortran 77 style.
A FLUKA car would be a regular car which does the job it is supposed to do. Imagine VW Passat or whatever. If you enter such a car for the first time, it will take you less than 10 seconds to orient yourself, since things are as expected: clutch, throttle, brakes etc.. If you forget to fasten your seat belt, you will get an error message which tells you exactly what is wrong. If you need some extras which goes beyond the standard equipment, you can add them yourselves (by the FLUKA user routines), although the developers limit what you can attach to your car. You are not allowed to touch the engine at all, the developers tune it for you to best possible performance.
FLUKA is closed source, and black-box like. If something fails with the engine (the physics models inside FLUKA), and this happens very rarely, you should take the car to repair ( = notifying the developers). Only the developers have access to the engine interior, and can fix it. While they do this, you realize that the interior may look rather old fashioned (the source is written in Fortran 77), and imagine it might be difficult to maintain, but the developers are experts, and have worked with it for many years. No reason to change this, as long as the engine runs smoothly and you still can find the special gasoline for the car (= a Fortran 77 compiler, deprecated on many newer Linux distributions).
If you want to publish benchmarks against other cars (other codes or experimental data), you must first talk back to the developers, and they want to assure that you have been operating the car right. (Unlike removing the brakes, then publishing how the car crashed.) The FLUKA car is increasingly popular, since it has a steep learning curve, is easy to run and the driver does not need to know how the engine is working.

A Geant4 car. Geant4 provides you all the pieces you need to build a car. ANY car.
Geant4 is not a car. It is a large box of Lego where you - in principle - can build your own car. We are not talking about normal standard Lego bricks, but the most fancy kind of them, Lego Technic C++ style bricks! If you ever have programmed in C++ and played with Lego, you know that equally to Lego you can also attach these code bricks in ways which they are not really supposed to (weak typing). Installing the Lego bricks in your laboratory may require some expert knowledge.
No-one has ever build a Lego based car similar to the FLUKA car, where you just step in, start the engine and go places. But there is no doubt, given infinite resources, you can build yourself a Ferrari, if you want. You can build a diamond inlaid SUV if such things turns you on. In principle anything is possible, but you need a lot of good developers and plenty of time. No research group has access to indefinite money supplies (or time), so instead research groups using Geant4, focuses on their specific needs. For instance, a famous research group in Boston have developed an engine (doing protons), which works well for their specific needs. In Japan a group is working on a special vehicle, lets say a Caterpillar (think gMocren is a part of this), which eventually can do specialized tasks (treatment planning with ions). That is fine, but if you want to adapt it to your own needs which goes beyond the application originally was designed for, it can again be quite some task and requires a good deal of programming knowledge. (Assuming you get the source code at all. If you get it, you still need to understand what is going on).
Perhaps some group has already developed higher level parts such as a carburetor and a light generator which are available to other researchers, yet they are not obliged to give these parts away. Geant4 is not GPL.

A SHIELD-HIT type car. Note, the driver found the light switch.
SHIELD-HIT is a russian Niva. Well, not precisely a regular Niva. At first glance you think, this is a normal car, not unlike a FLUKA car. You have to get a special contract with the code owners at INR before you may access the car.
Once you got it, you feel confident you can run this car effortlessly. However, as soon as you get inside, you realize something is very different. First of all you need three different keys to start the engine. The clutch is mounted on the steering wheel, the light switch is hidden under the seat, and if you need to do left turns, you must configure the car to do so before you start it. You need an English speaking Russian to tell you all this, because essential parts of the manual is written in Russian, and the manual itself is incomplete, only covering the light switch part.
If you look on the engine, you again realize it has lot in common with the FLUKA engine (SHIELD-HIT is also written in Fortran 77, and the geometry parser is also CG).
The key difference to the FLUKA car is, if something is broken, you are allowed (or even encouraged) to repair it yourself. Clear error messages or other indications of what is wrong, are seldom. You may simply have operated your Niva wrong, of there may be a real bug in the engine. But you do have access to the source code - and this enables you to do all the modification you want in the code. If you know exactly what you want, this is actually a big advantage. Imagine yourself stranded in a village in the middle of Siberia, you will be happy you drive a Niva. When your Niva is fixed, the car runs smoothly - just as smooth as a FLUKA car or a custom Geant4 based "forward going vehicle" would do. And the Niva is tolerant to various gasoline types (you can compile with g77, gfortran, ifort etc...)

So, our MSc student David has invested a lot of time in building the next generation Niva, the Niva version 2.0 (currently also known as SHIELD-HIT10A). It is supposed still to resemble a regular car but with improved user friendliness . The clutch and light switch are moved to more intuitive positions. Only one key should be necessary for starting the engine. And, as I mentioned in an earlier blog-post I am currently preparing an English manual for the new Niva 2.0.

David is also benchmarking the Niva 2.0 and overhauling the engine (meaning, better parameters for the physics models matching the recently released experimental data by E. H├Ąttner). Finally, the Niva 2.0 will feature a lot of new features which are not readily available in any other Monte Carlo particle transport vehicle, such as air conditioning and cup holders (one for each passenger).

SHIELD-HIT10A, aka Niva 2.0. Fortran 77 style artwork is still visible despite of the upgrade. (APTG developer impression).

Now, let us assume, when David finishes his MSc February 2010, he would like to do a PhD project involving a pair of windscreen wipers and a light generator.
He has three codes to choose from. Of course, we all like playing with Lego. Lego is fun, and someone has already developed a Lego light generator ... so we only need to build the windscreen wipers, and off we go, doing a lot of research. (I really get carried away now.)
Alternatively David could choose to continue to work with the Niva 2.0. As a side effect the Niva will be upgraded with windscreen wipers which may benefit the continuation of the SHIELD-HIT project. Not as much fun as working with Lego, but probably as useful. Personally, I'd hit it, but working with Fortran77 is really demotivating. Especially if the code is full of GOTO statements.
Finally we have the choice of working with FLUKA. Perhaps this is the easiest, but in my opinion a bit dull since we are not contributing with much new on the developer side of the code.

There will be more of the Niva 2.0 at the MC2010 conference in Stockholm, where David will present his work (either poster or talk, we don't know yet).

Come and meet us!

Tuesday, October 5, 2010

Pretty Good Privacy and Evolution

This year, the danish government forced all its internet users to use the "NemID" solution for digital communication between the several public institutions, banks etc. The NemID concept is based on regular asymmetric encryption with a public and secret key pair. The developers of NemID realized very wisely that a significant amount of users (if not the majority) won't be capable of storing their secret key safely on their respective computers running windows.

The solution is that a private company "DanID", contracted by the danish government, stores the secret key for the user (imagine this happening in Germany!), and any interaction is realized with a java based login portal and a TAN list.

Without commenting on the trustworthiness of "DanID", this solution obviously does not integrate with typical Linux mailers such as Evolution.

Therefore, my colleague Bjarne Thomsen recently urged me (multiple times, thanks) to encrypt / sign my emails using gpg. Last time I did this was in 2004, but I must admit I cannot remember where I stored my old secret key (it is probably lost), and the revocation file is probably also gone. So, I had to start again from scratch. Here is the recipe:

Fist generate a new key pair. I was very paranoid, and closed down any closed source processes which I do not trust (skype, flash, google earth ...), while generating this key.

$ gpg --gen-key

Let it be valid for 2 years, you will probably loose your secret key, forget your pass phrase and/or your revocation file sooner or later, and there is no way you can delete keys from the key server.
You can also choose between RSA and DSA/ElGamal signing/encryption. I chose RSA, for no specific reason. For the bit length the default is 2048, but I chose 4096 bit, which should be safe until year 2030.

You will get a response akin to:

pub 4096R/xxxxxxxx 2010-10-04 [expires: 2012-10-03]

where the xxxxxxxx value is your public key identifier.

Next, you submit your public key to the key server:

$ gpg --keyserver --send-keys xxxxxxx

And finally I recommend you generate the aforementioned revocation file.

$ gpg --output revoke.asc --gen-revoke xxxxxxxx

Anyone who has this file can revoke your key. You can print the file on paper and store it a safe place, if you wish.

So, now you are ready to go. Fire up evolution, go to your mail account setup. There is a tab which says "Security". In this tab there is a place where you can enter your secret key ID. Don't worry, your key identifier is not secret in that sense, the actual key is protected with your pass phrase.

Now you are able to send signed emails. Evolution will ask for a pass phrase when accessing your key.

But you probably also want to send encrypted emails. In order to do so, you need to import the public key of the recipient. Evolution does not do this automatically, this is a very old bug in evolution which still has not been fixed, see #259665.

Instead, you must manually import the recipients public key. I look up the recipients key id on a key server, such as this one:

$ gpg --keyserver --recv-keys xxxxxxxx

If you are sure you got the right key, sign it:
$ gpg --sign-key xxxxxxxx

Ideally, you meet the person and exchange they key (e.g. at key-signing party)

If you need to sign against a specific secret key, use:
$ gpg --default-key xx(yoursecretkeyID)xx --sign-key xx(keyIDtobesigned)xx

List your keys with:
$ gpg --list-keys

Tadaaa, now you can encrypt the mails in evolution. Note that the email addresses of the public key and the recipient you mail the key to must match.

If you ever need to revoke your key, do:
$ gpg --output revoke.asc --gen-revoke xxxxxxxx
$ gpg --import revoke.asc
$ gpg --keyserver --send-keys xxxxxxxx

Oh yes, and here is my ASCII armored public key:
Version: SKS 1.1.0