Home » PANDA » PandaRoot » EMC » failure of QA macro of EMC reconstruction
|
|
|
|
|
|
|
|
| Re: failure of QA macro of EMC reconstruction [message #9877 is a reply to message #9876] |
Sun, 06 December 2009 00:35   |
Johan Messchendorp
Messages: 693
Registered: April 2007
Location: University of Groningen
|
first-grade participant |
From: *xs4all.nl
|
|
Hi,
I only checked the spectra on one of the machines (suse-enterprise, gcc4.3.2, 64-bit, rev. 7276). The QA checks report problems on most of the other machines as well, with all a positive shift in delta-phi (albeit all small). I changed the QA macro now with 1000 events, which for the average one should get a very precise number. There might be a logic mistake in the macro, but to me it looked fine. Could you take a look at QAmacro_emc_3.C and maybe try to run it with high statistics on your machine?
Actually, looking at your PDF file, I do see a statistically significant shift in the mean of delta-phi as well, also positive.
Greetings,
Johan
[Updated on: Sun, 06 December 2009 00:45] Report message to a moderator |
|
|
|
| Re: failure of QA macro of EMC reconstruction [message #9879 is a reply to message #9877] |
Sun, 06 December 2009 12:00 |
mpeliz
Messages: 51
Registered: February 2008
Location: Ruhr-Universitaet Bochum
|
continuous participant |
From: *dip.t-dialin.net
|
|
Hello,
looking to the standard macros in the emc directory
it seems that for the geometry used in the qa macros
the mapper version 6 should be used, e.g.
macro/emc/sim_emc.C: Emc->SetGeometryFileNameTriple("emc_module125.dat","emc_module3new.root ","emc_module4_StraightGeo24.4.root"); //MapperVersion: 6
while the mapper for the 3rd macro is instantiated with version number 2
macro/qa/emc/QAmacro_emc_3.C: PndEmcMapper *emcMap=PndEmcMapper::Instance(2);
I do not know if this causes the problem, but it is inconsistent anyway. Since Johan has simulated and digitized 10k events, could you try to run the reconstruction with a consistent setting of the mapper and see if this changes anything?
Another point to check might be the latest changes for the PndEmcStructure and PndEmcXtal classes announced recently by Ola and Elwin on this forum. But this is just a wild guess, since we do not know at which point the error did not occur. Maybe it was even present at Dubna, 2.5 years ago.
Best regards,
Marc
|
|
|
|
|
|
|
|
| Re: failure of QA macro of EMC reconstruction [message #9884 is a reply to message #9881] |
Sun, 06 December 2009 14:32 |
Elwin Dijck
Messages: 16
Registered: June 2009
Location: Groningen, The Netherland...
|
occasional visitor |
From: *mxp.dsl.internl.net
|
|
Hi all,
I think the macros/mapper versions etc. are alright and the shift is caused by incorrect handling of the skewed shapes of the barrel crystals.
In my changes to the PndEmcXtal class, I changed PndEmcXtal::frontCentre to properly take the skewing of crystals into account (ie. cases where the parameters phi and theta of TGeoTrap are non-zero). To show that the skewed shapes can result in the observed phi-shift, here is a plot of the phi-difference between the center of the front face and the center of the crystal as a function of theta (the normals of the front faces of the crystals all point towards the target). It looks similar to the theta-dependence of the shift.
Interesting from the QA test results is that the sign of the shift seems to have flipped around November 24 when my changes to the PndEmcXtal class were commited. I think the origin of the problem is in PndEmcDigi::depthPosition. Before my changes the result was wrong, and afterwards it was still wrong but in a different way. The main problem is that for the skewed TGeoTraps, the front face normal vector and crystal axis vector are not the same, which PndEmcDigi::depthPosition doesn't take into account. Thus PndEmcDigi::depthPosition that uses the front face normal does not return a position that lies on the central axis of the crystal.
I think the shift can be fixed by adding another parameter to PndEmcXtal that returns the unit vector in the direction of the central axis of the crystal and using that in the digi position calculation. Since my changes this vector is already calculated in the PndEmcXtal constructor anyway, it only needs to be accessable. See the attached files for changes in the code.
svn diffs
Index: PndEmcXtal.h
===================================================================
--- PndEmcXtal.h (revision 7277)
+++ PndEmcXtal.h (working copy)
@@ -52,6 +52,7 @@
const TVector3& centre() const;
const TVector3& frontCentre() const;
const TVector3& normalToFrontFace() const ;
+ const TVector3& axisVector() const;
const TGeoTrap& geometry() const;
const TGeoRotation& rotation() const;
@@ -66,6 +67,7 @@
TVector3 fCentre;
TVector3 fFrontCentre;
TVector3 fNormalToFrontFace;
+ TVector3 fAxis;
ClassDef(PndEmcXtal,1)
};
Index: PndEmcXtal.cxx
===================================================================
--- PndEmcXtal.cxx (revision 7277)
+++ PndEmcXtal.cxx (working copy)
@@ -70,12 +70,14 @@
fFrontCentre = pos + axis_vector;
fNormalToFrontFace = -1.0 * normal_vector;
+ fAxis = -1.0 * axis_vector.Unit();
} else {
//cout << "Crystal orientation in module " << id->Index() / 100000000
// << " -dz" << endl;
fFrontCentre = pos - axis_vector;
fNormalToFrontFace = +1.0 * normal_vector;
+ fAxis = +1.0 * axis_vector.Unit();
}
}
@@ -137,6 +139,12 @@
return fNormalToFrontFace;
}
+const TVector3&
+PndEmcXtal::axisVector() const
+{
+ return fAxis;
+}
+
const TGeoTrap&
PndEmcXtal::geometry() const
{
Index: ../EmcData/PndEmcDigi.cxx
===================================================================
--- ../EmcData/PndEmcDigi.cxx (revision 7277)
+++ ../EmcData/PndEmcDigi.cxx (working copy)
@@ -117,7 +117,7 @@
//cout << "depth" << endl;
TVector3 pos = xtal->frontCentre();
- TVector3 norm=xtal->normalToFrontFace();
+ TVector3 norm = xtal->axisVector();
norm*=fPositionDepth;
pos += norm;
I haven't fully tested this, but here are some results for 500 photons @ theta = 90 degrees (1 GeV) where the shift is biggest. Black - old code (negative phi shift), blue - after my changes to PndEmcXtal (positive phi shift), red - using axis vector (phi shift seems mostly gone).
Could someone properly check whether this really helps?
Best regards,
Elwin Dijck
-
Attachment: skewing.gif
(Size: 8.56KB, Downloaded 738 times)
-
Attachment: test.gif
(Size: 10.73KB, Downloaded 682 times)
-
Attachment: PndEmcXtal.h
(Size: 1.89KB, Downloaded 291 times)
-
Attachment: PndEmcXtal.cxx
(Size: 3.81KB, Downloaded 298 times)
-
Attachment: PndEmcDigi.cxx
(Size: 7.58KB, Downloaded 350 times)
[Updated on: Sun, 06 December 2009 15:14] Report message to a moderator |
|
|
|
|
|
|
|
| Re: failure of QA macro of EMC reconstruction [message #9887 is a reply to message #9886] |
Sun, 06 December 2009 17:49 |
Elwin Dijck
Messages: 16
Registered: June 2009
Location: Groningen, The Netherland...
|
occasional visitor |
From: *mxp.dsl.internl.net
|
|
Good. I expect there can still be a small phi shift in some cases because the actual depth of showers is energy-dependent, while the depth used for reconstruction is constant. The default depth of 6.2 cm seems to work reasonably well, but I guess making this value energy-dependent at some point might further improve the reconstruction, especially at the lowest energies.
[Updated on: Sun, 06 December 2009 17:56] Report message to a moderator |
|
|
|
Goto Forum:
Current Time: Fri Nov 29 14:50:48 CET 2024
Total time taken to generate the page: 0.00869 seconds
|
GSI Forum
Search
Help
Members
Login
Home
