Conversation
|
Thanks. There is already a piece of code to add tracker uncertainty. This is done in a more realistic fashion than what you propose as far as I can see. It would be preferable to integrate this code instead of developing a new one. I'm not sure about the split. Why not add noise to the root data? You still need to decide when pairing (reconstructing the track) what you want to store (times, energies, etc.) ?
Reproducing what happens is the real case is the best path forward so your current implementation makes sense to me. |
|
Here is a new draft in the form of a new application |
f3bf93e to
ee24715
Compare
ee24715 to
1588a17
Compare
This PR adds new features:
I am not entirely happy about the current solution because I think
pctpairprotonsis now doing too many things at once. However, I had to put the code here to access the intermediate values (energy or TOF) before converting them to WEPL. I suggest the following future solution: splitpctpairprotonsinto three applications, one that would pair the protons, one that would add noise to the data and one that would convert the energy-loss or the TOF to WEPL. This would lead to cleaner and shorter application code, and more flexibility when defining data processing pipelines using PCT. However, for the time being, I think we can keep adding features topctpairprotonsand split it later on.I also have a question: how to deal with values that obviously don't make sense after noise is applied? I am thinking about i.e. protons that have more energy in the downstream detector than in the upstream (which could happen with a real detector with poor energy resolution), or positions that are outside of the detector. The current code leaves all responsibility to the user, but perhaps there is a better way?
If you agree with the current state of the code, I'll add some documentation before merging (hence the WIP).
(Sorry for the long message!)