online/offline issues

• FEX to TC to Digi

  • TSF : "nothing changed" except TC to digi don't use old map anymore
  • BLT : "nothing changed"
  • ZPD :
    • A different FEX for each raw DAQ format and nTick (FEX selected by configuration).
    • ROM produces ZPD Section TC with a version number.
    • Abstract interface to access ZPD section TC (offline code protected from internal TC format change which doesn't add new data).
    • New FEX needs to be implemented.
    • More clever data packing needs data to know what they look like. (fully store the initial tick for each track and only delta values for the next ticks, or have a compact storage covering ninety-something percent of the cases and an expended one for occasional particular tracks/events ....) This can be done only when we have some parasite data to look at.
  • GLT : Sudong
  • From Olya : The L1 TC->Digi sequences is managed by packages L1DctOep and L1TOepSequences. They both working proper, make good Digi (Zpd still has to be updated for new format). The Parasite and Production modules are available and they are separate (TSF - parasite is a copy of production, ZPD- parasite is derived from production). This part is practically done.

• Configuration

  new tsf - zpd in June 2003
  • What : see TSF/ZPD/GLT parts
  • All configuration flags allowing to skip portion of the LUT loading should be removed before going to the production system.
  • Online needs configuration TC. Partially written :
    • NEW TSF LUT TC --> done
    • ZPD LUT TCs --> partially done
    • New TSF + ZPD parameters (DAQ format, offset, ....) --> to be done
    • GLT : new lines, new stuff?
    • Global : who is the production trigger. this is connected with TrgConfig.
    • The map could be put in the configuration : need TC
    • the BLT mask should be added
  • needs to create new branches in the configuration alias tree.
  • The simulation needs some sort of configuration digis in the database.
  • ultimately, we need a configuration digis to configuration TC converter (for createFileTable). Since this conversion is a one to one conversion and since the ZPD LUT TC contains everything, there should be only one persistent object in the database containing all the ZPD LUTs unless we can make a many DB objects to one TC correspondance.

• Conditions

  We have a set of conditions objects that pop up.
  • BLT vs BLT-z. --> needed for correct BLT simulation
  • Firmware versions. --> might be needed if firmware changes : no work needed now for that.
  • ....
  • No work has been done on the subject.

• Map and automatic detection

  DONE
  • Logic to resolve conflict between expected map and automatic detection is in L1DctOdf/L1DctBaseMapFiller.
  • Ability to run with one ROM connected to 2 TSF crates.
  • Not clear if offline can deal with a ZPD not in slot 2 : how many offline applications depend on the fact that L1DBltPtdSectionTC::id()==2 for a BLT or that the BLT section TC is always the first one in a BLTxxx Module TC? Apparently only the BLT/PTD TC to digi is impacted
  • Do we want it in the database? Yes in the configuration, although not critical for switching ZPD to production trigger, a database XTC file pointer (BdbFileIdentifier) might be enough.

• Digi to TC

  • TSF "post 2003" digi to "post 2001" TC format done (I believe). This is the only digi to TC conversion made.
  • ZPD : the version of the TC to produce is determined by the digis available in the event.
  • In both cases, an intelligent TC/TC comparator is needed for the TC -> digi -> TC test due to unkept info in the digi.

• Teststand maintenance

  (not crtical to start triggering with ZPD)
  • Keep it compiling and running.
  • Improving it : (example : boards names are in simulation converter and in teststand, some portions are missing, ...)

• FEX maintenance

  (not crtical to start triggering with ZPD)
  • Changing TC format.
  • Answering to a change in the raw data format.
  • Reducing the time and/or data volume.

• DCT "calibration"

  (not crtical to start triggering with ZPD)
  • runs but will need tests and more clever offline tools to diagnose problems.
  • integration with Run Control.

• Interactions with L3

  • L3 can't run if the 2 TSF crates are not processed by 2 different ROMs. Will change the error checking from "there is 2 TSF module TCs" to "there is 24 TSF section TCs". The FEX guarantees that there will be a section TC for each answering TSF even if it contains no segment.
  • It loads the TSF LUT from the database.
  • It needs the TSF Digi to TC for the simulation.
  • It needs to know about the new GLT lines.