| Implementing Software Alignment into PandaROOT [message #21666] |
Tue, 24 October 2017 12:04  |
Roman Klasen
Messages: 2
Registered: October 2017
|
occasional visitor |
From: *specf.him.uni-mainz.de
|
|
Hello,
I'm plan to integrate a software alignment framework into PandaRoot. For now, that means that our alignment parameters are stored to transformation matrices that are multiplied to the ideal transformation matrices to simulate a realistic, non-ideally aligned geometry.
As far as I can see, our simulation chain currently works like this:
0. MC tracks are generated by the BoxSim or DPM generator and fired on a geometry that can either be perfectly aligned or realistically misaligned
1. MC hits on the sensors are then digitized in the 1-Digi macro, and digital row, column and sensor ID data are stored to lumi_digi.root
2. The 2-reco macro reads those digi hits and reconstructs the (x,y,z) position in the panda frame of reference assuming an ideal geometry without misalignment. This is done by the PixelClusterTask and more specifically a PndSdsChargeWeightedPixelMapping object
3. Afterwards, our own PndLmdDim class reads this ideal position, and transforms it to a realistically misaligned position using the transformation matrices for the ideal and a real, misaligned geometry (in simulation only, since we obviously don't have those in the actual detector). This could also be where we introduce the alignment parameters found by software alignment.
4. Those hit positions are saved to the reco.root file after they have been transformed from the position they would have been were the geometry perfectly aligned to the position they are in case the geometry suffers from misalignment (the realistic case)
Firstly I'd like to ask if I understood this correctly.
If so, I wanted to ask how other groups are doing this since the PndLmdDim Class is specific to our detector, or if it were better to change this method to actually introduce the misalignment step earlier in the PndSdsChargeWeightedPixelMapping class. That means the reconstructed hits are stored in their realistic, misaligned position by this class directly. Afterwards, a separate aligner class would transform those positions back to the ideal positions using the alignment parameters found by software alignment. It seems the second version is mapping reality more closely and doesn't depend on our PndLmdDim class, so it could be used by other groups as well. But no such aligner class currently exists.
Best wishes,
Roman
|
|
|
|
| Re: Implementing Software Alignment into PandaROOT [message #21696 is a reply to message #21666] |
Fri, 03 November 2017 15:37  |
Stefan Pflueger
Messages: 99
Registered: February 2012
|
continuous participant |
From: *specf.him.uni-mainz.de
|
|
Hello everyone,
Roman and me have done some research and as far as we can understand, the alignment should be handled within the geometry. The difference between data taking of panda and the simulation world are the steps simulation and digitization. After that all other macros/steps are identical for the simulated data and panda data reconstruction.
IMPORTANT: In order to study misalignment TWO geometries are needed! The simulation and digitization steps use one geometry. And a second geometry is used in the further track reconstruction. This geometry is the only one needed later on, but should not necessarily the same as the first geometry. And this second geometry should be determined from the design geometry and corrections that come from the alignment procedures ([design geometry] * [alignment correction matrices] = [simulation/data geometry])!
Now we have a question: Did anyone try or plan for this already or which is the correct way to handle all this? Because in the whole reconstruction chain the geometry is usually just generated once in the simulation step, then saved in a parameter root file. The other macros then read in this parameter file and use it to initialize the RTDB of FairRoot. Consequently the geometry used for the simulation is available again, which is exactly the behaviour we do NOT want for alignment studies!
So our idea would be to NOT read in the parameter file in the macros after the digitization step and just initialize the RTDB with another geometry. Is that correct or possible? Has anyone tried this before?
Thanks in advance!
Stefan
[Updated on: Fri, 03 November 2017 15:38] Report message to a moderator |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
GSI Forum
Search
Help
Members
Login
Home
