Follow-up from "WIP: Implement 2D measurements"

The following discussions from !2140 (merged) should be addressed:

• @graven started a discussion: (+4 comments)

  This type of if suggest that HitOnTrack should be part of the ‘inside’ variant — as it wants to be replaced with visits (remember: visitis just a fancyswitchstatement with a hard (but safe)castand some syntactic sugar… — andtype()` also wants to distinguish types, so why not use actual C++ types to represent those types…

• @jadevrie started a discussion: (+2 comments)

  @wouter I could use your expertise in getting the alignment derivatives for 2D measurements right.. any suggestions? Currently the 1D implementation uses the 'trajectory' of the 1D measurement, but 2D measurements provide an XYZ space point instead.

  auto sMeas = std::visit([&](const auto r) -> auto {return r.sMeas;}, resultvar);
    Gaudi::XYZVector                  arm = trajectory.position( sMeas ) - pivot;
    ROOT::Math::SMatrix<double, 3, 6> dPosdAlpha;
    // Derivative to translation
    dPosdAlpha( 0, 0 ) = dPosdAlpha( 1, 1 ) = dPosdAlpha( 2, 2 ) = 1;
  
    // Derivative to rotation around x-axis
    dPosdAlpha( 1, 3 ) = -arm.z();
    dPosdAlpha( 2, 3 ) = arm.y();
  
    // Derivative to rotation around y-axis
    dPosdAlpha( 0, 4 ) = arm.z();
    dPosdAlpha( 2, 4 ) = -arm.x();
  
    // Derivative to rotation around z-axis
    dPosdAlpha( 0, 5 ) = -arm.y();
    dPosdAlpha( 1, 5 ) = arm.x();
  
    return unit * dPosdAlpha;
  
    // compute the projection matrix from parameter space onto the (signed!) unit
    // return unit*AlignTraj( meas.trajectory(), pivot ).derivative( m_sMeas );
  }

• Need to figure out why the minus sign in the projection matrix is needed for Y only - most likely some redefinition of a sign higher up.

• @ldufour started a discussion: (+5 comments)

  It seems very similar information to what's stored in your enum earlier. Was it not possible to use those?

• @graven started a discussion: (+5 comments)

  why accept a const FitNode& if the very first thing that happens next is to cast away that const? Perhaps instead of hiding the problem from the caller, you should make it explicit, and then fix it as 'high up' as possible -- as making things work multi-threaded with lots of const_cast around is a nightmare...

        SVectorT residual( FitNode& owner ) const {
          owner.smooth();
          return m_residual;
        };
  
        /// retrieve the residual, overloading the function in Node
        SMatrixT errResidual( FitNode& owner ) const {
          owner.smooth();
          return m_errResidual;
        };

  (This is also inside Master and therefore has no real connection to this MR)

Wishlist:

• investigate 2D measurements for Muons as well (not just VP)