You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
As mentioned by @mposik1983 in the tracking meeting on April 4, 2024, we will need to include detector alignment info for a realistic tracking study.
Describe the solution you'd like
No existing effort within ePIC as I know of. Below are suggestions from @osbornjd based on his sPHENIX experience:
we need to develop our own custom detector element class that interfaces with Acts. This will be called instead of the default ACTS based detector element class and will contain the necessary code to determine what the local to global transform should look like. We then need to also create our own custom class that holds the transformation information. Here's the sPHENIX example detector element class. We then have a class which inherits from the Acts::GeometryContext that holds the relevant transform information here. This probably doesn't need to be an inheritance structure thought, since Acts::GeometryContext is just an alias for std::any
Describe alternatives you've considered
N/A Additional context
The actual approach needs to be discussed more in the near future.
The text was updated successfully, but these errors were encountered:
I suppose, we'd need to learn to simulate the misalignment to quantify do studies on the effect of it. That might have to go into the geant geometry instead. From what I understand, Joe's considerations are for implementing the corrections, which is question looking far off into the future.
Is your feature request related to a problem? Please describe.
As mentioned by @mposik1983 in the tracking meeting on April 4, 2024, we will need to include detector alignment info for a realistic tracking study.
Describe the solution you'd like
No existing effort within ePIC as I know of. Below are suggestions from @osbornjd based on his sPHENIX experience:
we need to develop our own custom detector element class that interfaces with Acts. This will be called instead of the default ACTS based detector element class and will contain the necessary code to determine what the local to global transform should look like. We then need to also create our own custom class that holds the transformation information. Here's the sPHENIX example detector element class. We then have a class which inherits from the Acts::GeometryContext that holds the relevant transform information here. This probably doesn't need to be an inheritance structure thought, since Acts::GeometryContext is just an alias for std::any
Describe alternatives you've considered
N/A
Additional context
The actual approach needs to be discussed more in the near future.
The text was updated successfully, but these errors were encountered: