This LHCb/ASD meeting was organised with the aim of improving LHCb/ASD co-ordination, specifically by

• providing an opportunity for LHCb and ASD to exchange views on software environment and directions,
• having someone from LHCb explain the LHCb software strategy so that the background for LHCb comments and requests is understood, and
• clarifying the process for accepting/rejecting and prioritising requests for LHC++/RD45 developments.

This was a very positive meeting, with much common ground on software issues even if the issues are approached from different directions. The detailed discussion points and issues of concern are recorded below. Overall, though, there were two main conclusions.

1. Well-defined interfaces for software components of analysis and reconstruction packages appear to be the correct way forward, although more work is needed in this area, in particular to understand the cross-experiment issues.
2. A revised set of meetings is needed to bring together ASD developers and the LHC experiments to properly review and prioritise various requests for LHC++ and RD45 developments.

ASD group agreed to reflect on these two points and return with proposals in the near future. These proposals would be discussed initially with LHCb but then with all of the LHC experiments.

A key factor in LHCb software process is the need to cope with user (i.e. physicist) requirements. This means that some options (e.g. allowing a mix of Fortran/C++) are supported through necessity rather than choice. LHCb have developed the GAUDI architecture for their software. Within this architecture, the intention is to reuse externally developed software wherever possible, developing only software that is LHCb specific or unavailable elsewhere.

This desire to reuse external software leads to concern about how software from many different sources can be integrated. There are particular concerns if use of an externally developed package requires the use of yet other libraries that create incompatibilities. LHCb feel the need for a HEP-wide software integration model to cover issues such as interface specifications, naming, error codes and versioning.

Dirk Düllmann commented that whilst this may be desirable, it requires agreement between experiments—ASD would certainly accept some rules but can't be expected to follow 4 conflicting sets. Pere Mato agreed with this but felt that the developments with HTL had been a good start and were a basis on which to build awareness of the issue.

LHCb's primary hardware platforms are Windows/NT (the principal development environment) and Linux (the platform preferred by physicists and used for production work). Some support is required for HP-UX as this is used for production work in some external institutes. In response to questions from David Jacobs and Dirk Düllmann, Florence Ranjard confirmed that LHCb has no requirement for HPUX 11, but that ASD software should be supported for use with the egcs 1.1.2 compiler rather than the native HP compiler.

There was more discussion about the level of support that LHCb could expect in future for ASD software running on Windows/NT. From the LHCb side there is a strong desire to profit from the advantages of the Windows development environment and a feeling that supporting software for both Windows and Linux is required to avoid being locked into one particular environment. From the ASD point of view, LHCb is the only experiment requesting support for Windows/NT and so such support is not high on the list of divisional priorities. There was some feeling on the LHCb side that this was a chicken and egg situation.

LHCb are currently using C++ but are also evaluating Java as an alternative. In part this is due to pressure from the user community: much pressure to investigate Java comes from physicists who are told that Java is a much simpler language to learn and to use and is more truly object oriented. They therefore wonder why they should be expected to migrate today from Fortran to C++ rather than straight to Java. LHCb felt that, if the current prototyping work gives promising results, then the clamour to use Java will increase strongly. In this case they also felt that ASD should take a leading role in preparing for a move to Java.

Discussion around C++ issues was brief. There was common agreement on the compilers (Visual C++ for Windows and egcs for Linux). Although ASD have not yet been using the latest C++ language features (e.g. namespaces and templates), this has been because these have not been supported by the Sun compiler until recently; now that the Sun compiler supports these features ASD will start to use them.

There was much discussion about the use of Java, however.

ASD have little experience with Java as yet and this, added to the difficulties of supporting a mixed Java/C++ environment meant that it would be difficult for ASD to take a lead role in any Java developments. People from LHCb, however, felt it important that there should be a strong central co-ordination of Java developments—this would help to ensure agreement on a common core of utilities and avoid the proliferation of multiple alternatives for particular tools.

It was agreed that Java/C++ integration is difficult. There was concern on the ASD side that some C++ code would be needed in the reconstruction packages for performance reasons, but people from LHCb felt that the reconstruction and analysis packages would have to be in the same language as some 're-reconstruction' would be required during analysis work. Whilst there are concerns about performance of Java code today, this is not felt to be an issue in the long term as optimised "just in time" compilers are becoming available. In the short term the advantages of Java for development probably outweigh the performance disadvantages.

The major problem in moving to an entirely Java based solution would be the rewriting of GEANT4 in Java. However, a Java based environment with GEANT4 remaining in C++ would not be as difficult to develop as an entirely mixed Java/C++ solution.

There was common agreement on the need for a basic set of foundation libraries to be used as the basis for building higher software layers. Today the set includes STL, CLHEP and the NAG C library but libraries for, e.g., histograms and ntuples, particle properties etc., should be added to the list. It is important to LHCb that these libraries (and their interfaces) be defined within the integration model.

LHCb have chosen to separate the persistent and transient representation of objects and believe that the validity of this choice is demonstrated by the ability to use different persistency solutions today (such as Zebra, ROOT I/O and XML) and the ease with which Objectivity/DB or Expresso could be integrated in the future.

In response to a question from David Jacobs, Pere Mato commented that the converters needed to map the persistent to the transient representation added about a 20-30% CPU overhead to an empty analysis algorithm, an overhead that would be expected to decrease rapidly as real analysis algorithms are included. The converter to/from the Zebra format had been the hardest to produce and, in principle, the effort required to produce a converter for an object oriented persistency solution could be reduced, if not eliminated, through the use of a data dictionary.

Discussion about the need for improved interactive analysis tools exposed a key issue—the conflict between developers of integrated packages and users who wish to be free to integrate the best components of multiple such packages using their own framework. Notably, Dino Ferrero Merlino commented that "Gaudi is so central that it will always break up whole packages provided elsewhere" and that "Gaudi is a wall between halves of ROOT". Pere Mato agreed with this analysis but replied that the halves of ROOT represented different domains and that LHCb (and others) should be free to pick the best tool in each domain.

David Jacobs asked how developers of interactive analysis tools could be expected to cope with the integration demands of 4 different experiment frameworks. Pere Mato replied that the key was the definition of the interfaces to the packages. In response to a comment from Dirk Düllmann that a general package interface might lead to a performance penalty, Pere Mato replied that not having such an interface would lead to a cost in terms of repeated development of software packages and difficulties for the end users. LHCb feel a strong need to use packages provided elsewhere rather than writing software themselves and an integration framework together with defined interfaces for software packages allows this. It was pointed out that this need not be a "one way traffic". Software packages, such as a messaging library, were being written by LHCb and could be used as a foundation by ASD and by other experiments.

John Harvey asked if it wasn't important now to define the different components that might be needed as part of an overall analysis and reconstruction environment. Andreas Pfeiffer replied that this was happening within ASD and that Pavel Binko is involved in this work.

The advantages of dynamic libraries were understood by all. Apart from the problem of finding the right compiler switches on the various platforms, however, there is also the issue of libraries/interfaces—which library has the correct version of a routine with a given name. Pere Mato agreed that this is a problem, but one that can be solved with the use of a configuration management tool, such as CMT which is used by LHCb. Dirk Düllmann commented that ASD had as yet held off adopting a configuration management tool, hoping that a common tool (perhaps SRT) could be agreed between the LHC experiments.

Following Pere Mato's presentation, there was further discussion on some key items.

Although there are no current problems with LHC++ for Windows/NT, there are problems with CERNLIB which is still much used. The release of a multi-threaded version of CERNLIB for Windows/NT is appreciated but there is still need for a dynamic library. This conflicts, however, with the "no development on CERNLIB" policy. In the longer term, can LHCb expect ASD software to be supported for Windows/NT?

The need to provide HEP-specific Java libraries was recognised, in particular a minimal CLHEP building on existing Java libraries. The extent to which ASD could play a lead role in their development was unclear, however.

David Jacobs was not sure there was any particular message here—LHCb had just chosen to be independent of any persistency solution. Pere Mato did not agree and pointed out that ATLAS had also made this choice. He suggested the focus might need to change to look at the conversion issue rather than just storage. Dirk Düllmann agreed, saying that users wanted control of the view of the data as well as provision of platform independent I/O. He felt that Expresso would offer this, allowing some sort of configurability.

How can differently built frameworks coexist? The direction taken by the interface project was felt to be correct. Unfortunately, attendance at LHC++ meetings where this strategy could be reviewed was felt to be poor. This led to a discussion on experiment and ASD roles and interfaces for product development.

John Harvey presented some slides, which, amongst other issues, drew a distinction between the R&D and Product Development phases for software. Looking at existing meetings, he felt that these were more appropriate to the R&D phase but LHC++ work, for example, is now at the Product Development stage. He suggested that it would be appropriate to set-up more formal meetings, perhaps with the scope for any one meeting limited to a specific component (such as HTL or Expresso) rather than LHC++ as a whole. He felt that in this way experiments could better fulfil their proper "end user" role, especially in terms of formulating requirements, developing use-cases and responding to requests for input from the developers.

David Jacobs commented that defining a more formal role for experiments might ensure that the people present realised that they were present as representatives of an experiment rather than on a personal basis. He felt that the current situation had developed as, historically, LHC++ and RD45 had been under the LCB umbrella and had seen this as the formal body to which they should report. He agreed that changes were desirable and accepted that ASD should return with proposals for a new structure to formalise relationships with the LHC experiments.

David Jacobs remarked that the discussions had mostly centred around issues related to LHC++ and RD45; he asked if LHCb had any concerns with GEANT4. John Harvey felt that GEANT4 has moved even beyond the Product Development phase and that LHCb are just getting started as users. User Support for GEANT4 is potentially an issue, but LHCb are part of the GEANT4 collaboration and are trying to become more active. David Jacobs commented that ASD would be interested in hearing more from LHCb as their use of GEANT4 increases.

John Apostolakis mentioned that providing shared libraries for GEANT4 was under discussion, but perhaps as one-off items rather than being included in the main releases.

Tony Cass, January 4th, 2000