p348-daq merge requestshttps://gitlab.cern.ch/P348/p348-daq/-/merge_requests2024-04-09T21:03:51+02:00https://gitlab.cern.ch/P348/p348-daq/-/merge_requests/479Draft: First commit, just copy-paste the 2022A HCAL settings2024-04-09T21:03:51+02:00Andrea CelentanoDraft: First commit, just copy-paste the 2022A HCAL settingsCloses #119Closes #119Andrea CelentanoAndrea Celentanohttps://gitlab.cern.ch/P348/p348-daq/-/merge_requests/478Resolve "Integrate WaveBoard digitizer in DaqDataDecoding"2024-04-09T11:42:05+02:00Andrea CelentanoResolve "Integrate WaveBoard digitizer in DaqDataDecoding"Closes #118Closes #118https://gitlab.cern.ch/P348/p348-daq/-/merge_requests/475Draft: merge current 2023b developments into master2024-04-10T11:32:00+02:00Mirald TuziDraft: merge current 2023b developments into masterAs 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...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 https://gitlab.cern.ch/P348/p348-daq/-/commit/d497ec255bf04c170696aaa7fb4905dc9a17bf77. 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 https://gitlab.cern.ch/P348/p348-daq/-/commit/26bace95a4a14e416d10c2a39107d4a6c583e0ee) 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.Complete reconstruction of 2023B (NA64mu) dataAnton KarneyeuHenri Hugo SieberAnton Karneyeuhttps://gitlab.cern.ch/P348/p348-daq/-/merge_requests/471Draft: Resolve "Fix ST time thresholds for hadron runs in 2023A"2024-02-16T13:35:37+01:00Benjamin Banto OberhauserDraft: Resolve "Fix ST time thresholds for hadron runs in 2023A"Closes #112Closes #112Complete reconstruction of 2023A (NA64e) dataBenjamin Banto OberhauserBenjamin Banto Oberhauserhttps://gitlab.cern.ch/P348/p348-daq/-/merge_requests/406Resolve "Fixing warnings from Micromega struct"2024-03-06T09:12:56+01:00Benjamin Banto OberhauserResolve "Fixing warnings from Micromega struct"Closes #73Closes #73Benjamin Banto OberhauserBenjamin Banto Oberhauserhttps://gitlab.cern.ch/P348/p348-daq/-/merge_requests/309Draft: Resolve "Detail magnets geometry definition"2023-12-15T16:36:44+01:00Benjamin Banto OberhauserDraft: Resolve "Detail magnets geometry definition"Closes #15Closes #15Benjamin Banto OberhauserBenjamin Banto Oberhauserhttps://gitlab.cern.ch/P348/p348-daq/-/merge_requests/254GEM timing processing2023-07-31T11:22:27+02:00Benjamin Banto OberhauserGEM timing processingGEMReco.h and conddb.h can now process timing calibrations to produce time information of GEM hits (thanks to M. Hoesgen).GEMReco.h and conddb.h can now process timing calibrations to produce time information of GEM hits (thanks to M. Hoesgen).Anton KarneyeuAnton Karneyeu