Create condition + accessors + calibration for beam line position
The PV finder needs to know the position of the beam-line. Functors like 'rho' will also be a lot more useful if the beamline is used as a reference (rather than the z-axis.)
Currently, the PV finder accesses the beam line position as
struct Beamline_t {
double X = std::numeric_limits<double>::signaling_NaN();
double Y = std::numeric_limits<double>::signaling_NaN();
Beamline_t( Condition const& c )
: X{( c.param<double>( "ResolPosRC" ) + c.param<double>( "ResolPosLA" ) ) / 2}
, Y{c.param<double>( "ResolPosY" )} {}
};
This relies on the resolver positions telling where the center of the velo is. This involves calibration errors. Next it relies on the beam being in the center of the velo, which is also only approximation.
In LHCb MC the size of the interaction region is about 25 micron in the transverse plane, and about 60 mm along the z-axis. (The average PV resolution is about 15 micron in xy and about 120 micron in z.) Besides the position of the interaction region, also the direction of its major axis is important.
Therefore, we propose to make a new data structure that holds:
- the average position (x,y,z) of the interaction region
- the 'spread' (covariance matrix) V of the interaction region (about 25 micron in x,y, and about 60 mm in z)
- the direction tx, ty of the major axis. To very good approximation these are just tx = Vxz/Vzz and ty = Vyz/Vzz where V is the spread matrix.
This data structure needs to be available in the PV finder, but also in functors that cut on the distance to the beam-line. (BLRHO?)
For the calibration we could write an algorithm that computes
- the average PV position tp extract x,y,z
- the average of PVx (Pvy) in bins of PVz (to extract tx and ty)
- the covariance matrix (just (x - ) (y-) etc) (We can then also check if cov matrix and angles agree.)
Note that since the PV resolution is of the order of the size of the beam in the transverse plane, you would want to select only PVs with small errors (e.g. large number of tracks) for the calibration.
The next question then becomes where we should run it. It could be treated in the same way as the alignment, in the sense that HLT1 uses the calibration from the previous run and HLT2 uses the calibration determined between HLT1 and HLT2 (if that is still the plan.)
In any case, the first thing to do it make sure that TrackVertexMonitor produces plots that allow us to monitor this.