| Gleam/ |
Defines the Gleam application |
| ldfReader/ |
Does the initial handling of ldf data. It is used by LdfConverter, which takes the events as presented by ldfReader and writes digis to the event TDS. It is dependent on the LDF library, whose source is maintained by the Online group. See the package ldfBuild for more about this library.
Note to self: LDF is a wrapper around the Ebf (and other) data. See L(at) P(hysics) A(cquisition); also see: Also see: View of /fitsGen/data/ft1.tpl and GLAST-GS-DOC-001, Jan 22,2008: Science Data Products File Format Document and Physics Event Datagrams |
| LdfEvent/ |
Definition of the LDF-specific TDS classes. |
| LdfConverter/ |
Handles ldf or ebf input, either raw or "FITSified", storing digis in the usual place in the TDS. It depends on the ldfReader package to parse the input file.
The LDF Online's library EventSummary::marker routine is used to determine if the retrieved event is a data event or not. A marker == 0 denotes a data event (from Jim Panette 6/22/2004) non-zero makrers are non-data events..where marker == 5 is a "sweep event"...whatever that means. |
| RootConvert/ |
Will contain the code which is common for RootIo and for RootCnvSvc. The code which is expected to be shareable is the very low level conversion code, excluding any framework-like code, and anything related to the links between the different data classes. |
| RootDisplay/ |
Adds 2 menu items in the Gleam GUI to allow the user to set the requested index or run/event pair to be read in for the next event. Uses the RootIoSvc in RootIo to communicate requested run/event pair or index to RootIo. Note that if the requested index or run/event pair are invalid - the menu items will re-appear - requiring the user to make another selection. |
| RootIo/ |
Defines the Gaudi algorithms that read and write ROOT files. The following Gaudi algorithms are defined in this package:
- FhSetAlg: prepare the common data for the file headers to be written.
- mcRootWriterAlg: writes a Monte Carlo ROOT file using the MC data on the TDS.
- mcRootReaderAlg: read a Monte Carlo ROOT file, and puts MC data on the TDS.
- digiRootWriterAlg: writes a Digi ROOT file using digi data from the TDS.
- digiRootReaderAlg: reads in a Digi ROOT file and puts Digi data on the TDS.
- reconRootWriterAlg: writes a Recon ROOT file using recon data from the TDS.
- reconRootReaderAlg: reads in a Recon ROOT file and puts Recon data on the TDS.
- relationRootWriterAlg: writes a relation ROOT file using the relations stored on the TDS. This algorithm must be run after all other ROOT writing algorithms.
- relationRootReaderAlg: reads in the Relation ROOT file and puts relations on the TDS. This algorithm must run after all other ROOT reading algorithms.
Services: RootIoSvc Allows for random event access via the GUI (when using RootDisplay) and can control the event loop depending upon the min number of events in all read root files
One can also find a tool, FhTool, which give access to the current file headers, and a few helper classes (FhSystemEnv, FhJobOptions, FhCmtConfig and FhChronoStatTable) which ease the interpretation and use of the headers data, as demonstrated by FhDemoCaloSetAlg. |
| rootTestData/ |
A central location for ROOT test data. |
| rootUtil/ |
Builds a low-level ROOT interface library that can be used to access ROOT data.
Routines:
There is one test routine associated with this package, it is called test_rootUtil. If the test is successful - it will return an error code of 0 - otherwise you will see an error message and the run will return -1.
On Linux: glastpack.pl run rootUtil test_rootUtil.exe rootUtil/virj/src/test/testRoot.root.
On Windows: Using VCMT: Choose rootUtil as the current package From the Drop-down project list choose test_rootUtil - app Enter the path to the testRoot.root file located in rootUtil.
- Test:
- .root Click the Run button
|
| commonRootData/ |
Defines the ROOT classes that are common utility classes and/or are shared amongst the other ROOT packages.
This package contains:
|
| Detector Geometry: |
| geometry/ |
?????see Graphical Class Hierarchy |
| geomrep/ |
Contains graphical representations for various geometry objects. A test program demonstrates how to set up a simple display, and shows intersections of rays and shapes. |
| Simulation Algorithms: |
| G4Generator/ |
GLAST interface to the Monte Carlo simulations toolkit Geant4 (see here for more information on this C++ toolkit). The steering is done with the Gaudi algorithm G4Generator. |
| G4HadronSim/ |
Contains the code that implements the various Geant4 Hadron models available from the "physics_lists" subfolder of the standard Geant4 download.
For more information, please see the Geant4 website. |
| G4Propagator/ |
GLAST interface to the Geant4 version of the "Particle Propagator." The job of the propagator is to "propagate" the track parameters, including error matrix, from the point at which they are defined to a given end point.
Several classes are defined in order to accomplish this task:
1) G4PropagatorTool - This is a Gaudi tool for interfacing external Glast packages to the propagator. It is also responsible for obtaining the necessary Geant4 geometry information from the G4GeoemetrySvc as well as obtaining a pointer to the Geant4 TrackingInformaton class
2) G4ParticlePropagator - The top level class which implements the IKalmanParticle interface for the propagator. Mostly implements the functions for returning specific values
3) G4PropagationTool - a tool that implements the IPropagator interface.
4) ParticleTransporter - internal class which interfaces to the Geant4 volume code to perform the actual transportation through the Geant4 geometry
5) TransportStepInfo - an internal utility routine keeping track of information for each step. |
| Digitization Algorithms: |
| AcdDigi/ |
Contains all ACD digitization algorithms. The digitization takes as input the Monte Carlo data pertaining to the ACD volumes and determines the detector response of each Photo Multiplier Tube (PMT). |
| TkrDigi/ |
Contains the algorithms for Glast digitization: TKR. |
| CalDigi/ |
Performs the digitization of the calorimeter (CAL) simulated readout, as laid out in these requirements. |
| Trigger/ |
Implements
|
| Reconstruction Algorithms: |
| AcdRecon/ |
Contains the ACD (Anti-Coincidence Detector) reconstruction algorithms. The primary class in this package is AcdReconAlg which is a Gaudi Algorithm. |
| TkrRecon/ |
(See TkrRecon Namespace Reference.) contains the code that reconstructs tracks from hit strips in the TKR, and then reconstructs vertices from the tracks.
It's organized as a series of Gaudi algorithms that act successively, taking input from, and sending output to, the Transient Data Store. Starting from TkrDigi objects, it generates the TDS objects TkrCluster, then TkrPatCand, TkrFitTrack and finally, TkrVertex.
The major driver algorithms are written to support multiple implementations of a particular reconstruction. The interface between the algorithm and the implementation appears as a Gaudi tool. For example, TkrFindAlg currently has three implementations in various stages of development: TkrComboPatRec, TkrLinkAndTree and TkrNeuralNet, with Gaudi tool interfaces ComboFindTrackTool, LinkAndTreeFindTrackTool and NeuralNetFindTrackTool, respectively.
In order to simplify the interface to the casual user, the Tracker reconstruction chain is controlled by a top level algorithm, TkrReconAlg, which treats the major driver algorithms as Gaudi subalgorithms.
The diagram ... |
| CalRecon/ |
Reconstructs the energy and direction of incident particle from the calorimeter information.
Package contains 2 algorithms: CalClustersAlg and CalDisplay.
The control flow diagram of CalRecon package, including also the CalDigi package, is given on the following WEB page: CalRecon diagram
CalClustersAlg calculates the energy, position and direction for calorimeter clusters and applies energy corrections. Actually there is no real clustering algorithm implemented, CalClusterAlg now considers, that there is only one cluster including all hitted calorimeter crystals. For this "cluster" the algorithm calculates the following parameters and stores them in the Event::CalClusterCol object:
- total energy sum
- energy corrected by profile fitting method
- energy corrected by last layer correlation method
- energy sum for each layer
- average position
- average position for each layer
- direction of incident particle
CalDisplay algorithm provides the display of reconstructed data. |
| merit/ |
Implements an algorithm, meritAlg, that:
- copies variables from AnaTup to the output n-tuple (called "MeritTuple")
- does a PSF and Aeff analysis.
|
| AcdUtil/ |
Contains all various ACD utility classes and functions. The common feature of the code in AcdUtil is that it is can be used anywhere else in the ACD software.
This tends to fall into two categories: 1) Geomtrical descriptions and functions 2) Code to access and use calibrations
This package contains three Gaudi services which are described more below 1) AcdGeometrySvc is used to get access to details of the AcdGeomerty 2) AcdCalibSvc provides the calibrations used in reconstrucion 3) AcdSimCalibSvc provides the calibrations used in simulation |
| TkrUtil/ |
Package provides TKR utilities for common use, both inside and outside of TkrRecon. |
| CalUtil/ |
????? |
| HepRepCorba/ |
Implements a Corba server for the HepRepSvc. |
| HepRepSvc/ |
Implements a GAUDI service to provide HepRep functionalities for GLAST. HepRep is a standard HEP format for graphic description of an event; it is easy, extendable and flexible enough to accommodate all the possible event features.
HepRepSvc helps to build an HepRep representation that can be passed (in various ways) to an external graphical client for event display; known HepRep-compliant clients are WIRED (100% HepRep compliant) and FRED (not completely HepRep compliant, but almost). |
| HepRepXml/ |
Implements an XML streamer for the HepRepSvc. |
| userAlg/ |
A "user hook" allowing development of algrorithms in the Glast Gaudi environment Since it "uses" the global package Gleam, it depends on all packages needed to build the simulation/ reconstruction environment. This includes
- access to all quantities in the Transient Data Store (TDS)
- writing text output to the log file (which can be turned on/off with the gui "printer").
- generating histograms and tuples, which would then be written to a ROOT file. (Need to document this.)
- ability to add components to the display, via GuiSvc.
The primary component (which can be easily added to) is UserAlg.
Interactive Utilities:
|
| Ntuple Service: |
| ntupleWriterSvc/ |
Defines the service RootTupleSvc, which implements INTupleWriterSvc. It allows for multiple trees and multiple files, and has only a setup phase: one defines the tuple at initialization time, with pointers to the tuple values. |
| AnalysisNtuple/ |
Contains a set of tools and an algorithm that runs them to produce a comprehensive ntuple of recon results. The tools, which can be invoked independently from the algorithm, also allow access to all of the calculated variables.
The package name is a bit misleading, since the only the algorithm depends on NTupleWriterSvc, not the tools. |
| xmlBase/ |
Provides services for parsing, interpreting and writing xml.
For basic parsing and access to parsed information it depends on the W3C DOM Specification and in particular makes use of the Xerces implementation of the DOM. Value added in this package includes
- several utilities for more convenient retrieval of information from an xml document
- an implementation of the IFile interface, to be used with documents such as instrument.xml which have an ini file-like form. Such documents should preferably reference the dtd ifile.dtd in the xmldata subdirectory of this package. See the file myIFile.xml in the same subdirectory for an example of how to do this.
- functions to serialize an in-memory DOM representation of an XML document to an output stream.
Examples of use of some of these facilities may be found in the test programs main.cxx, test_mem.cxx and test_IFile.cxx |
| xmlGeoDbs/ |
Provides a place to keep geometry description files separately from the code (in packages xmlUtil and detModel) which interprets them. Files common to all descriptions (currently dtd and materials file) are kept in the xml directory of this package. Instrument-specific files are kept in a subdirectory of the xml directory named after the instrument so, for example, files specific to the flight instrument are in xml/flight. The top file is named after the instrument (e.g., xml/flight/flight.xml). The "meat" of the description is entirely in included files, such as flightCALDimPrim.xml (floating point constants used in calorimeter description) and flightTKROneTkr.xml (simple solids and their positionings to build up tracker for a single tower).
Subdirectories are used as follows:
- flight is for standard LAT instrument. There are two versions: flight.xml and flightSegVols.xml. The only difference is that CsI crystals are built up as a stack of smaller CsI volumes in the latter case
- latAssembly has descriptions of the different missing-tower configurations as the LAT is being assembled. Since there is only one configuration with a particular number of towers, the top-level files have names like 2TowerSegVols.xml
- em is for the complete Engineering Model instrument, calorimeter + tracker
- minitower is for the Engineering Model, tracker only
- cu is for Calibration Unit
- Slab trivial single-box geometry for testing
- flightSlab integrates slab and current flight model
- misalignment mostly use standard flight geometry, but place towers one by one to produce known misalignments for testing.
- EM Unused; obsolete.
|
| xmlUtil/ |
Provides services for manipulating certain generic xml elements. At this time these include elements for describing constants and arithmetic (, , etc.) and those having to do with recording the genesis of an xml file ().
The DocMan class and the derived class GDDDocMan facilitate sharing of a single XML document among several clients. Clients can sign up to be called back when an element of a particular type is encountered. DocMan itself is responsible for parsing the file and managing the resources this requires. GDDDocMan "knows" about constants; it provides the additional service of evaluating and substituting for constants before any client handlers are invoked.
This package also provides classes for representing and manipulating identifier dictionaries and identifier conversions. An identifier logically consists of a sequence of (name,value) pairs in which the value is a non-negative integer. An identifier dictionary is a means of specifying constraints on a collection of Identifiers in such a way that
- The collection of identifiers forms a tree
- Given the value sequence from an identifier, it is possible to reconstruct the (unique) corresponding name sequence.
An identifier conversion is a list of operations defined on a subcollection of identifiers from a dictionary, transforming them to a new collection of identifiers (not necessarily belonging to the same dictionary). An id converter is a group of compatible identifier conversions.
These elements (for arithmetic, identifiers, etc.) are described in gdd.dtd, the dtd describing generic geometry, hence that file and the xml files using it are also kept in this package. When xml namespaces become usable with a c++ parser it would be preferable to split off the utility elements into their own namespace(s).
In addition to several test program, this facility includes stand-alone programs to automatically generate special-purpose xml files from an initial file describing an instrument.
See release.notes for recent activity. |
calibGenACD/
|
Contains code to produce calibration constants for ACD. The package includes the following executables:
- runPedestal.exe: runs pedestal calibrations using periodic triggers
- runMipCalib.exe: runs mip calibrations using charged particles and tracker data
- runRangeCalib.exe: runs range crossover calibration using all event data
- runVetoCalib.exe: runs veto threshold calibration using all event data
- runCnoCalib.exe: runs veto threshold calibration using all event data
- runCoherentNoiseCalib.exe: runs coherent noise calibration using periodic triggers
- runCarbonCalib.exe: runs carbon peak calibration using CAL GCR selection and tracker data
- runRibbonCalib.exe: runs ribbon attenuation calibrations using charged particles and tracker data
- runHighPed.exe: runs pedestal calibrations special AcdPedestal run
- runVetoFitCalib.exe: runs veto threshold v. setting calibration using special calibraiton runs
- runCnoFitCalib.exe: runs cno threshold v. setting calibration using special calibraiton runs
- runHighRangeCalib.exe: creates high range PHA -> MIP calibration using various inputs
- runMeritCalib.exe: runs a check on gains, thresholds and range calibrations
- calibReport.exe: make the HTML report for a calibration
- makeResultTree.exe: convers the calibration xml file to a root file
|
| calibGenCAL/ |
?????see Calorimeter Calibration Software calibGenCal v3 (???) Description, Document # LAT-TD-05595-01 (Mark Strickman) and Cal Calibration Software (Zach Fewtrell) |
| calibGenTKR/ |
Set up to run two calibration applications:
- the root macro doBadStripsCalib as a compiled program to calibrate hot/dead strips in TKR.
- TOT calibration using cosmic ray muon data
|
| calibRootData/ |
Contains Root classes used in conversion of calibration Root files to TDS objects
Typical TKR files, like ToT charge injection calibration, will be composed of one tree per tower. The tree will have two branches, one with a single TkrTower object, the other with a set of objects, each of which has data for a single unilayer. See, for example, the class TotUnilayer. |
| calibTkrUtil/ |
????? |
| calibUtil/ |
Contains utilities for storing, searching for, and accessing calibration data. "Calibration data" include at a minimum hardware status information, such as hot and dead tracker strips, and conversion constants, such as those characterizing light attenuation in calorimeter crystals.(also see Calibration Services Specification) |
| CalXtalResponse/ |
CalCalibSvc. ICalCalibSvc provides a Cal specific streamlined interface to the GLAST calorimeter calibration database. CalCalibSvc is currently the only concrete implementation of this interface.
CalCalibSvc supports the following features:
- Simple interface: requires only specification of unique Cal xtal and range as input.
- Some calibration types are vectors which represent the 'knots' on a spline curve.
CalCalibSvc generates the spline objects for these types for the user. CalCalibSvc handles storage/deallocation/validation for these objects.
Once created, spline objects are retained in memory until they become invalid. At this point, the cache is flushed and new objects are created.
- CalCalibSvc can be configured to assign different flavors to each calibration type.
- Multiple instances of CalCalibSvc may be created if the user needs more than one flavor for one or more calibration types.
|
| CalibSvc/ |
Contains classes and interfaces for calibration-related services, in particular a data service, a conversion service for the metadata, and (ultimately) conversion services with associated converters for individual calibration classes. |
| CalibData/ |
Contains data model for the transient detector store: definitions of the classes and of hierarchy within the store and assignment of class ids. |
| MootSvc/ |
Contains classes and interfaces for Moot-related services. Classes for some data returned by Moot services may be found in the CalibData package. |
| mootCore/ |
Contains classes and interfaces providing configuration tracking services (aid in building, registering with fmx, queries, etc.) to online users, such as LICOS.
A separate package, fully integrated into GLAST Offline, will provide the subset of those services of interest to offline analysis. |
| CRflux/ |
Defines the following cosmic and earth albedo fluxes
The following heavy ion sources are defined: CrHeavyIon CrHeavyIonVertical CrHeavyIonZ6 CrHeavyIonZ14 CrHeavyIonZ15 CrHeavyIonZ26 CrHeavyIonVert6 CrHeavyIonVert7 CrHeavyIonVert8 CrHeavyIonVert9 CrHeavyIonVert10 CrHeavyIonVert11 CrHeavyIonVert12 CrHeavyIonVert13 CrHeavyIonVert14 CrHeavyIonVert15 CrHeavyIonVert16 CrHeavyIonVert17 CrHeavyIonVert18 CrHeavyIonVert19 CrHeavyIonVert20 CrHeavyIonVert21 CrHeavyIonVert22 CrHeavyIonVert23 CrHeavyIonVert24 CrHeavyIonVert25 CrHeavyIonVert26 |
| DetDisplay/ |
Gaudi constituents (all IGuiTool's)
- DetectorDisplay -- Uuses the Glast geometry instantiated by the DetectorGeometry visitory to display the detector.
- MCdisplay -- Displays the Inthits, Poshits, and tracks from data found on the TDS
|
| EbfWriter/ |
A "user hook" allowing development of flight-oriented algrorithms in the Glast Gaudi environment. Since it "uses" the global package Gleam, it depends on all packages needed to build the simulation/ reconstruction environment.
This package has 2 functions:
- Convert the hit information obtained from the TDS into the on-board format to write to TDS
- Encapsulate flight code, to allow evalutaion of flight algorithms in the off-line enviornment.
This package demonstrates how to:
- access to all quantities in the Transient Data Store (TDS)
- writing text output to the log file (which can be turned on/off with the gui "printer").
|
| FluxSvc/ |
Implements the Gaudi objects:
- FluxSvc: mangages (using the package flux) the sources. Also implements the Runnable interface
- FluxAlg: generates the current incoming particl
- ExposureAlg: if a Clock (or "TimeTick") pseudo-particle was geneated, puts the info into the exposure history
- PointInfoAlg; Manages calculation of position and orientation entries in the "merit" tuple, with an entry per event, and the pointing info tuple, fed by ExposureAlg.
Usage is primarily via the FluxAlg algorithm, which access the service to generate a particle and place it in the TDS.
|
| Interleave/ |
Manages the insertion of interleaved background events into a Gleam simulation.
|
| SwigPolicy/ |
Simplified Wrapper and Interface Generator, provides an easy way of exposing C and C++ code to higher level languages, such as Python.
This package provides the infrastructure for exposing SAS C++ code as modules that can be readily imported and used in the Python environment. |
| astro/ |
Builds a library with useful Astronomical utility definitions
|
| idents/ |
Contains identifier definitions for
- towers (ModuleId)
- crystals (CalXtalId)
- ACD Tiles and ribbons (AcdId)
- Tracker volumes down to wafers (TkrId)
- Geometry Volumes (VolumeIdentifier)
|
| configData/ |
Defines classes that hold LAT configuration information for the processed event.
This package contains:
|
| lsfData/ |
Definition of the LDF-specific TDS classes |
| detCheck/ |
Provides tools for examining and validating a detModel geometry description. Each tool is implemented as a c++ class and a standalone program which invokes it. Other applications linking to the library may also use the classes. The entire package may someday become a subpackage of detModel.
To date five functions are provided:
- Overlap checking, executable test.exe. See the class Overlaps and main program overlapsMain.cxx. It examines all sibling positioned volumes (children of the same composition or stack) to see that they don't overlap. It also checks that all children of a composition are contained in its envelope. There is also a dump mode which will output volume dimensions and positions even when there are no overlaps.
- Documentation of constants, executable constsDoc.exe. See the main program constsDocMain.cxx, which invokes detModel utilities to produce html output.
- Summary materials statistics, executable summary.exe. See the class SolidStats and main program solidStatsMain.cxx. It outputs numbers of volumes made of each material, total cubic volume of each material, and so forth.
- Creation of heprep file from xml desscription, suitable as input for FRED
- Dump of geometry information (centroid position; X,Y,Z dimensions) for all active elements, executable dumpIds.exe
|
| detModel/ |
Provides an interface to a generic detector description or model suitable for use by an application such as Simulation or Reconstruction.
Currently, the source of the model is an xml file, such as flight.xml, which describes a particular detector according to the document type description in ggd.dtd, but clients of detModel are insulated from the xml source.
For more news please look at http://www.fisica.uniud.it/~riccardo/research/glast/GDD |
| enums/ |
Definition of common enumerations
|
| facilities/ |
Consists of simple utility classes. One of them, Util, is a place for static routines with no other logical home. |
| flux/ |
Implements source definitions, and a procedure to extend them. |
| gui/ |
Primary user interface is through a singleton GuiMgr object. It manages:
- gui::GUI the primary interface to the window system. GUI is abstract, must be actually implemented by either WinGUI or MotifGUI
- gui::Menu - Encapsulates the menu bar for an application, a collection of pull-down menus.
- gui::SubMenu - Represents a pull-down menu, GuiMgr maintains one for the File menu.
- gui::DisplayControl - Manages 3-D graphics
- gui::PrintControl- Allows user control of printout to an associated console window
See the Document describing its use. = Dead link. |
| rdbModel/ |
Contains classes and interfaces for describing and accessing a relational database. In particular it is designed with the calibration metadata database in mind. The only persistent input form of the description supported at this time is XML; see rdbmsDescrip.dtd. |
| tip/ |
Provides a generic, iterator-based interface to tabular data. Includes file-related abstractions which are independent of the low level data format (e.g. FITS or ROOT). |
| celestialSources/ |
Container package for astrophysical sources to be used by Gleam and observationSim. |
|
The GRB Physical model: simulating a transient source |
|
Redefinition of the GRB phenomenological model for Gamma-Ray Bursts |
|
|
|
PulsarSpectrum is a package that simulates gamma-ray emission from pulsars within different models and scenarios. It is based on the same structure of the GRB package contained in celestialSources. It is fully compatible with the GLAST LAT software, and can be easily interfaced with Gleam or ObservationSim in order to produce photons from gamma ray pulsars for studies on science performances and data analysis. The Simulator is also able to compute the timing decorrections due to period change and barycentric decorections. As the GRB simulator, PulsarSpectrum creates a TH2D ROOT histogram that contains the flux of the simulated sources (ph/m2/kev/s) vs. energy (keV) and time (s.). The time profile of the source is a 1 (or 2) peaked curve (random generated), and the spectral profile is created according to the emission model choosen by the user. This TH2D histogram is then available to Gleam and ObservationSim simply through the flux package. The source code for PulsarSpectrum is included in the celestialSources package under the directory named Pulsar. The test program is named test_PulsarROOT.exe and produce some plots of an example of pulsar whose parameters are set in the code of the executable.
2 simulation models are included:
- PSRPhenom, based on an analytical formula for the spectrum based on Nel and DeJager (1995 ;
- PSRShape, that allows the user to simulate arbitrary phase-energy models;
|
|
|
|
|
|
The sources in this package implement flux::ISpectrum sources to provide photons from astrophysical sources for Gleam and observationSim. |
|
microQuasar is a package that simulates gamma-ray emission from x-ray binaries/microquasars. The model simulates three aspects:
- sinusoidal modulation of the flux across the binary orbit period
- two regions of different spectral index across the orbit
- a cyclic "on" period for the high energy jet during the disk cycle
A description for how the sinusoidal modulation works can be found at:
http://d0.phys.washington.edu/~burnett/glast/generate_periodic/oscilations.htm
There are 16 parameters (case insensitive) to drive this model, supplied in the source xml file ... |
CHS/ ?????
ConfigSvc/ ?????(Eric Charles)
GCRCalib/ ?????
GuiSvc/ ????? (Toby Burnett)
STpolicy/ ????? (Toby Burnett)
f2c/ ????? (Toby Burnett)
| Last updated by: Chuck Patterson
02/25/2009 |
|
|