Monday, March 21, 2011

The "ideal" Monte Carlo user interface

If you have read many of our posts, you probably know that radiation Monte Carlo software plays a large role in both Niels' and my research efforts. Niels wrote an insightful and entertaining overview of the available Monte Carlo engines relevant for particle therapy. I'm going to talk about one of the things that most MC users have surely thought about or at least been frustrated by: user interfaces.

I'll start by making a disclaimer. Monte Carlo for radiation / particle transport is not a simple problem. It takes many person years worth of effort to produce a codebase that gives reasonable results. This post is mostly my musings about some ideal user interface. I am the proverbial beggar who also wants to be a chooser :)

Most interaction with MC programs is performed by creating input files of some sort (in Geant4 these are called macro files and can function in largely the same way). Usually these input files allow you to set the majority of important parameters relevant to your simulation (e.g. beam parameters, target geometry, detector geometry, scoring parameters, etc). While initially cryptic (see Fluka and MCNP input files), these text input files are extremely flexible and can be generated programatically or with a GUI. The problem of course, is that your typical input file format is not very intuitive, designed to be machine parsible, rather than human friendly. And as all new MC users know, input files and their syntax are one of the major hurdles in getting up and running.

A Fluka input file.

So what would the ideal MC user interface look like? Radiation physics users of MC engines want to irradiate something and score some quantity. For medical physics users, that usually means irradiating a human or water phantom and scoring dose or fluence. To me the obvious interface for MC codes would be identical to 3D CAD (computer-aided design).


The open source FreeCAD CAD program.

A 3D CAD style interface would put you directly in the geometry of the simulation world. Build your target from simple shapes or import existing geometries (e.g. DICOM files), graphically designate your beam source, type, and direction, and set up your detector geometries. More importantly, you would be able to manage your simulation end-to-end in the interface.

It can be argued that 3D CAD is as hard or harder to learn than a given MC engine. My approach for a user interface would be to expose the minimum useful controls, making advanced options discoverable through menus and configurable with shortcuts.

The follow-up disclaimer is that 3D CAD is also not an easy problem, so we are unlikely to see this soon. In fact many of the MC programs can import geometries from CAD programs (see SimpleGeo), but I'm unaware of any that have attempted to fully integrate a CAD-style GUI as a primary user interface.

What's your ideal Monte Carlo user interface? Leave us a comment and let us know.

2 comments:

  1. Well there are a number of MC codes that do integrate a CAD-style GUI as their primary user interface. However, they are dealing with a different domain/energy range, namely optical photon transport. Thus, their purpose is significantly different than the particle transport codes that you mention.

    There are basically two reasons which I can see, there might of course be others as well, why you don't find such interfaces in typical radiation transport codes. On one hand those codes have a long standing history which goes way back and the code base does not lend itself easily to the development of a modern 3D CAD interface without embarking essentially on a redesign and rewrite of hundred thousands of lines of code.

    On the other hand the developers of 3D CAD applications as well as those of MC particle transport codes live in two different universes. For 3D CAD you need people specialized in computer graphics & software development, whereas typically the developers of MC radiation transport codes have their background in nuclear/theoretical physics. For the time being these are still two camps who do not really know each other, even though there surely would be significant benefit to my mind.

    ReplyDelete
  2. Hi Chris,

    Thanks for stopping by our blog and commenting!

    You are definitely right about ray tracing programs (I assume that's what you mean by optical photons). I also agree that the major problem is that 3D CAD and MC particle transport are both very difficult and require very specialized knowledge, so you're unlikely to find those groups of people together, minus big money. Ray tracing is a significantly simpler (and more lucrative?) problem, I assume.

    P.S. SimpleGeo looks really nice, but I only have Linux machines.

    ReplyDelete