Our GBL track fits have strange looking covariance matrices at the USBPix FEI4 plane (placed just before the last MIMOSA plane) and at the last Mimosa plane. The resolutions (square root of leading diagonal of the cov matrix) are very big.
When we print out the resolution from a GBL routine, it has x and y swapped, and is 1/sqrt(12) of the pixel dimensions. So maybe this is the cause of the Changing the resolution in the geometry config file has no effect. (Changing which way round rows/cols are and their sizes does have an effect).
How do we change the resolution of our USBPix? Do we have to do something special in the geometry file?
Any idea where it is taken from?
Hi Nigel,
would you mind sharing your configuration files (geometry & main config) so we can have a look?
Thanks,
Simon
Cannot attach .conf files here, so copying and pasting:
[Corryvreckan]
log_level = “FATAL”
log_format = “DEFAULT”
log_file = ‘logs/log_corry’
#number_of_events = 10
[EventLoaderEUDAQ2]
name = “TLU_0”
get_time_residuals = true
adjust_event_times = [[“TluRawDataEvent”, -1us, +1us]]
[EventLoaderEUDAQ2]
[ClusteringSpatial]
charge_weighting = false
use_trigger_timestamp = false
use_earliest_pixel = false
use_mean_timestamp = true
[Correlations]
make_correlations = true
[Tracking4D]
momentum = 5.0GeV
max_plot_chi2 = 30
spatial_cut_abs = 200um,500um
min_hits_on_track = 7
time_cut_abs = 200us
track_model = “gbl”
exclude_dut = true
require_detectors = “USBPIXI4_10”
[DUTAssociation]
name = “ABC_31”
#type = “its_abc”
time_cut_abs = 230us
spatial_cut_abs = 0.3mrad, 20mm
use_cluster_centre = true
use_ellipse = false
range_x = 20mrad
range_y = 10mm
[AlignmentDUTResidual]
#log_level = “INFO”
name = “ABC_31”
#type = “its_abc”
iterations = 1
align_position = false
align_orientation = false
align_orientation_axes = z
max_associated_clusters = 3
max_track_chi2ndof = 30
#prune_tracks = false
range_x = 10mrad
range_y = 20mm
[AnalysisItkStripEfficiency]
name = “ABC_31”
#type = “its_abc”
perimeter_exclude = 0
#chi2ndof_cut = 2 #ORIGINAL. CHANGED BY G.JAIN.
chi2ndof_cut = 0.2
inpixel_bin_size = 75.5um
delay_cuts = 15, 12
[TLU_0]
orientation = 0,0,0
orientation_mode = “xyz”
position = 0,0,0
role = “auxiliary”
time_resolution = 1s
type = “tlu”
[MIMOSA26_0]
material_budget = 0.00075
number_of_pixels = 1152,576
orientation = 0,0,0
orientation_mode = “xyz”
pixel_pitch = 18.4um,18.4um
position = 0,0,0
spatial_resolution = 5.32um,5.32um
time_resolution = 230us
role = “reference”
type = “mimosa26”
[MIMOSA26_1]
material_budget = 0.00075
number_of_pixels = 1152,576
orientation = 1.67613deg,-0.194978deg,-0.447709deg
orientation_mode = “xyz”
pixel_pitch = 18.4um,18.4um
position = 0um,0um,148mm
spatial_resolution = 5.32um,5.32um
time_resolution = 230us
type = “mimosa26”
[MIMOSA26_2]
material_budget = 0.00075
number_of_pixels = 1152,576
orientation = 2.10493deg,-0.253878deg,0.15361deg
orientation_mode = “xyz”
pixel_pitch = 18.4um,18.4um
position = 0um,0um,289mm
spatial_resolution = 5.32um,5.32um
time_resolution = 230us
type = “mimosa26”
[ABC_31]
material_budget = 0.05
#material_budget = 0.1 #19dec
coordinates = “polar”
number_of_strips = 1536,1
order = 0
orientation = 0,0,0.0deg
orientation_mode = “xyz”
pixel_pitch = 0.15471mrad,18.1mm
position = 0mm,0mm,409mm
spatial_resolution = 0.0433188mrad,5.068mm
r_center = 534.639mm
r_max = 507.916mm
r_min = 489.823mm
role = “dut”
stereo_angle = 20mrad
time_resolution = 400us
type = “its_abc”
[MIMOSA26_3]
material_budget = 0.00075
number_of_pixels = 1152,576
orientation = 1.80579deg,-0.274447deg,-0.204317deg
orientation_mode = “xyz”
pixel_pitch = 18.4um,18.4um
position = 0um,0um,535mm
spatial_resolution = 5.32um,5.32um
time_resolution = 230us
type = “mimosa26”
[MIMOSA26_4]
material_budget = 0.00075
number_of_pixels = 1152,576
orientation = -1.64828deg,0.653573deg,0.0704738deg
orientation_mode = “xyz”
pixel_pitch = 18.4um,18.4um
position = 0um,0um,667mm
spatial_resolution = 5.32um,5.32um
time_resolution = 230us
type = “mimosa26”
[USBPIXI4_10]
material_budget = 0.00075
#material_budget = 0.02
number_of_pixels = 336,80
orientation = 0.499505deg,182.272deg,-0.509073deg
orientation_mode = “xyz”
pixel_pitch = 50um,250um
position = 0mm,0um,798mm
spatial_resolution = 14.44um,72.17um
time_resolution = 230us
type = “usbpixi4”
[MIMOSA26_5]
material_budget = 0.00075
number_of_pixels = 1152,576
orientation = 1.80121deg,-1.32164deg,-0.0503057deg
orientation_mode = “xyz”
pixel_pitch = 18.4um,18.4um
position = 0um,0um,818mm
spatial_resolution = 5.32um,5.32um
time_resolution = 230us
type = “mimosa26”
Simon
Geetika Jain is doing the analysis.
When she changes the resolution of the USBPix, and asks GBL track for
the resolution, it has no effect. She says:
“gblErrorsMeasurements under the traj.getMeasResults tag displays pixel_size/sqrt(12), irrespective of the resolutions mentioned in the geometry config file.”.
Changing the resolution does however affect other things, like chiSq of the fit.
Hi @hessey
that’s curious, we do use the uncertainty of the cluster as the measurement uncertainty, see here:
// Uncertainty of single hit in local coordinates
Eigen::Matrix2d covv = Eigen::Matrix2d::Identity();
covv(0, 0) = 1. / cluster->errorX() / cluster->errorX();
covv(1, 1) = 1. / cluster->errorY() / cluster->errorY();
pt.addMeasurement(initialResidual, covv);
The cluster uncertainty itself is set from the resolution configured in the geometry file here:
// Set uncertainty on position from intrinsic detector spatial resolution:
cluster->setError(m_detector->getSpatialResolution(column, row));
cluster->setErrorMatrixGlobal(m_detector->getSpatialResolutionMatrixGlobal(column, row));
so I really wouldn’t see why this doesn’t have an effect. Maybe @lhuth has an idea?
/Simon
Hi,
that’s super odd. I gave it a try and changed the resolution in an example config and do see the difference in the GBL covariance matrix.
Are you using the current master of corry?
Best,
Lennart
Not sure if we are using master of corry. We are on a branch called Jonas-work.
We do see effects in the covariance matrix when we change the resolution. But not in the result of calling getMeasResults(…) in GblTrajectory.cpp
Our set up along the beam direction is 3 Mimosas, DUT, 2 Mimosas, USBPix, last Mimosa. The covariance matrix at the first 6 planes look good. But for the USBPix and last Mimosa, the diagonal elements get very big. (sqrt(diagonal) ~50 microns for x and y in first 6 planes jumps to 300 microns for last two planes).
While trying to understand that, we noticed that the result of getMeasResults for USBPix resolution gives (72 um x, 14 um y) – which looks the wrong way round: USBPix has 250 um x 50 um pixels, with the 50 in the precision direction, aligned with x, so expect 1/sqrt(12) giving (14, 72) um.
So we tried swapping the order in the geometry file, but nothing changed here. They remain “the wrong way round”.
Things are confusing: for some reason, the USBPix x and y coords are swapped when making a standard plane. So it is not entirely clear which way round these errors should be. But still, if we swap the resolutions in the geometry file I would expect that to be reflected here. We also multiplied the resolutions by 10, nothing changed here.
We are currently removing the x-y swapping, changing the geom file, changing the big rotations (90 deg, 180 deg I mean), re-aligning, and seeing what happens.
Hi @hessey
I hope that you understand that we have a hard time providing support for a code that we don’t know and have never read. In our code there is not even any direct access to the GBL trajectory, so there must be quite some changes in your derivative.
So we tried swapping the order in the geometry file, but nothing changed here. They remain “the wrong way round”.
The order in the geometry file has no relevance (in the official code that is) since detectors are ordered by z position.
Things are confusing: for some reason, the USBPix x and y coords are swapped when making a standard plane.
I am not entirely sure what you are referring to with “standard plane” here, it sounds like a EUDAQ term, which would place the problem in your decoder in EUDAQ2.
Maybe you could try to use the official Corryvreckan version and upstream the relevant changes you have? That would also mean they get a proper code review and we can ensure that they work as intended with the rest of the framework.
Best,
Simon
I will look into getting Geetika to switch to master. But I am sure nothing changed in the GBL library. And the master version also has access to the resolution of the track at a given plane, see line 846 in corryvreckan/GblTrajectory.cpp at master · simonspa/corryvreckan · GitHub
The swap is not in the order of planes in z, but in the order of (sigma-x, sigma-y) resolution in the geometry file.
Yes, Standard Plane is an EUDAQ term. We have removed the swap, and are seeing if that fixes things.
Hi @hessey
that’s not what I meant - of course the code has access to GBL public methods, of course, but the user does normally not. Hence, you are altering code in the tracking class - and then it’s really hard to tell what goes wrong without looking at the code. 
Cheers,
Simon
Hello Simon
To re-iterate,
the output of the gblErrorsMeasurements parameter under the traj.getMeasResults tag (called within the ‘fit’ function of the GblTrack class) is always displayed as (pixelXsize/sqrt(12), pixelYsize/sqrt(12)), irrespective of the resolutions mentioned in the geometry config file.
We expected this parameter to reflect the resolutions as put in into the config file.
But since that is not happening, therefore the question.
Why or for what would GBL calculate pixelsize/sqrt(12)? If default set, then even with resolutions written in on the config file, the default seems to override.
Or,
Is this how gblErrorsMeasurements under traj.getMeasResults is defined - as a fixed quantity, i.e. pixelsize/sqrt(12)? And this is not the parameter that is used during chi2 calculation.??!
Hello @gjain,
To re-iterate on Simons arguments:
- We cannot reproduce this effect in the current master. I’ve tested different sensors, rotations and resolutions in the geometry.
- You are using a corryvreckan version that has diverge from the master since a) you access a parameter that we do not provide access to in neither the
GBLTrackor any module and b) @hessey stated that you are on a branch called Jonas Work. We might had some bugs in the tracking code that have been fixed after your code might have diverged. - All uncertainties in GBL have to be provided in local coordinates. So I do expect to always get local x and y errors, defined by your col/row errors, which I also get
- We use the GBL as an external library to ink against and provide all information to the
GBLTrackin theTrackin4Dmodule. Here we define, as Simon stated
// Uncertainty of single hit in local coordinates
Eigen::Matrix2d covv = Eigen::Matrix2d::Identity();
covv(0, 0) = 1. / cluster->errorX() / cluster->errorX();
covv(1, 1) = 1. / cluster->errorY() / cluster->errorY();
pt.addMeasurement(initialResidual, covv);
The values from the geometry are correctly returned after fitting. This can be checked via
LOG(TRACE) << "Results for detector " << name << std::endl
<< "Fitted residual local:\t" << residual_local_.at(name) << std::endl
<< "Seed residual:\t" << initital_residual_.at(name) << std::endl
<< "Fitted residual global:\t" << ROOT::Math::XYPoint(clusterPos - corPos) <<std::endl
<< "error: "<< gblErrorsMeasurements;// <- This needs to be added to master
in the GBLTRack
- We are pretty confident, that this is functional, but are happy to retrieve any input if you find issues on the current master.
GBL is not calculating any pixel size/error at all, but takes it as an input. The GBL library is only implementing the math - everything also has to be done in user code.
Same here - we do not manually calculate any chi2, but let the GBL library do the work for us. If you believe that something is wrong there you need to contact the GBL authors: Home · Wiki · Claus Kleinwort / General Broken Lines · GitLab
Cheers, Lennart