The Quick and Dirty Guide for Parallelizing FLUKA

(Single PC version)

Imagine you got a desktop or laptop PC with 4 or perhaps even 8 CPU cores available, and you want to run the Monte Carlo particle transport program  FLUKA on it using all CPU cores.
The FLUKA execution script rfluka however was designed to run in "serial" mode. That is, if you request to repeat your simulation a lot of times (say, 100) issuing the command rfluka -N0 -M100 example, each process is launched serially, instead of utilizing all available cores on your PC.

A solution can be to use a job queuing system and a scheduler. Here, I'll present one way to do it on a Debian based Linux system. Ubuntu might work just as well, since Ubuntu is very similar to Debian. A feature of the method presented here, is that it can easily be extended to cover several PCs on your network, so you can use the computing power of your colleagues when they do not use their PCs (e.g. at night). However, this post will try to make it very simple, namely set it just on your own PC. In less than 10 minutes you'll have it up and running...

The idea is to use TORQUE in a very minimal configuration. There will be no fuzz with Maui or similar schedulers, we will only use packages we can get from the Debian/Ubuntu software repositories.
In order to be friendly to all the Ubuntu users out there, all commands issued as root are here prefixed with the "sudo" command. As a Debian user you can become root using the "su" command first.

First install these packages:

$ sudo apt-get install torque-server torque-scheduler 
$ sudo apt-get install torque-common torque-mom libtorque2

and either

$ sudo apt-get install torque-client

or

$ sudo apt-get install torque-client-x11

after installation we need to setup torque properly. I here assume that your PC hostname cannot be resolved by DNS, which is quite common on small local networks. You can test whether your hostname can be resolved by the "host" command. Assuming your PC has the name "kepler", you may get an answer like:

$ host $HOSTNAME
Host kepler not found: 3(NXDOMAIN)

this means you may need to edit the /etc/hosts file, so your PC can associate an IP number with your hostname. Debian like distros may have a propensity to assign the hostname to 127.0.1.1 which will not work with torque. Instead I looked up my IP number (which in my case is pretty static) using /sbin/ifconfig, and edited the /etc/hosts accordingly, using your favourite text editor (emacs, gedit, vi...)
My /etc/hosts file ended up looking like this:

127.0.0.1 localhost
#127.0.1.1 kepler.lan kepler
192.168.1.108   kepler

If your hostname of your PC can be resolved, you can ommit the last line, but under all circumstances you must comment out the line starting with 127.0.1.1.


Once this is done, execute the following commands to configure torque:

$ sudo echo $HOSTNAME > /etc/torque/server_name
$ sudo echo $HOSTNAME > /var/spool/torque/server_name
$ sudo pbs_server -t create
$ sudo echo $HOSTNAME np=`grep proc /proc/cpuinfo | wc -l` > /var/spool/torque/server_priv/nodes 
$ sudo qterm
$ sudo pbs_server
$ sudo pbs_mom

(Update: If qterm fails, you probably have a problem with your /etc/hosts file. You can still kill the server with $killall -r "pbs_*".)

Now let's  see if things are running as expected:

$ pbsnodes -a
kepler
     state = free
     np = 4
     ntype = cluster
     status = rectime=1326926041,varattr=,jobs=,state=free,netload=3304768553,gres=,loadave=0.09,ncpus=4,physmem=3988892kb,availmem=6643852kb,totmem=7876584kb,idletime=2518,nusers=2,nsessions=8,sessions=1183 1760 2170 2271 2513 15794 16067 16607,uname=Linux kepler 3.1.0-1-amd64 #1 SMP Tue Jan 10 05:01:58 UTC 2012 x86_64,opsys=linux

and also

$sudo momctl -d 0 -h $HOSTNAME

Host: kepler/kepler   Version: 2.4.16   PID: 16835
Server[0]: kepler (192.168.1.108:15001)
  Last Msg From Server:   279 seconds (CLUSTER_ADDRS)
  Last Msg To Server:     9 seconds
HomeDirectory:          /var/spool/torque/mom_priv
MOM active:             280 seconds
LogLevel:               0 (use SIGUSR1/SIGUSR2 to adjust)
NOTE:  no local jobs detected

Now setup a queue, which here is called "batch".

$ sudo qmgr -c 'create queue batch'
$ sudo qmgr -c 'set queue batch queue_type = Execution'
$ sudo qmgr -c 'set queue batch resources_default.nodes = 1'
$ sudo qmgr -c 'set queue batch resources_default.walltime = 01:00:00'
$ sudo qmgr -c 'set queue batch enabled = True'
$ sudo qmgr -c 'set queue batch started = True'
$ sudo qmgr -c 'set server default_queue = batch'
$ sudo qmgr -c 'set server scheduling = True'

[update: you may want to increase walltime to 10:00:00 so jobs dont stop after 1 hour]

and start the scheduler:

$ sudo pbs_sched

The rest of the commands can be issued as a normal user (i.e. non-root).

Let's see if all servers are running:

$ ps -e | grep pbs
 1286 ?        00:00:00 pbs_mom
 1293 ?        00:00:00 pbs_server
 2174 ?        00:00:00 pbs_sched

Anything in the queue?

$ qstat
$ 

Nope, it's empty.

Lets try to submit a simple job

echo "sleep 20" | qsub

and within the next 20 seconds you can test, if its in the queue:

$ qstat
Job id                    Name             User            Time Use S Queue
------------------------- ---------------- --------------- -------- - -----
0.kepler                 STDIN            bassler                0 R batch

Great, now were ready to rock 'n roll! This is really a minimalistic setup, which just works. For more bells and whistles, check the torque manual.

All we need, is a simple FLUKA job submission script: rtfluka.sh

#!/bin/bash
#
# how to use this
# change to directory with the files you want to run
# and enter:
# $ qsub -V -t 0-9 -d . rtfluka.sh
#
#PBS -N FLUKA_JOB
#
start="$PBS_ARRAYID"
let stop="$start+1"
stop_pad=`printf "%03i\n" $stop`
#
# Init new random number sequence for each calculation. 
# This may be a poor solution.
cp $FLUPRO/random.dat ranexample$stop_pad
sed -i '/RANDOMIZE        1.0/c\RANDOMIZE        1.0 '"${RANDOM}"'.0 \' example.inp
$FLUPRO/flutil/rfluka -N$start -M$stop example -e flukadpm3

Update: Note that your RANDOMIZE card in your own .inp file must match the sed regular expression above, else you may repeat the exact same simulation over and over again...


Let's submit 10 jobs:

$ qsub -V -t 0-9 -d . rtfluka.sh

And watch the blinkenlichts.

$ qstat
Job id                    Name             User            Time Use S Queue
------------------------- ---------------- --------------- -------- - -----
15-0.kepler               FLUKA_JOB-0      bassler                0 R batch          
15-1.kepler               FLUKA_JOB-1      bassler                0 R batch          
15-2.kepler               FLUKA_JOB-2      bassler                0 R batch          
15-3.kepler               FLUKA_JOB-3      bassler                0 R batch          
15-4.kepler               FLUKA_JOB-4      bassler                0 Q batch          
15-5.kepler               FLUKA_JOB-5      bassler                0 Q batch          
15-6.kepler               FLUKA_JOB-6      bassler                0 Q batch          
15-7.kepler               FLUKA_JOB-7      bassler                0 Q batch          
15-8.kepler               FLUKA_JOB-8      bassler                0 Q batch          
15-9.kepler               FLUKA_JOB-9      bassler                0 Q batch 

Surely, this can be improved a lot, suggestions are most welcome in the comments below. One problem is for instance, that the random number seed is limited to a 16 bit integer, which only covers a very small fraction of the possible seeds for the RANDOMIZE card.
Update: There is also a very small risk that the same seed occasionally is used twice (or more often). Alternatively one could just add a random number to a starting seed after each run. (Any MC random number experts out there?)

Output data can be processed in regular ways, using flair. 
Alternatively you may use some of the scripts in the auflukatools package, which for instance can do the merging of USRBIN output with a single command. Auflukatools also includes rtfluka.sh as well as a CONDOR job submission script rcfluka.py, which is better suited for heterogenous clusters.

Finally, here is a job script for SHIELD_HITxxA, (which is even shorter):

#!/bin/bash
#
# how to use
# change to directory you want to run
# $ qsub -V -t 0-9 -d . rtshield.sh
#
#PBS -N SHIELD_JOB
shield_exe  -N$PBS_ARRAYID

Enjoy!

Totally unrelated: englishrussia.com just posted some nice pics from the Budker institute for Nuclear Physics in Novosibirsk, Russia. Certainly worth visiting, have a look at:
http://englishrussia.com/2012/01/21/the-budker-institute-of-nuclear-physics/
 :-) Heaps of pioneering accelerator technology was developed there, such as electron cooling, the first collider, lithium lenses (e.g. for capturing antiprotons), and they supplied the conventional magnets for the beam transfer lines to the LHC at CERN. I visited the center many years ago but my pics are not as good. :-/ The German wiki about Budker himself, is also worth reading.

Visit at the Primary Standards Laboratory in Slovakia

This post is not related to computing, but more to medical physics. Primary standards dosimetry laboratories (PSDL) are important for medical physicists, since they define fundamental quantities such as dose. If you buy some dosimeter, say, an ionization chamber, it is most likely calibrated at a PSDL (for ample amounts of money) or a secondary standards dosimetry laboratory (SSDL) which is linked towards a PSDL. Not all countries have a PSDL or SSDL, and some countries (like Slovakia in this case) have both PSDL and a SSDL facilities. To my knowledge, Denmark quite recently got the SSDL status at the National Institute for Radioprotection.

During summer vacation 2011, after finishing the run at CERN, I had a rather messy tour across Europe and also went to Bratislava to visit some friends. Here I got the chance to get a tour of the Slovakian PSDL at the Metrological (not to mistaken with the Meteological) Institute. It is my second vist at a PSDL - a few years ago, I visited the PSDL at the National Physical Laboratory in the UK, but I only got crappy mobile phone pictures.

The Metrological Institute of Slovakia, Bratislava.

The director of the institute, Jozef Dobrovodsky gave me a tour of the facility. They have a close cooperation with the NPL - most physicists working with particle therapy may have heard of proton dosimetry expert Hugo Palmans who works at NPL near London, but (quite conveniently) actually lives in Bratislava.

Jozef and Hugo looking at Roos plane parallel ionization chambers from PTW, well suited for measuring depth-dose curves of pencil shaped ion beams.

Outline of the facility.

The facility has a Betatron, a Cobalt-60 unit, a 320 kV X-ray unit, a Caesium-137 irradiator and a neutron vault with various neutron sources.

Mock-up models of Cs-137 sources (these are NOT radioactive).

A part of the control room, with the very well known UNIDOS electrometer by PTW, which I worked a lot with e.g. while at CERN.

Probably the most important room is where the Co-60 irradiator is kept. Co-60 has a long history serving as reference radiation for a wide range of dosimetric tasks. Beam quality is usualy expressed relative to Co-60 standard. However, Co-60 irradiators are getting rare. Radiation treatment with Co-60 is rather something seen in developing countries, at most hospitals they were replaced with megavolt linear accelertors, also for safety issues. (Messing with radioactive sources is always a bad thing and should be avoided). As a researcher, it gets increasingly difficult to get access to a proper reference radiation.

The yellow box holds the Co-60 source, behind the tank an additional collimator is visible which can be mounted in front of the Co-60 unit.

Co-60 irradiation room. The tank holds a Markus ionization chamber, and the dose-rate can be reduced by increasing the distance to the Co-60 irradiation unit.

Next we took a look at the X-ray irradiation room. X-rays have lower energies than Co-60 and are made electrically and not from a radioactive source.

Two X-ray sources are seen here, one in the background with wheels of various copper filers which can be positioned in the beam. Copper filters can remove characteristic lines of the X-ray spectrum, thereby flattening it. In front an X-ray diagnostic device is visible.

How to make 90 Volts. :)

Cs-137 provide a photon field at about half the energy of the MeV Co-60 photons.

Cs-137 irradiation room.

Cs-137 irradiator seen from the front. Aperture can slide to the right, exposing the room to the source.

A real gem was their Betatron: it's a Czech construction, which can deliver both electron and photon beams. The betatron is an old design originally invented by the Norwegian Widerøe, who also invented the idea of drift tubes, widely used at almost any accelerator today. Betatrons (especially functioning betatrons) are a very rare sight today,  most were replaced with LINACs long time ago. I once saw a betatron at the physics department of Freiburg in Germany, but it was not operational anymore. This one however is still functioning! (Look how clean and tidy it is... I am used to messy laboratories.)

Second time I ever see a betatron. Yay! :-)

You can extract either photons or electrons on either side. This is the photon exit (I think).

They even had a spare betatron tube, heavily tarnished by radiation damage to the glass.

Control console for the betatron. Nice and sleek.

Power supply and controls for the betatron. Many components are still genuine Czech, manufactured by TESLA.

Finally we visited the neutron vault. Here they had three neutron irradiators: two different accelerator based sources and a range of radioactive neutron emitters. The neutron sources were kept in a cave in the floor shielded with lots of plastic material for neutron moderation/absorption. The sources they have are quite common. Some intense alpha source (Plutonium or Americium) mixed with some light material (Beryllium). A Californium source was also there which fissions spontaneously.

Neutron vault. In the floor several neutron sources are kept, and can be raised out of the cave by the visible holder. I was a bit hesitant, when the scientist suddenly pulled a string, and the holder surfaced out of the neutron cave, as shown on this picture. “Is it empty?!” “Sure it's empty.”

This accelerator was very cute: protons accelerated towards a tritium target produces a neutron beam. The design of the high voltage terminal looks very much like the design found in the terminal of our Van de Graaf KN machine in Aarhus.

The ion source can be seen in the middle.

Beam is directed against a tritium metal hydride target, which is rotated to redistribute the dissipated power over a larger area. This produces a neutron beam, exiting to the lower left.

I always found acceletor technology very interesting, especially old designs where you easily can recognize what is going on (or not). If it is eastern-european design, it's just even more interesting, since they tend to look rather different and often show signs of various improvisations.

This is some Russian accelerator based neutron source. However, it was not really used if I remember correctly, and unfortunately I didn't pick up all the details about it.

I was once told that its very characteristic for Russian accelerator systems, that the vacuum tubes are fixed with 4 screws only.

This concludes our little tour at the irradiation facilities of the primary standard lab in Bratislava. Thanks to Hugo Palmans and Jozef Dobrovodsky for the tour!

An antiproton and a proton dosimetry researcher meet. No annihilation, but some sort of a bound state, clearly sharing common goals and interests.

Cloud computing in medical physics*: A snapshot - July 2011

These days if you do almost anything with a computer hooked up to the internet, you’ve probably heard the term “cloud computing”. Well I’m here to tell you that cloud computing actually does mean something and that it is something useful for medical physics! In this post I’m going to take a quick look at the current state of cloud computing research in medial physics and how it got there.

First things, first, what do I mean by cloud computing? Cloud computing generally refers to scalable computing resources, such as data storage, CPU time, or software access, offered over the internet with a pay-as-you-go pricing scheme (and sometimes free). This service can be provided at a few levels: raw server level access (infrastructure as a service, IaaS), pre-configured systems for specific tasks (platform as a service, PaaS), and software as a service, SaaS, e.g. Gmail or Dropbox. The interesting thing about cloud computing is that, suddenly, anyone armed with a network connection, a credit card, and a little know-how can have access to an unprecedented amount of computing resources. This opens up a huge number of computing possibilities for medical physicists, among others.

Starting in the second half of 2009, our research group at the University of New Mexico, the UNM Particle Therapy Group, started investigating using IaaS-style cloud computing as the basis for massively parallel medical physics calculations (read, very fast, large calculations). Our very first results, demonstrating proof-of-concept with proton beam calculations on a “virtual Monte Carlo cluster” of nodes running on Amazon.com’s EC2 service were presented at the XVIth ICCR conference in Amsterdam in May, 2010. We presented a poster of our second set of results at the AAPM annual meeting in July, 2010 and then posted a paper to the arXiv titled “Radiation therapy calculations using an on-demand virtual cluster via cloud computing” http://arxiv.org/abs/1009.5282 (Sept. 2010).

It has been exciting to see the reactions to our posters, talks, and arXiv print, with most physicists immediately seeing the potential benefits offered by the new levels of access to computing resources offered by cloud computing services. Even more exciting is to see the projects subsequently launched by other medical physics researchers.

So what’s happening now?

• Chris Poole, et al (Queensland Univ. of Tech.) posted a note to the arXiv titled “Technical Note: Radiotherapy dose calculations using GEANT4 and the Amazon Elastic Compute Cloud” http://arxiv.org/abs/1105.1408 (May, 2011)
• Chris Poole also posted code used in that project to http://code.google.com/p/manysim/ (May, 2011)
• UNM held a workshop that included tutorials on using cloud computing for medical physics calculations. Sponsored in part by Amazon.com. (May, 2011)
• UNM launched a cloud computing webpage in conjunction with the workshop: http://www.cs.unm.edu/~compmed/PTG/cloud.html (May, 2011)

• At least *seven* cloud computing abstracts at the AAPM/COMP 2011 meeting
• McCloud: Toward 10 Million Monte Carlo Primaries in 5 Minutes for Clinical Use
• Monte-Carlo Simulation in a Cloud Computing Environment with MapReduce
• Toward Real-Time Monte Carlo Simulation Using a Commercial Cloud Computing Infrastructure
• Toward Web-Based Real-Time VMAT and IMRT Inverse Planning Using Cloud Computing
• Fast and Reliable Cone-Beam CT Reconstruction Using Cloud Computing
• Cloud Computing for Interventional Fluoroscopy Dose Assessment
• The Compute Cloud, a Massive Computing Resource for Patient-Independent Monte Carlo Dose Calculations and Other Medical Physics Applications

Compared to our single abstract at AAPM last year, you could claim there has been an “exponential explosion” in interest in cloud computing in medical physics since we presented our first results in 2010! Does this mean we’ll see 50 abstracts in 2012 mentioning cloud computing? (Two points does not a trend make?? ;) )

I look forward to seeing where this new technology will take our field.

*I’m really leaving off all of the (mostly commercial) cloud-based PACS and related radiology software and services. Some of these are mentioned in our paper on the arXiv.

Antiproton Radiotherapy Experiments at CERN

In this moment we have a week of antiproton beam at CERN for radiobiology and dosimetry experiments. The main experiment is to measure the relative biological effectiveness (RBE) of antiprotons. As an endpoint we use clonogenic survival of V79 Chinese hamster cells (in vitro).

What makes this experiment so complicated, is :

• we only have narrow beam geometry available at CERN
• antiprotons are rare, we only get app. 1 Gy / hour
• beam is highly pulsed, i.e. a 500 nanosecond spill every 90 seconds.

Therefore, we invest a lot of effort in performing precise dosimetry with multiple redundant systems. This is a long story, which I will tell more about another time. Here, let me just show a few pictures...

The antiproton beam line with a water phantom for dosimetry.

The entire experiment is located in an experimental zone at the antiproton decelerator (AD) at CERN. We share our zone with the AEgIS people, who want to find out if antiprotons fly up or down in the gravitational field of the earth. :)

Franz-Joachim Kaiser messing with the water phantom. Behind him the AEgIS beam line.

Three ionization chambers (ICs) are visible here, from the left to the right: a custom made "Advanced Roos" chamber, a Markus chamber and the MicroLion liquid ionization chamber. All by PTW.

Gafchromic EBT film irradiated with antiprotons. Beam spot is about 1 cm FWHM. The narrow beam geometry makes us very vulnerable to positioning errors...

... and therefore we also monitor the beam from spill to spill with a Mimotera detector.

We are usually 2-4 people on a shift. Tonight I will do the night shift with Franz-Joachim (to the left). Stefan will leave soon. Usually, I would do night shifts with Roy Keyes, but he couldn't be here this year.

I build this little box for the experiment: it interfaces the antiproton decelerator with the printer port of our data acquisition computer. No need for expensive IO cards or fancy LabView. Basically it is just some TTL logic and optocouplers. On the server side, a daemon listens to the parallel port if a new spill of antiprotons is coming in.

Once triggered, the server takes care to read out all data systems, such as beam current transformers, ionization chamber and scintillators.

Client programs, here running on the laptop to the left, can connect to the server, and change various settings of the readout procedure.

Again, this is home-brew. Earlier, the data acquisition was some libncurses based stuff, this year is the first time we had a traditional GUI for the client and a clear client/server separation. I wrote the client in C++/QT4 and compiled it for linux and win32. Stefan did a package for mac. Server is pure C, linux only. Sometimes, I think the most valuable course I had when I was a student at our Physics department in Aarhus, was a C-programming course.  (And that course was only offered once! What a shame!)

Fiona from the Belfast QUB group is in charge of the film scans, and making sure there are enough sweets for all of us.

Entire experimental zone in the AD hall, seen from above, where our non-existant counting hut would be..

A bit off topic, but just over our heads, there is a positron beam line, which delivers the positrons to the anti-hydrogen "bottle" of ATRAP. Positrons go from the right side to the left.

Me, checking up on things... :-) I think this is the 8th or 9th time I am working at the ACE experiment.

Alanine is one of the most reliable solid state dosimeters for such exotic beams such as antiprotons. Here a stack of pellets is prepared for irradiation.

Once the pellets have been irradiated with antiprotons, they are shipped for read out to our collaborators at the National Physical Laboratory (NPL) in Teddington, UK.. (The NPL serves also as a primary standard lab for radiation quantities.)

Alright then.. :/

Recursively posting this blog entry.

More pictures here.

The Monte Carlo Race 2011

We saw earlier how different cars (and a box of Lego) could fit the description of various Monte Carlo particle transport codes. Every year there is the prestigious Monaco Grand Prix race (according to Wikipedia, I must stress, I am absolutely not into cars!), and this race passes the famous Monte Carlo region with its casino.

What you may not be aware of is the little known, sister event called the Monte Carlo Grand Prix, the year long publishing competition of Monte Carlo codes. I’m going to give you a run down of the latest results. Get a seat in the grandstand and plugin your ear plugs!


Monte Carlo codes are surging in radiotherapy treatment planning. For a course at the Aarhus University Hospital I had to give [footnote1] a little review of MC codes in radiotherapy. Inspired by a talk given by Emiliano Spezi I did a little study done using the ISI web of knowledge which clearly shows this trend:

Number of publications on “Monte Carlo Treatment Planning”. Data for 2011 are still incomplete for obvious reasons.

For a real race we of course need several competitors. In addition to the Geant4, FLUKA and SHIELD-HIT cars, we will have a few new participants joining the race!

From the country of The United States of America there are the two participants, MCNP and MCNPX developed in the secret labs of the Bombs-R-Us factory (a.k.a. Los Alamos), now released to the public (with a few exclusions) against a modest fee. MCNP helps physicists transporting neutrons as well as photon and electrons. The grand old MNCP brings along its more recent offspring MCNPX which also can transport heavy ions!

Just of north of the US, the Canadian National Research Council funded the development of EGS4/EGSnrc and as a courtesy to our medical minded people BEAMnrc was developed which is particularly suited for simulations of linear accelerators for radiation therapy. Rumours say that this nifty product is based on US technology from University of Wisconsin, ‘traitors’ some might argue, I’d say this is a remarkable example of pan American friendship!

The Japanese people, known for their industrial know-how, diligence and incomprehensible machine translated manuals contribute with this gemstone of technology: the PHITS multi purpose particle transport vehicle... sorry... code, maintained by the Japanese Atomic Energy Agency! Jovial attitude to technology breeds wonderful gadgets, often decades ahead of what eventually will appear in Europe.

Finally, and being among us for a while are the diligent efforts of our European friends in University of Barcelona in Spain. Hola PENELOPE!  PENELOPE can transport photons and electrons, evil tongues may even say much faster and smoother than our Canadian opponents. Let the masses judge how well they perform on the curved streets of Monaco.

Anyway, the race started many years ago and is still going on, let us see the current results:

Number of publications on various MC codes (not restricted to therapy planning)

Clearly MCNP has been roaring through the Mediterranean streets long before computers became mainstream and when 1 MByte was still an unbelievable amount of memory. It would have been a dull race, if EGS4 had not slowly appeared on the horizon. Geant4 was not conceived of when FLUKA already had an early start. Both Geant4 and FLUKA are developed at CERN, which makes their performance particularly exciting. Geant3 does not even appear here, it had a trauma from an earlier rally - it might recover, but bones tend to heal slowly at that age.

The fiery tempered Spanish PENELOPE and the latest ace from the United States MCNPX entered the rally roughly at the same time, and here the race gets really exciting! Let us take a closer look at the last 10 years. All codes are surging, so I will plot it relative to the total amount of publications per year:

The Monte Carlo Particle Transportation Grand Prix, during last 10 years.

It’s clearly a close race between the elderly and not-so-elderly codes. MCNP is clearly losing against its younger offspring MCPNX which also offers heavy ion transport. However, it is difficult to hide that MCNPX is loosing towards Geant4. The good news for MCNP is that it will be merging the MCNPX code base so it will get a boost of sorts! The success of Geant4 is truly amazing! Even if Geant4 cars are complicated, DIY affairs, the possibility to have total freedom with modding your car, giving it personal style, seems to attract a solid customer base.

FLUKA clearly shows a remarkably constant relative user base, going steady, going strong. But woo-hoo... whats happening with EGS4? The medical physicists came out of their closet declaring themselves as BEAMnrc users, and EGS4 is superseded by EGSnrc... 2011 could be one of the last years we hear of EGS4, but no-one will really miss it, we’ve got EGSnrc and BEAMnrc.

Trailing still is PHITS. PHITS users have still not published this year (2011) at the time writing these lines, but obviously I would not be surprised if it suddenly might come into play. Hopefully Japanese physicists will find time to catchup after they fix their issues with their nuclear power plants.

Where are the Russians? I can see smoke coming up on the horizon somewhere behind, I hope it is not a fire, but just a demonstration of the new engine. I am confident the Russian mechanics (with some aid from their friends in Aarhus :-) are working on it, and we soon will see fast SHIELD-HIT Niwas with whining tires and roaring physics engines in the curved streets of Monte Carlo.

The race isn’t over yet, and frankly I am not sure if it is supposed to end at all... but what can be said, some codes will prevail, others may lag and eventually disappear from the race.

See you next year at the Monte Carlo rally 2012 - readers are welcome to place their bets for 2012 below !



[footnote1]
“You have to give a 5 ECTS course in dosimetry.” Yeah right, I thought, it took me almost 4 months to prepare and run it, do all the exams (400 pages + external reviewer), no time for research whatever, looking forward for the day when it was all over. What followed? Research? Guess again: more teaching!