Level 1 Calo Software Meeting at RAL on 11 February 2000.
---------------------------------------------------------

Present: Murrough, Scott, Tara, Bruce, Norman, Eric

The draft agenda was as follows (though some items were reordered
and some not covered due to lack of time):

- choice of VME standard                   [Norman     10']
- progress with HDMC in the UK             [Scott      10']
- status of Kithsiris work                 [Bruce      10']
- discussion on Diagnostics....            [All        10']
- progress with old/new DAQ systems        [Various   >30']
  * carving up the old DAQ
  * starting afresh with DAQ -1 (ProZAQ)
  * towards DAQ groups ROD crate DAQ?
  * ROOT
  * network VME from Linux
- report from DIG meeting at CERN          [Norman     10']
- discussion on DAQ directions....         [All       >30']
- other topics
  * configuration database?
  * final DAQ use cases?
- report from ROOT workshop                [Tara       10']
- future workplan
- next UK and/or video meeting


Choice of VME Standard
----------------------

We are desperately short of backplane pins in the CPM and JEM crates.
The engineers would like to implement only a reduced A24D16 VME, without
interrupts and various other parts of the standard. At the same time we
would like to have geographical addressing which is part of the VME64ext
standard.

A separate issue: could we use VME protocol with 3V instead of 5V signals?
This suggestion provoked a horrified response at the recent DIG/ROD meeting!

Problems will include: interfacing standard VME modules (eg CPUs) to crates
with non-standard VME; also modules such as the TCM which will also sit in
the PreProcessor crates which are (somewhat) less constrained.

We thought that we probably didnt need interrupts, but the VME issue needs
further thought and discussion. If we diverge from VME so much, should we
just go for another bus or define our own protocol?


HDMC in the UK
--------------

Scott has implemented all the DSS and TTCvi registers and memories but
gets segmentation faults when adding large memories. This is fairly but
not completely reproducible. He has reported this to Cornelius, but they
dont see such problems at Heidelberg.


Status of Kithsiris work on the TTCvi
-------------------------------------

Bruce has received some code updates and a status report from Kithsiri.
See here.

The TTCvi code wont compile on (68K) LynxOS, so it must be used via network
daemons. There is a standalone program and also panels integrated into the
UK diagnostics.

For tests of LVDS susceptibility to the reported jitter on the TTC clock,
this code is needed urgently at Birmingham. [As of 17-Feb this is now done].


Discussion on Diagnostics Software
----------------------------------

We are still updating the UK diagnostics despite a decision in principle
to move to use of HDMC. The UK people still want extra features in HDMC.
We should again list these and get them implemented - probably by a UK
person as Cornelius and Volker have no time at the moment.


Progress with and discussion of DAQ Software
--------------------------------------------

Last year, and again at the recent UK meeting, Norman presented
(see slides)
a picture of a parallel strategy for DAQ development which showed two
converging paths:
(a) a DAQ -1 based system incorporating elements of the existing DAQ
(b) continued development of the existing DAQ system, gradually incorporating
    elements from the ATLAS DAQ -1 suite

He fleshed out the details of option (a) and gave the recent progress:
code for obsolete modules has been removed leaving only the DSS and the old
TCM; all the C code has been fixed to compile with the C++ compiler.
Future work will include: removing run control aspects from daqctl, leaving
is as a standalone database editor; using network VME in daqprod and moving
to OO Module classes; using ROOT in daqana and ditching HMINI and friends.
An updated version, v425 has been installed in CVS.


At the end of last year, Murrough produced a completely DAQ -1 based DAQ
skeleton with a view to pursuing Normans option (a). This was added to our
CVS repository under the name "prozaq". This uses the integrated GUI and
the OO database to start a simple run controller which in turn starts
(empty) producer and analyser programs. Murrough saw the future work
(see slides)
as mainly common to both approaches with significant effort required in
defining the new database and implementing the database editor; creating
Module classes using common infrastructure with the software used for
diagnostics; etc.

Meanwhile the pressure from detector groups (including ourselves) for
the DAQ group itself to provide a test beam and ROD crate DAQ solution
has finally resulted in more attention being given to that. We may be
invited to help develop it.


In the discussion during the meeting, and a few days later at a separate
software strategy meeting, it was felt that we do not that the available
manpower to pursue the two parallel paths. It was also felt that we needed
a working DAQ system incorporating the TTCvi continuously. So, even if the
option of gradually evolving the existing DAQ might involve more effort
in total, we will follow that route.


Report from DIG meeting
-----------------------

Both Norman and Eric attended the recent DIG meeting at CERN.
The main points were:
- the DAQ -1 open source proposal was welcomed (but its only
  for the Back End).
- proposals for the test beam/ROD crate DAQ for the summer were
  presented. It looks like its going to a bodge in the short term.
	Eg analysis programs will have to run off event data saved into
	files, ie no decent buffer manager will be available.
- our suggestion of breaking the 5V VME voltage standard is not
  favoured by anyone else


Use of ROOT and the recent ROOT workshop
----------------------------------------

Tara mentioned that the shared libraries in the latest version of ROOT
are incompatible with the previous version.

He recently attended the ROOT workshop. It is being used in industry
and by many experiments, especially at Fermilab who have their own
support team for it. However there was very little ATLAS representation.
It looks like there is likely to be a wide user community (there have
been 60000 downloads of the software), good support and ongoing
development at least for the medium term (eg a Java-ROOT interface).

Remaining problems: support for external libraries (eg CLHEP) is still
missing; also there is no overall coherent documentation (though all
classes have documentation of their methods etc).

So far ATLAS is sitting on the fence in the ROOT vs LHC++ holy war.
But we need a solution now - while it seems that LHC++ is in the throes
of being completely rewritten.


Status of our CVS repository
----------------------------

Tara summarised the packages and tagged versions currently in CVS. These
are now listed on his web page.
Since very radical changes were being made to the "daq" package, we
decided to separate the new developments from the old, renaming the ancient
and the more recent versions as "daq413" and "daq421" with forthcoming
developments keeping the "daq" label. The ancient DAQ now also includes
the complete set of what is now labelled "daqclibs" for reference.
	

Next meeting
------------

We will aim for a video conference with Heidelberg on Tuesday 14 March.
Meanwhile, Bob Jones will visit on Friday 25 February.