ATLAS Software Workshop Minutes

CERN, May 04 - 08, 1998

Day	Time
Mon	09:00	Topic	L. Tuura: Developing Atlas software with SRT and CVS
		References	N/A
Tue	09:00	Topic	J. Knobloch: Introduction, Agenda
		References	Slides: HTML, PPT
		Summary	Main topics: Arve, Software development environment, operating systems, database and event, SRT and CVS Physics workshop in Grenoble: Current computing situation presented: Last major release of FORTRAN simulation Work still required on Fortran reconstruction First release of OO framework imminent Software process taken seriously Software release tools being implemented Platforms/compilers/commmercial software: few combinations work Offline software plans: Some detailed planning exists, but more detailed milestones required Upcoming milestones: OO reconstruction framework (April 98), 1 TB database prototype (end 98), first OO software release (end 99) Domain decomposition: short descriptions will be prepared of each domain, distributed with invitations to participate. Domain decomposition as a whole needs to be described verbally, too. Next tasks: Arve: Documentation, events from OODB, event display, magnetic field, integration of algorithms, single particles from Geant4, components, user support; Simulation: create Atlas Geant4 team, detector description database, build Atlas G4 framework, test beam simulations; general: get more people involved, improve ASP, establish a detailed plan, analysis strategy
		Discussion	Complaints about documentation/WWW: A major cleanup is foreseen soon.
Tue	09:35	Topic	H. Meinhard: DIG decisions
		References	Slides: HTML, PPT
		Summary	Reviews: graphics design completed by updating design document, SRT awaiting updated documentation, Astra design, muon code, graphics code being prepared Repository policy and structure: Official ([aiming at] ASP compliance), external; contributed can be added later; access restrictions to be enforced; creation of top-level packages needs DIG approval, subpackages the one of superpackage coordinator (DIG advises on request); one responsible per package with commit/tag access, can grant access to (few) more developers; periodic reviews of repository by DIG; Change logging through ChangeLog file at package level; public .h files in subdirectory with package name; MS Studio files can be provided, but not obligatory Arve: head revision inconsistent, being cleaned up; old CLHEP removed; framework prototype project carries on, aimed at finishing in May 98 Round of domains: B field: Map implemented in Objectivity; ID: Pixel clustering being rewritten in C++; Simulation: Setting up Geant4 for cal. test beam, similar for Datcha and TRT, may want to use Arve, geometry data base to be clarified; Event: optimised access to ID digis, working on muons, then calo, aim to have events in Objectivity by August workshop; Graphics: can read ID events, preparing new version of Atlantis, Wired using XML; Reconstruction: xKalman++ well advanced, to treat non-const B, iPatRec being polished, design documents being prepared, MC with non-const B required, Track class design exists and will be discussed by DIG Access to DIG minutes will be simplified Units discussion launched, implications with respect to Geant4 to be understood
		Discussion	Utilities which don't follow the ASP: Where should they go? Contributed software? Is there a need? Where should it reside?
Tue	10:05	Topic	G. Poulard: Status of Fortran software, MC consolidation
		References	Slides: HTML, PS
		Summary	MC consolidation: Motivation was difference of batch and interactive simulation programs. Main problem was Atlsim. Rewrite of major parts in Fortran difficult because of evolving Age code; amount of work not negligible. Beginning of April: restrict scope to a 'limited consolidation': use atgeant, rebank agetof, ffread for batch, I/O version of atlsim, dzdoc, comis, kuip ... for interactive program, otherwise identical components, hence physics will be identical. Milestone: end May '98 98_2 release: Protection against nonsensible data cards in Slug; Dice: missing energy deposit in coil cured by reducing step size; Atutil: bug fixes; Atrecon: iPatRec disabled because library messup, muon box taking multiple scattering into account; Atrig: 403 to be implemented; work going on on combined reconstruction Cvs migration: Event generators, genz, genslug, slug, atrig moved. To be done: dice, atutil, atrecon, atlsim, will take about a month
		Discussion	Why is there still an atlsim on the test area? What is the difference in physics to more recent ones? Changes required to Slug because of SRT Q: If production will be based on CMZ version, why migration of Fortran to cvs at all? A: Because we need to maintain the software for another few years How to integrate C++ parts of atrecon into the cvs repository?
Tue	11:05	Topic	S. Fisher: SDE working group
		References	Slides: HTML
		Summary	Working group with 2...3 representatives per experiment; for Atlas: Bob Jones, Steve Fisher; focused on testing and CASE tools so far For CASE tools, questionnaire developed in order to find out how they are used, and what people expect; influence on evaluation criteria A few alternative CASE tools looked at: Together/J, written in Java for Java, uses UML, simultaneous design and code editing, HTML generation, scripting with tcl; but not very stable, Java only, slow ObjectDomain, shifted from tcl to Java. Supports UML, scripting in tcl, reverse engineering coming soon. Rather slow, not very stable ObjectTeam: UML, tcl scripting, Client-Server; data base is real repository, locking at class level; support for project hierarchy, fast reverse engineering, available on many platforms (not Linux). 3...4 releases per year on all platforms, support for laptops coming Request: make NT programmer-friendly: Asis for NT, Cygnus 19.1, emacs 20.xx, cvs? Documentation standards for manuals: Should we use SGML? If so, with which DTD?
Tue	11:25	Topic	G. Kellner: The role of IT/IPT group
		References	Slides: HTML, gzipped PS
		Summary	Context: 4 LHC experiments, limited resources, common projects being defined by Thursday club and LCB IPT: Common team supporting cross-experiment activities Project of IPT group for a Software Development Environment Need to take care of people, process, and technology IPT: assist in establishing, maintaining, and improving software production process; select, maintain set of SE standards, procedures, methods, tools; share process improvement ideas across projects; transfer by direct participation with projects (up to 6 months); help with customisations and special requirements; watch technology trends; training (just in time - oriented towards needs) Urgent and important issues: Quality assurance, methods and tools for testing, documentation systems and management, project planning and tracking in distributed environment, configuration management, installation models for tools Planning of actions: Determine priorities with input from expts and projects by small working group; set up LCB project on SDE Current size of the group fairly limited; last year's activities: Re-engineering of Opal trigger code, software tools service, configuration management, consultancy on OMT, Light, project management, Wired, mobile agents, testing, FrameMaker support
		Discussion	Q: Is event display part of the mandate? A: Needs to be discussed with the experiments Need to keep in mind that as much as possible, outside collaborating institutes are able to benefit Q: To which extent can the requirements of on-line real-time applications be considered? A: As far as the tools are concerned, this can certainly be done, but at the application level things are probably going to be too different between projects.
Tue	12:10	Topic	J. Knobloch: Computing platforms
		References	Slide: HTML
		Summary	Systems currently supported for Atlas software: HP-UX (CERN), AIX (CERN), NT (CERN), DUX (Arlington), Linux (Glasgow + CERN), IRIX (Argonne), Solaris (?) Future: HP-UX, Linux, NT; if supported by outside institutes: AIX, DUX, Solaris
		Discussion	Clear that PC support (Linux, NT) is vital At least one commercial Unix, but no particular preference for HP-UX No objections not to ask CERN for HP-UX 11 support; 10.20 will remain supported
Wed	09:00	Topic	H. Meinhard: Arve introduction
		References	Slides: HTML, PPT
		Summary	History: developed within last ~ 2 years, mainly by Toby Burnett Framework to get OO code in C++ going, provides basic infrastructure (GUI, loop over events, display facilities) Clear need to provide larger community of developers with these facilities Cleanup and user documentation being done now, release to be expected this month Release ('LHCC milestone') will support HP-UX (aCC) and WNT (VC++), incorporates access to Geant3 Zebra events via RD Schaffer's Event packages; user documentation with sample application code Upcoming release is seen as a means to get more developers started; work towards new design and implementation of control, graphics, user interface etc ongoing Developers must expect need to change their (thin) interfaces to Arve some time in the future
Wed	09:15	Topic	T. Burnett: Arve demonstration
		References	Slides: HTML, PPT
		Summary	Object oriented, in C++ (some parts in Java) Environment, set of utilities Hello world application: User class needs to inherit from Module To write: main(), class HelloWorld. Main instantiates Arve, HelloWorld gets attached to it HelloWorld::Rep inherits from ArvePlottableRep (inherits from PlottableRep), need to implement an update() method Application creates a console window, and a graphics window including a menu bar integrated wire-frame 3-d graphics Menus on the menu bar can be added and extended, dialog boxes for user inputs (eg. parameters) Graphics window can be split, individual items can be switched on and off on the display, easy to distinguish between detector and event data display Help system is available, keyboard shortcuts defined Print control, event loop Single particle generation (Gismo) Electromagnetic (egs) and hadronic (gheisha) interactions Units: currently cm used Arve uses 'callback' mechanisms a lot (no central control instance) More complex example: cylinder with events generated with increasing phi Objects know how to draw themselves Serious example: TRT reconstruction Adds menus to change incoming data, re-do the reconstruction 'Test beam': to generate events with user-selectable particle id (muon, H->2Z->4mu shown), direction, ... Also support for batch mode running, Motif user interface Coming soon: 'LHCC milestone' release with 'howto' documentation, implementation of object networks, Geant3 simulation results from Zebra tapes Longer term future: full integration with Atlas graphics, Geant 4, control according to Atlas model
		Discussion	Other applications: Datcha Q: How can information flow between modules be established? A: Left to the user application Q: Can Arve be multithreaded? A: Depends on what sort of control is meant, probably can be made multithreaded, but no work done yet Linux: Will be addressed after NT and HP-UX
Wed	10:45	Topic	RD Schaffer: Event issues
		References	N/A
		Summary	Digits provide their position in space, relation with detector elements Navigation, iteration tools provided Some optimisation done ID digits available now, working on muon, next will be calo RD45 workshop conclusions: RD45 will be split into production and R+D part; milestones for R+D: Database usage over WAN, clustering/ re-clustering strategy, interface to MSS (HPSS) For WAN usage, more realistic use cases are required; relationship with proposed project (RD55) needs to be defined
		Discussion	Q: Will it be possible to define the page size at the database level rather than at the federation level? A: No plans yet Need to get the terminology for event/digits right in order to cover as many subdetectors as possible with as few terms as possible
Wed	11.15	Topic	J. Knobloch: 1 TB milestone
		References	N/A
		Summary	Official LHCC milestone: demonstrate ~ 1 TB event data base by end of 1998 Have Objy server, 100 GB disk attached to it Event store in Objy by August Test beam data into Objy (eg. tiles - July '98) Objectivity - HPSS interface under study 1 TB milestone for RD45 already in April 1997 Our milestone not achievable with disks only, HPSS will be required Plee for help from outside institutes
		Discussion	Atlas Objy server is a temporary one running Objy V4 Measurable results need to be defined Some performance numbers available from CDF
Wed	11:30	Topic	Discussion about NT requirements
		Discussion	Triggered by Steve Fisher Should there be ASIS for NT? What about NICE replica? Can we use CERN NICE services from outside institutes? There is a HEPNT committee, but not much seems to come out of it Needed now: Cygwin, cvs, emacs 20, autoconf, ... Bologna NICE clone: core of a central Italian repository Is AFS for distribution acceptable? Web page with clickable .zip would also be fine. No solution yet for NetBIOS network over WAN for security reasons Should the use of Visual Studio or SRT be recommended?
		Decision	Will start to collect draft requirements (Steve Fisher, Steve O'Neale, David Candlin), will be discussed via E-mail
Thu	09:00	Topic	J. Shiers: LHC++ issues
		References	Slides: HTML, PPT, PS
		Summary	Outlook on next week's LHC++ meeting (Monday May 11th) Issues: Access at CERN, distribution, SRT, Linux, ... Access at CERN: via central file servers (AFS for Unix, Novell for NT) Outside CERN: Preferred way via local installation through the network Registration will be required for outside use, including contract addendums for Object Space, Objectivity/DB, Iris Explorer LHC++ export tree is in /afs/cern.ch/sw/lhcxx/export, ftp recommended, klog discouraged Commercial software distributed as provided by vendor, HEP extensions in source and binaries. Tar/zip files for Unix/NT C++ libraries: ObjectSpace Internet<ToolKit> Objectivity: V5 for NT and Solaris received, licenses for Java binding HepODBMS: tested against V5; available as prototype/first version for 98a Will look at BaBar conditions database CLHEP: will use aCC, comments from STAR NAG C library: Mark 4 plus bug fix, waiting for Mark 5 Gemini: meets URD, can select NAG C or Minuit, post 98a, will be offered as IRIX Explorer module Analysis environment: Current HistOOgram frozen, now works on NT, DUX, AIX, HP, SUN HEPInventor, nt/loop equivalent for HEPExplorer, improved graphics modules (incl. postscript module), page layout not yet HEPExplorer ported to NT, DEC, AIX Scripting language survey to be done; solution that will allow to use scripting language of your choice (Tcl, Perl, Python, etc) Support for all components for Linux foreseen for early next year; exact procedure (intermediate releases of indiv. products?) to be decided Submission of software to LHC++ encouraged; need procedure: should be relevant to LHC++ of interest to at least one/more expts conform to minimal set of standards Draft document will be provided and iterated LHC++ on unofficial platforms: minimal standards (incl. test cases, documentation etc) Test or evaluation versions not appropriate for the LHC++ tree Procedure to be discussed Support for 'new' compilers also to be evaluated
		Discussion	Q: Registration procedure for LHC++? A: Basically similar to CERNLIB
Thu	09:35	Topic	L. Chevalier: Magnetic field software
		References	Slides: HTML, gzipped PS
		Summary	Muon reconstruction in spectrometer: 650'000 calls to Bfield routine per reconstructed muon single mu in nominal luminosity: ~3.3sec: 33% B-field, 33% tracking, 33% pattern and fits (ttbar evts: full reco 10-15min, full simu 1hr) Magnetic field anywhere in spectrometer must be accessed in very short time; interpolation algorithms required with minimum of conditionals Fortran reference code: 1.7*10^-6 s / call In spite of inhomogeneous field, size must remain reasonable, hence use highly non-regular (non-equidistant) grid: 770'000 points, 4 MB for 1/16 of the total detector volume for ideal (perfect symmetry) situation C++ aim to keep the time of the Fortran code At the moment: wrapper for Fortran code Next step: write directly in C++, find good container for map and pointer system Discussed with BaBar, D0, (to discuss with Geant4) Build virtual B-field class (several design considerations, discussions with Kors and Lassi)
		Discussion	Q: 650'000 calls in limited eta-phi: Aren't there ways to organise the field map to speed up execution by reducing the search area? A: Not possible with the pointer system, but study of alternatives in progress. Q: What is the timescale? A: 1-2 months hopefully Q: What is the trade-off between efficiency and speed? A: At present aim at very high efficiency (97%) Reminder that current planning is 200 SpecInt95 per event
Thu	09:50	Topic	S. Fisher: ASP working group
		References	Slides: HTML
		Summary	Small, but successful meeting; G. Pawlitzek had been invited as an expert on software processes and tools Editorial committee: shorten introduction and de-emphasize start-up, introduce fixed term of office of 'domain architects' ASP document format: being moved from Latex to SGML or XML as a trial, not a general strategy for ATLAS software documentation Evaluation of external software: try once with CLHEP and adjust the procedure if necessary Informal procedures: should not be overly defined in a formal document; keep walk-throughs. After design reviews, people to be encouraged to talk about their design and the review - but don't include this in ASP Metrics: start collecting; no decision on what to do with results and numbers Design reviews: A couple of small changes accepted, catch-all rule was introduced; add section to reviewers report for general comments; try copy of final report with trivial issues (commas, grammar) filtered out by moderator More design rules: some (proposed by Wim Lawrijsen) to be discussed in the ASP mailing list. No inheritance across domain boundaries?
		Discussion	Disagreement on proposed rule of no inheritance across domains; a change as important as this one needs to be discussed on atlas-sw Proposal to discuss coding rule changes on the mailing list; no changes should be applied before we have had at least two code reviews, unless our rules conflict with the C++ standard
Thu	10:40	Topic	K. Sliwa: Announcement: Workshop in the US
		Summary	Signs that Boston is too expensive U Michigan is ready to organise it, price would be 70 USD per night, no car required Tuesday to Saturday rather than Monday to Friday? Decision to be taken on Friday
Thu	10:50	Topic	L. Tuura: Naming conventions
		References	Proposal to atlas-sw: HTML
		Summary	Mail sent to atlas-sw asking for comments No feedback on naming conventions proper Discussion about permitting (or requesting) underscores between acronyms and normal words: We require them Units: Some discussion beforehand, no decision yet today. Some people would prefer energies in GeV
		Decision	Naming conventions adopted with the change described above, and excluding the item on units
Thu	11:05	Topic	J. Knobloch: LHCC workshop summary
		References	N/A
		Summary	Day 1: Architecture (domains, frameworks, components, glue); very different interpretations of these terms Aim: strong coherence and loose coupling of domains Clear need to define the architecture very early on in the project, for each level of the project decomposition Domain decomposition is not just manpower decomposition Sufficient time required to get architecture and glue right Framework is an artefact to support chosen architecture, is architecture-specific and hence likely to be collaboration-specific Integration technology: proprietary vs public standards Day2: Migration strategy: The formal vs the pragmatic approach Atlas approach considered formal Need to find the best compromise: what counts is the quality of the final project Metrics can be very useful to motivate migration to OO Training: Courses not sufficient; new technology, just-in-time training, examples to be exchanged and collected in a central repository Workshop outcome: Clear consensus to increase the amount of sharing between experiments: components, interfaces, software process, tools Share early in order not to preclude later sharing Steps: Define a common vocabulary, discuss architecture, understand domain decomposition better, identify components to be shared Role of a central support team (see G. Kellner's presentation during this workshop) Technical forums proposed on specific items
		Discussion	Q: Are there really efforts going on to discuss sharing between experiments, and to compare different approaches? A: Yes, the Thursday Club is the forum for this at the moment Q: We can't ask all test beam communities to migrate to OO now. A: That's not the case; the impetus comes from within the communities which then get our support
Fri	09:00	Topic	C. Onions: SRT status and plans, package migration
		References	Slides: HTML
		Summary	SRT status: New version 00-02 in March: Rules for .age files, new commands show, update, prepare, new supported architectures (AIX, Lynx/OS, Linux), notification list for repository changes SRT plans: integration of tools, fix Fortran preprocessing on AIX and NT, Fortran options on NT, Add cdf rules, documentation; all to be rewieved. Longer term: Java support, MS Studio integration? Migration status: converted: All generator packages, commons, agetof, slug, geant3, atdummy, atrig. To be done: atrecon with nested packages ipatrec, xkalman, pixelrec, atutil, atlsim, dice, muonbox, 'Mains' package Also in: Arve, Event, AgeToCxx, ..., CLHEP Releases every two weeks; 0.0.2 was HP only, need to sort out DUX, AIX, Arve with g++, AgeStructures, implement access control
		Discussion	Q: What is the policy concerning compilers? A: Native compilers on Unix platforms
Fri	09:15	Topic	M. Stavrianakou: Repository: Use, structure, access control
		References	Slides: HTML, PS
		Summary	Repository areas: official Atlas software, external software, contributed software (added later if needed) Recap of DIG decisions on repository policy and structure (see H. Meinhard's talk on Tuesday) Official Atlas software (endorsed by offline software community, ASP compliant or in the process of obtaining compliance) External software (as defined by ASP), single coordinator per package; no local copies of officially supported external software External users should only need standard languages and compilers. All packages must build on all supported platforms, and have a standard interface for the librarian. Periodic reviews foreseen. Area for contributed software, perhaps to be added later: For software written by Atlas members, Atlas-specific. Inclusion must be discussed with people affected. Rules for external software apply as well. The packages cannot be part of the official Arve software, or be local copies thereof. Obsolete, unmaintained, or unused packages will be reviewed and removed The Fortran software is to use exactly the same scheme.
		Discussion	Q: Can help be provided for developers to set up their own versioning with cvs? A: No solution yet - will be addressed 'Parsers' need to be defined more precisely (XML usage must be possible, for example)
		Decision	Proposal adopted
Fri	09:30	Topic	L. Tuura: Control domain
		References	N/A
		Summary	No direct contribution to 'LHC++ milestone' Arve release Documentation of components until June DIG, some design documents as well Video conference moved to Mondays 17.00 h (Geneva time) Documentation outline
		Discussion	Q: Where would DCOM be discussed? A: Control domain, if at all
Fri	09:35	Topic	G. Poulard: Reconstruction meeting
		References	Slides: HTML, PS	N/A
		Summary	Organisation: No OO/Fortran separation, priorities need to be set; more working groups being set up Calorimeter code being rewritten in C++ (calorec++), preserving existing interfaces, some hiccup with SRT; contact with Event Filter group, clean separation between I/O and algorithms to be ensured Calorimeter: work on pile up ongoing, improvements on structure of unpacking All calo modifications (EM and HAD) to be ready by beginning of June xKalman++: Alpha exists and is being tested, results identical for single particles, but factor 2 slower, move to non-uniform B field iPatRec: Aim to have a working version by beginning of June, only in SRT "Pure" OO project: Astra Documentation: some exist, but more work needed Muons: starting to migrate to C++, preserving interfaces. Main concern: speed of the code Datcha Fortran frozen, OO being developed, needs better communication Combined reconstruction: Ntuples defined and existing, progress to be expected by Atlas week Track classes: Following A. Poppleton's proposal; same structure for all reconstruction packages Arve integration foreseen, needs data access Event format: Discussion started about detector organisation, general structure of events, data flow Another meeting by end June
		Discussion	Q: GEANE requested by muon group; what do we do about it? Is its functionality provided by Geant4? A: Gilbert strongly discourages this Q: What is the track class about? A: Reconstructed quantities, not MC truth
Fri	09:55	Topic	S. Fisher: Java working group
		References	Slides: HTML, gzipped PS
		Summary	Introduction to Java given by Onne Peters Java to C++ interface Coding rules: S. Fisher, K. Bos, O. Peters will prepare a proposal with as much in common as possible with the C++ rules Package names: agreed on prefix ch.cern.atlas SRT and Java: Javac is not makefile friendly, experience from Wired will be looked at. Builds should use share rather than lib or bin Development tools: looked at Visual Cafe, Visual Age, TogetherJ, JAS Java Beans: wrapper for BeamInfo was suggested
		Discussion	Standard implementation language of our software is C++
Fri	10:00	Topic	J. Hrivnac: Graphics working group
		References	Minutes of Graphics meeting: HTML
		Summary	Benefitted from access to events Scripts written which provide skeleton classes (a la MS Studio/MFC) Output files prepared or being prepared for all packages Wired: Capable of reading Atlas data, Atlantis-like displays Wired is using XML for data transport, requires authoring of DTD XML adopted for exchange of Ascii files in graphics domain Atlantis: Si there, next will be muons, user interface being improved, documentation under work, tutorial being prepared Histograms in Java: can easily be interfaced to Atlas Graphics Aravis: not entirely Atlas graphics compatible yet, but hope to find volunteers to do the necessary work Object browser: under work
		Discussion	XML decision should be brought up in DIG, because it may have influence on other domains, too
Fri	10:10	Topic	M. Stavrianakou: Testing working group
		References	Slides: HTML, gzipped PS	N/A
		Summary	First attempt of a testing workgroup, with assistance of IT/IPT (Stefano Paoli) Aim: Survey current status, agree on improvement programme, implement in Atlas or Geant4, then transfer to other projects Survey being prepared; ingredients: ASP rules; granularity: unit testing vs integration testing Aleph experience: testing coordinator, team of community members; reference histograms, set of criteria, all supported platforms Atlas trying to establish something along the Aleph lines Industry: criteria for testing derived from requirements and architectural design. Testing is an activity, not a phase (starts at very beginning of the project) Not clear whether test plan should be part of the design document, or be documented separately Next steps: complete survey report; nominated testing coordinator, establish testing group; start work on test plan; document unit testing procedures in ASP; WWW page Another meeting around next DIG end June
		Discussion	Q: Does IPT have tools for regression testing? A: Need to understand requirements first, before we talk about tools
Fri	10:20	Topic	K. Sliwa: World-wide computing group (jointly with CMS)
		References	N/A
		Summary	J. Shiers: View of RD45 on the proposed new LCB project C. von Praun on simulation of distributed computing architecture (nicewww.cern.ch/~praun/ATLAS-CMS-JointMeeting/slides.ps.zip) Discussion on second draft of PAP: Clearly converging, new draft early next week, can be presented to LCB in June. Mailing list will be established. To sign the author list, contact Krzysztof Sliwa How can Atlas approval be achieved? Needs approval by Executive Board
Fri	10:30	Topic	D. Candlin: NT support for outside labs
		Summary	Reminder of discussion on Wednesday
Fri	10:50	Topic	H. Meinhard: Summary of decisions, planning of next cycles
		References	Slides: HTML, PPT
		Summary	Reminder of DIG decisions (see H. Meinhard's talk on Tuesday) Reminder of repository structure and policy (see M. Stavrianakou's talk on Friday) More decisions: Fortran consolidation continues with limited scope Finish cvs migration Finalize Arve 'LHCC milestone' release Start collecting criteria for 1 TB milestone Start requirements collection for outside NT developers ASP: Make user-friendly, shorten, rephrase, update; try rules for external software with CLHEP; don't change C++ rules now Naming conventions: Proposal adopted without units, and requiring an underscore between acronyms and full names Coding rules for Java to be drafted, package name prefix is ch.cern.atlas (note that the default implementation language remains C++!) Need to study XML, general recommendation required Go ahead with testing team Support for RD55 PAP Other workshop highlights: Status of Fortran software, 98_2 release, cvs migration SDE working group, role of IPT group Arve demonstration LHC++ status: Linux on the road Magnetic field Summary of LHCC computing workshop in Barcelona To be addressed during next cycle(s): Domain descriptions Criteria for 1 TB milestone Events into Objectivity Arve framework release ASP editorial work Web spring cleanup B field implementation Detailed schedule, milestones Geant4 for testbeams, later for whole Atlas MC production Geometry database Physics analysis strategy Migrate more people to OO Work on units decision Port software to Linux MC consolidation Migration to cvs, SRT consolidation Requirements for NT Sort out CLHEP problems Tile test beam data into Objectivity
		Discussion	CLHEP issue: Need more information for next week's LHC++ meeting Q: Linux: Which compiler to use? A: Only egcs provides both advanced compliance with C++ standard, and Fortran compatibility How to get Linux installed on a PC at CERN? Needs to be clarified Migration to OO really requires access to data Missing from work plan: Store events from Tile testbeam into Objy, analyse with LHC++ Arve release will be a framework, not a reconstruction program. Reconstruction modules will be plugged in to Arve step by step, starting next cycle
Fri	11:10	Topic	D. Froidevaux: Report from Grenoble workshop
		References	E-mail summary of Grenoble workshop: HTML
		Summary	Overlap and communication between physics and software communities still to be improved Dates for physics TDRs pushed back slightly Production needs to be started soon (top, Z+jet, EM jets) Geometry for MC can be frozen Lack of progress on pile-up and noise Atrig / Atrecon compatibility problem Combined N-tuples for analysis of fully reconstructed events Atlas Geant4 group creation Physics analysis tools: Root - Explorer comparison LHC++ suite: Problems in outside institutes Physics TDRs will use PAW/Fortran or Root
		Discussion	Root - Explorer is not the correct comparison, as Explorer is covering only part of the functionality Q: What does the proposed benchmarking mean? A: Performance in terms of response, handling of data files, maintainability Geant4 work needs to be very carefully planned
Fri	11:50	Topic	H. Neal: Workshop in August
		Summary	250 miles each of Chicago 35'000 students Happy to host the August workshop Place with a long tradition in physics discoveries Many will arrive in Detroit (KLM/NorthWest) Hotels available (~ 72 USD), transport can be arranged Terminals, meeting rooms available
		Discussion	Indications that future workshops in the US could take place in Argonne or Boston
		Decision	We thankfully accept the offer to hold the meeting in Ann Arbor from Tuesday August 25th till Saturday August 29th