In December 2000 the Multi-Language Commission (MLC) was set up by the Computing Co-ordinator, in consultation with the CSG, with a membership of Julius Hrivnac (Orsay), David Quarrie (LBNL), and Marc Virchaux (Saclay). The MLC presented its final report at the end of September; the report was made public within ATLAS and comment invited. The issue was discussed at the CSG meetings of 26 October and 7 December 2001. This document summarises the decisions that arise from that meeting and some subsequent e-mail discussion.
It is worth noting at the outset that, in common with all the LHC experiments, ATLAS already deploys several languages (including C++, JAVA, Fortran, IDL, and Python) across the full range of its software: the focus of the MLC was on the the languages to be used for 'algorithmic' code ( for simulation, reconstruction, and analysis) and the associated 'core' software, and what the ATLAS policy should be with regard to the use of the various languages in these areas.
The MLC report ( http://atlas.web.cern.ch/Atlas/GROUPS/SOFTWARE/OO/architecture/General/MLC-Recommendation.txt) consists essentially of four recommendations:
The CSG is grateful to the MLC for these carefully-considered recommendations. The CSG recognises the growing use of JAVA and agrees that it is, in important respects, a simpler language than C++. On MLC.2, the CSG is not, however, ready to endorse the immediate launch of a significant effort to re-write the framework in JAVA. It is already policy that the framework should be developed with a watchful eye on a possible change to JAVA in the future, but the CSG feels that the present state of ATLAS software, combined with the imperative of testing that software through the first round of Data Challenges (DC0,1,2), means that the earliest such a change could be deployed is after DC2 (end 2003).
Development work could of course begin earlier, but this would require careful planning of the effort required, and of course the availability of such effort. As with other 'strategic' computing choices for the LHC, such a move would also require consideration of the strategy and intentions of the other LHC experiments and plans for major software components (e.g. Geant4). In short, the CSG's decision on MLC.2 is to keep the situation under review, noting that a JAVA version of the framework is not feasible until after DC2 at the earliest.
Turning to MLC.1, the CSG accepts the idea of a "restricted" multi-language policy in the sense that, although the framework language as well as the recommended development language must remain C++ (at least for the foreseeable future), well-encapsulated modules written in Java or F90/95 can be accepted as long as they are provided with proper C++ interfaces to the framework. In the spirit of MLC.3, the responsibility of the development, writing and maintenance of these interfaces lies with the Java or F90/95 developers themselves. The only additional responsibility on the framework developers should be to ensure the availability of Java and F90/95 support in the software management tools and to make sure that the general C++ interfaces of the framework are kept as simple as possible, avoiding language-dependent features as far as possible. They should also push the idea of a genuine modularity of the code as far as possible.
As is the case for any major new piece of code which is to be included into the general Atlas software, the CSG would like to be informed at an early stage of the project, and to be assured of the long-term maintenance of the code. This procedure applies independent of the choice of language. (Issues such as compatibility with the general framework, code quality, memory usage and speed, will be checked by the broader ATLAS Physics and Computing community, including the software QA group.)
On MLC.4, the CSG notes that a certain amount of F77 code will have to be handled probably for some considerable time. The CSG does not wish at this time to commit to a re-write of this code. However, as the F90/95 language is compatible with F77, replacing F77 compilers by F90/95 ones should require a minimal amount of work and would eventually be desirable, and may even become necessary.