L1Calo Software meeting on 17 October 2003

The meeting consisted of a core discussion at RAL with separate phone conferences in the morning with Attila and in the afternoon joined by Gilles. The agenda order was adapted to the particants at the time.

Discussion on software for the jet trigger

Attila has written some software for testing the jet algorithm in the JEM. Some of this is an extension of the jemServices package. Attila should ask Cano to commit these changes. The new jet firmware has some programming model additions and removals which should also be included.

There is also some standalone software. We should try to include this too. However the standalone test mode involves generation of random data and trigger menu on the fly which is not directly compatible with the simulation framework which relies on files.

Reading out the new input and output spy memories in the new jet firmware will require an additional data type.

L1A generation and BUSY

A scheme to track BUSY in the L1A generation was agreed by email. This involve the DSS outputting the trigger type to identify the L1ID within the DSS memory and the ROD counting the number of whole ORBITs. The latter requires a firmware change - this is waiting for a response from David Francis as to where we should report the ORBIT count in the event header.

Migration to gcc 3.2

Birmingham desktop systems are now using RedHat 9 which comes with gcc 3.2 by default, though the gcc 2.95 compiler could be installed as well. The online and dataflow software is also available under gcc 3.2. Its not urgent, but we clearly need to migrate at some point and it may be convenient to do so soon. It was suggested that Bruce, Murrough and Steve discuss a timetable.

Bruce reported that the RedHat migration at CERN was not yet clear but the most likely aim was for a HEP wide licence for the supported RedHat "enterprise" distribution.

cmmSim reorganisation

The cmmSim package has passed through a number of hands in the last fortnight. Steve has reorganised the class structure to allow automatic use of the right software subclasses for the selected firmware function in an elegant fashion. Juergen has added use of the trigger menu for the jet and energy sum functions.

Juergen has implemented the real time energy sum function (apart from some of the saturation details). The DAQ readout is still missing. This needs the format to be finalised and then a ROD writer to be developed.

Feedback from TDAQ developers meeting

The first of what is intended to be a series of meetings for software developers across the whole TDAQ project was held on Wed 15 October. Bruce and Norman joined this meeting which was well chaired by Fred Wickens to facilitate phone participation.

The main purpose of these meetings is to identify issues and report back to subgroups. The talks are available via the CERN agenda system. Norman and Bruce highlighted a number of issues.

In the feedback from the testbeam the main complaint was the complexity of the database and the time take to merge databases. [Some of this may be addressed by the new TDAQ Segments (see Andreis talk) to be introduced in the next Online release].

Other testbeam problems included an EF bottleneck on event rate, whether the ROS should wait or not for L1As and the ROS not being tolerant enough of some conditions. There were also complaints about incomprehensible error messages.

Returning to the database theme, some new features of the Online database were announced - but some desired features (eg updatable DAL) are not yet implemented and the community should indicate priorities for these features. On the offline side there may be problems integrating many different databases already being used by various subdetectors.

The talk on monitoring was interesting and well received.

Presentations to the Lisbon TDAQ meeting

Norman suggested a list of issues we should feed back to the Lisbon TDAQ meeting. These include problems with the database (lack of updatable database), worries about run states and (lack of) rules and how multistep runs such as calibrations are organised.

Feedback from non-experts

At the QMUL joint meeting we requested some feedback on our software from non software experts. We have received two reports so far.

Tony spent a day looking over Bruces shoulder. He was impressed but would need documentation (a userguide) to be able to repeat all the required steps. He would like to spend more time and take better notes.

Pete has also had a test drive. His major concern was the level of knowledge needed to edit the database. He remarked that the tooltips for run parameters were very useful - they need to be kept up to date.

Reorganisation of test vector generation, number of DAQ slices

Following the reorganisation of test vector generation by Steve, the number of DAQ slices is now defined only by the source module (eg CPM, JEM) from which test vector generators and sink modules find the value.

This may need to change when ROD firmware is updated so that the ROD can selectively throw away parts of the Glink data (eg no slices of CPM input data but 1 slice of CPM hits output). In that case it may be more sensible to have the single, more detailed, control at the sink (eg ROD) end.

TTC broadcasts, DSS, TTCrx I2C part

Gilles believes that the ModuleI2CRegister part should work for the TTCrx on both CPM and CMM. He will try to check this by running a remote test on the RAL system.

There had been a worry that our proposed TTC broadcast scheme would need to be radically revised because of limitations of the DSS. It turns out that a few short wires can be added to the DSS motherboards to connect all the broadcast command bits. A small firmware change would also be needed. Murrough should check and revise the TTC broadcasts document before we formally request these changes.

Software releases

The first, and so far only, release of our software was about one year ago. Should we make another one? It would mark the end of a period of testing before we start using the ROS.

The minimum mechanics involved are: (a) get all developers to tag their packages, (b) build the release from latest tagged versions - ie instead of the HEAD version as in the nightly build, (c) test installing and using it. In addition its a good time to ensure all doxygen and other documentation is up to date.

A related issue is whether that would be a good time to change our working module of using CMT to mainly develop a few packages against the release instead of everyone checking out and building the HEAD version of all packages. It would take a little testing to get this going properly.

Again, as Steve wasnt present, it was suggested that Steve, Bruce and Murrough discuss the issues.

ROS software and integration with DB and simulation

New hardware (PC, FILARs and HOLAs) are expected at RAL in the next week or two. Meanwhile Bruce has started looking at the software again - finding conflicting instructions on how to configure Linux for the ROS...

We also need to decide which version to install. More recent versions use new CMTCONFIG settings which are not the same as those in the online release we are using. This may not be a big problem and Bruce would prefer to use the latest version in case we request changes.

We would also need to integrate the ROS with our database and simulation. We need to be able to describe the Slink connections to the FILAR inputs so we can predict the output ROS fragment. The simulation needs the same data. We can consider using the standard Dataflow "eformat" package in the simulation to build ROD fragments into ROS fragments. This needs further brainstorming after the Lisbon workshop.

Directions and priorities

We had a long discussion about the direction and priorities. This started by listing the tests and the missing software. The lists are show below.

Types of test

• Single module tests and acceptance tests: all modules!
• Connectivity & Link tests
• System Tests - operation
  • Setup
  • Soak tests
  • Exploring phase space
  • Rate tests
• Calibration
  • Timing (Digital)
  • LUT, BCID, Synch (Analogue)

Missing or incomplete software (module related)

• PreProcessor
  • Atlas/L1Calo software training
  • Module services (HDMC parts)
  • Complete simulation (PH has started this)
  • Test programs (e.g. video memory controls)
• JEM
  • Testing JET component of module services and simulation with new jet firmware
• CMM
  • JET component
• CTPD
  • Simulation (simple model for CTPD in our framework)
  • Control (RodBusy, etc.)
  • Interaction of databases, one in L1Calo framework and the other in CTPD framework
• 6U-ROD
  • Simulations for some datatypes (related to firmware development)
• 9U-ROD
  • Everything (module services and simulation)
  • (on-module monitoring)
• ROS
  • Analyser of Events
  • IOM inline event comparison
  • Db interaction, simulation (readers, etc.)

Missing or incomplete software related issues (system related)

• Offline
• Multistep runs for calibration
  • Stepping is untested
  • Checkpoints
  • Run numbers
• Event dump (new formats, modified formats.)
• Physics test vector input
• Generating test vectors (some modules)
• Histogramming
• Calibration
  • Pulse
  • Analysis
  • Control: delays, settings
  • LTP?

Priorities

1. ROS
   • Installation
   • Integration (database/simulation/comparison)
2. Stepping (multistep runs)
   • Use of in existing setups.
   • Anticipated use in integrated calibration
3. PreProcessor
   • Ground work
   • Integration of existing work

Next meeting(s)