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

Readout plane upgrade, readout validation and new library version #92

Merged
merged 71 commits into from
Jun 14, 2023

Conversation

jgalan
Copy link
Member

@jgalan jgalan commented Jun 7, 2023

jgalan Large: 3257

  • Library version increased to v2.0

The aim of this PR is to add the new metadata members required for future implementation of readout plane rotation and orientation so that the new readouts can be already pre-generated for pipeline validation.

We have introduced new members inside TRestDetectorReadoutPlane.

  • fAxisX and fAxisY. They are initialised internally using the fNormal value.

  • fTotalDriftDistance disappears, and it is replaced by fHeight which is defined by user.

  • fCathode position will now disappear. We just define the height of the active volume above the readout plane. There is still a method GetCathodePosition that returns the readout position at a given fHeight.

Related to: rest-for-physics/framework#438

@jgalan jgalan changed the title Readoutplane preparations Readoutplane preparations and new library version Jun 7, 2023
@jgalan jgalan changed the title Readoutplane preparations and new library version Readout plane upgrade, readout validation and new library version Jun 7, 2023
@lobis
Copy link
Member

lobis commented Jun 7, 2023

I am confused, should we not use #85 for these changes? should I just close it?

@jgalan
Copy link
Member Author

jgalan commented Jun 7, 2023

I am confused, should we not use #85 for these changes? should I just close it?

No, just merge it, I wanted to create a reduced one with the final metadata members (without final implementation) we will need for the readout. Because readouts need to be regenerated with the new metadata members for the pipelines, and we need to fix a new release.

@lobis
Copy link
Member

lobis commented Jun 7, 2023

I am confused, should we not use #85 for these changes? should I just close it?

No, just merge it, I wanted to create a reduced one with the final metadata members (without final implementation) we will need for the readout. Because readouts need to be regenerated with the new metadata members for the pipelines, and we need to fix a new release.

Then I have one more comment before this is frozen: I think it would make more sense to store a height parameter instead of the cathode position. The readout position (TVector), normal vector and height (along the normal vector) should be enough to completely define the readout in space. We could still support the users to define the readout using a point in the cathode plane but a single parameter height should also be supported (in my opinion) and I think it makes more sense to store it as a single parameter. Also I am not sure I like the idea of naming the opposite plane to the readout as "cathode" as not all readouts use drift for reading (light?) we should perhaps use more generic words.

@jgalan
Copy link
Member Author

jgalan commented Jun 8, 2023

I am confused, should we not use #85 for these changes? should I just close it?

No, just merge it, I wanted to create a reduced one with the final metadata members (without final implementation) we will need for the readout. Because readouts need to be regenerated with the new metadata members for the pipelines, and we need to fix a new release.

Then I have one more comment before this is frozen: I think it would make more sense to store a height parameter instead of the cathode position. The readout position (TVector), normal vector and height (along the normal vector) should be enough to completely define the readout in space. We could still support the users to define the readout using a point in the cathode plane but a single parameter height should also be supported (in my opinion) and I think it makes more sense to store it as a single parameter. Also I am not sure I like the idea of naming the opposite plane to the readout as "cathode" as not all readouts use drift for reading (light?) we should perhaps use more generic words.

I agree, the cathode can just disappear.

We can just call it fDriftDistance? But that would be not generic. Perhaps fActiveVolumeHeight?

@lobis
Copy link
Member

lobis commented Jun 8, 2023

I am confused, should we not use #85 for these changes? should I just close it?

No, just merge it, I wanted to create a reduced one with the final metadata members (without final implementation) we will need for the readout. Because readouts need to be regenerated with the new metadata members for the pipelines, and we need to fix a new release.

Then I have one more comment before this is frozen: I think it would make more sense to store a height parameter instead of the cathode position. The readout position (TVector), normal vector and height (along the normal vector) should be enough to completely define the readout in space. We could still support the users to define the readout using a point in the cathode plane but a single parameter height should also be supported (in my opinion) and I think it makes more sense to store it as a single parameter. Also I am not sure I like the idea of naming the opposite plane to the readout as "cathode" as not all readouts use drift for reading (light?) we should perhaps use more generic words.

I agree, the cathode can just disappear.

We can just call it fDriftDistance? But that would be not generic. Perhaps fActiveVolumeHeight?

I think perhaps fHeight should be clear enough.

@jgalan
Copy link
Member Author

jgalan commented Jun 8, 2023

From this point I expect we are not going to modify any more the data members, so I use the version at this point to regenerate validation readouts. TREX-DM, etc.

@@ -504,7 +504,8 @@ void TRestDetectorReadoutPlane::UpdateAxes() { // idempotent
}

void TRestDetectorReadoutPlane::SetRotation(Double_t radians) {
fRotation = radians;
// sets fRotation modulo 2pi
fRotation = TVector2::Phi_0_2pi(radians);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In principle, why radians would be above 2PI? It could be a way to identify a problem. For example if I do something like plane->SetRotation(180) I will see soon that when transforming to degrees somewhere else in the code, the value is out of range.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could add a warning then whenever it goes over 2pi. I think it makes more sense to store rotation between 0 and 2pi in general (not just in this class).

@@ -523,3 +523,17 @@ TVector3 TRestDetectorReadoutPlane::GetPositionInWorld(const TVector2& point, Do
Double_t TRestDetectorReadoutPlane::GetDistanceToPlane(const TVector3& point) const {
return (point - fPosition).Dot(fNormal);
}

void TRestDetectorReadoutPlane::SetAxisX(const TVector3& axis) {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When or why we want to do this?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It could be useful for testing for example.

@jgalan
Copy link
Member Author

jgalan commented Jun 14, 2023

Ok pipeline is now green. It means that now I have to get back to master on the framework validation?

I understand the pipeline will fail, but once the PR is merged we are back to normal.

Also rest-for-physics/framework#438 is green

@jgalan jgalan merged commit 11822a7 into master Jun 14, 2023
@jgalan jgalan deleted the jgalan-readoutplane-update branch June 14, 2023 10:26
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