Sometimes kalman filter (the one in main) gets positions way outside tms

[jdkio]

Running ConvertToTMSTree.exe /pnfs/dune/persistent/users/abooth/nd-production/MicroProdN1p2/output/run-spill-build/MicroProdN1p2_NDLAr_1E18_RHC.spill.nu/EDEPSIM_SPILLS/0000000/0000100/MicroProdN1p2_NDLAr_1E18_RHC.spill.nu.0000101.EDEPSIM_SPILLS.root

lol y value outside TMS: 20401.4        TMS: [-3500, 500]
Predicted y value outside TMS: 20401.4  TMS: [-3500, 500]
Material not supported
7

7 is kUnknown in Material.h. Here it is with extra printouts:

lol y value outside TMS: 20401.4        TMS: [-3500, 500]
True x: -3218.99,       Reco x: 5.31348e-310,   True - Reco: -3218.99
True y: -2443.62,       Reco y: 0,      True - Reco: -2443.62
  {x, y, dx/dz, dy/dz, q/p, z} = {-3237.5, -2018.78, 0.142384, 2.28493, 0.00368483, 11588}
  {x, y, dx/dz, dy/dz, q/p, z} = {-3213.75, 20401.4, -5.88605, -256.585, 0.00187467, 11533}
Predicted y value outside TMS: 20401.4  TMS: [-3500, 500]
True x: -3177.95,       Reco x: 5.31348e-310,   True - Reco: -3177.95
True y: -2461.59,       Reco y: 0,      True - Reco: -2461.59
  {x, y, dx/dz, dy/dz, q/p, z} = {-3213.75, 20401.4, -5.88605, -256.585, 0.00187467, 11533}
  {x, y, dx/dz, dy/dz, q/p, z} = {-3166.55, -2362.39, -999.9, -999.9, -0.05, 11478}

This causes issues because Material matter(density); gets a density of 2.82 Made material with unknown fMaterialType, given density 2.82 This causes issues when SetProperties() is run because

        default:
          std::cerr << "Material not supported" << std::endl;
          std::cout << fMaterialType << std::endl;
          throw;

In my kleykamp_issue_158 branch, I'm throwing an error and catching it instead. This prevents the material from being updated in the bethe block calculation. But ideally we fix this so the positions are never outside the TMS in the first place

[AsaNehm]

In this example the x and y value of the reco is 0 (or to a very good approximation). Unlikely but possible. The (assumed) output from the Kalman filter then turns this into something senseful for x and something completely out of bounds for y. So my guess is that something is going wrong there with the Kalman filter which shouldn't be the completely up-to-date version of it afaik

[AsaNehm]

Is this solved with the merge?

[LiamOS]

Not completely I don't think.

[jdkio]

I don't understand the kalman filter. The y value is wrong, but are the steps before it doing something wrong? A kalman track can go outside the TMS if the muon is entering or exiting. But if we used a real hit to make this node, then this node should be constrained in the TMS. If that's the case, then it might help to print the inputs to the calculation and then see what went wrong

Actually, we assign a large y uncertainty to hits, but we know it must be constrained into the active region of the TMS. Can you change the y uncertainty as it gets close to the edge to take this into account? Assuming you can't do a 2 sided uncertainty, always make the y center be +15cm from edge assuming an uncertainty of 30cm

[LiamOS]

Uncertainties have to be Gaussian by construction, and thus symmetric. The reason particles end up outside the detector seems to be twofold:

• propagated out; if the track state has picked up a large y-slope it may end up overshooting the boundary. I'm not sure what the best way to solve this would be, but it could be the case that iterating on the Kalman with modified initial conditions can fix this.
• instability; some of the tracks start to oscillate above and below the detector. This is rare, but I don't understand it at all yet.

[jdkio]

I've added track smoothing in https://github.com/DUNE/dune-tms/tree/kleykamp_track_smoothing I need to validate it properly. But it seems to sometimes help, but not all the time. Like in some cases, the y error message disappears, but in other cases it's back. That may be because it's not doing exactly what I'm trying to do, and validating will fix it