Those pages describe my first thoughts of what could be the future of PISA.

The Virtual Monte Carlo

The very first question might be "Why do you want to fix something which is not broken" ? Well, it of course depends on the definition of not broken (one could certainly consider that the output of PISA is broken, not 100% PHOOL compliant, that is). But more importantly, it will certainly break as soon as Geant321 does. And as Geant is no longer really supported nor developped, this will happen sooner or later. And this will break Pisa as Pisa is a 100% Geant3 application.

This last statement already gives an hint on what to do : make Pisa a x% Geant3 application, where x is strictly less than 100. The closer to zero, the better. This is by no means a little work, so it should be planned carefully. One key point I would like to make is that making Pisa a 100% YourFavoriteMCHere is not the way to go, as it would simply transfer the problem. Also, Pisa is currently mainly a Fortran based application. Moving it to C++ (our main language in C++) would probably be a good think too.

Fortunately, there is a way out, which still requires a major rewriting of Pisa, but hopefully will make it a Geant3, Geant4, Fluka (and YourFavoriteMCHere) application. The hero here is named VMC (Virtual Monte Carlo). It started its life in ALICE, is now publicly available, and is actively developped. This guy defines an abstract C++ interface to interact with a Monte Carlo detector simulation package. Concrete implementations do exist for Geant3 (the one which is actively used by ALICE currently), and for Geant4. Fluka is not there yet, but should be soon (the same ALICE people push hard for this to happen).

Anyway, as I said, moving from the current Pisa to the next one will be a major task. But I wanted to have a better view on how major exactly. So in the last few days I did play with the VMC and Pisa to see what it would take for the move. I'll explain in what follows where am I in that process (which I tentatively call VPisa©).

In the VMC language, one must distinguishes between a Monte Carlo (e.g. Geant3) and a Monte Carlo Application (e.g. Pisa). The Monte Carlo software is of course not our job, so I won't say anything about it. A VMC Application must define (at least) 2 classes deriving from 2 VMC bases classes : TVirtualMCApplication which is the "main program" code, and TVirtualMCStack which is the object responsible for handling tracks (primaries and secondaries). Both are pretty lean and quite self-explanatory. Also worth noticing is that the geometry description (including materials and media definition) is fully handled by the new ROOT Geometry Manager (also described in Chapter 16 of ROOT User's Guide), which is supposed to be faster than Geant3 for e.g. finding in which volume a given point is (a central issue for tracking software), and has some nice checking capabilities (e.g. finding overlaps between volumes).