Roy and Niels

Roy and Niels

Monday, January 31, 2011

Making Bubbles: The Particle Way

BTI BubbleTech Industries manufacture neutron detectors intended for personal dosimetry. Theses devices contain a polymer gel holding very small droplets of a superheated gas. When a neutron interacts with these superheated droplets, a phase transition happen from liquid phase to gas phase expanding the volume dramatically - a bubble appears.

The video below demonstrates how such a detector responds to a (weak) Americium-Beryllium neutron source:



The activity of the AmBe source was 2.64E+4 neutrons per second. The detectors we had were calibrated against ICRP-60 in terms of dose equivalent, according to BTI. The sensitivity of the particular detector shown in the video above was about 0.7 bubbles / µSv dose equivalent.

The detectors come with an integrated piston which repressurizes them, so they can be reused, however not indefinitely. We used our detectors rarely, and kept them refrigerated. However, after two years the encapsulation/pressurization system leaked.

The bubble detectors can be bought with varying sensitivity ranges and BTI even offers a set of detectors which are sensitive above a varying energy threshold. Deconvoluting the counts in each detector of this set will yield a coarse energy spectrum, in e.g. 6 energy bins.

We have used the these bubble detectors in our antiproton beam line at CERN in order to get a coarse measure of the amount of fast neutrons emitted from the antiproton annihilation. We used both the personal dosimeter type and the BDS spectrometer.



The picture above show how multiple personal dosimeter detectors are places at a certain distance from the annihilation vertex.

Unfortunately we had some trouble interpreting the results from the spectrometer. The BDS spectrometer counts seemed to be simply unphysical and a spectrum could not be deconvoluted. The readings from the personal dosimeter also seemed to be off by an order of magnitude.

After some investigations we started to suspect that these bubble detectors were not only sensitive to fast neutrons, but also to charged particles, such as protons. From the antiproton annihilation we do get a similar amount of protons and a threefold multiplicity of energetic pions, which have a long range, far beyond the position of the bubble detectors.

A paper in NIM B, which was published a few years ago by us, lists our findings. Basically we conclude that the sensitivity (# of neutrons per bubble) is quite comparable to that for protons, and perhaps a bit less for pions. The proton part we could test at our storage ring, ASTRID, which we have in the basement of our Physics Department in Aarhus.

In the video you are about to see, we extract a few million protons at about 50 MeV from the synchrotron. The bubble detector here is immersed in a water bath.



The range of the protons are clearly visible. A distinct Bragg peak does not really form, the effect is primarily related to nuclear interaction cross sections.

Friday, January 14, 2011

Open access, medical physics, and arXiv.org

If you read research papers, chances are you’ve heard the term open access. In this post I’m going to talk about what open access is, the state of open access in medical physics, and what medical physicists can do if they want to make their work open access using sites such as arXiv.org. The quick summary is: the primary obstacle to open access in medical physics is adoption by authors. Most journals are already on-board in important ways. If you want to make your medical physics publications open access, you probably can and I encourage you to do so.

According to our friends at Wikipedia, open access is “unrestricted online access to articles published in scholarly journals”. Open access is generally placed into two categories: “Green” open access and “Gold” open access. Green access is defined as author “self-archiving”, when the author places a copy of a paper on their own site or on an e-print server. Gold access is free access provided directly by journals.

No-fee access has many benefits for researchers. For medical physics, these benefits are potentially greater than for other fields, due to the fact that medical physicists are found in a wide variety of settings with varying levels of paid journal access (i.e. universities, community hospitals, small clinics, etc). Even being located at a large university with a large medical center, I have personally run into access barriers. For example, I can only access Medical Physics with my personal subscription; for a time the library subscribed to the Red Journal, but not the Green Journal; the university has no love for Radiation Protection Dosimetry whatsoever. In the current economic climate I’m not optimistic that institutional subscriptions will be on the increase. Ultimately, open access offers availability of information to all regardless of institutional affiliation or budget. (Also, I hate messing with proxies... :) )

While open access is strongly established in some disciplines, particularly physics, computer science, math, and earth science, medical physics seems to have lagged behind the curve greatly, especially in self-archiving.

“The availability of gold and green OA copies by scientific discipline. The disciplines are shown by the gold ratio in descending order, rather than in alphabetical order.” CCA 3.0. Björk B-C, Welling P, Laakso M, Majlender P, Hedlund T, Gudnason G. doi:10.1371/journal.pone.0011273

The above plot from Björk et al. shows the percentage of publications that are made open access in different disciplines. In some sub-disciples of physics, such as high energy physics, the rate of self-archiving is up to 100%. For reasons unknown to me, medical physicists have not embraced open access, despite the supportive polices of medical physics journals (see lists below). I suspect that medical physicists are largely ignorant of the journals’ policies. If medical physicists want to provide open access to their work, they have options to both self-archive (green) or publish in open access journals directly (gold).

arXiv.org
In 1991, high energy physicists began self-archiving their publications on a site called the arXiv (that X is supposed to be like a Greek “chi”). Since then, the arXiv has expanded to cover all of physics, as well as other fields, such as mathematics and computer science. As the leader in physics self-archiving, the arXiv is a logical destination for medical physicists to post their papers. In fact, the arXiv has a medical physics category. Currently, the medical physics category of the arXiv has very low activity relative to the number of medical physics articles published that are eligible to be posted. (I plan to investigate the posting rates in a future blog post.) While the activity is low, it is encouraging to see prominent medical physics researchers, such as Steve Jiang (UCSD) and Thomas Bortfeld (MGH/Harvard), posting articles. (Thanks!) In fact, one tiny area of medical physics that seems to be very well covered on the arXiv is GPU based calculations in medical physics. That’s probably due to Jiang’s group leading the way in posting their publications.

Medical journals
While medical physics journals all allow self-archiving to servers such as arXiv.org, medical journals related to medical physics seem to be much less enthusiastic about open access (see the list for details). The Elsevier journals allow pre-prints and self-hosted archiving, but the main radiology journals have open access “hostile” policies. The one thing that has seemed to crack journals such as those from RSNA is government mandates. One example is the recent rule requiring NIH funded research publications to be made available as open access on PubMed Central within 12 months of initial publication. This rule has had a wide ranging effect on journals and led to much discussion. Funding agencies in other countries have instituted similar rules.

What does this all mean for you?
  1. If you’ve published in medical physics journals, you can probably make your work open access right now by posting your articles to arXiv.org.
  2. If you are planning to submit an article to a journal, you should read the journal’s copyright policy before submitting and before posting a pre-print (or post-print). Some journals have very strange policies, unfortunately, and this has to be taken into account when submitting for publication.
I encourage authors to strongly consider making their work open access, either by self-archiving to the arXiv or publishing in one of the gold access journals. Ultimately, the arXiv is just an example of an e-print repository, but it seems to be the best choice for now. If, for example, a dedicated medical physics repository were created and critical mass were achieved, the papers on the arXiv could be stored there as well. I haven’t discussed the concerns some people have with open access (see the Wikipedia entry). If there is interest, I might talk about that in another post.

Journal policies
Below I will list the current (Jan. 2011) policies of the journals (as far as I can tell, UAYOR, YMMV, IANAL, etc). You can find out more information about the open access policies of these journals and others by using the SHERPA/RoMEO tool.

The state of open access in medical physics journals:
The state of open access in medical journals related to medical physics:

Wednesday, January 5, 2011

libdEdx version 1.0 released

Version 1.0 of libdEdx is now available at sourceforge.net

List of features:
  • ICRU 49 date tables for protons and Helium ions (PSTAR, ASTAR)
  • MSTAR for heavy ions
  • ICRU 73 with and without the erratum for water target
  • A Bethe implementation for any ion, including Linhard-Sørensen equation for low energies
  • Support for 278 ICRU target materials, i.e. the complete ESTAR material table, all with default I-values for the Bethe equation
  • I-values can be overridden for elements
  • Automatic application of Bragg's additivity rule, if requested target material does not exist in default table for e.g. MSTAR.
  • Detailed documentation, and multiple example files
  • CMAKE based installer, with uninstall target.
  • getdedx as a frontend command line program for querying the library
  • Two modes of operation: simple for lazy programmers and fast for e.g. MC codes.
  • GPL license (non-GPL versions available upon request)



How to use libdEdx, simplest possible example.

Demonstration of command line program getdedx. 100 MeV protons using PSTAR on water:

Usage: getdedx program_id  Z icru_target_id energy.

bassler@kepler:~$ getdedx 2 1 276 100
100.000000 MeV/u HYDROGEN ions on WATER target using PSTAR
dEdx = 7.286E+00 MeV cm2/g

Carbon ions on alanine target, using ICRU 73:

bassler@kepler: getdedx 5 6 105 400
400.000000 MeV/u CARBON ions on ALANINE target using ICRU73
 Bragg's additivity rule was applied,
 since compound ALANINE is not in ICRU73 data table.
dEdx = 1.068E+02 MeV cm2/g

For reporting bugs and feature request, you can use our trac ticket system or drop us an email.

Thursday, December 30, 2010

Happy new year...

... and a few wishes for 2011:

libdEdx: I hoped I could announce first official release of the stopping power library before 2011. Unfortunately, there are a few minor problems with the Bethe implementation which Jakob wanted to fix first. It is almost done...
Just to give an idea what's coming up: libdEdx 1.0 will probably be a Linux-only release and we most likely won't include ESTAR tables. Good news are that PSTAR, ASTAR, MSTAR and the ICRU 73 (old and new) tables seem to work. The entire ESTAR ICRU material composition table is supported, so if the user of the library calls a non-standard compound, Braggs additivity rule is automatically applied according to the stochiometric compositions defined by ICRU (see list here).
The Bethe-equation implementation allows the user to override the mean exitation potential for elements. Also, an uninstall target is now provided in the CMake configuration.
If you can't wait for the 1.0 release of libdEdx you may test revision 85 in the SVN repository which is quite close to something functioning.
Enough said about that.

So, regardning the current status of SHIELD-HIT10A: The main developer and maintainer Prof. Nikolaj Sobolevsky from INR Moscow visited us again in Aarhus for a month (a few pictures to be added later). Basically, we discussed the changes from 08 to 10A, the fitting of nuclear models to recently published experimental data and  the development framework in general.  More importantly, we try to encourage a clearer road map for SHIELD-HIT. In particular, this involves settling on a clear license model and terms of use. This process is ongoing and takes time, but surely we still see SHIELD-HIT filling a gap which neither FLUKA or Geant4 fills when it comes to combining ease-of-use while still having access to the source code. Stay tuned for more on this.

Now for something completely different: Since this blog (<-- beware of the recursion) quite unintentionally has turned more or less into a blog on topics in computing, medical physics and particle therapy, I have invited a fellow blogger Roy Keyes from University of New Mexico (Albuquerque) to contribute. Roy and I have shared many night shifts at CERN running our antiproton experiments.
Roy Keyes' (to the left) inexhaustible repository of real life anecdotes helped me to stay awake during the long night shifts at CERN October 2011. Thanks, Roy. Everyone, say hi to Roy...
Common work topics are also Monte Carlo simulations, mostly FLUKA, which UNM is running in the Amazon cloud (awesome idea!). In addition, Roy works on an open source DICOM-RT viewer dicompyler. Dicompyler resembles in many ways my PyTRiP project, which is supposed to be a versatile python visualization tool for the heavy ion treatment planning program TRiP, including a GUI. Probably these projects will merge at some point and take over the world. Again, more on this later.

BTW: You can meet Roy in a little test video I made about the CERN antiproton experiments. Alas, since kdenlive crashes big time in the current version at project loading, I never made it further than the intro and gave up the editing. I'll have to wait until kdenlive is updated in Debian testing repo. But I got looooots of wonderful footage, including details of antiproton production and french speaking technicians fixing dead synchrotrons! :-)

Plenty of plans, only little time, but surely this blog will become much more lively 2011. With these words, I wish you all a happy new year!

Cheers,
Niels

P.S.: Future non-work related blog entries from my side will be published on http://opasnajazona.blogspot.com. (The similarity to a nuclear waste dump is not coincidental.)

Monday, November 29, 2010

The Stopping Power of Frozen Water

In my last blog entry I commented on stopping powers of fast ions in medical physics, and announced the libdEdx library. (Stopping powers describe the energy loss of fast charged particles in material, thereby transferring energy to the target matter.) Stopping powers directly relate to the deposited dose, but there are plenty of more subtle effects where they may or may not have a profound influence:
  • Range of ions in matter. Often the mean excitation energy (not to be confused with the ionization potential or w value...) in the Bethe-equation is used as a macroscopic fitting parameter for the range of ions. Effects such as an primary particle dependent I-value are reported, even this is unphysical. Discussion is going on what the I-value for water actually is covering the 75 to 85 eV interval. PSTAR claims 75 eV. More recent studies seem to agree on a value close to 80 eV.
  • Ionization chambers rely on a solid assertion of stopping power ratios, since these detectors measure dose to air. In order to translate this to dose to water, you should know the particle spectrums and the stopping power ratio of water to air (see e.g. IAEA TRS-398 dosimetry protocol, so far one of the best out there, even though it has its flaws...) Or, you can use a parametrization, as Armin tries to show in our recent yet unpublished paper (pre-print).
  • Detector and biology response models such as the Katz or LEM model rely on the stopping power of ions. How large these effects are, is still to be investigated, and is something we want to look at using libdEdx and libamtrack.
There may be many more applications, whereas the first two mentioned here are quite well researched. Frustrating enough, if you have to calculate e.g. the stopping power ratios for a given particle spectrum, you have to rely on the ICRU49 (PSTAR/ASTAR) table and the ICRU73, and they are not calculated consistently. Ok, the errors may be minor for practical dosimetry purposes, but thinking of primary standard laboratories such as PTB in Braunschweig or NPL in London who try to increase the precision at least one order of magnitude, you may get into difficulties.

How can this be, don't we have a large data base on experiments for various ions on various targets? Well, yes, for some ion/target combination, but not for all of them. Peter Sigmund from University of Southern Denmark, (now Professor Emeritus), once showed a very nice matrix of combinations at our 4th Danish Workshop, where all the experimental gaps are.
Even worse is the situation for compounds, here no or very little data are available.

So, we decided to take this up a the 5th Danish Workshop on Particle Therapy, in order to sort out the field, and give the research some direction.
This brings me back to the title of this blog entry: The workshop was scheduled to take place tomorrow (30th November) in Aarhus, but exactly due to the stopping power of frozen water, we had to cancel it. Several key persons were stuck in various airports and could not make it because of snowstorms.

Now... this massive amount of snow in Aarhus at this time of the year is not common, and frankly, I wonder if I am going to make it to work tomorrow. Instead, I would like to invite you - dear reader of this blog - to stop a few minutes with me and silently enjoy the scenery below, accompanied with a piece of J.S. Bach.

Sunday, November 7, 2010

One Stopping Power Library to Rule Them All: libdEdx

Stopping powers describe the energy loss of charged particles traversing matter. In particle therapy, stopping powers are an essential ingredient for calculating the dose distribution of ion beams.

A direct way of calculating the stopping power is using the Bethe equation. However, this equation requires a good knowledge of the ionization potential (in particle therapy jargon: "the I-value") and for compounds this value is pretty ill researched. The I-value can be found experimentally, but there are only few experimental data available for compounds relevant for particle therapy, such as various tissue types and even for water. Our postdoc. Armin Lühr has recently submitted a paper where he takes a closer look on these issues which is available on the archive: http://arxiv.org/abs/1010.5356

Several programs provide stopping powers, either as analytic calculations or inter/extrapolated experimental data. The list below may be incomplete, but these are the codes I have been in touch with so far:
  • ESTAR: for electrons. (Fortran77)
  • PSTAR: for protons. (Fortran77)
  • ASTAR: for alpha particles (Fortran77)
  • MSTAR: for alpha particles and heavier ions up to Z=18. Basically MSTAR is scaling ASTAR data, where the scaling factors are fitted to experimental data. (Fortran77)
  • ATIMA: code developed by GSI. (Java wrapping a Fortran core)
  • TRIM/SRIM: Application which can simulate any ion on any compound.
And various tables provided by the ICRU:
  • ICRU 49: proton data and alphas, equivalent with PSTAR/ASTAR.
  • ICRU 73: ions heavier than helium, old version
  • ICRU 73: new version after errata, quite similar to MSTAR, even if calculated differently.
and in summary they don't agree too well at lower energies (say below 10 MeV/u).

Nonetheless: from an application developer point of view this leaves you in a dilemma of choosing the proper code for your application, and most likely we will see more updates, since the issues are not solved yet with the erratum of the ICRU73.

In addition, from a technical point of view most stopping power codes are not written in convenient ways which allows a clean integration into your application. This is a common thing which happens when physicists develop code: the code will always be optimized to work nicely on the developers computer and fulfill their specific needs. Platform portability, an API, and install scripts following de-facto standards are mostly absent.

This is why we started the development of libdEdx.

libdEdx is meant to be a platform independent stopping power library which contains multiple tables to choose from, and can be extended with additional algorithms/tables. Currently libdEdx includes ESTAR,PSTAR,ASTAR,MSTAR and ICRU73 data as well as an implementation of the Bethe-equation akin to that found in SHIELD-HIT.
The material database is based on the extensive ICRU set found in the ESTAR table, and using Braggs additivity rule libdEdx can extend the MSTAR/ICRU73 data set to cover the ESTAR material list.

libdEdx comes along with an installer based on cmake, and the first official release should be able to run on Windoze just as well as Unix/Posix/Linux compliant platforms.

Surely, Geant4 also offers a range of stopping power tables to choose from, but you do not want to install entire Geant4 just to access the stopping power values.

Our bachelor student Jakob Toftegaard (who very conveniently has a background in physics and computer science) did most of the coding. A very early experimental pre-release is available on sourceforge, but if you want to experiment with it and even contribute you can also grab the most recent version from the SVN repository.

P.S.: Armin and David will present libdEdx on the MC2010 conference in Stockholm on the 9th to the 12th November. Posters can be found here.

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!