ATLAS Software Workshop Minutes

CERN, February 14 - 18, 2000

These minutes are still under construction; the finals are bound to be different.

Day	Time
Tue	09:00	Topic	N. McCubbin: Introduction, news, general status
		References	N/A
		Summary	Chairman of National Computing Board: Alois Putzer (Heidelberg) elected CERN computing review: Atlas represented as follows: Steering group: Norman McCubbin (alternate: Gilbert Poulard), World wide computing: Alois Putzer (Laura Perini), Software: Dario Barberis (Martine Bosman), Management and resources: John Huth (Helge Meinhard) Simulation group: Andrea Dell'Acqua resigned as coordinator, position vacant for the time being, hope that Andrea will ontinue work in the simulation area CSG met during last software week, mainly about CERN/LHCC review and Architecture post-ATF; COB: Architecture post-ATF, software agreement, DoE/NSF review; working CSG meeting on plan Architecture: ATF reported in November, report and recommendations endorsed as baseline by EB and CSG. Architecture team: Katsuya Amako, Paolo Calafiura, Gilbert Poulard, David Quarrie, David Rousseau, RD Schaffer, Craig Tull. Chief architect identified, but announcement delayed due to formalities Technical group launched, will use existing mailing lists (mainly atlas-sw-developers). Maya Stavrianakou acting as convener Agenda: Awareness-raising sessions on Java (vs C++) and RD45/Databases; combined physics performance groups should be attended by everybody! Norman very aware of concerns about communication; try to post regular summaries of activities to be appended to weekly report
		Discussion	Q: Could you comment on the statement that C++ is a dangerous language? A: It is recognised that C++ offers a lot of potential pitfalls (memory leaks, ...) to the unaware user; steep learning curve. Java seems to be much better in all these respects There is a training course on pitfalls of C++ at CERN during the week of February 28 All languages are potentially dangerous without adequate quality control Q: Why did Andrea resign? A: The understanding is that he did not agree with personnel choices and with the thrust of the architecture discussion
Tue	09:35	Topic	S. Fisher: Java in Atlas
		References	N/A
		Summary	If we were to choose today, the choice would be Java; C++ is dying, Java is growing. Co-existence of C++ and Java not trivial. Recipe needed to replace C++ by Java Massive migration effort from Fortran to OO implemented in C++ Java appeared some five years ago, used in newest applications, JavaBeans very attractive. Java widely used in graphics applications (Wired, JAS) Now more books newly published about Java than about C++, 6 of the top 100 sales of Amazon were about Java Should we stay with C++? Makes writing code much more of a challenge, excludes amateurs, good for job security and tool vendors, ... Java advantages: Automatic memory management, no *, ->, & to worry about, clean definition of interfaces, no .h files, elegant world-wide naming scheme, byte code can execute anywhere, easy to learn (empowers larger fraction of the HEP community) Issues for technical group: Naming conventions and name spaces, garbage collection, use of shared libraries (all gone with Java), external software, documentation (JavaDoc is a great help), ... Mixing of C++ and Java: No inheritance across boundary; communication: Corba is elegant but slow, JNI not very elegant; both can easily call out to C Once a C++ programmer has moved to Java, typically they don't go back. Syntax very similar, although semantics reasonably different If we think that Java is the right choice, we should migrate asap rather than waiting for more C++ to be written Possible concerns: easy to program? general feeling seems very positive; performance? addressed by JIT compilers, byte code to C converters; what about investment into C++? Measure time to do semi-mechanical conversion Potential strategy: Understand what is involved in the conversion from C++ to Java by converting the G4 geometry (~ 100 classes): how to do it, how hard it is, what the resulting code looks like, how it performs. Positive outcome will allow a very rapid transition to Java Existing tools: C2J, C2J++, Cappuccino (handles templates, overloaded operators, typedefs, pointer arithmetic) Impact: agents and I/O (send program to data, not the other way around), high parallelism possible Final remarks: stop wasting effort on C++, not too late yet to move to Java. "It's a bad plan that can't be changed."
Tue	09:55	Topic	J. Hrivnac: Graphics and Java
		References	N/A
		Summary	Java very attractive for graphics, tool support very good Pros: see all those mentioned by Steve Fisher, better interfacing to existing Java applications, many things are much easier and more elegant, easy persistency and network access, multi-threaded. Cons: Current software in Fortran, Fortran with clever tricks, Zebra, Age, C++, F90, ... Migration/Interfacing/Wrapping very complex - but we have got to face this problem anyway Graphics: Fundamental requirements and architectural choices concerning Graphics (objects don't know that they can be displayed, independence of chosen graphics package) can easily be achieved in Java. Natural solutions for GUI, scripting, and simple storage. Natural link to XML Possible plan: Feasibility proven by mature products. Until May 2000 workshop: control design and implementation, until August 2000 workshop: interfacing to C++ objects; migration finished by end 2000. Support for existing (C++ and Fortran) graphics implementations until end 2000 Web page with links
		Discussion	Isn't the choice of the implementation language somewhat arbitrary? Our choices of Fortran and C++, at the respective points in time, were not wrong at all. Are we going to re-write our code every five years?' An alternative model would be to allow for interfacing of different languages, in particular Java with C++ C++ was the wrong choice from the very beginning Q: Can somebody comment on the uniformity and portability of compilers and tools? A: The Slac linear collider project uses a C++ simulation, and a Java reconstruction. Java compilers have been found to be significantly less problematic and more portable; the only noteworthy problems were in the area of graphics Is the Geant4 geometry really the right test case? One ever problematic area is the I/O with the complex data structures we use. This is not touched by the Geant4 geometry Q: A significant C++ code base exists already in Atlas simulation, probably a little less in reconstruction. A: Not obvious that this is true Q: What about the algorithmic features of Java? Is it fast enough? A: Conclusive measurements still need to be done in Atlas, but first indications are that speed differences are due to the different libraries used rather than the implementation language. More detailed tests to follow Q: Is there adequate library support for Java for algorithmic code? A: Yes Java optimiser is in theory in a better position, as it can act at run time rather than at compile time. No problems have been encountered writing ambitious reconstruction code in Java Java does not have conditional code, portability issues are much less pronounced than for traditional languages such as C++ It is important that we take a long-term decision, cannot jump from one bandwaggon to the next every five years. Isolation through well defined interfaces is required It is very important that the future framework is done such that different implementation languages can co-exist (N. McCubbin) The implications of migrating to Java need to be very well understood, taking into account that Atlas is not acting in isolation. Steve and Julius are asked to prepare a software note describing the pros and cons as an input for further discussion, taking note of the points raised in the discussion
Tue	10:50	Topic	D. Quarrie: Atlas architecture and framework
		References	N/A
		Summary	David introducing himself: experience on several HEP experiments, now ramping up his Atlas involvement Input to AT: Feature list, ATF document based on dual approach Relatively small core team, to be augmented by experts on various fields, strong communication with the rest of the community Work already started at LBNL understanding the boundary conditions, and the functionality for the May prototype (see Craig's talk) Meeting schedule being established For May prototype: Take PASO as baseline functionality, will minimise transition of existing PASO code USDP use-case driven approach to be pursued by Katsuya and Chris Day, input from Gilbert Poulard, David Rousseau and Marjorie Shapiro Gaudi being evaluated as baseline for prototype; coherent vision, clear distinction between abstractions and implementations. Many components match those identified by ATF. Some things missing though Evaluation of Gaudi: Use case coverage, software process, configuration management - resulted in fairly high marks Gaudi architecture vs our feature list: 185 features covered, no one not covered, 47 irrelevant, 11 not understood; willingness to collaborate, openness to new ideas, past history all mean that there is a good possibility for productive collaboration Gaudi superior to, but not as mature yet as, the BaBar/CDF framework, no limitations of physics functionality to be expected Meetings: pulling in the members from outside LBNL, via video. Reports foreseen for weekly software meetings, 2 three-day workshops in March and April, mailing lists and discussion forums, Web access to Case tool, tutorial in May software workshop
		Discussion	Q: Should try and use existing infrastructure as much as possible, eg. the software repository and the CVS browsers. A: The remark was mostly about the CASE tools Larger outside labs, eg. Brookhaven, might be a better potential source for additional manpower
Tue	11:15	Topic	C. Tull: Milestones and deliverables
		References	N/A
		Summary	Proposed major milestones: Prototype in May 2000, design review of alpha release June 2000, Alpha release (including USDP feedback) September 2000, Beta release December 2000, fully functional release in October 2001 May 2000 prototype: Pre-alpha, demonstration of basic functionality, not easily usable for more than simple tasks. Tutorial to be given in May workshop. Assuming to start from Gaudi, add Atlas event model, graphics and other features. Feature set must include reading of Physics TDR data, event display, sequence of multiple user modules with I/O to transient data store; should include dynamic loading of user modules, dealing with sequences with branches and filters, may include rudimentary interactive user interface, limited data persistency. Basic transient event store: Gaudi (after evaluation of BaBar/CDF versions), existing transient event model to be incorporated Gaudi: users are expected to write algorithms and converters; for May 2000 prototypes: only algorithms required, access to physics TDR data through existing event model Possibility for common interfaces with Gaudi, and different implementations, wherever necessary Event display: for May 2000, existing display to be plugged in like any other algorithm Scripting interface: Lower priority for May 2000 Limitations of May 2000 prototype: Linux only, Gaudi binaries provided as external packages, little documentation, some interfaces with limited functionality Only 10 weeks left - detailed schedule Real users required soon for Q&A, design, performance feedback, starting with a few "friendly users" not diverting too much effort for support. Candidates: PASO users, other interested parties - contact Craig September 2000: USDP and fast prototyping merged, Fortran wrapped, event model, limited database integration, run-time configuration, limited physics analysis output December 2000: targeted at trigger TDR, input from Geant3 events October 2001: All other missing functionality for first full version Tight schedule, hence help needed; don't hesitate to contact members of the Architecture Team
		Discussion	Q: Which Linux? A: One specific version, still to be defined Additional feature for September 2000: Input from Monte Carlo generators and fast simulation
Tue	11:35	Topic	P. Mato: Gaudi - LHCb software architecture
		References	N/A
		Summary	Gaudi strategy: started some 15 months ago with a small design team of 6...8 people, chief architect, librarian etc. identified; collected user requirements and use-cases, basic criteria for design, choices for implementation of initial prototypes, incremental approach to development. Comprehensive design review after ~ 1 year Important property of Gaudi design: Interface vs implementation via pure abstract base classes; algorithm implements an abstract algorithm interface, and uses services via interface classes, thus preventing unnecessary exposure of implementation details Algorithms with two interfaces, IAlgorithm (typically used for event I/O) and IProperty (parameters and settings of the algorithm) Factories and dynamic loading: allows for plug-and-play, using the Factory pattern Transient-persistent separation: various persistency techniques available concurrently History: started in September 1998, architecture review in November 1998, first release in February 1999, second release in May 1999, third release in November 1999. Team now ~ 12 people. Effort now on wrapping existing Fortran code in order to have a productive application (reconstruction) soon Possible collaboration: Foundation libraries, partly frameworks and toolkits. Starting point is the interface model. Benefits from LHCb point of view: better design, higher quality of basic infrastructure services, CERN IT efforts more focused, better communication. Disadvantages: less freedom, more formality (change procedures, upgrades, ...), risk of failure. Practical aspects: regular meetings, workshops, mailing lists and other collaborating tools, common repository(?)
		Discussion	Q: What does Gaudi stand for? A: Nothing - it's just a nice name of an architect Use case driven approach requires active participation of the community AT Workshops will be held at CERN - proposed dates: 9-11 March, week of 17 April. Excellent opportunity for user input into the process Q: Is there a technical student working on a Java implementation of Gaudi? A: Yes, but this is not a very high priority item. No major problems have been encountered yet Q: What are the LHCb ideas about exception handling? A: Not much developed yet - most algorithms return a status code. There is lots of room for improvement Q: What about wrapping existing code? A: Foreseen for September version, details not yet fixed Q: We need to consider the requirements of the test beam activities. A: Yes, the time line has not been discussed a lot, and may be adapted, but it may not entirely be possible to resolve the different interests of the software and the detector communities The March workshop may be used to fix priorities of requirements on functionality This year's test beams are important, we must be able much later on to read the data back
Wed	09:00	Topic	RD. Schaffer: Report from Database working group
		References	N/A
		Summary	Reports from meetings: production databases, RD45, CHEP Progress on event model and identifiers: changes to EventManager, first proposal for logical identifiers Data extraction from Geant3: Tilecal and RPC digits to come in forthcoming release Data base support for testbeams beyond Tile: possibly something in parallel in 2000, more direct use perhaps in 2001 by muons and LAr Infrastructure for calibration DB to be considered DB support for Geant4 simulation: discussions have begun, needs to be documented, must fit into the plan to get data out of Geant4
		Discussion	Q: What is the status of the hits from Geant3? First indications are that Geant4 has got a long way to go, we urgently need hits from Physics TDR data. A: The bottleneck is to redefine the mapping between hits and digits
Wed	09:15	Topic	S. Bentvelsen: Detector description
		References	N/A
		Summary	Status of AGDD XML definition, and Geant4 builder AGDD: currently at version 4. New: stacks, versioning, boolean volumes, identifiers; tools: generic model, Persint, G4Builder; implementation files: Muon, SCT, LAr, ... Versioning: New attribute DTD_version Stack: useful for positioning volumes in space (single or multiple, absolute or relative positioning), stacks allow for multiple volumes along given axes without repeating dimensions again and again. Example (Steven Goldfarb): RPC description Parameters: wanted by many people, but reluctance to implement it into AGDD. Possibilities: XSL, m4. More understanding needed Geometry definition with AGDD in good shape, independent of programming language; producting AGDD XML files not a waste of time AGDD XML feeds C++ generic model, which in turn feeds the G4Builder G4Builder takes geometry and material from AGDD, generic (ie. not detector specific) Debugging: visualisation using DAWN, HBOOK histograms with observables No 'mother envelope' in AGDD, hence iterative method implemented to derive it, which is expensive in terms of performance Only default units, no boolean volumes yet, identifiers incomplete Input: material and geometry XML files Example: 10 GeV electrons into SCT, works fine Accumulation of statistical quantities to histograms possible in interactive mode Source code for AGDD v4 will be put into SRT soon
		Discussion	Q: Does G4Builder support internally multiple positionings or replicas? A: No, not currently Migration of moving the Tile monitoring with Objy from Offline to Online should be strongly encouraged, will give valuable insights
Wed	09:40	Topic	D. Malon: Discussion of database requirements
		References	N/A
		Summary	Purpose: Re-evaluate the requirements, input from Vincenzo Innocente and Federico Carminati Provocative summary: object data bases are dead, flat files are on the ascendancy... we should move to flat files (?) RD45 soliciting experiments' views of requirements, careful re-assessment of needs of experiments required involving users, and assess possible courses of action Decisions by Atlas: independency of data base supplier (users do not see Objectivity specific constructs), the same would apply for any other technology. Nevertheless, room for interpretation of this statement. Care must be taken not to loose all advantages of an OODBMS. Current Atlas baseline choice: Objectivity Paris Sphicas' summary at CHEP: still not clear whether OODBMS is the way to go - CDF, D0, Star, Phenix decided against it (at least for event data). Hope to receive boosts by grids. Are LHC experiments facing a phase transition? Not in terms of data volume requirements. Main difference: timescale Not proven yet that we can do something with an OODBMS that we cannot do with other technologies
Wed	09:55	Topic	F. Carminati: Persistency in Alice
		References	N/A
		Summary	Alice strategy on persistency: present position Policy: move immediately to C++, allowing for Fortran wrapping, and limiting C++ complexity (Java-like subset, using ROOT polymorphic containers, no STL, no LHC++, CINT). Single framework imposed on all users. Providing support, documentation and training Why Root? full set of container classes, robust object I/O, super-PAW functionality, C++ as scripting language, self-documenting, free, supported and available on all platform, support for network access and parallelism MDC I: aggregate rates of about 14 MB/s, 7 TB total MDC II: aiming at 100 MB/s Comparison of Root against Objectivity: no surprises, detailed report available. Main conclusions: Root and Objy can be made to cooperate, but Objectivity needs expert tuning OODBMS market not taking off, only candidate is from a small company, poor improvements in the last 5 years. Tests so far not conclusive, HSM does not seem to match well to OODBMS systems Do we need an OODBMS? Is concurrent writing necessary? Can we afford not to have a failsave solution? Is it acceptable to have two different models for persistent and transient data? Cannot beat network latency on WANs for object level access Do we really want to impose the burden of Objy on all labs (cf. Redhat 6.1 crisis)? put data in proprietary format? afford to help Objy? need to access everything from everywhere? want to store everything in a federation? Alice: all databases in Root, event or tag databases in RDBMS (Root interface to MySQL and Oracle). Losing vendor support, advanced distributed features, concurrent write access, transparent access from any part of an event to any other one. Gaining baseline solution which has been shown to work, little risk (sources available), single model for persistent and transient data, schema evolution (soon to be automatic), self-generated object description, all platforms and OS, consistent with containers, browsing and analysis tools, optimised for different access granularity, integrated environment also for analysis, open-source style support, portable data files Time is running short, need to build up the system now. Root found the best (only?) solution responding to Alice's requirements
Wed	10:15	Topic	V. Innocente: Persistency in CMS
		References	N/A
		Summary	HEP data: events, environmental, event-collection metadata, user data, ... - all those are linked together. Suffered most heavily from bad availability of these relationships in the past (LEP). Hence DBMS is required, and an OODBMS is a natural match to OO programs. Different DBMS technologies for metadata make navigation much more difficult Physical clustering separate from logical user view Is an OODBMS overkill for histograms? Not really the point... more frequently used are N-tuple like datasets requiring the same level of management and book-keeping like the experiment-wide data Objy features CMS uses: Persistent objects are real C++ (and Java) objects, I/O cache management, smart pointers, efficient containers, full direct navigation in complete federation, flexible physical clustering of objects, object naming CMS satisfied, find Objy easy to use, file size okay (comparable with Zebra of Bos), robust and stable, well documented. Cons: does not implement the latest C++ features (but converting rapidly towards Ansi standard); additional configuration elements; performance degradations (need careful monitoring of running applications, much to learn from BaBar and Compass); Objy is a bare product (integration into framework is user's responsibility); Objy is slow to respond to user requests for new functionality Found missing: scalability (64k files not sufficient), efficient and secure AMS, activator and de-activator, private user classes and data, user application layer OODBMS is not a silver bullet, but offers a coherent solution to the problem of managing different kinds of data
		Discussion	The statement about metadata is not correct in the case of D0 and CDF, D0 in particular has very sophisticated mechanisms in place
Wed	10:50	Topic	Discussion about database requirements
		References	N/A
		Discussion	Q: How did CMS evaluate the scalability of Objectivity? A: This is based on the assumption that Objy removes the 64k file limit, but even with this limit, things can work out if one federation is used per year. Federations of 10 TB or more are in production use Crucial to re-assess the requirements now that there is significant experience around with existing systems Alice and CMS seem to agree on almost everything except for the conclusions, probably due to different emphasis. Very true that the end user analysis is a very important requirement to the system The fact that Objy is a small company is very worrysome We do not need to aim for a perfectly integrated solution since we have decided to separate the transient from the persistent representations. It may still be easier to stick with a single system, though Navigation from N-tuple back to raw data does not seem to have the same importance for CMS and Alice; how important is it for us? Q: Why do CMS use an OODBMS if it is blobs in the end that get stored? A: Not really the case - CMS is storing well structured objects for the most part ODMG compliance should not be overemphasised - that's not the way industry has been going How do we proceed in capturing Atlas' requirements? Interested people should send their input to atlas-database@atlas-lb.cern.ch or even to atlas-sw@atlas-lb.cern.ch and atlas-phys@atlas-lb.cern.ch RD45 will set up a small working group on requirements with representatives of experiments - should take non-LHC experiments into account as well Decisions should be avoided that narrow us down unnecessarily, should try to preserve options with minimum hazzle
Wed	11:30	Topic	D. Rousseau: Introduction to reconstruction
		References	N/A
		Summary	Steps to do: 1) Atrecon-like OO/C++ on Geant3 data; 2) Atrecon-like on G4 data; 3) incremental improvements of algorithms, new algorithms First step started already - algorithms being rewritten, interfaces being defined, big modules being split into manageable pieces, factorising commonalities. Integration with the framework to be done as soon as it is available Beyond that: updated raw data format and content, ROD simulation; use of databases and detector description; alignment and calibration; speed and robustness; improved and/or new algorithms Combined performance: either wait for upstream information, or direct conversion of existing banks/N-tuples Systematic comparison of new code with Atrecon on Physics TDR data, will require changes of detector layout in Atrecon Need coding rules, naming conventions, guidelines Test beam studies to be considered Reading Geant3 data into new framework expected by autumn 2000, Geant4 data and full database use in 2001 Report with reconstruction plans available
		Discussion	Q: How far is the reconstruction code with the conversion to C++? A: Depends a lot of the detector, see next talks for details Q: What is a reasonable time scale for G4 data? A: There is the TDAQ TDR in 2001, for which Geant4 data would be most useful, which means that the data must be available by end 2000, irrespectively of the physics testing of Geant4
Wed	11:45	Topic	D. Rousseau: Inner Detector reconstruction
		References	N/A
		Summary	Track reconstruction well understood, several packages (two in C++). Planned: adapt to new framework, modularise, converge, improve algorithms Raw data to be defined more precisely, detector description being exercised, geometry handling to be done, no provision yet for calibrations, noisy/dead channels, ... Track finding: wealth of algorithms available (general purpose as well as specialised), partly quite different, but using similar utilities that should be factorised. Improvements of algorithms still foreseen Track extrapolation: well defined, but difficult (performance requirements) Fitting: two algorithms (Kalman, chi^2), closely coupled with track finding algorithms Track output class: broad agreement on content, design choice more general than just track, utilities to be provided Other items: vertexing, kinematic fitting, conversions, K0, visualisation, ...
		Discussion	Q: What is exactly planned concerning the convergence of the utilities of iPatRec and xKalman++? A: Detailed considerations are only starting now. Work done by Hywel Philips is part of this Breaking large modules into smaller packages is a big job that requires lots of work defining the interfaces - how are we going to organise that? A: The package authors will take care
Wed	11:55	Topic	J. Schwindling: Liquid Argon Calorimeter reconstruction
		References	N/A
		Summary	Comparing code in Atrecon with new ones, clear that algorithms should be preserved, improving the structure and later adding missing items. OO analysis and design (USDP approach) going on in parallel, leading to entities, packages, and interfaces Comparisons with Atrecon very important; want to obtain exactly the same numbers, then compare CPU and memory consumption, and improve algorithms Things to be done: access to G4 and real data, electronic noise and pileup, database for geometry, calibrations, ..., particle identification Testing starting now, list of entities and packages by May 2000, use-cases from others started, code for event filter by end 2000 No major technical problems foreseen, but time scale and process dominated by the motivation of people
		Discussion	What do you do if in the process of comparison, you find a bug in Atrecon? A: Understanding the differences is the minimum, we may correct Atrecon and re-run it Pileup etc. can be added at three different stages: at generator level, at hit level, at digi level. Needs more understanding, but hits are obviously needed. Should not be in the reconstruction
Wed	12:10	Topic	F. Merritt: Tile Calorimeter reconstruction
		References	N/A
		Summary	Tilecal pilot project completed in December 1999, test beam analysis going on Paso triggered discussions among LAr and Tile, common interfaces foreseen for cells and clusters, common utilities - this requires some changes to the Tilecal pilot project Main elements: cell energies (tile only), towers (radial sums of cells) - first tile only, then combined with LAr, clusters (aggregates of cells or towers), protojets (combined clusters), jets. Code to support different strategies. All kinds of objects will be usable as seeds for jet finding Target dates: Read G3 cells into Paso in release 0.0.41, define towers by April 1 (feedback by May SW week), sample version of cluster and jet finding code by April, further development on cluster and jet finding, comparison with Atrecon through summer 2000
		Discussion	Q: Is the eta grid of 0.1 by 0.1 enough for Etmiss to work? A: To be discussed with the experts
Wed	12:20	Topic	J. F. Laporte: Muon system reconstruction
		References	N/A
		Summary	Existing software: cleanup and consolidation going on now, disconnect trigger, muon system reconstruction, combined muon reconstruction. Concerns that there is no active DICE maintainer Muonbox (Fortran): going to be wrapped in Paso using last version Amber (advanced C++, well designed): developed under NT, being ported to Unix. Maintainers being identified. Both packages will be with us in the foreseeable future Ideas about modularisation and interfaces exist (track segments in station, track fitting segments, track fitting digits) Track in Amber is very sensible, separating data and algorithms, quite similar to ID ideas, taking into account various qualities, different representations, different locations, ... Most critical operation: propagation of tracks with stringent performance requirements. Two candidates exist (Cobra, one in muonbox), will be provided as track helper class Release of ongoing update now, Muonbox in new framework, modules and common track class in March, Amber in new framework in June, revisit common modules and track class in summer
		Discussion	Q: Where do you take the detector description from? A: For the last four years or so, AMDB was used, hence no major changes are expected
Wed	12:30	Topic	S. Tapprogge: Trigger Level 2 reconstruction issues
		References	N/A
		Summary	Issues: need to check trigger decision online (EF) and offline. L2 code must be resource friendly. Access to calibration and alignment, development environment Priority: finish technical proposal, survive T/DAQ reorganisation implying interim period
		Discussion	Basic entities and interfaces are very important, need to be defined sooner rather than later
Wed	12:35	Topic	F. Touchard: Reconstruction in Event Filter
		References	N/A
		Summary	Not a plan... but requirements on plans of other people! Offline algorithms and code to be used in EF (expertise, maintenance, avoid biases) Constraints: ~ 1 kHz rate after L2, flexible boundary between L2 and EF. Assuming 1 processor per event means 1000 processors per second of processing time (issues of cost, management, space); urgent to evaluate asap a realistic size, on-line access to data bases (calibration, geometry, B-field, mass storage), event model, robustness Need asap realistic code to evaluate required resources; algorithms must be modular, robust implementation with run time exception handling, efficient, flexible
		Discussion	There is a conflict - we won't have the final code by end 2000... Q: Understanding of CPU constraints hopefully does not depend on how the geometry is obtained. A: It makes a difference whether or not we can hold the geometry in memory
Thu	14:00	Topic	N. McCubbin: CERN review of LHC computing
		References	N/A
		Summary	No separate LHCC review, amalgamated into CERN LHC computing review CERN review: Steering board (chair: Sigi Bethke), panels on computing model (chair: Denis Lenglin), software project (chair: Matthias Kasemann), management and resources (chair: Mario Calvetti). Atlas represented in all committees by a representative and a deputy/alternate Driving force of CERN review: lack of resources for LHC computing Review to report to CERN management at the end of spring 2000 Software panel: 4 talks by Atlas on 17 March about process, planning, training and milestones; architecture, data model and program infrastructure; simulation and physics; non-experiment specific software; Atlas expected to answer a couple of questions Management and resources panel: kicked off, Atlas to report on 24 March about its hardware requirements for high-level trigger and reconstruction if to be implemented today Very rough go at a schedule: Computing TDR in 2002, MDC I before TDR, MDC II involving regional centres after TDR. Trigger TDR in 2001, hence realistic studies in 12 months' time, hence constraints on framework, I/O and reconstruction modules. Does not look completely crazy Highly interesting and demanding period ahead of us
		Discussion	Q: How are we to select speakers, and to collect information? A: CSG will be deeply involved, input on contents will be solicited from the full community Q: What about data modelling and event definition? A: It is taken into account in the plan Q: Should summarize all what would need to be done for May, September, ... A: Yes, will do that Should use the tools recommended by Atlas All help appreciated by people who know how to plan software activities How many items do we expect to end up with? BaBar had 800 items on reconstruction, and 400 ones on data base...
Thu	14:50	Topic	T. Johnson: Java Analysis Studio
		References	N/A
		Summary	JAS started from SLD experiment, based on IDA (Toby Burnett) and SLD extensions - only concepts survived. Integrating ideas from LHC++, Hippodraw, ..., and exploiting advantages of Java. Aim: solve real life physicist problems JAS: Modular Java toolkit for analysis of HEP data - data format and experiment independent, arbitrary complex analysis modules written in Java, rich GUI including data explorer, histogram display, manipulation and fitting, ... user extensible. Supported on Windows, Linux and Solaris, known to work on many more machines Components: Can really be used independently from each other Remote data access: transport analysis code to the data, not the other way around, but giving the impression as if the application ran locally (using Java agent technology). Extension (being worked on): distributed data analysis Example of Java analysis code: reconstruction of linear collider data Convenient installation procedure at least for Windows Demonstration: opening and working with a PAW N-tuple, interactive manipulation of histograms and their representation, code for analysing N-tuple, projections and slices, interactive fitting, access to a data server at SLAC (simulated linear collider data) running remotely, still preserving all manipulation power, experiment-specific plugins, scripting interface (BeanShell) New features: Plot component can be used in other applications, MVC (model-view-controller) design, jEdit editor incorporated, HTML support (display HTML within JAS) Future features: 3D support Users: BaBar for Online data monitoring, US linear collider studies (complete reconstruction and analysis package in JAVA), CLEO, other smaller scale users OpenSource: Experiments can contribute! Sources in cvs, accessible via Web or cvs server. Intend to put all code under LGPL, platform-independent build system Documentation: LCD step-by-step tutorial, users guide being augmented, HOWTOs being created, ... Ongoing work and requests: requested: fitting from program, page layout from program, scripting; integration with Wired, with LHC++ (moving towards AIDA, the generic interfaces); data access: working: PAW, stdHEP, SQL, flat file, Java Objects; ongoing: Objectivity; future: Root, generic C++ objects Atlas needs simple data objects - lightweight transient/persistent layer, minimise unnecessary use of templates, ... Website: http://jas.freehep.org/
		Discussion	Q: What about booking, filling, operations under program control? A: Being investigated... need to understand what exactly the requirements are Q: Could JAS be made to work with Condor? A: Probably yes, but not trivial Q: What output data formats does JAS support? A: Histograms in serialised format or GIF images or XML, otherwise there is nothing yet Q: First user requirement is to have the functionality of PAW Q: Logging/macro recording is very important; what about vectors of points and vector operations? what about function plots? A: Being considered - many people have asked for it Not all user requirements are the same Q: Is the performance good enough for online applications? A: Only minor problems seen in BaBar online monitoring Q: How many people are working on JAS? A: About two full-time persons, plus fractions of other people's time
Thu	15:55	Topic	V. Vercesi: Event filter software - status and plans
		References	N/A
		Summary	Event filter: some kHz input rate, some 100 MB/s output Still early for final implementation, further studies needed on architecture on technology DAQ/EF prototype "-1": scaled down version of "final" architecture EF will be highly CPU bound, expected to need at least 25 SPECint95 s per event; can study issues on small-scale models Filtering code: inherit as much as possible of the offline code Share of rejection between L2 and EF not yet clear; need to exploit early physics discovery potential Monitoring and calibration: global physics monitoring possible, EF ideally suited. Even simple alignment and calibration tasks are conceivable Data flow is specific for the EF, addressed by factorising the EF farm into components: sub-farm input, event handler, sub-farm output, supervision and control (crucial!) Different implementation choices being considered, not changing the component model Java mobile agents being considered Implementation candidates: PC commodity, SMP, Intel multiprocessor (SCI interconnect) - all implemented in prototype "-1" Would have been ideal to have the final reconstruction code available for these tests - have used a transformation of the Fortran calibration program of the EM calorimeter reconstruction to C++; Atrecon Fortran code tried as well (painful experience - needed to create an interface to ATRIG, difficult to use) Policy of using offline code in EF based on many considerations (experience and common sense): manpower shortages, transition between the two worlds, direct comparison; but requires that development of algorithms takes requirements of EF into account from the beginning. Funnel shaped selection required. Parametrisation needed in many places (e.g. B field); reconstruction only needed in EF in part of the detector Implications not only on algorithms, but on whole architecture; need to run L1 and L2 code in the framework Need software which is representative of the Atlas reconstruction and analysis chain; EF ready to plug this code in. Important that this code be available soon in order to evaluate resources. Staged approach perfectly valid Prototype "-1" chosen as next-generation test beam DAQ system, busy implementing reconstruction, calibration and alignment code EF group can be considered a "user" in the sense of the architecture team
		Discussion	For May 2000 framework milestone, some of the issues will be addressed. Experience in BaBar does not raise concerns about the overhead of the framework CTP: about 250 SPECint95 s for reconstructing a full event, EF budget is 25 SPECint95 s Trigger/DAQ TDR should give the real picture of the final system, which requires sensible, credible and reliable estimates Architecture work needs to take into account L2 (and perhaps even L1) issues
Thu	16:35	Topic	M. Stavrianakou: Repository and releases
		References	N/A
		Summary	Most information available through librarian's and developers' Web page Some 45 top level packages, contributed software, external software, pseudopackages (interfaces to external packages) Fortran and Age quite stable, slow growth of C++ (don't people develop any longer?) External software outside repository: Isajet, Herwig, Geant4, Qt, Cernlib with shared libraries Supported platforms: HP, DEC, Solaris, Linux (still on RedHat 5.1); AIX has been dropped Sticking with about fortnightly releases, nightly builds being used now by developers Possible improvements: tag submission via WWW interface, automatic notification of package coordinators in case of errors, possibility of multiple builds for each target (debug and optimised), possibility of using packages from previous releases (?), possibility of phased (staged) releases (a la CMS SCRAM) Production release: 9 months late, waiting for Ecal testing. As soon as this is finished, freeze production release and remove write access to test area. Production release with archive libraries only. Updated production release later with atlsim (at least on HP and Linux), and remove read access to test area. After that, development on the Fortran software can be done, but not the full testing procedure for production software Build and release tools: SRT, CVS server, build server, build logfile analyser, browsers, automatically maintained list of package coordinators, dependency grapher, FAQ - maintained by Lassi Tuura Outstanding issues: coordinators for generator packages (except for Isajet and Herwig); AGDD not yet in repository; simulation with Geant4 not yet in repository; package author list still to be updated; some circular dependencies left; build and release improvements; future of SRT - confusion, frustration, anger etc etc
		Discussion	Q: What is the current usage of DEC? A: Only one institute expressed interest; there is also a problem with shared libraries on DEC If linksets are to be used, all basic packages need to be converted first to use them Q: What about the required change of the muon system geometry? A: Not for the production release, will go into the fortnightly releases
Thu	16:55	Topic	M. Stavrianakou: Technical group
		References	N/A
		Summary	Web address (preliminary) Mandate and organisation: open forum for discussion of technical issues such as configuration management, programming support, external software, infrastructure, tools, testing, documentation etc., consulting with QC group, data base group etc. Can decide on strictly technical issues, reports and recommends to CSG on decisions that have political impact Communication via atlas-sw-developers or atlas-support; no formal membership. Proposal to identify a core team of people, with one referee per issue Open issues: Naming conventions and namespaces (new proposal based on DIG decision in 1998 - QC group and CSG involved); shared libraries, recommendations/scripts for user setup; garbage collection (recommendations by Lassi Tuura, decision by CSG?); external software and how to "release" and use with Atlas release software; documentation (2 groups to target: developers/experts, and end users/beginners); setup scripts for Atlas offline; exceptions; logging; support for Java
		Discussion	Coordinator for documentation eagerly needed Logging of applications will be addressed by architecture team The Java question is a very involved question which requires a lot of work Technical group should address development in outside labs as well Important that the responsibility for each question is clearly identified and communicated in the beginning
Thu	17:15	Topic	M. Stavrianakou: Tools for C++ code checking
		References	N/A
		Summary	Evaluation performed, involving users in all steps Code used: Atlas event package, classlib, Geant4 (mainly processes) Criteria: technical, operational, managerial, other Surviving: CodeWizard (many checks implemented, 71% of Spider rules could be implemented; reports not customisable), performance equivalent to compiler; QA C++ (comes with 500+ checks, configurable to cover 65% of the Spider rules, STL support in next version, reports include metrics and are fully customisable - however, new version was not available at the time of the evaluation) Slight tendency for CodeWizard (cheaper, runs on Linux, much used in academia)
		Discussion	Cost for outside institutes is an issue Q: Are there evaluation licenses available? A: Not easily Q: How large is the overlap between the old Atlas rules and the Spider ones? A: Fairly large Q: What about Together and Remedy? A: Together is the recommended tool, new version being prepared by Steve Fisher. Remedy is being set up for Atlas now, should be up and running by end February
Fri	09:00	Topic	D. Rousseau: Event content
		References	N/A
		Summary	Two meetings held; goal: sketch event content by categories; feedback solicited Raw data: need revision of digits soon, feedback asked through data base coordinators, involving Detector Interface T/DAQ group Raw data content depending on trigger: short "normal" format, long format in case ROD input is passed on; decoding and pre-treatment to be handled by detector description Other online information: collider information (luminosity), slow control; storage depends on update frequency True event: particles from Pythia (and other generators), truth information from Geant4, separate from each other Trigger information: might evolve during a fill (but not during a run?). Trigger pattern before and after prescaling, all setup parameters in data base Enough information from L2 and EF to understand why a certain decision was made Reconstruction: see CSG & domains -> Reconstruction -> Entities; need for common behaviour of reconstructed entities, need ability to make any reconstruction result persistent Re-reconstruction of parts of the event: clear tagging mechanism required in order to handle output objects correctly; old results not to be modified Logging: which algorithms with which parameters were run, what happened during reconstruction, ... all accessible from data store
		Discussion	Need to clarify which body is responsible for discussing this, and through which channels the communication goes
Fri	09:30	Topic	J. B. Hansen: Report from Jets/Etmiss/E-gamma working group
		References	N/A
		Summary	Activities: Development of OO software for reconstruction, development of new algorithms. Quality control being addressed Comparison test beam vs MC; studying jet calibration based on MC studies MC studies: validation of Geant4 (understand required level of detail), shower parametrisation (again required level of precision to be understood)
Fri	09:35	Topic	J. F. Laporte: Report from muon working group
		References	N/A
		Summary	Muon isolation criteria to be addressed Muons inside jets dormant because of lack of manpower Rejection of pi/K decays Combined muon reconstruction at level 2 - simple, works well
Fri	09:45	Topic	D. Barberis: Report from b tagging working group
		References	N/A
		Summary	Group is merger of offline and trigger groups Trigger code: impact parameter resolution at level 2 looks fine; comparison of old code with CTrig: CTrig slightly worse; timing concerns overcome by modifying the pt threshold; outlook: add seeds from calorimeter, evaluate acceptance, comparison with Offline code Different methods for b tagging: vertex and soft electron, very different virtues, cannot easily be combined; neural network approach for the combination. Input: weights as given by the two algorithms. Results sightly better than for vertex method alone. Next steps: add jet pseudorapidity and momentum Improvements of vertex algorithm: use longitudinal impact parameter improves rejection by ~ factor 2
Fri	10:00	Topic	J. Hrivnac: Graphics status and plans
		References	N/A
		Summary	One or more graphics objects for each real object. Some domains well integrated, shortfalls in LAr, Tile, and Reco Scenes: display, statistics, misc. Display scenes in fairly good shape Strategy: Almost all event displays written in Java or Fortran, same direction in statistical packages. C++ little involved. Migrating graphics to Java, making maximal use of existing stuff. Strategic questions to be discussed in CSG, technical and architectural ones by technical group and A-team Plan: 2000: maintenance and bug fixes for C++ and Fortran framework, completion of graphical objects in C++, building of Java framework; ... Atlantis being converted to Java, Wired exists, GraXML and AVRML to be merged, XML to be made more general, JAS exists, AsciiText trivial, Core requires work Risks: Interface to legacy C++, contacts in LAr, Tile, Reconstruction
Fri	10:20	Topic	D. Barberis: Quality control group issues
		References	N/A
		Summary	Reminder of mandate Software "ownership": Each package to be owned by a working group (architecture, system, combined, physics); working group to review and approve design and implementation Goals: good design, good code, good documentation Software "onion" model only valid for very initial stages, onion kernel to be extended to the surface soon Coding conventions: Spider as starting point, added some minor Atlas modifications, examples of good and bad code, automatic checking tool. Could allow (few) documented exceptions if good reasons Software process: adopt UML as design language, consider USDP seriously for large projects, provide full documentation for every step (design documents, user guide, reference manual) for new software. For existing stuff, reverse engineering to be considered - most existing packages are not adequately documented Community invited to look at the documents, and to comment on them
Fri	11:10	Topic	H. Meinhard: Workshop summary
		References	N/A
		Summary	(see slides, I'm not going to summarise the summary here)
Fri	11:50	Topic	N. McCubbin: Conclusions, closing remarks
		References	N/A
		Summary	Another interesting (if exhausting) week A-team launched; architecture workshops March 9-11, April 17-19 Progress noted in several areas, hope that A-team launch can sharpen focus of those efforts, as should emergence of plan Very anxious to put a simulation coordinator in place as soon as possible Release tools: SRT is the Atlas release tool, all Atlas software should be under it. Some exceptions possible, but AGDD should not be one, but should be put into the repository as soon as possible Will continue with SRT for some time; hope that the review of release tools can resume in a good collaborative spirit Awareness-raising sessions: Java: useful and interesting. Pros and cons need reasoned assessment. Objectivity/persistency: will run and run... wait to see how RD45 organises input Agenda: a bit rushed this time. Please comment on format/scope. New organiser wanted
		Discussion	Clarify what our DB strategy is? A: Baseline choice is Objy, will promote its use for simulated and test beam data Q: Could some of the Architecture Workshop sessions be videoconferenced? A: Will try... No weekly software meeting on April 20 Many people missed the Thursday evening session...
Fri	12:15	Topic	C. Tull: May 2000 workshop
		References	N/A
		Summary	Looking forward to host the workshop on May 9-13. Possibly ancillary workshops on XML and geometry, and on HENP and HPSS Web page on organisation being prepared, follow the SW workshop page