Separate the phototube and digitizer into two distinguishable pieces.

[cwwalter]

This will allow us to separately specify various tubes, HPDs etc and digitizer electronics models.

Erin already started this work but I just rediscovered some work by Stan Seibert you also might look at in the archive/PMTProperties branch. It has some abstract base classes for digitizers that might be useful.

[cwwalter]

After this work is done, then a next step is issue #11.

[thomaslindner]

Hi,

I'm working on the option of using FADCs for HK and am hoping to find some time to test the performance of such a system using WCSim. Fixing this issue would clearly be helpful, since it would be easier to swap in a FADCDigitizier for a TDC/ADCDigitizer.

Have you considered/decided on how information would be transferred between the PMT simulation and the digitizer simulation? Ie, what data class would be used for communicating between the different classes?

Off the top of my head, I would imagine that you'd want something like

// List of all PEs for a particular PMT
class PMTSignal {
private:
G4int tubeID;
std::vector peTime; // time at which PE was created.
std::vector peCharge; // if in units of PE, then just drawn from a gaussian centered
// at 1 with width of PMT charge resolution.
std::vector truth; // some sort of pointer back to which true trajectory caused this hit.
// + all normal setters/getters
}

So for each photoelectron for a given PMT you would be storing the time and charge. I think this would be enough information to be able to simulate artificial waveforms for each PMT. This is the technique that we used for the ND280-FGD FADC simulation.

I don't think it would be necessary to have this information be persistent: it would just be an intermediate between the PMT and digitizer simulations.

Erin pointed out in a recent talk that it might also be nice if the PMT simulation also provided a pulse shape. It seems to me that it would be sufficient (at least for the near term) to have a single canonical pulse shape for each PMT. Ie it would not be necessary to have different single PE pulse shapes for each pulse: but rather to just have a single different pulse shape between PMTs and HPDs. So the HPD simulation would define some canonical pulse shape that was narrower than the PMT canonical pulse shape.

Naturally we would also need a solution to issue #11 before we could do a proper simulation of the FADC performance.

Thomas Lindner

[eosullivan]

Hi Thomas,

Thanks for your comments on this. I am going to use the DigitsCollection class in Geant4 to pass the information between the PMT and Digitizer. I also considered using the HitsCollection class, but I couldn't find a compelling reason for using one over the other, and so ended up using DigitsCollection because I am maybe slightly more familiar with it.

I think the general method which you outlined is basically what I had in mind. The PMT module will take in the HitsCollection from the sensitive detector, will convert the pe into a charge by pulling from a distribution which is specific to the PMT type (the qpe0 array that exists currently in src/WCSimWCDigitizer.cc, for example), and then will output a collection with tubeID, the time of the event, and the charge.

I am glad to hear that this will have applications for your tests. Please let me know if you have any further comments, either now or once this update is committed.

Erin

[cwwalter]

This was fixed by pull request #17.