Software Workshop pre CM40

Date: 24th, 25th October (Friday, Saturday)

Location: Room A, Physics Department, Roma Tre University, Rome.

Time: Friday: 1400, Saturday 0900-1400 CEST (GMT+2)

Connectivity: Eduroam or University WiFi (TBC)

NOTE: There will be a general strike in Italy on October 24 that will likely affect local transportation. Below are details and tips from Domizia. Please plan accordingly.

<From Domizia>

Please take note that most likely on Friday there will be a general strike which may heavily affect public transports, both local buses and metro and the trains from Fiumicino airport. Also taxis in these circumstances may be difficult to find.

(Durga please contact software workshop attendees who may not be in this list yet to warn them!)

One option which could be interesting if you are landing at about the same time and are planning to go to the same place as other people in this list is to book in advance a private transportation service, like for instance

the single trip from the airport to where you want in Rome (included Roma Tre Department
in via della vasca navale 84 if you have to reach directly the software workshop!) costs
25 euros (Taxis charge 40 euros) and you may have to wait for other passengers, but additional
passengers (up to 8 people) pay 6 euros. For the receipt probably you will get a single one, so it may
interesting if you are a group from the same institute. You can book online and pay by
credit card or by phone 48 hours in advance and pay cash to the driver.
To profit from the group fee you should book for the whole group. If you
need us to help you with the booking please send your flight information to Ludovico Tortora

If you want to share a taxi or shuttle on the 24th, the attendee arrivals are:

Adam Dobbs: FCO: 2040
Jan Greis: FCO: 1030
Ryan Bayes: CIA: 1040
Chris Hunt: LHR-FCO BA556: 1750
Durga Rajaram: EWR-FCO UA40: 0745
Chris Rogers: LHR-FCO BA560: 1610

Please sign up if you plan to attend.


  • C. Rogers, RAL
  • J. Greis, Warwick
  • C. Pidcott, Warwick
  • C. Hunt, Imperial
  • D. Rajaram, IIT
  • S. Middleton, imperial
  • J. Nugent, Glasgow
  • F. Drielsma, Geneva
  • Zhihui Li, Sichuan
  • M Uchida, Imperial College
  • R Bayes, Glasgow
  • J. Martyniak, Imperial


Global Reconstruction

Geometry plan


  • FD has EMR MC Digitizer and Track Reconstruction code
  • Track reconstruction -- reconstructs primaries, matches secondaries (if any), calculates range, charge ratio
  • Seems to crash occasionally -- appears to be an issue in loading calibration maps and/or channel map keys - FD investigating

Data quality flags

  • How do we get data quality (really reconstruction quality) flags to the DB?
  • Option A:
    • Have a post-processing job run on RAL PPD machine and get it to CDB via MICENet
      • But --
        • have to retrieve data (from CASTOR or a wget)
        • need to maintain a MAUS installation on a PPD machine (could be circumvented by CVMFS)
        • need to maintain a PPD machine and monitor cron jobs
  • Option B:
    • Have the MAUS job on the GRID spit out the flags?
      • can't do it with a simple return value since it might not fit into a INT
        • currently the GRID job takes the exit status from MAUS and gets it into the IC Metadata DB
      • Solution: have MAUS write out an XML file to cwd which Janusz can then read, parse, and retrieve flags and get them into the IC Metadata DB
        • The flags will still need to get into the CDB
        • Janusz's solution is to have a cron job at RAL pull information from the IC Metadata DB and update the CD
  • Option B seems better long-term
  • What's needed to get the flags out of MAUS
    • Mappers to write a flag for each spill
                   data_quality: {
                     "flag_name": T/F
    • Each detector/mapper can write out several flags if necessary or potentially useful for analyses downstream
    • Need MC flags for Digitizers and Hits
    • Need flags from Global Reco and Global PID eventually
      • the datastructure should be put in place even if the mappers are not ready to send flags
    • Q: Do we need flags from the DAQ Unpacking? I think if we're going to setup flags, we should flag whatever could potentially be useful
    • Since the flags will be written by Mappers they will be spill-level
    • Need a Reducer at the end to go through the flags (which are spill-level) and put out a summary flag for each run
      • this can be based on a tolerance defined in a datacard
        • e.g. detector_digi_quality = True if (nTrue / (nTrue + nFalse) ) > detector_digi_tolerance