GLAST LAT Project
Science Tools - 12 June 2002
The Science Analysis
Software Development Environment
-- for tools too!
T. Burnett
T. Burnett
1
GLAST LAT Project
Science Tools - 12 June 2002
Outline
•
•
•
•
Requirements
Implication
Review of SAS environment
Example
T. Burnett
2
GLAST LAT Project
Science Tools - 12 June 2002
Requirements
• There must be a single framework for development
and configuration of the software.
• The software tools must be able to interoperate with
the rest of the GLAST analysis software. This
includes simulation and reconstruction. Thus
libraries must be easily available to tools written for
either domain.
• We should be open to accept contributed software,
in any language, especially F77.
• We support the Linux and Windows platforms.
• Code documentation must be integrated with the
code itself, according to the doxygen convention and
current SAS rules.
T. Burnett
3
GLAST LAT Project
Science Tools - 12 June 2002
Implication: use what we have now
Item
Current technology choice(s)
File version control
remote cvs with ssh access to
repository at SLAC
Package management, build tools
CMT
with gmake/gcc or VC++,
Primary language
C++
wrappers for other compiled
languages, esp. f77
Development platforms
Visual Studio on Win 2K, XP
Red Hat Linux
Execution framework
Gaudi
T. Burnett
4
GLAST LAT Project
Science Tools - 12 June 2002
Pros and Cons for Science Tools
Pros
Cons
• Almost two years’ experience, • Science needs may differ
local support
• Could be rather difficult to
• Wider support
support contributed or
existing code, especially from
• We don’t want to draw a line
developers unused to C++.
between developers
• Makes it much easier to share
code
T. Burnett
5
GLAST LAT Project
Science Tools - 12 June 2002
Why C++
• Basic value of encapsulation of data now
well-established
• Build on success of Babar and all other new
HEP experiments: Belle, D0, CDF, ATLAS,
CMS, LHCb
• Now a standard, most compilers approach it
• Standard Template Library provides rich
menu of algorithms and object containers.
• Required to use a C++ specific framework
T. Burnett
6
GLAST LAT Project
Science Tools - 12 June 2002
About Platforms
• Windows PC
– Our preferred development environment
due to rapid development made possible
by Microsoft Visual C++ MSDEV
• linux
– The preferred choice for most European
developers
– Required for SLAC batch support
• solaris
– not supported now, but in reserve if
needed for SLAC batch.
T. Burnett
7
GLAST LAT Project
Science Tools - 12 June 2002
Why CVS?
• Concurrent Versions System, the dominant
open-source network-transparent version
control system.
• Useful for everyone from individual developers
to large, distributed teams:
– Client-server access method lets developers
access the latest code from anywhere there's an
Internet connection.
– Unreserved check-out model to version control
avoids artificial conflicts common with the
exclusive check-out model.
– Client tools are available on all our platforms.
• Web-based repository browser available
(cvsweb)
T. Burnett
8
GLAST LAT Project
Science Tools - 12 June 2002
Code management choice: CMT
Legacy of Babar’s SRT: building apps from packages
– Package: collection of source files, with public header files in
a folder (usually) with the package name
– Produces a binary library and/or executable
CMT (for Code Management Tool): our choice
– Developed at Orsay in response to deficiencies of SRT,
adopted by LHCb and ATLAS
– Supports Windows
– Clean model for package dependencies
• Support for compile-time, link-time, and execution-time
– Configuration specified in a single file
– The cmt tool generates makefiles, or MSDEV files
– Uses CVS tags to correspond to versions
T. Burnett
9
GLAST LAT Project
Science Tools - 12 June 2002
Execution framework requirements
– Support “event”-oriented processing, three
phases
• initialization
• event-loop generating or processing events
• termination
– Define flexible way to specify processing
modules to be called in the execute loop,
without need to recompile/relink
– Provide services, especially for making ntuples and histograms
T. Burnett
initialize
execute
finalize
10
GLAST LAT Project
Science Tools - 12 June 2002
Gaudi: our framework choice
• Open source
• Stable, but active developers, in use by LHC
experiments ATLAS, LHCb
• Very good documentation
• All code called via component interfaces:
–
–
–
–
Algorithm
Service
Converter
DataObject
• Support for shareables: all code is loaded
dynamically
• Job control parameters set in job options file.
T. Burnett
11
GLAST LAT Project
Science Tools - 12 June 2002
External software accessible by interface
packages
• Xerces – XML parser
• CLHEP – class library with 3-vectors, Lorentz vectors
etc.
• ROOT – analysis and I/O
• Geant4 – simulation of particles in matter
T. Burnett
12
GLAST LAT Project
Science Tools - 12 June 2002
Gaudi Algorithm as a component
• Components are similar to
those of Corba or COM:
implement an abstract
interface.
• Easy to substitute
components: actual
concrete implementation
to be used is determined
at run-time from a simple
ascii file.
• Example diagram: A
ConcreteAlgorithm:
• Implements 2 interfaces
• requests services from 6
services via abstract
interfaces
T. Burnett
13
GLAST LAT Project
Science Tools - 12 June 2002
How A Gaudi app works: a partial Block diagram
Services
FluxSvc
(sources)
Algorithms
FluxAlg
Persistent
ROOT
files
Transient Data Store
McParticleCol
G4Generator
GlastSvc
(geometry)
McPositionHitCol
TrkDigi
mc.root
TkrDigiCol
“TkrRecon”
mcRootWriter
TkrVertexCol
recon.root
reconRootWriter
T. Burnett
14
GLAST LAT Project
Science Tools - 12 June 2002
The SAS Documentation Task Force
•
Web Site
•
•
http://www-glast.slac.stanford.edu/software/core/documentation/
Charge
1.
2.
3.
Ensure that all GLAST SAS policies and procedures are accurately
documented.
Provide and maintain standard templates for code and web pages.
Assess the current documentation both for developers and users.
a.
b.
c.
Audit all GLAST SAS web pages to insure consistency and readability.
Audit existing Doxygen generated developer documentation to highlight areas of
improvement and guide creation of Doxygen guidelines.
Reorganize existing documentation, in conjunction with documentation owners.
4.
5.
6.
Maintain Doxygen guidelines for GLAST SAS, including examples.
Maintain automated generation of Doxygen pages for code packages.
Develop plans for generating and maintaining a GLAST SAS Developer
Guide.
7. Develop plans for generating and maintaining a GLAST SAS User Guide.
8. Arrange and participate in developer and user documentation walkthroughs.
9. Develop and provide online tutorials for all GLAST SAS utilities and
products.
10. Develop a plan for regular maintenance of the documentation.
T. Burnett
15
GLAST LAT Project
Science Tools - 12 June 2002
An example: GRB spectra
• Needs
T. Burnett
16