ATLAS Software Workshop Minutes

CERN, November 24 - 28, 1997

Day
Mon	Topic	Gilbert Poulard: Introduction into Atlas Software/Fortran Software
	References	Transparencies: Web
	Summary	N/A
	Decisions	N/A
	Actions	N/A
	Topic	Helge Meinhard: Introduction into Atlas Software/OO and ASP
	References	Transparencies: Web
	Summary	N/A
	Decisions	N/A
	Actions	N/A
	Topic	Lassi A. Tuura: Introduction into Atlas Software/CVS and SRT
	References	Transparencies: PDF, PS/GZIP, Thumbnail PS/GZIP
	Summary	N/A
	Decisions	N/A
	Actions	N/A
	Topic	DIG Meeting
	References	N/A
	Summary	N/A
	Decisions	N/A
	Actions	N/A
Tue	Topic	Jürgen Knobloch: Introduction, Agenda
	References	N/A
	Summary	N/A
	Discussion	N/A
	Decisions	N/A
	Actions	N/A
	Topic	Rudiger Voss: Muon software/Overview, DICE integration
	References	Transparencies: PDF, PS
	Summary	N/A
	Discussion	N/A
	Decisions	N/A
	Actions	N/A
	Topic	L. Chevalier: Muon Software/Geometry database, magnetic field, patter recognition
	References	Transparencies: PS
	Summary	N/A
	Discussion	N/A
	Decisions	N/A
	Actions	N/A
	Topic	Patrick Hendriks: Muon software/OO pattern recognition for DATCHA
	References	Transparencies: PS
	Summary	N/A
	Decisions	N/A
	Actions	N/A
	Topic	Julius Hrivnac: Graphics/Status and plans
	References	Atlantis picture data base Wired home page A more detailed description of usage of JavaBeans in Wired Summer student Eberhard Wolf's talk on the subject.
	Summary	N/A
	Decisions	N/A
	Actions	N/A
	Topic	Hans Drevermann: Graphics/Atlantis
	References	Transparencies: Web
	Summary	N/A
	Decisions	N/A
	Actions	N/A
	Topic	Marc Donszelmann: Graphics/Wired
	References	N/A
	Summary	N/A
	Decisions	N/A
	Actions	N/A
	Topic	Andrea dell'Acqua: OO simulation
	References	Transparencies: Web
	Summary	N/A
	Decisions	N/A
	Actions	N/A
	Topic	Control domain strategy discussion
	References	N/A
	Summary	N/A
	Decisions	N/A
	Actions	N/A
	Topic	Database meeting
	References	Group pages, meeting agenda, minutes.
Wed	Topic	LHC++ team: LHC++ Roadshow
	References	Roadshow Description
	Summary	N/A
	Decisions	N/A
	Actions	N/A
	Topic	Elzbieta Richter-Was: ATLFAST status and plans
	References	ATLFAST home page
	Summary	N/A
	Decisions	N/A
	Actions	N/A
	Topic	Rene Brun: ROOT and ATLFAST
	References	N/A
	Summary	N/A
	Decisions	N/A
	Actions	N/A
	Topic	Fons Rademakers: ROOT and Objectivity data
	References	N/A
	Summary	N/A
	Decisions	N/A
	Actions	N/A
	Topic	Reconstruction meeting
	References	N/A
	Summary	N/A
	Decisions	N/A
	Actions	N/A
	Topic	World-Wide Computing Group
	References	Group pages, meeting agenda, minutes.
Thu	Topic	Jürgen Knobloch: ACOS report
	References	Transparencies: Web
	Summary	N/A
	Decisions	N/A
	Actions	N/A
	Topic	Laura Perini: LCB report
	References	LCB home page (includes minutes) LHC++: general, licenses, license costs, distribution
	Summary	N/A
	Decisions	N/A
	Actions	N/A
	Topic	Gilbert Poulard: FOCUS report
	References	N/A
	Summary	N/A
	Decisions	N/A
	Actions	N/A
	Topic	Gilbert Poulard: COCOTIME report
	References	Transparencies: Web
	Summary	N/A
	Decisions	N/A
	Actions	N/A
	Topic	Helge Meinhard: DIG report
	References	N/A
	Summary	N/A
	Decisions	N/A
	Actions	N/A
	Topic	Helge Meinhard: GNATS report
	References	N/A
	Summary	N/A
	Decisions	N/A
	Actions	N/A
	Topic	Jürgen Knobloch: Collaborative tools
	References	Transparencies: Web
	Summary	N/A
	Decisions	N/A
	Actions	N/A
	Topic	Maya Stavrianakou: MC consolidation
	References	N/A
	Summary	N/A
	Decisions	N/A
	Actions	N/A
	Topic	Roger Clifft: Reconstruction domain report
	References	N/A
	Summary	N/A
	Decisions	N/A
	Actions	N/A
	Topic	Traudl Hansl-Kozanecka: Trigger domain report
	References	N/A
	Summary	N/A
	Decisions	N/A
	Actions	N/A
	Topic	ASP related topics
	References
	References	Agenda and some background material. Transparencies: - Chris Onions: N/A - Rosemary Candlin: PS - Steve Fisher: Web, Power Point - Julius Hrivnac: Web - Helge Meinhard: Web
	Summary	The agenda dealt with some topics where ASP procedures had not yet been defined as well as with possible improvements to be made in review and ramp-up procdures. Because the original meeting was rescheduled, the order of the agenda had to be changed to allow various speakers to go to other meetings. Also, there was not enough time to cover everything on Wednesday, and we decided to continue on Thursday afternoon. Use of the CVS Repository (Chris Onions) Lassi had already given a presentation on Monday morning, but here we were more concerned with defining the way in which in which various users interact with the repository. Chris identified some areas where we needed to define procedures: Conventions about tagging (choice of name and version numbers) Who sets a tag (the programmer or the Software Librarian) When is a product stamped (after a review? and after repairing a bug?) Testing (Rosemary Candlin) The first meeting on testing took place on the last Friday afternoon of the last workshop, and there was no chance to report it then, Rosemary recapitulated the suggestions that had been made then, which are provisionally incorporated in the current ASP. The slides are based on these suggestions. Note that the slides speak only of "classes". We should also include "packages", considered as a set of classes reviewed together. The procedures suggested are based on what we can realistically expect developers to do in our circumstances. We got some input from Bob Jones, who has to face the same problems with the online software. We identified the various kinds of tests that were needed: to check the correctness of the code, to check compatability with known physics results and to check compliance with performance constraints. We suggested the people who should be responsible for different types of testing and when they should ensure that it is done The person responsible for a package design should supply a test plan describing what tests are to be carried out and how. This plan should be submitted at the design review. Class implementers should provide black box tests for all their non-trivial methods and supply the tests and their results to the code review where their classes are reviewed for the first time. Programmers will be expected to have carried out adequate white box testing before the review (ie checking that instructions execute in the expected order), but white box tests will not be reviewed. Where classes appear for the first time within a package, it may be appropriate to test individual classes within the context of tests of the package conssidered as a whole. It was not considered necessarily appropriate to insist that classes should have a "test" method and this suggestion was rejected. Implementers should test that their code runs on all supported platforms. If comparison data exists at the time of the code review, the implementer should show that his code produces results that are consistent within the desired accuracy. If no comparison is possible, the Software Librarian has the responsibility of organizing tests once the relevant data become available. If stated performance constraints are already known at the time of code review, the implementer must present tests showing that show that the code satisfies the constraints. The Software Librarian is responsible for organizing further tests if the constraints (or the platforms) change. Note that we don't say anything about the form that tests should take, but we do say that reviewers should ensure that they are suitable. We may provide some rules/guidelines in the ASP, just as we do for designs and code. Reviews and Ramp-ups (Steve Fisher) Feedback on the review process. Steve reported on feedback from design reviews and ramp-ups. The experience of reviews was perceived as generally positive by those reviewed, but Steve wished to encourage designers to get their rough designs checked by 2 or 3 people at an early stage so as to avoid the situation where there is severe criticism of the principles of a design at the formal review. We decided that this was a question of changing the culture of the collaboration, rather than anything that could be defined in the ASP. It was pointed out that an important part of a design review was to identify inadequacies in the requirements definition, and that these should be reported to the Moderator, who will then pass on criticisms to the domain. Feedback on the design report. There have been complaints about the illegibility of the document - diagrams too small, and unstructured ASCII text. Steve is looking at these problems, but pointed out that some diagrams contained a lot more than the recommended 7+-2 boxes. Juergen queried whether documents had to be in StP, since some people were already used to other (nicer) tools. There are strong arguments against this, particularly that documents could not be automatically generated and checked, and that developers would need to make use of classes defined in a single repository. The question of a change of CASE tool will be raised again in the LCB CDE group and we may wish to reconsider our choice again. Code Reviews. Steve now has a proposal for the CodeReport. It can be tried out at the first Code Review (for Patrick Hendricks). External Packages (Julius Hrivnac) Julius emphasized that external packages were likely to be increasingly important and that we should have some established criteria for accepting or rejecting a package. He listed the different types of product: cern produced, cern maintained, commercial packages etc. He suggested that before a package was accepted it should undergo an evaluation by a group of referees, who would fill in a questionnaire covering such aspects as: usefulness quality level of support needed how much do we depend on it source availability design availability The referees may also suggest further tests to be carried out before a decision is made. The questionnaires would be returned to the DIG for decision and not to the person or domain who made the original request (though obviously they should be informed). There are still outstanding questions to be considered. Will it be be held under the SRT? How are dependencies to be identified and managed? Can we allocate a quantitative risk value to a package and match this against a required quality level of our product? Program should run even if some package is not available Some packages are required all the time Maintenance (Helge Meinhard) Helge had already reported that Gnats was now available for fault reporting, so he was mainly concerned with establishing maintenance procedures. Who is responsible for fixing bugs? Original authors? (not really feasible for Atlas, where PhD students leave after a couple of years?) Community to which the authors belong? Package maintainer? Master librarian? Anybody else? What does it cover? Bug fixes? Responses to changed requirements? Other improvements?
	Decisions	Use of the CVS Repository (Chris Onions) Chris will get together with Lassi and Maya to produce a proposal for the next software meeting. Testing (Rosemary Candlin) We decided to go ahead with these proposals, apart from the question of test methods, and to incorporate them more formally in the ASP. Steve and Rosemary will look at additions that need to be made to the design and code reports to deal with incorporating tests and their results with the rest of the text. The first versions will be ready for the next software workshop. Reviews and Ramp-ups (Steve Fisher) The evaluation at the beginning of a possible ramp-up should be passed back to the domain, who willdecide what is to be done next. Reviews and Ramp-ups (Steve Fisher) We stick with StP for the present, and designs that have already been produced with another tool must be converted before review. Steve will define the Code Report in detail and will work on improving the appearance of both that and the Design Report. Kors suggested that there should be a public presentation after a successful design review. This was thought to be an excellent idea, and to be encouraged, but not a matter for the ASP to set down rules. External Packages (Julius Hrivnac) Julius will write up his suggestions and design the questionnaire. Maintenance (Helge Meinhard) We thought that the domain as a whole should be responsible for maintenance of its own packages, and that it should nominate a person or persons for the task. They will be responsible for dealing with any changes of the three types mentioned above. Helge will write up this proposal.
	Actions	Chris, Rosemary, Julius and Helge will write up their various proposals in a form suitable for the ASP and will make them available separately from the main ASP document as soon as possible, and anyhow before the next Software Workshop. Steve will make proposals about the Code Report and about changes to the Design Report so as to cover testing. He will make the necessary changes in any ancillary documents (such as for those review procedures). Rosemary will update the User's Guide to add any relevant new information.
	Topic	Combined muon performance with Arve
	References	N/A
	Summary	N/A
	Decisions	N/A
	Actions	N/A
	Topic	Control domain working group
	References	Agenda
	Summary	N/A
Decisions	N/A
Actions	N/A
Fri	Topic	Steve Fisher: Control domain issues
	References	Transparencies: Web
	Summary	The most important decisions are summarised below: finalise ramp-up of ARVE implement L. Tuura's component model in ARVE framework (this model is believed to be forwards compatible with Java Beans) continue development with Java Beans (possible future solution) accept LCB milestone for control framework by April '98 in conjunction with 1) and 2) recommend publicly ARVE as a framework for reconstruction in C++ test pursued options with USE cases consider (no decision taken) the choice of scripting language
	Decisions	N/A
	Actions	N/A
	Topic	Rosemary Candlin: ASP working group report
	References	N/A
	Summary	Using cvs/srt (original presentation by C. Onions) C. Onions, L. Tuura and M. Stavrianakou are to come up with a proposal for the use of the repository and the role of the librarian. Testing (original presentation by R. Candlin) Substantial decisions were made; it now remains to be seen how they work out in practice. Some of these decisions are summarised below: Design submitters are required to also submit a test plan. Code will be subjected to black-box testing which will have to be documented and submitted together with the results. Further tests regarding accuracy, performance and other quality features are to be investigated. The software librarian will be responsible for organising (not necessarily carrying out) the tests. Feedback from reviews and ramp-up (original presentation by S. Fisher) There is concensus that these are useful procedures. Problems (would) appear if/when a reviewer disagrees with the whole principle of the design. This can probably be prevented by carrying out earlier, informal reviews. It was agreed that the results of a ramp-up should be passed on to the domain for further action. The rule for freezing a product under ramp-up is waived as unrealistic. The issue of the choice of StP as the required tool for producing design reports was raised and various arguments against it (different choice in Geant4 team, user-friendliness), as well as for it (uniformity of style for the reviewers, use by online community as well) were debated. The issue will be reconsidered in spring '98. A. Reichold requested that more textual annotation (explanations, justification etc) be added to design documents. It was agreed that such annotation should be presented in a 'structured' form rather than plain text for readability. External software (original presentation by J. Hrivnac) A questionnaire for 'reviewers' of external software will be compiled by J. Hrivnac. Maintenance (original presentation by H. Meinhard) H. Meinhard will prepare a proposal for a maintenance procedure.
	Decisions	N/A
	Actions	N/A
	Topic	RD Schaffer: Database working group report
	References
	Summary	It was pointed out that database naming conventions have to be established. Following the proposed scheme for Geant3 digit implementation in Objectivity, access to Inner Detector digits (and maybe muon system as well) is foreseen for January '98. Event collections (original presentation by M. Schaller) should have an STL-like interface and be limited to as few container types as possible. A versioning mechanism for Objectivity (original presentation by A. Perus) primarily for detector description, calibration and alignment, based on a model analogous to cvs was proposed; a working prototype will be available in January. Other presentations included a status report on CDF Run-II data management with Objectivity by K. Sliwa and a proposal for a common LHC computing project on Mass Storage by ALICE.
	Decisions	N/A
	Actions	N/A
	Topic	Gilbert Poulard: Reconstruction group report
	References	Transparencies: Web
	Summary	The status of and plans for the various packages were presented. A full OO version of IPATREC is in preparation; an intermediate release is foreseen for end '97. I. Gavrilenko's plans for the OO version of XKALMAN (XKALMAN++) and some further input from S. Qian were presented. I. Gavrilenko, S. Qian and S. Almehed are encouraged to collaborate on the XKALMAN++ development. The ASTRA design is nearly finished. An interface to IPATREC has been implemented and is being tested. Following this part of the presentation, the OO migration and ASP compliance issues were discussed. It was agreed that it is important to adhere to the ASP defined practices. However, it was also understood that the developers are essentially going through a learning phase, where training and mentoring should be provided and the outcome of this phase (prototypes) is not to be viewed as 'official' software. The status of other reconstruction topics (calorimetry, e/gamma strategy, combined muon and inner detector reconstruction) was also presented. The event-filter group request for offline code (preferably in C++) to be run in the context of the DAQ Prototype -1 was discussed. As a possible first step, the developers could identify the points were performance vs speed trade-offs are feasible. This could be aided by profiling tools (to be pursued by S. Jarp). Following up on the issues of the OO migration and the ASP compliance, which, as pointed out by H.P. Wellisch should be viewed as two distinct steps, it was agreed that further training (volunteered by S. Fisher) will be provided at the next software week.
	Decisions	N/A
	Actions	N/A
	Topic	Helge Meinhard: World-Wide Computing Group report
	References	Agenda, Minutes
	Summary	N/A
	Decisions	N/A
	Actions	N/A
	Topic	Jürgen Knobloch: Summary of decisions, planning on next cycles
	References	ACOS transparencies: Web
	Summary	proposal for ACOS computing appendix of MOU : see text DIG decisions: proceed with code reviews review choice of design tool in April '98 lift g++ compliance requirement muon software: deadline for production 05/12/97 OO pattern recognition in DATCHA: interest in investigating extension to general muon reconstruction graphics: request support for graphics (J. Knobloch to contact G. Koelner) consider design review concluded LHC++ roadshow: various arguments for and against; interface for analysis environment to be further evaluated; suggestion to 'export' roadshow to outside institutes; suggestion for ATLAS/LHC++ update at the next software week ATLFAST: include FORTRAN version in official repository consider inclusion of C++ version in 'user software area' ROOT: following a mail by K. Sliwa summarising his impressions from the presentation, it is agreed that: criteria for proper evaluation and comparison should be established a clear disctinction should be made between short-term solutions and long-term products 'Thursday' reports: investigate HyperNews system (C. Onions and R. Jones) 'revive' LIGHT (J. Knobloch to discuss with G. Kellner) proceed with consolidation and cvs/srt migration as planned Reconstruction domain: Bridge gap with reconstruction working group Bi-weekly software coordinator's report (as proposed by J. Knobloch) (see also the first report) Dates of next workshops
	Decisions	N/A
	Actions	N/A
	Topic	ACOS meeting
	References	N/A
	Summary	N/A
	Decisions	N/A
	Actions	N/A