Adapt readouts to support veto systems

[lobis]

Currently the readout class is built with pixelated detectors in mind where there is a common volume (sensitive volume).

In the particular case of veto systems there are multiple sensitive volumes (each plastic scintillator slab) each connected to a single channel detector, therefor there is a clear correspondence between volume and channel.

In the conversion from Geant4 simulation to DetectorLib, we lose the information about which volume each hit comes from, since typically we only care about a single volume. This is a problem for the kind of detectors I am describing because it makes very hard to identify each hit with a channel afterwards.

I think we should:

• Create a new readout class (TRestDetectorVetoReadout?) to handle these types of detectors, which should be possible to initialize from the simulation geometry (TGeoManager) with minimal user configuration: which are the veto volumes, and where are the detector planes in each (given by a point and a normal vector).
• Modify the TRestDetectorHitsEvent and TRestDetectorSignalEvent to also store the volume information of each hit/signal. (because otherwise we cannot further process because we lose volume information). I do not love this option because it's not very clean but I cannot think of anythin else.

Please let me know if you think this approach is valid or we should use another one.

[jgalan]

The readout class allows to create any number of readout planes. Thus each veto could be constructed by defining a plane with a single module and a single readout channel.

The channel at each veto would be identified with a signal channel id, which is defined inside TRestDetectorReadoutChannel. This is the link with the electronics.

Thus, the scheme to construct a system of VETOs inside TRestDetectorReadout already exists.

I think the missing part is to define the technology of the readout. This could be a new metadata member inside TRestDetectorReadoutPlane that says the technology is scintillator, micromegas, etc.

Then the process that must generate a signal from the hits position will identify which is the type of readout plane, and apply the algorithm that is appropriate to the technology to simulate the signal.

Of course, what it is missing perhaps is a way to create a multi-plane readout definition that identifies with the GDML or TGeoManager geometry.

====

Thus, to your first point, I think there is no need to create a new TRestDetectorVetoReadout, but perhaps to introduce a way inside the TRestDetectorReadout that can be initialised from a GDML geometry where we used some naming convention.

To your second point, I don't like the idea, because this is artificial**. At the detector stage we must be able to find the volume information thanks to the readout class definition. E.g. using method TRestDetectorReadoutModule::IsInside. We could perhaps add a method inside TRestReadout, e.g. TRestReadout::GetReadoutPlane( TVector2 pos) that returns the readout plane where the hit was found.

** Artificial because in some scenarios the detector event data will be filled with experimental data where we do not have the information of the hits volume (but the channel id). Thus, we must unify the way we access the data for MonteCarlo and experimental data.

[jgalan]

Also think that you will need to associate a channel id to each channel when generating the readout, thus I could imagine that when building the TRestDetectorReadout you might give to the TRestDetectorReadoutModule the name of the geometry volume it is associated with.

E.g. TRestDetectorReadoutModule::fGeometryVolumeName

if this value is defined, then the readout could try to initialise the readout module/plane metadata members from the geometry volume (e.g. an instance of TGeoManager). In this case, the readout could contain an instance from the TGeoManager, TRestDetectorReadout::fGeometry

[jgalan]

Seen from another point of view, if you really need hard access for every hit to the volume information produced from MC, then probably is better to implement whatever in the geant4lib domain.