Mu2eKinKal passive material definition

[RobMina]

Define passive material (DS and concrete) used by KinKal for extrapolating tracks to the CRV.

This PR contains the material definitions and geometry setup, not the intersection calculation and handling (which will be in a subsequent PR). Therefore, the track extrapolation itself is unchanged relative to the current head.

[FNALbuild]

Hi @RobMina,
You have proposed changes to files in these packages:

• TrackerConditions
• DataProducts
• GeometryService
• Mu2eKinKal
• KinKalGeom

which require these tests: build.

@Mu2e/fnalbuild-users, @Mu2e/write have access to CI actions on main.

📝 The author of this pull request is not a member of the Mu2e github organisation.

About FNALbuild. Code review on Mu2e/Offline.

[brownd1978]

This is really nice work, I just have a few questions about optimizing the implementation.

[brownd1978]

This is a useful new function, but it relies on the default KinKal energy loss to be moyal mean. A better solution is to code the unrestricted ionization mean directly, inside KinKal.

[RobMina]

Hi Dave, I've added a check that the KinKal energy loss is configured to use moyal mean so that this scaling is only ever applied in that case. That should maintain consistency on the Offline side until the KinKal update is in and available on cvmfs to build against.

[brownd1978]

Thanks for this check. I agree with the AI that this block should be flagged as temporary, pending moving it to KinKal.

[RobMina]

Hi @brownd1978 , I modified the implementation of KinKalGeomMaker to use the GeometryService objects, so SimpleConfig is no longer parsed there.

[oksuzian]

Issues found

1. applyBetheCorrection() is plumbed through but the correction is dead in the current head — silently.
KKMaterial::applyBetheCorrection() returns betheCorrection_, set true only when elossmode_ == moyalmean. That's the right safety gate. But since this PR explicitly doesn't add the passive-material intersection handling yet, the only consumers are the existing IPA/ST/CRV xings. If the default eloss mode isn't moyalmean, the new bool argument threads through every KKShellXing ctor and does nothing. That's fine functionally, but there is no warning/log anywhere telling the user the correction they added code for is inactive. Consider a one-time mf::LogInfo when betheCorrection_ is false, so this doesn't get silently lost when the concrete planes land in the follow-up PR.

2. betheCorrectionFactor re-implements KinKal internals and will silently drift. In Mu2eKinKal/inc/KKShellXing.hh:

  inline double betheCorrectionFactor(MatEnv::DetMaterial const& mat, double mom, double pathlen, double mass) {
    ...
    double const Tmax  = 2.0*me*bg2/(1.0 + 2.0*gamma*me/mass + (me/mass)*(me/mass));
    double const delta = mat.densityCorrection(bg2);        // same density-effect KinKal uses
    double const meanChange = -xi*( std::log(2.0*me*bg2/I) + std::log(Tmax/I) - 2.0*beta2 - delta );

This hand-rolls the unrestricted Bethe mean using eloss_xi, eexc, densityCorrection pulled out of DetMaterial. Two concerns:

• It omits the shell correction (shellCorrection) that KinKal's own ionizationEnergyLossMPV includes. For the low-bg2 regime that matters; for the ~100 MeV electrons/muons here it's small, but the ratio f is then not a clean "same physics minus the restriction," so the comment "same density-effect KinKal uses" is only half-true.
• This is exactly what maintainer @brownd1978 objected to: "A better solution is to code the unrestricted ionization mean directly, inside KinKal." The author's reply acknowledges this is a stopgap until KinKal is updated on cvmfs. Worth an explicit // TODO(remove once KinKal provides unrestricted mean) in the code (not just the PR thread) so the temporary path is findable.

3. Early-return inside the Type-2 block can skip all later regions. In makePassiveMaterials (KinKalGeomMaker.cc):

    if(nType2 > 0) {
      std::vector<double> uVerts = vertsOf(2,true), vVerts = vertsOf(2,false);
      if(uVerts.empty() || vVerts.empty()) return;   // <-- returns from the whole function

If Type-2 exists but has degenerate/empty outlines, this return bails out of makePassiveMaterials entirely, skipping the side walls, other roof types, and endcap. It should break/skip the Type-2 block, not abandon everything downstream. Same pattern to double-check at line 538 (if(nfound == 0) return;).

4. invSqrt3 is computed but unused in makePassiveMaterials. Line 420 declares double const invSqrt3 = 1.0/std::sqrt(3.0); at function scope, but the Type-2 block re-uses it while addConcretePlane has its own local copy. Harmless, but the function-scope one is only used inside the Type-2 if; verify it isn't a leftover (-Wunused won't catch it since it is referenced at line 556). Minor.

5. Magic numbers vs. comments. The comments carry the run-2 expected values (e.g. 449.7, 680.8, -3904), and the code derives them from config — good. But several call sites reuse vHalf(2)/lenHalf(2)/uHalf(2) as the roof thickness/extent for other types (4, 9, 10, 23, 29, 30). If Type-2 is ever zeroed but those types aren't, roofYhalfThick = vHalf(2) becomes 0 and those roof slabs get zero thickness. The run-1 fallback only triggers on nBoxOf(2) <= 0, so a partial config could produce zero-thickness planes rather than a clean skip. Worth a guard.

6. MaterialsList.data — trailing NbTi element flag change. The NbTi line changed from 0.65 Niobium 0.35 Titanium 0 to 0.65 Niobium 0 0.35 Titanium 0 ..., and every DS material gained per-element 0/1 flags. This is a format change to a widely-shared conditions file. Confirm the parser interprets the inserted flags as intended (Niobium 0, Titanium 0) and that no other client of NbTi/DSSStainless breaks — this file isn't Mu2eKinKal-only.

[brownd1978]

Thanks for modifying the shielding block code to use GeometryService objects. Aside from a few quibbles this all looks good now.
Once merged, please open an issue regarding moving the total energy calculation to KinKal proper.

[brownd1978]

Thanks for this check. I agree with the AI that this block should be flagged as temporary, pending moving it to KinKal.

[brownd1978]

This material is defined but never used (Aluminum element is used instead).