GlueX Software Meeting, August 20, 2019
GlueX Software Meeting
Tuesday, August 20, 2019
3:00 pm EDT
JLab: CEBAF Center A110
BlueJeans: 968 592 007
- Online Skims (David)
- Review of minutes from the last Software Meeting (all)
- Review of recent issues and pull requests:
- Review of recent discussion on the GlueX Software Help List (all)
- Action Item Review (all)
Talks can be deposited in the directory
/group/halld/www/halldweb/html/talks/2019 on the JLab CUE. This directory is accessible from the web at https://halldweb.jlab.org/talks/2019/ .
- CMU: Naomi Jarvis
- JLab: David Abbott, Stuart Fegan, Mark Ito (chair), David Lawrence, Simon Taylor, Carl Timmer, Beni Zihlmann
- /mss/halld/halld-scratch will be zero'ed. The exact schedule has not been set.
- Cache files where the disk version was different from that on tape. These files were lost.
David described not only the new system for performing skims of special triggers online, but also the new architecture for writing data to disk in the counting room as it comes out of CODA. See his slides for details.
- The basic idea is to do skims of special triggers (BCAL-LED triggers, random triggers, sync events, etc.) in the counting room while we take data. Those skim files are then immediately available for calibrations. This could speed up calibrations needed in advance of the first reconstruction pass on the data.
- To speed up the process, blocks of triggers that do not contain the special triggers can be skipped. Time is saved by avoiding dis-entanglement of the events. This means that there will be a reduction of the number of PS triggers in the skimmed output; all blocks have PS triggers, but not all PS triggers are in blocks with special triggers.
- Information from the block headers will be put into a relational database, including information on the number of each type of trigger, the first and last events in each output file, etc. These quantities can be migrated to the RCDB later.
- The architecture of the new Hall D Data recording scheme will use fast copies using remote direct memory access (RDMA) to transfer data from IB interface to IB interface without involving the CPU. RAID servers will send and receive data from ramdisks and the data written from memory to arrays of traditional partitions on multiple RAID servers. From there the jmigrate system will look for data to be shipped to the Computer Center for storage on tape.
- There are still some issues to deal with, including more thorough testing, and definition of a back-pressure mechanism (especially if the skim process cannot keep up).
Review of minutes from the last Software Meeting
We went over the minutes from August 6. David reported that the reconstruction launch at NERSC got going again last week, but ran into problems over the weekend due to a change in how tape is handled at JLab.
Review of recent discussion on the GlueX Software Help List
We briefly discuss the issue with SQLite versions of the CCDB. There is still no clear-cut, works-everywhere solution.