← tgeo-material  ·  part 1: the 2-point functions

Where the material is: composition, endcaps, and a hunt for a service chimney

CMS Phase-2 cmsSimGeom-Run4D123.root · ROOT 6.41.01 · 9 September 2026 · follow-up to part 1

Part 1 measured how much material sits between two tracker layers. That immediately raises the question of what it is and where it sits — is the budget in the layers themselves or in the gaps, is it silicon or cabling, and does the endcap behave like the barrel? This page answers those, plus a hunt for an azimuthally localised service shaft, which came back negative for an interesting reason and turned up a ROOT bug on the way.

1. Where the material sits

Before any correlator, the plain question: what does the material distribution look like? Shooting one radial ray per (z, φ) cell and splitting each step exactly across r bins gives the density field ⟨1/X₀⟩ per cm, of which the φ-average is the structural overview.

2. In the layers, or between them?

Tile the radius as [L1 body][gap][L2 body][gap]…[BTL body], using each layer's own envelope. Layers and gaps then add to the whole thing with nothing missing. At |z| < 15 cm:

What it is made of

The headline split hides the more useful fact. The BTL alone is 0.364 of the 0.626 in-layer total, and it is 58% active LYSO. Take it out and the picture inverts: in the tracker proper the sensors contribute 0.047 against 0.214 for module and readout material. Inside a single inner-tracker layer the sensor is about 8.5% of that layer's budget and the hybrid/chip mixture is about 91%. So "silicon plus carbon fibre" is not the right mental model for a tracker layer — overwhelmingly it is readout electronics.

The classification uses CMS's own composite names, which carry the role (servicecomposite, supportcomposite, hybridcomposite, tkLayout_SenSi), so it is their labelling rather than ours. Two honest caveats: hybridcomposite…ModuleSupportPlate is mechanically support despite the prefix and is counted with the module mixture, where it is the single largest entry; and servicecomposite is cables and cooling blended together and cannot be separated at this level.

3. Layer centroids

Part 1 anchored the correlators at each layer's mid-envelope radius. The physically right anchor is the material centroid — the x/X₀-weighted mean radius within the envelope — and the two are not the same:

The inner tracker is off by a uniform 2.5 mm, which largely cancels when you take the difference between two layers. TB2S (OT4–OT6) is exact to a fraction of a millimetre. The one that matters is TBPS, and OT1 in particular, where the centroid is 2.1 cm inside the mid-envelope radius: those envelopes are 8 cm thick and the material sits in the inner part. A layer-to-layer parametrisation intended for a track fitter should be anchored to the centroid column, not the mid-envelope one.

4. Where the services enter

A radial scan through the barrel at z ≈ 0 sees almost no service material — 3% of the budget. That is not because there is little of it, but because services run longitudinally and turn outward only at the ends of the barrels. Integrated over r < 125 cm:

Four times more service material at large |z| than in the barrel core, and beyond z ≈ 255 cm — past the last sensors — services and support are essentially all that is left.

5. The endcap, away from the transition

The direct analogue of the barrel correlator with r and z swapped. A path runs from a point on disc A to a point on disc B,

A = (r_A, phi_A, z_A)  ->  B = (r_A + dr, phi_A + dphi, z_B)

and G(r_A, Δφ, Δr) is φ-averaged with r_A kept as an axis, for the same reason z_A is kept in the barrel: disc material varies strongly along it. Pairs are chosen clear of the barrel/endcap transition — TFPX discs 5–8 (global z = 67–140 cm), TEPX 9–12 (175–265), TEDD 3–5 (185–265).

A disc-to-disc step costs 0.037–0.049 X₀: two to three times an inner-barrel layer step (0.016–0.022), and comparable to the outer barrel pairs. Per measurement, the endcap is materially the expensive place to be.

6. Hunting a service chimney

The tracker services have to leave the volume somewhere, and a plausible picture is a localised shaft at one azimuth. We looked for it and did not find one. The evidence:

• Inside the tracker (r < 125 cm), the radially integrated budget varies over φ by at most a factor 1.64 at any z, and the worst cases are broad quarter-azimuth modulations, not spikes.
• In the IT–OT service annulus (16 < r < 30 cm) the modulation is stronger, max/median 2–3. But a Fourier decomposition of the azimuthal profile is dominated by n = 18 at 37–47% amplitude, with a subharmonic at n = 9. That is eighteen service bundles spaced around the azimuth — periodic structure, not a shaft. (With 120 φ samples, harmonics above n = 60 would alias; nothing suggests they are present.)
• Where the services actually exit we found ectkcable:, the tracker PP1 cable cone, spanning |z| = 271–329 cm and r = 124–178 cm. It is enormously dense — 8.4 X₀ traversed radially, dominated by stainless steel — but over a 180-point azimuthal scan its max/median is 1.1. Uniform.

The only genuinely narrow azimuthal features in that region are two 10-degree aluminium wedges, ectkcable:ETSU at φ = 355°–5° and its 180-degree mirror, which are structural spurs inside the cone and carry no budget excess relative to the cable sectors around them.

So: a dense service cone, yes, and one that any forward track pays for heavily. A localised service chimney, no — not in this geometry. What this does not exclude is r > 350 cm, outside the tracker, where the scan is blocked by the crash described next.

7. A ROOT bug found on the way

The trigger here is ectkcable:ETSU, the PP1 wedge, which packs three degeneracies into one shape: a plane where rmin == rmax, and two pairs of z-planes at identical z — combined with a 10-degree φ wedge and a strongly flaring cone (rmin₂ = 140.5 > rmax₁ = 128.3).

The φ dependence is sharp and reproducible: a radial ray at z = 290 cm survives at φ = 0 and dies at φ = 5°, exactly the wedge's phi1 + dphi. Offsetting the sampling off the 5-degree boundaries lets a full 180-point azimuthal scan run clean, which is the workaround used for the numbers above. A single ray at the failing (z, φ) does not always die, which initially made it look like accumulated state corruption; it is not, it is purely whether that ray lands on the boundary.

Suggested fix: convert both recursions in TGeoPcon::DistFromInside to a loop with an iteration cap and return the accumulated distance when the cap is hit. That turns an unrecoverable stack overflow into a bounded, slightly-wrong answer — the usual TGeo failure mode for degenerate input, and much preferable in a scanning application. It may also be worth warning at construction about Pcon planes with rmin == rmax or repeated z. Full writeup with a reproducer is in BUG-TGeoPcon-DistFromInside-recursion.md alongside the code.

Reproducing

source ./renv.sh
root -l -b -q run_matfield.C     # the density field and its projections
root -l -b -q run_endcap.C       # the disc-to-disc correlators

root -l
.L mat_budget.C+
mb_init();
mb_census(15.0, 256);            # the layer/gap table and centroids
mb_draw_census(15.0, 256);       # the composition figure
mb_class_vs_z(0, 125, 30, 0, 300);   # services vs z
mb_hunt_phi(350, 25, 40, -300, 300, 180);   # the azimuthal hunt