Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Making veto readouts work #98

Merged
merged 53 commits into from
Sep 28, 2023
Merged

Making veto readouts work #98

merged 53 commits into from
Sep 28, 2023

Conversation

lobis
Copy link
Member

@lobis lobis commented Jul 31, 2023

lobis Large: 3070 Powered by Pull Request Badge

When working on veto readouts I had to make some changes.

The new veto system readout is defined here: https://github.com/iaxo/iaxo-readouts/tree/master/vetos. Additional information can be found in the README.

Previous to this PR, the coordinates are passed to the readout plane/module as simple projections (x,y,z) -> (x,y). This is not general and fails unless the readout is in the appropiate plane. I made modifications to account for the necessary transformation of coordinates. A veto readout has many readout planes (one for each veto) with each plane having a single module and channel.

With the changes in this PR the veto readout works fine. This can be tested using the instructions provided in the link above.

However I think something must have been broken by this changes as the PandaX pipeline is failing. Since this PR required fundamental changes it was hard not to break anything.

Currently the veto reaodut is produced as a separate readout (one for the detector (MM), one for the veto system) but they should be integrated into one. Once we fix the problems introduced by this PR on the detector readout this can be done hopefully without much effort.

In order to distinguish between regular readout channels and veto channels I have added a type "veto" to the veto readout channels. This is carried over to TRestDetectorSignal along with another optional field "name" in order to know at a glance which veto volume it corresponds. We could also add a position field which could help in analysis of experimental data.

Processing of signals coming from different types of readout channels needs to be different. I modified the TRestDetectorHitsToSignalProcess to also compute the light travel delay and attenuation for the vetoes. It automatically looks for the signal type parameter and if "veto" is found, it will not do the regular drift but instead do light attenuation and delay.

@lobis lobis changed the title Lobis working on veto readout Making veto readouts work Aug 2, 2023
@lobis lobis marked this pull request as ready for review August 3, 2023 10:56
@lobis lobis requested review from jgalan and juanangp August 3, 2023 10:56
lobis and others added 26 commits August 30, 2023 19:59
…to-readout

* origin/master:
  remove unused variable
  only affect XYZ hits
…to-readout

* origin/master:
  Addressing compilation issue after merge with master
  Removal of custom typedef any since it is misleading with std::any, replaced by RESTValue
…nto lobis-working-on-veto-readout

* origin/lobis-working-on-veto-readout:
  [pre-commit.ci] auto fixes from pre-commit.com hooks
@lobis lobis requested a review from a team September 28, 2023 11:20
@lobis lobis merged commit ba29df4 into master Sep 28, 2023
62 of 63 checks passed
@lobis lobis deleted the lobis-working-on-veto-readout branch September 28, 2023 11:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants