Production Software¶

R21-01-28-testbeam-production.a¶

• 2021/01/29
  • Period 3 keep-ups and 'state of the code' software.
• Up-to-date with trunk from 2021/01/28. Significant changes made it more sensible to base a new branch.
• Test Beam specific changes:
  • Improved magnetic field mapping (Teresa/Mark) and wire chamber reconstruction;
  • Bug-fix in raw2root which was causing runs with empty first events to be defaulting to ND for some services;
  • Updated beamline geometry reflecting the changes in ToF locations for Period 3, and associated updates to the ToF reconstruction.

R19-09-24-testbeam-production.f¶

• 2020/04/27
  • Period 2 raw2root and pclist processing. Will be used to get first pass of calibration.
• This tag is up-to-date with trunk from 2020/04/24.
  • Contains improvements to raw2root, detector reconstruction, beamline reconstruction etc.
• Two previous tags (.d and .e) were made whilst finalizing all software:
  • Both merged with trunk on 2020/04/14.
  • R19-09-24-testbeam-production.d (2020/04/16) had setup files (externals, packages) incorrectly configured for the tag.
  • R19-09-24-testbeam-production.e (2020/04/17) incorrectly loaded the calibration csv files.

R19-09-24-testbeam-production.c¶

• 2020/01/16
  • For keep-ups
• Changes to the unpacking of the beamline raw data, as described in commit 40499:
  • Change to the default unpacking behavior of the beamline data. My understanding was I had put much stricter requirements in place to ensure the correct data fragments are matched up with each other, but I actually hadn't. It would have been ok a lot of the time, but I tightened up these requirements. Specifically, there was previously no checking if the wire chambers or the digitizer saved the same number of data fragments to the trigger or TDU, even if they were explicitly being unpacked. The trigger board and TDU were explicitly checked, since they were saved in the same offline data structure. If there were fewer than the number of triggers, it would just fill the first n triggers and leave the remaining without wire chamber or digitizer data. Not ideal, since we can't be sure this is the matching which was required. If there were more than the number of triggers, we'd get an exception thrown, caught, and the spill ignored, which is the correct behavior (in my view). I changed it so that this is the case for all instances of different number of data fragments between trigger board, TDU, wire chambers and digitizer (if they're being unpacked; if not then this isn't enforced, obviously). Additionally, the default behavior was not to unpack trigger, for some reason (likely left over from commissioning before shut-down). This may have alleviated problems with the issues described above, but it's very hard to know; this is complicated. In general, we want the trigger unpacked, so I have changed this. Everything now works as I thought it was set up and I have tested it at length on beamline-only and full testbeam-merge (beamline-stream) data.

R19-09-24-testbeam-production.b¶

• 2019/12/10
  • For keep-ups
• Integration tag, including all test beam specific changes to software over summer
• Change to the saving of the magnetic field information; no longer saved in the raw data product (the data product still contains a field for it but not necessarily reliable), the reconstruction now retrieves this information. In the future, will be from a database. In this tag it uses the same method as the previous tag, but the beamline run number is the only thing saved in the raw data product.

R19-09-24-testbeam-production.a¶

• 2019/09/24
  • Period 1 first production.
• First tag of branch for initial production data processing
• Magnetic field information is saved in the raw data products