BmnRoot 26.10.0-210-gc52d34b0
Software framework of the BM@N experiment
Loading...
Searching...
No Matches
mp2 Directory Reference

Description

Millepede-II cross-check of BmnAligner

Runs the same alignment task through the pre-compiled Millepede-II (pede) solver, so that its result can be held against the one BmnAligner produces. Reference: https://www.desy.de/~kleinwrt/MP2/doc/html/index.html

Task as configured here: BmnMeasureLin4 track model, BmnRun8TopDM detector model, cnstr_38e_lin4.json constraints, psg_38e_lin4.json pre-sigmas, 7466.noa_rlerr.list dataset.

Toolset

Sources are at /home/igor/millepede-ii (override with MP2SRC), built with a plain make (not make -j: the Fortran module dependencies are not declared, a parallel build fails). run.sh picks pede from $PATH, falling back to the build directory. It is currently on $PATH as ~/.local/bin/pede (a symlink); a genuinely system-wide install needs root:

sudo install -m755 /home/igor/millepede-ii/pede /usr/local/bin/

Run

./run.sh            # whole dataset
./run.sh 20000      # first 20000 tracks, for a quick check

Everything lands in out/:

file what
mp2mille.bin binary records, one local fit (track) per record
mp2par.txt initial values and pre-sigmas of the global parameters
mp2con.txt linear equality constraints
mp2steer.txt steering file
mp2labels.txt label → element/composite + parameter (not read by pede)
millepede.res pede result: value, pre-sigma, difference, error per label
sl.mp2.json the same result as a BmnAligner solution file

sl.mp2.json is what makes the two comparable: it has the format BmnAligner::LoadSolution() reads, so the millepede solution can be loaded into the ordinary machinery (or fed to reconstruction) like any other.

How the task is translated

Parameters. BmnMeasureLin4 leaves phi and theta without effect. Rather than carrying them and fixing them by constraints - which is what BmnAligner has to do, its parameter vector being fixed at 6 - they simply do not exist here: pede only knows parameters that appear in the binary file. The 98 constraints of cnstr_38e_lin4.json that only fix phi/theta are therefore dropped (they are reported as skipped), leaving the 4 that carry physics. 38 elements + 11 station halves, 4 parameters each = 196 global parameters.

Hierarchy. The two levels of BmnAlignHierarchy are expressed the way Millepede does hierarchies: each measurement carries every derivative twice, once against the element's own parameter and once against the same parameter of the owning station half. That is exact for these four parameters - the propagation Jacobian J is the identity for dX/dY/dZ/psi once the composite pivot sits on the beam axis, which is the pivot default the detector models use. Constraint coefficients written on elements are promoted to the composites accordingly (the J^T c_leaf term of PromoteConstraints), so they keep constraining the effective correction.

Local fits. One record per track, 4 local parameters. Measurements go in unmodified (no reference trajectory subtraction): the model is linear in the local parameters, so pede refits them itself. The global derivatives do need a reference track, and it is the same weighted straight-line fit BmnAligner starts from (LinRegressionAlphaPart), on the nominal geometry. Track selection - min hits, chi2/NDF, ignored elements - is BmnRootIterator's, i.e. identical to the BmnAligner run.

Pre-sigmas. Written into the parameter file, where pede gives them the same meaning: 1/sigma^2 added to the diagonal. Note that BmnAligner scales its own priors by fOmegaScaleFactor because it minimizes a scaled MSE; pede minimizes a proper chi2, so the sigma acts directly.

First run (7466.noa_rlerr, whole dataset)

450917 records, 4856822 measurements, 196 global parameters, 4 constraints, 4 iterations to dF < 1e-3, ~1 min. Sum(Chi^2)/Sum(Ndf) = 2.02, on which pede issues its standard "multiply all input standard deviations by 1.42" warning - the hit errors in the DST are optimistic, which affects the error scale, not the solution.

Against cfg/run8/solutions/sl7644.e38top.00.json (BmnAligner, same task), per element, effective corrections:

mean diff rms max abs
dX 0 0.0030 cm 0.0075 cm
dY 0 0.0050 cm 0.0116 cm
dZ 0 0.0373 cm 0.1121 cm
psi 0 0.02 mrad 0.04 mrad

So the two agree on the geometry to well inside the hit resolution, dZ being the weakly determined parameter it always is.

What they do not agree on is how that geometry splits between the two levels: pede puts essentially the whole station-half mean into the composite (element own shares come out at the 1e-4 cm level), which is what the pre-sigmas ask for - the data is blind to the split, so it is decided by minimizing sum_i (A_i - c)^2 / 0.05^2 + c^2 / 0.5^2, whose optimum is c ~ mean(A_i). BmnAligner's composite values are 2-3 times larger, with the element own shares compensating. Worth a look on the BmnAligner side: the split is the one direction its priors constrain only weakly (ApplyPresigmas scales them by fOmegaScaleFactor), so it is also the slowest to converge.

Known differences from BmnAligner

  • No outlier rejection here (BmnAligner drops tracks by OUTLIER_FACTOR in BmnAligner.cxx). For a like-for-like comparison add outlierdownweighting 3 and chiscut 30. 6. to mp2steer.txt - or, better, first check whether the two agree without it.
  • Element errors in sl.mp2.json are the element and composite errors added in quadrature. millepede.res carries no covariance between the two levels, so that number is approximate; the per-label errors in millepede.res are exact.
  • Single iteration of the global fit is not enough if the corrections turn out large: the global derivatives are computed from the nominal-geometry track fit. Re-run mp2prep.C with the solution applied if the result moves anything by much more than the hit resolution.
Directory dependency graph for mp2:

Files

 
mp2prep.C