This is merely meant to be a list of some things Eric and Kurt/Gennadiy/Ron/Jim have identified as places where CET can begin to dive in. Additionally, it's some notes I (Eric) wrote down and proceeds from one or two things that are in hand to things generally that need doing: outstanding tasks that I'm a little worried about. I'm leaving off from this list things that Andrzej and I are tackling currently.

System set-up

Gennadiy has made strong headway here, designing the LCC-108 test stand. There is an identified network configuration (in a document in git, in fact). That network is largely constructed. Two machines uboonedaq-evb-01 and uboonedaq-seb-01 are up and running. We may bring in more machines. When we move into the uBooNE detector hall, and D0 Assembly pit before that, we'll definitely need this CET support also.

Convert the current Make build system to Cmake

This is pending Gennadiy's estimate of the person-hours that will be required to do this. We have (a slightly arcane) autoconfig/Make build working on the code that needs building that's in git now; Eric's feeling is Cmake would be nice, not indispensable. Gennadiy and Kurt are correct to point out that this code base will grow significantly, so this may well be worthwhile. The current directory structure is not conducive to a quick flip to Cmake. Gennadiy and Kurt know this.

CSS Studio: EPICS monitoring

There's been much discussion of taking NOvA's EPICS monitoring/alarming GUI faithfully over to uBooNE DAQ. We continue to discuss whether this is a small effort, leveraging off the NOvA experience. Geoff Savage thinks, I believe, that this might be overkill. But, if it's easy, we should probably do it.

Run Control

We imagine a series of cshell/python scripts to start/stop runs, slow-monitoring and offline processes. At the lowest level, when the seb machines re-start their data-taking processes and await connection from assembler, and assembler starts on the evb machine and connects up, that's the start of a new run. This is probably a job for which a design should be discussed.

File Management

SAM (Sequential Access Model). Adam Lyon is the CD liason. Pour on the flesh eating ants, and the rest writes itself.

Beam Data

Acquiring and merging this stream with the DAQ stream must be discussed soon. We have legacy mBooNE scripts which do this. CET or someone may have a more elegant, generic solution we can lean on.

State Preservation/Recovery

There's been some vague discussion of robustifying code, so as to recover from run crashes, e.g. This problem is considered to some extent in the current code, with some signal handling, etc. This would require probably really diving into the current C code base to see what's there and what's needed, if anything. Perhaps y'all CET guys have a bigger/different scope in mind than what I've elucidated here.


uBooNE will need a database with tables to hold run/event information, calibration constants, code versions, etc: stuff that an analyzer offline will want to pull in to her analysis. Is this orthogonal to EPICS databases (now revealed to be in fact flat files, not really databases)? What about backing this database up and EPICS databases (sic) up to ENSTORE, or whatever? Should we do that?

Perhaps we stick the ECL (electronic collaboration log) in this category of things too. We have a Postgres database for the ECL. Is this yet a third database? This one is FNAL CD-supported (backed up), which seems nice. Can all of 'em be thus supported? Again, a design seems wise here.

C++'ifying the codebase

This, like going to Cmake, might be nice, but is perhaps even less obviously a big benefit. I may be wrong. I would not object strongly I guess if people make a case for this.


Geoff Savage (CD, non-CET), Glenn Horton-Smith (KSU), Gennadiy are on this, we believe.