MuonPRDTest - Preparations for Avalanche Scheduler, simplified output handlng & bugfixes in Mdt tests

Hi everybody,

this MR the start of the clean-up of the MuonPRDTest package (cf. ATLASMCP-141). The primary aim is that each sub-tester declares its data dependency to the avalanche scheduler such that the MuonPRDTest can be included later in an MT job. Further, the handling of the TTree output is drastically simplified by introducing the MuonTesterTree package.

MuonTesterTree The package is basically a pull-over of the I/O classes of the MuonTester project, the central tool to study the reconstruction performance within the muon SW community. The design of the package is motivated that the common validation code in the muon SW, especially the MuonPRDTester basically follows this pattern,

   /// Declaration of the data member
   std::vector<int>* some_data_ptr; 
   /*
      .... Add the thing to the TTree
   */ 
   tree->Branch("CakeTastesGood", some_data_ptr);   
  /* 
    .... At the beginning of each loop reset the data
  */
   some_data_ptr->clear();

if new data is added to the validation TTree. It makes the code lengthy as the declaration & the initialization of a new branch is scattered across multiple places. Also it is kind of prone to errors - especially, forgetting the last one made me scratch my head why the .. is my disk hard disk suddenly hammered down. The MuonTesterTree simplifies the muon validation code tremendously. It handles the creation of the TTree, the communication with the THistSvc to write it to disk and a consistent handling of the data branches. All data members inherit from the common IMuonTesterBranch interface that provides init, name & fill. The call of init guarantees that the branch name has not already been occupied by another branch instance. The method is called on any data-member registered with the tree. The branches are internally ordered by alphabet. The fill method ensures that the data stored in the branch has been updated properly unless an escape default value was defined before. fill is only called that are directly owned by the MuonTesterTree. If a compound branch has a IMuonTesterBranch as direct data-member, it is responsible to check for this one to have a successful fill. The four branch classes below are the most basic building blocks satisfying the interface. They are the only classes that directly communicate with the TTree.

1. Implementation to save flat numbers: ScalarBranch must be updated between each fill call unless a dummy default value is provided that is used instead
2. Implemenation to save std::vector<>: VectorBranches automatically clear themselves if they contain data from the previous event fill. If the branch is not touched between two calls, it is cleared as well.
3. Implementation to save std::vector<std::vector<>>: MatrixBranches have the same behaviour as the VectorBranch.
4. Implementation to save fixed-size arrays: ArrayBranches require that each element of their storage is updated unless a dummy value is explicitly provided.

Compound classes to store the Muon identifier, x,y,z of a 3 vector or the full 4-vector are provided in IdentifierBranch, ThreeVectorBranch and, FourVectorBranch, respectively.

To use the MuonTesterTree, it is recommended to let the algorithm inherit from AthHistogramAlgorithm

#include "AthenaBaseComps/AthHistogramAlgorithm.h"
#include "MuonTesterTree/MuonTesterTreeDict.h"

class MyHistValAlgorithm: public AthHistogramAlgorithm {
 public:
  MyHistValAlgorithm(const std::string& name, ISvcLocator* pSvcLocator);

  StatusCode initialize() override;
  StatusCode finalize() override;
  StatusCode execute() override;
  unsigned int cardinality() const override final { return 1; }

private:
   MuonTesterTree m_tree{"<tree name>", "<Output stream in THistSvc>"};
   /// Saving of flat numbers
   ScalarBranch<int>& m_runNumber{m_tree.newScalar<int>("runNumber")};
   //// Saving of std::vector<>
   VectorBranch<float>& m_weights{m_tree.newVector<float>("weights")};
   /// Saving of std::vector<std::vector<>>
   MatrixBranch<float>& m_pos_x{m_tree.newMatrix<float>("HitPosX")};

Initialize:

StatusCode MyHistValAlgorithm::initialize(){
    /// Standalone modules like the MdtDigit tester can be added via
    m_tree.addBranch(std::make_unique<MDTSimHitVariables>(m_tree,"MDT_SDO", msgLevel())); 
    
    /// The init call registers the TTree with the output
    ATH_CHECK(m_tree.init(histSvc()));
    return StatusCode::SUCCESS;
}

Execute:

StatusCode MyHistValAlgorithm::execute() {
   /// Retrieve current context at the beginning
   const EventContext& ctx = Gaudi::Hive::currentContext();
   /*
      Calculate the variables and assign branches
   */
   /// Dump the event
   if (!m_tree.fill(ctx)){
       ATH_MSG_FATAL("Failed to execute the analysis");
       return StatusCode::FAILURE;
   }
   return StatusCode::SUCCESS;

}

Finalize:

   StatusCode MyHistValAlgorithm::finalize(){
       ATH_CHECK(m_tree.write());
       return StatusCode::SUCCESS;
   }

The migration to the MuonTesterTree will allow the muon SW community to write basic blocks to dump digits, residuals such that they can be recycled in other places of the validation chain as well without reimplementing them. This will drastically simplify the kickoff of @mbarel's qualification task. Tagging @zyan here as well as he expressed his interest to use the MuonTesterTree package for the Mdt calibration stream.

MuonPRDTesterModule The PrdTesterModule is the basic class to implement the muon PRDTests. It is equipped with an IMuonIdHelperSvc and declares by default the data-dependency of the MuonDetectorManager. Inheriting testers must override the following two methods.

    /// Initialize all ReadHandleKeys
    bool declare_keys() override;
    /// Dump everything to disk
    bool fill(const EventContext& ctx) override;

The Mdt testers have already been migrated in this MR and can be used as a design template for the migration of the other testers. Tagging here @minlin as he will migrate the other testers as well to use ReadHandleKeys and implement Identifier branches for the other muon detectors.

Fixes in the Mdt digit tests The plot of the global X&Y positions of the Mdt digit lead to something that is similar to

However, @rosati noted that the digits from the same tube layer should also have the same global X&Y coordinate. This bug has been found & is fixed now. Further, the local digit position is now stored w.r.t. restframe of the first multi-layer

Tagging: @pscholer, @stavrop, @mvozak