Skip to content

Draft: merge current 2023b developments into master

Mirald Tuzi requested to merge 2023b-patch into master

As a disclaimer, this branch contains a couple of different updates revolving around the preparation for the 2023B data reconstruction. Unfortunately, when I started implementing the things, as I was still fairly new to the different Git tools, I did not break the activities down into different issues, leading to this one single branch containing all the 2023b updates. @akorneev please let me know if that would be alright with you, or if it is better to try to separate the things. Sorry for the inconvenience.

This is the list of updates included in this branch:

  • tracking implementation for 2023B, meaning
    • tracking_new.h contains all the relevant steps to run the algorithm
    • placements files for the configurations ECAL in and ECAL out exist
      • All elements are aligned, with the exception of ST12, and ST11 and ECAL with a preliminary alignment. I would create a separate issue for them
    • geometry files for ECAL in and ECAL out created using the placements files and na64mu simulation, taking into account as well rotations, as computed from the survey measurements
    • field maps for MS1 and MS2 are not included (see comment in tracking_new.h https://gitlab.cern.ch/P348/p348-daq/-/blob/2447174a6cc4a4f4e7bf309ddb9c724c6edb7256/p348reco/tracking_new.h#L1098), as they sum up to 9 MB, which may be rather large to store on Git. My suggestion would be to store them in the twiki, although please let me know if you have other suggestions
  • calibration files for all calorimeters were already merged in d497ec25. In a separate MR, VETO for high intensity (#100) would be updated.
  • Updates to ST_response and MM_response
    • I added a couple new histograms, and in MM_response, I basically took over all the correlation histograms from https://gitlab.cern.ch/P348/p348-daq/-/tree/eth-mm-dev that @bbantoob had implemented, as they proved to be very useful for muon mode
    • Additionally, I added amp-ratio plots, the necessary ingredients of which I will address in a dedicated section.

MM amplitudes

One of the famous monitoring histograms during beam time is the amp ratio plot, which is an important indicator whether the trackers are properly calibrated. The information for these plots is extracted from the raw charge (raw_q), which, by default is not accessible by the user through RecoEvent as it is not stored in the MicroMega struct.

I understand that in the past, it was also not really necessary to do analysis with this information. However, with the new upgrades, in particular the pre-scaler, and for muon the runs at higher intensity, it has turned out to become an important tool to better understand the data.

Because of that, I wanted to propose a way to store the raw_q information. I discussed this with @bbantoob yesterday, and the basic idea was to keep the processing "hidden" from the user, i.e. try to not modify p348reco.h. The preliminary solution I came up with (see 26bace95) was to define a new boolean in MM_plane_calib that can be set in conddb.cc for each run period, and each MM plane individually, if it is needed. One of the biggest concerns was how this would affect memory usage. "By eye", I have not observed any significant issues, but I'd be happy to hear what you think of this too @akorneev .

If you have any questions or concerns, please let me know! Thanks a lot in advance.

Edited by Mirald Tuzi

Merge request reports