Mirrors CERN QMUL |
ATLAS Level 1 Calorimeter Trigger Software | |
L1Calo Software | Minutes: 10 April 2002 | |
![]() |
L1Calo Software phone conference on 10 April 2002Present: Bruce, Gilles, Murrough, Norman, Steve, Thomas.Actions from previous meetings
Murrough: databasesMurrough has been preoccupied with spreadsheets for the cabling document and has not had much time to work on databases. He reported that the next Online software release supports definition and automatic checking of the allowed ranges of numeric attributes in the database which will reduce the amount of validation code required in the data access libraries. The existing code implements much of the functionality we need, but many areas need tidying up and completing, and documentation is still required for it to be useful for other people.Gilles: CPMGilles has been gaining experience with the CPchip VHDL model in preparation for the CPM tests. He has checked both real time and readout operations. The module itself had its first power on test recently at RAL. He still has to upgrade local systems at Birmingham to RedHat 7.2 but hopes to learn from Bruces experience first.Steve: simulationSteve has also mostly been working on cabling document spreadsheets. He has however done some work on the CPROD simulation, integrating the Bill Stokes test vector generation into his simulation framework. Some information, eg ROD source ID and ROD firmware types, ought to come from the database so more work on integration with the database is required. Moving to use CMT is also a priority.Bruce: module services, systems, ROSBruce has been busy developing the module services. There is now a library for each of the modules he is responsible for. He continues to migrate the "looper" ROD test program to the module services style.He has also upgraded one of the Concurrent CPUs to RedHat 7.2. This was not straightforward - but possible memory problems on the board are suspected. He finds that the Hannappel VME driver does not compile under RedHat 7.2 (or more specifically with the 2.4 kernel). So he is presently using the recently developed ATLAS VME driver code from CERN. This should be integrated into HDMC as a new VMEBus subclass. Bruce also reported that the ROS software distribution was now expected very soon - it only needs an accompanying email from Dave Francis. Thomas: JEMThomas and Andrea have been working on the JEM0 and are looking at using the DSS. Thomas has also been in contact with Sam about the JEM simulation software.One bit of good news is that Mainz will have a new PhD student (Michael Bussmann) starting in June who will spend one year working on JEP software. Norman: various statusRegarding hardware, Norman reported that the new crate had been successfully used to send VME-- cycles to the TCM. The CMM had also been powered on. Discussions have started on setting up a production.maintenance database for the modules and providing a protected web space for exchanging fault reports with the engineers.Norman has continued work on the data formats document which is now nearly complete. Norman also reported on the continuing work of the ROD crate DAQ task force. There are some varying views on how buffer management should implemented. [A new version of the draft document is now available]. ScheduleMurrough reported that the UK people expected to be preoccupied with developing the slice test software for the CP system for the next couple of months (at least). Unless there was a pressing need, it would be easier to get that into a reasonable shape before trying to extend it to the JEP and PP subsystems.Thomas thought that this timescale probably fitted the expected JEM developments. They will need one or two months more low level work on the JEM0. Thomas: calibration meetingThomas has arranged a meeting with LAr representatives to discuss the issues around our calibration requirements. This will be at 6pm on Thursday 18 April at CERN (unless we can find a date when Bill Cleland can also attend).We should also aim for something similar with the TileCal group. Norman: DIG mattersThe DIG training sessions are now both arranged and our participation has been registered.Another DIG task force is being set up to discuss detector database requirements. Murrough will be our representative. Norman: DAQ overview guideNorman took us through the first draft of an overall guide to our DAQ software. This is intended to give the big picture of how we expect everything to work together. So far he has the essentials of the main use case, ie taking the system from the powered off state through to starting and the stopping a run. More detail is required, eg in the area of databases. Some other aspects, eg use of the ROS, handling of L1As, etc need to be covered. Norman will incorporate comments and produce another draft.Murrough: online software review processThe Online software group recently initiated a review of its overall requirements and those of its component packages. However it was felt by other parts of TDAQ that more time was needed for this process. The various draft requirements documents can be found here.PS (after the meeting) a working group is being set up to discuss the Online software requirements. We are invited to propose a representative. Murrough: accessible systemAt the Heidelberg meeting, it was suggested that we try to set up a test system, accessible to all members of the group, where the Online software and our software were installed so that people without experience of the Online software could try it.Given the RAL firewall, it isnt straightforward to set up such a system at RAL. Building our software at CERN and making it available via AFS may be better but requires some work. We agreed that having this was not urgent at the moment. BrainstormingAfter the phone conference, the UK people held a brainstorming session to discuss a couple of issues. Being rather free ranging and based around a whiteboard these are more difficult to summarise, so only very brief notes are included below.L1A handlingThe basic idea is still to use the DSS to generate 32K samples of TTC information (L1A, ECR, possibly ORBIT and perhaps the trigger type) using the new general IO daughtercard. We want to allow for long waits after the (roughly) 32K samples have been issued in order to reduce the minimum L1A rate. However this may mean we cant use the DSS to generate the ORBIT as the local bunch counters in the TTCrx chips would overflow. The details of the required DSS firmware changes were decided. The use of TTC broadcast commands needs to be checked and we should also check in detail the use of all the TTC signals.DatabasesMurrough was grilled on the present implementation and plans for our use of databases. Some constraints on how we organise our database come from the existing Online software database. Linking of cable and firmware configuration to the other hardware configuration could be better - but would require support from the core Online database (probably). Given the hierarchical description in terms of detectors, how should cables between different ATLAS detectors be included?We agreed we will need many sets of calibration data and ways of moving between different calibrations (or phase space of calibration parameters) in multi step runs. The general idea of hiding the different types of database behind a single "facade" database object which could be passed to module services classes was agreed. This set of classes should have a stable and documented API. The database infrastructure to describe the various types of test run, including test vectors and simulation output still needs to be defined. Next meetingThis will be a video conference between RAL and Mainz on Thursday 2 May.ActionsActions from this and previous meetings:
Last updated on 11-Apr-2002 by Murrough Landon |