Towards a proof-of-principle prototype

Before turning to the actual design of the corresponding Pisa classes, let me say also that I wanted to see how Pisa could better fit in the Fun4All framework, right from the beginning, i.e. when producing Pisa hits. I think it would be great to have both input and output handled by Fun4All and let Pisa be "only" a tracker. Here's how my test macro looks like currently :

void run() (1)
{
  gSystem->Load("libframework.so"); (2)
  gSystem->Load("libvpisa.so");
  gSystem->Load("libGeom");
  gSystem->Load("libVMC");
  gSystem->Load("libPhysics");
  gSystem->Load("libEG"); 
  gSystem->Load("libEGPythia6");
  gSystem->Load("libPythia6"); 
  gSystem->Load("libGui.so"); 
  gSystem->Load("libdummies.so");
  gSystem->Load("libgeant321.so");

  Fun4AllServer* se = Fun4AllServer::instance();

  se->registerSubsystem(new PisaSimpleGenerator); (3)

  PisaDriver* pisa = new PisaDriver; (4)
  pisa->Verbosity(3);

  pisa->registerDevice(new PisaHALL); (5)
  pisa->registerDevice(new PisaBBC);

  se->registerSubsystem(pisa);

  // here we could imagine to register response module(s) ?

  se->run(1); (6)
}

1. Even before starting to comment this macro, the very first nice thing is the way you select the concrete MC implementation : use a macro (the name is currently hard-coded in PisaServer) :

   void PISAConfig()
   {
     TGeant3* geant3 = new  TGeant3("C++ Interface to Geant3"); 
     
     cout << "Geant3 has been created." << endl;
   
     //  geant3->SetDRAY(1); // any Geant3 specifics go here
     //  geant3->SetLOSS(1);
     //  geant3->SetHADR(0);
   }
   

   That's the only place you deal with MC specifics.
2. I obviously did not pay much attention to VMC lib dependencies (;-) ) so far, but the only relevant ones here are libframework.so which is a stripped-down version of phool+fun4all to be used on my laptop (I'm working on my laptop because VMC works better with ROOT 4) and libvpisa.so which contains the few new Pisa classes I'm talking about
3. The event generation ought to be Pisa-independent, and is simply filling a node with the relevant information (ie. a TVirtualMCStack)
4. Pisa is now a plain SubsysReco
5. Various pieces of Phenix are connected exactly the same way we connect analysis or reco modules to Fun4All, except we do it through PisaDriver (because the internal loops are different : PisaDriver has to loop over all primary particles contained in a single event, single event which is the unit of work for Fun4All)
6. Launch the simulation for one event.

The above macro actually does something, it creates the HALL volume (and companions) and the BBC geometry, and throw 1 particle in the device.

Every piece of PHENIX is modelled by a child of PisaDevice (for structural pieces) or PisaDetector (for an actual detector) , and is registered to the PisaDriver (which is simply a wrapper around the core VPisa class which is PisaServer to make it SubsysReco-compliant). Those interfaces are not finalized yet, but are not completely empty, either. Basically the geometry and material definition scheme is there. The placeholder for step management too :

class PisaDetector : public PisaDevice
{
 public:

  PisaDetector();

  virtual ~PisaDetector();

  /// Called by PisaServer at initialization
  virtual void createGeometry(PHCompositeNode* topNode) = 0;

  /// Called by PisaServer at initialization
  virtual void createMaterials(PHCompositeNode* topNode) = 0;

  /** Might want to disable the step manager 
      (e.g. to get the detector physically there, but not active).
    */
  virtual void enable(bool status) { fIsEnabled = status; }

  virtual bool isSensitive() const { return fIsEnabled; }

  virtual const char* name() const = 0;

  /// Former gustep in Geant3 land.
  virtual void stepManager() = 0;

  virtual const char* subsystem() const = 0;
};

To write all the above took me roughly one week (2 days digging through VMC/GeoManager/AliRoot docs, 1 day for the "framework" classes, 1 day for HALL + partial MAGNET geometry implementation, 1 day for BBC geometry).