Project

General

Profile

Work list 27-Feb-2013

Let's try to tag the work items in the following list by priority and state.

Priorities:
  • Urgent
  • High
  • Medium
  • Low
  • NiceToHave - if there is time available
State:
  • NotYetStarted
  • SomePrepWorkHasBeenDone
  • InProgress
  • Ongoing - this is for work that is ongoing, such as testing new versions of software or keeping the software running on the teststands
  • Waiting (for another task to be completed or for design discussions to take place, etc.)
  • Available - a working solution is available, but it may need to be improved or enhanced
  • Complete

Work Items

  1. [State = Ongoing, Priority - Medium] Test new versions of software on the WH14 and LNGS teststands. Keep the software at both teststands in working condition. Document the steps needed to run the system at each teststand.
  2. [State = Available] Create a VirtualBox VM with enough ds50daq software for Stefano to run SystemController tests on
    • [Notes] Stefano and Kurt succeeded in getting a ds50daq 2x2 V1720 simulator system running on Stefano's laptop on 22-Feb. There were a couple of deficiencies in this system:
      • Stefano needs to re-run the "iptables --flush" from the root account every time the VM is rebooted or restarted (this could be fixed by modify an appropriate system file)
      • the definition of the DS50DAQ_CONFIG_PATH environmental variable needs to be added to the .bashrc file in the ds50daq_user home area
      • RSH needs to be installed in the Virtual Machine
    • [State = NotYetStarted, Priority = NiceToHave] A cleaner, more robust version of this would probably be useful. This may consist of starting from scratch, using the notes here and here to create and configure the Virtual Machine, documenting all of the steps that are used in creating the VM, and documenting how an end user would would install Virtual Box and the VM on their computer and keep up-to-date with artdaq and ds50daq code changes.
  3. [State = InProgress, Priority = High] Aggregator
    • [Note] a 4 FR to N EB to 1 AG to disk test would be sufficient to demonstrate success
    • [State = InProgress] Work through the details of serializing and deserializing art data products by creating a demo system that sends serialized ROOT data from one process to another using sockets.
    • [State = SomePrepHasBeenDone] Create the aggregator application within the MPI program. Add the aggregator to the start/stop/init scripts.
    • [State = SomePrepHasBeenDone] Convert the socket-based demo described above to use MPI within the ds50daq system.
  4. Adding Fragment Types to the std::vector<artdaq::Fragment> data products in the art event.
    • The following are reasonable calls that might be used to access these data products:
      • getByLabel("daq", "V1495");
      • getByLabel("daq", "V1720");
      • getByLabel("daq", "V1724");
      • getByLabel("daq", "V1190"); // could be several variants
  5. Demonstrate and update the compression and decompression modules
    • We expect that we will need to add data members to the DS50CompressedEvent class to differentiate between the different types of board data
  6. Improve the determination of the allowed commands within the boardreader, eventbuilder, and aggregator applications
    • [Note] Currently, this is hand-coded.
    • [State = NotYetStarted, Priority = Low] The allowed commands should be linked to the state machine so that we don't have to maintain this information in two places.
  7. Message logger (sending of messages between processes/hosts needs to be implemented)
  8. Re-purpose dseb6 as dsag1
    • We have asked for recommendations on an appropriate RAID controller and 10 Gb interface card for this machine.
  9. Get 1495 readout working
    • once it is working, we should update the EventDump and EventCheck modules to make use of the data
    • a secondary goal might be to provide a somewhat realistic 1495 simulator generator
  10. Finish setup of the DAQ computer cluster (if needed), and verify that it is configured and working correctly
  11. Look into how long decompression (and compression) take (as input to whether we want to send the raw and compressed data to the Aggregator for some fraction of the events, for online monitoring, so that the monitors don't have to do decompression)
  12. Database interface plan
    • as input to this, it would be useful to have instructions for how to create an art service
    • Kurt sent links to the LArSoft DBI and the NOvA DBI to Alessandro on 22-Feb.
  13. Move the creation of the art instance in the EventBuilder application from StartRun time to Initialization time. And, return an error if SystemControl asks the art process to be reconfigured in the 2nd - Nth configuration message. This will probably also include input module changes to recognize new runs.

Backup information

Here are my raw notes from talking with Alessandro at LNGS on 18-Feb (I will clean this up soon):

Big issues
  1. Aggregator
    • a 4 to 2 to 1 to disk test would be sufficient to demonstrate this
  2. Products
    • getByName("daq", "V1495");
    • getByName("daq", "V1720");
    • getByName("daq", "V1724");
    • getByName("daq", "V1190"); // could be several
  3. compression

message logger

10 Gb on aggregator box
- rename dseb6 as dsag
- gbit interface,
- move second disks from EBs to AG
(maybe buy another)

real 1495 fragments

verify host files

sending events to aggregator - mainly compressed
to do - test how long decompression takes

database interface plan
- including art service

integrate xpra with PMT
- start creating ds50daq releases (less important now)

validate the state machine behavior
- create test script

shutdown vs reset
- convert to reset - this moves the system to the booted state
- this should be allowed from all states.

simulator doesn't set the list of enabled channels.

init from SC may need PMT to restart things if a different layout is requested

database interface:
- map of vectors
- find latest contents
- calibration table
- service should cache tables