Notes from STAR Software and Physics Analysis Workshop
April 15-19, 1996, at LBNL
Notes last updated on April 29, 1996
Convenors: W.J. Llope, D.L. Olson, and L. Ray
Notes by: W.J. Llope
Pre-Workshop Announcement and Final Agenda
Notes for Monday, April 15, 1996
Notes for Tuesday, April 16, 1996
Notes for Wednesday, April 17, 1996
Notes for Thursday, April 18, 1996
Notes for Friday, April 19, 1996
Convenors' List of Major Action Items
Monday, April 15, 1996
Return to the top of this document...
Introductory Remarks, L. Ray
The goals of the workshop are:
- continue development of physics analysis software
- move to GSTAR/G2T
- move to MOAST
- OFL/DAQ, OFL/HC data interfaces
- continue the offline software design
A number of other issues were raised.
How much analysis should be done before the DST production, and
how much should be done after?
The existing body of software needs to be surveyed, and
collected into a fewer number of standard packages with adequate
documentation.
Realistic simulations are the best way to recognize what tools
are needed. what basic results are we after? what software tools
are needed? which exist? which don't?
We need a full production environment for dealing with the data.
GSTAR Update, P. Jacobs
GSTAR was released in early february, new geometry interface
(AGI) is available.
All detectors are "in", just fine-tuning and fixing small bugs
now.
All gcards, switches, etc., have been turned into kumacs. This
needs a little work still.
Pavel Nevski will discuss the geometry interface.
D. Irmscher will discuss the g2t table definitions.
Reiterated need for geometry database, and overall production
interface.
Advanced Geometry Interface (AGI), P.Nevski
This is a Fortran extension to Geant. It contains a number of
operators, all of which are of the same form. Detector systems
are modules, and geant volumes inside modules are called blocks.
Blocks consist of two parts, the description of its own
properties, and the description of its contents. Data handling
operators control what is saved and how. The structure name is
four letters long, and it is used both as the bank name and as
the prefix for all of the associated fortran variables. The
order of assignment is irrelevant, but comments are mandatory
(it will not compile otherwise). The common include file,
AGECOM, is the interface to AGI.
The famous GEANT problems that can happen if volumes overlap
is not easily fixed automatically here. Have to look at geometry
that you define to insure that no volumes overlap. The materials
defined are the standard set from the Geant manual, plus 10
more.
There are two ways to hook AGI up to a geometry database: by
using the same records as Geant uses (DETM structures), or by RZ
files. To read geometry from the database, one would does a USE
command.
G2T Tables, D. Irmscher
There is no automatic mechanism for making table definitions
for new detectors (but not many new detectors are expected).
At some point the tables must be frozen. Should this be after
g2t, or elsewhere?
Tables are now defined with *.IDL files (dataset library),
not in INFORMIX (hurray). Integers do not exist, use "long" type
instead.
There are two new tables - one for decay modes (decay_mode.idl),
the other for decay daughters (decay_daughter.idl).
Then showed present forms for ten more tables.
supervent.idl - used to connect several gstar/g2t events
downstream of g2t. May need more information in this table, i.e.
event numbers of first and last event for each subdetector.
event.idl - merge_info variable added, allows one to embed
something in events that were read in.
vertex.idl - no changes.
track.idl - small changes to track pointers and no. of hits.
naming conventions are needed.
tpc_hit.idl - added path length in padrow.
mwc_hit.idl - similar to definitions used for TPC, volume
ID definition still under discussion.
ctb_hit.idl - standard definition.
vpd_hit.idl - standard definition.
svt_hit.idl - needs work still, in progress.
ftp_hit.idl - needs work still, in progress.
Trigger Software, P. Yepes
Trigger detector response packages need to be modified for
gstar/g2t.
MWC needs a smaller pixels, then just count number of
pixels with non-zero signal.
Only VPD does not already give DAQ-like data, this needs to
be added.
The geometry definitions need work. This is presently being
done with modules, needs to be done with geomtry database.
Introduced rl0 module by J. Whitfield, which mocks up the FPGA
tree for Level-0 sums, min. & max. multiplicity, and summary
information to be used in Level-3. Being rewritten in C++, this
makes a lot more sense than Fortran in this case. The algorithms
are simple, but further simulations are still needed.
Results from Level-0 simulations can be found on the WWW.
For Level-1 and Level-2, will use module rl1 to look for
"fluctuations". This needs to be implemented. Can the same code
used online be used for the simulations? Results for Level-1 and
Level-2 simulations are also on the WWW.
For High Level triggers, need work in combining the TPC sector
information with the SVT information. For the TPC, a fast
clustering module (D. Schminske) (sp?) is about a factor of two
faster - it takes ~5 microseconds/event for outer rows of the
TPC. The joblist includes rewriting this code in C++,
implementing it in MOAST, and tuning it to tss and tdh (i.e. the
tpc slow simulator and the online cluster finder, respectively).
What are the physics goals from Level-3? temperature (w/ Pt
cut?)? correlations? mean-Pt?
Global and other observables from the EMC, T. LeCompte
Described basic uses of an EM calorimeter:
- pi-zero measurements (i.e. photon measurements),
- other particles (once the detector can do photons, it can
also do, e.g., electrons),
- triggering (calorimetry is very fast compared to tracking),
- high energy particles (calorimeter resolution better than
that from tracking).
The objects that can be identified with the EMC are:
- electrons
EM energy cluster, good shower shape, track pointing at
cluster, E/p near one.
- photons
EM energy cluster, good shower shape, no track pointing
at cluster.
- neutral mesons (pi-zero and eta)
two good photons (large spatial separation), or
one cluster consistent with two nearby photons.
- jets
EM energy in a cone, TPC/SVT tracks in the same cone
The physics that can be done includes (all estimates below
are for 100 days of RHIC running)
- W,Z production in polarized p+p. The yields are 60k W+,
15k W-, and 3k Z. Problems include backgrounds to W- from hadrons,
and in Z->e+e- when on electron is goes too far forward to be seen.
Also, the yield of Z's w/ both electrons in the barrel is small,
which restricts our measurement to large bjorken-X. Tracking
in the region 1e+X is interesting. The connection between the
b-quark energy and the electron energy is much better known than
connection between scattered parton Pt and the jet Et for generic
jets. Also, this is gluon-induced, so it is an independent measurement
of the gluon distribution in nuclei. Described the CDF algorithm.
Estimated 16000 reconstructed b->eX decays for 500 GeV p+p,
1600 for 100 GeV p+p, and 200 for 200 GeV p+A. If we can trigger on
lower Et electrons, the rates go way up.
- charmonium production in p+p, p+A, and A+A. Described many
reasons why this is interesting. Need low-Et electron ID, an
algorithm for low-Et photon ID, and a di-electron trigger. Yields
for J/Psi, Psi' and Chi for 500 GeV p+p, 200 GeV p+p, p+Au,
and Au+Au were presented. The rates are not negligible, but again
they depend on the thresholds that are applied.
- Other topics
DCC searches, Drell-Yan production, Diphoton production,
pi0/eta ratios, search for lepto-phobic Z' boson, charm
production.
Infrastructure needs are
EFS (the EMC fast simulator) is the highest priority.
ESS (the EMC slow simulator) is needed to settle some
final design issues: SMD depth, effect of dead space of
SMD electronics and possible removable SMD, optical
read-out chain properties, etc.
Calibration: how do we close the loop between source and
pulser calibration with E/p in the data?
Reconstruction software: how to convert SMD information into
photon positions and energies? matching tracks to
EMC energy clusters? identifying low Et electrons?
reconstructing jets in AuAu?
Physics Analysis software: what jet observables do we want?
is statistical analysis of global observables good enough
for jet studies, or must jets be done E-by-E?
also, we need to look at quantities derived from pairs,
which is difficult to do in TAS.
More information of the present status of EMC simulations can be
found here.
Tuesday, April 16, 1996
Return to the top of this document...
Event-by-Event Physics, I. Sakrejda
- Jet Analyses
- Dimensional analyses (see SN on WWW)
- HBT
- Flow
- Mean-Pt, Slopes
- Stopping
- Event composition, strangeness chemical potential (i.e. ratios)
- Exotic shapes
Multiple scattering in detector limits resolution for secondary
protons (which are slow). One is off by several centimeters when
sxtrapolating between the TPC and the main vertex. SVT could
help here - need to talk to Ken Wilson about this.
"Easy Physics" includes net baryons at mid-rapidity, particle
multiplicities (K/pi is doable), and Pt slopes.
We have several tracking programs. Generally, when one doesn't
need an excellent momentum measurement, the acceptance is |y|<1.6.
Good momentum resolution is obtained for |y|<1.4.
~30 MeV pions do not exit the beam pipe. This has consequences
for measuring the DCCs being discussed by V. Koch. How low in Pt
can we go?!? Lower limits on Pt are ~70 MeV for TPC (medium
rapidity), ~40 MeV for SVT (low rapidity), while FTPC does high
rapidities.
One can get about a 50 MeV boost from the maximum crossing
angle that is possible (~7 mr). This does not increase lifetimes
very much. This needs to be added to the simulations. The
corrections would need to be rechecked, and more granularity
(i.e. statistics) would be needed. This would give a better
handle on mean-Pt.
Another possibility for measuring v. low Pt pions is to lower
the magnetic field to overcome the energy loss in the beampipe.
This should also be simulated. Is this better or worse than
using large crossing angles to get at low Pt?
Do we need to reconstruct tracks to get the Mean-Pt? perhaps
we can just compare the hit densities in the SVT and TPC. Higher
temperature events have a higher occupancy in the outer rows
of the TPC. how do the fluctuations in the multiplicity affect
such a measurement? how exactly should one cut on "outer"/"inner"
information to get at the Mean-Pt?
Speed tests for TPC-only simulations. Old geant: ~20 min/event
with moderate amount of physics turned on. GSTAR: ~6 min/event.
If one shrinks the cave to the size of the TPC, one gains ~2
min/event.
Temperature correlations - there is a broad range of
reconstructed slope parameters for a single value of the of
the quark scatters. This is not caused by the reconstruction
algorithms, the same thing is seen when the pure events are
studied. The form EXP(-Mt/T) gives the best fit for quark
=475 MeV, while the form (Mt**2)*EXP(-Mt/T) gives the best
fit for quark =275 MeV. This analysis includes feeding from
resonances, i.e the events are not purely thermal in the first
place. This makes simple analyses hard. Perhaps adding the
information on the primary vertex will improve this. Expect ~300
um stability in the beam position for Au+Au, and ~10 um
stability for p+p; this will improve the momentum resolution if
used in the algorithm. To do more, one needs PID.
Stopping analyses - we can measure momenta rather well, famous
plot from Brahms proposal shown. Venus and RQMD dN/dy are
similar in STAR acceptance, but thee can be distinguished from
Fritiof. What resolution on this do we have E-by-E? How much do
the multiplicities fluctuate E-by-E? Most models have very
little fluctuations in this multiplicity. Need to get the FTPC
group more involved here.
Chemical Potentials (particle ratios) - presently can't
distinguish between primary and secondary protons with the TPC.
The scattering smears the impact parameter by some centimeters.
Need to get more help from SVT here, in particular at maximizing
the matching efficiency for low-Pt protons. The large ionization
of slow protons can help here - don't just match to nearest
track, but to nearest "big" track.
Need to investigate the full range of beam energies from the
AGS to RHIC!
Exotic Events (DCCs), V. Koch
Continued discussion of DCCs beyond that given at most recent
STAR collaboration meeting, i.e. are DCCs observable? One needs
to consider that there are two kinds of processes attacking any
DCCs that might be formed.
The first is that pions in the DCC are "reheated" by the
surrounding heat bath via the processes pi+pi->rho, and
pi+rhi->a1. The analogy to a "laser shined though dust" was
made. The second is that pions from the surrounding heat bath
can penetrate the DCC. pions in the DCC could then be scattered
out by the processes pi+pi->rho, and pi+rho->a1.
The pion cloud around nucleons is coherant. This has already
been studied by experiment, so information is available to get
the rates for these "attacking" processes, and hence estimates
for DCC lifetimes. If the lifetime of the DCC is less than the
DCC formation time (2-3 fm/c) the forget it. Otherwise one needs
to do the full calculation including the scattering terms. In
this lifetime region, it might be possible to look for structure
in the di-lepton spectra. However, dileptons are also produced
by bremsstrahlung inside the DCC, eta dalitz, omega dalitz, a1
dalitz, etc.
Perhaps hadronic observables are sensitive to DCCs. The example
shown was to plot (1/Pt)(dN/dPt) versus Pt for specific
azimuthal angle regions. If a DCCs is near that azimuth, a
low-Pt enhancement would result.
Flow, M. Lisa
Discussed general aspects of directed and radial flow that have
been obtained from Bevalac measurements. A flow package is useful
not only for the flow observables, but is also provides the lab
azimuthal angle of the reaction plane. Showed results from revised
events that indicate that as low as "1/3 Berkeley Flow" is observable,
and that extracted angle of the reaction plane is highly correlated
with the actual value. Need to officially apply for package status,
then make it a separate from the TPC software and ready for general
use.
Fluctuations, G. Odyniec
Try to separate dynamical fluctuations from statistical ones.
Compose mixed events to set limits on the magnitude of the
statistical fluctuations, then "total - statistical = dynamic".
Noticed that Venus conserves momentum, but Hijing doesn't.
Using Venus event files that contain 5000 events.
This study is somewhat young - it is continuing.
HBT in STAR, S. Pandey
One spends ~60% percent of the time in HBT analyses working
on the cuts, the code itself is relatively simple. Keeping only
Qinv<600 MeV tosses about 90% of the pairs. This reduces the
needed disk space by about 40%, and makes the sensitivity of the
analysis about 0.5fm.
He expects that there will be many versions of HBT codes
around, so it is very important to standardize the table
definitions to be used for all HBT. This will allow one to
compare the different HBT codes directly.
Proposed "reals table", "background table", and "results
table". Several comments were made. Effort to define standard
HBT tables needs to continue.
Multiparticle HBT, D. Weerasundara
Described a detailed flow chart for multi-particle Bose-Einstain
correlation algorithms. This is in the existing program "sim_hbt".
Showed correlation functions for a number of different input
radii, with and without Coulomb, and for different number of particles
(m=400, 1000). Also described how temperature results depend on
different methods of including the Coulomb interactions
("Efimov+Cramer" and "Riverside").
Strangeness with the STAR Baseline, S. Margetis
observables are:
K+K- (dE/Dx, TOF, kinks)
Ks, Lambda, Anti-Lambda (V0 reconstruction)
Cascade+-, Omega+-
phi->K+K-
The TPC has a poor resolution for secondary vertex
reconstruction. This impacts the acceptance for strange
particles.
From the "kink analyses", one gets:
~20 K+-/event (all Pt)
~1 Ks/event (Pt>500-600 MeV/c)
~0.5 (anti-)Lambda/event (Pt>600 MeV/c)
~5 phi/event (all Pt, dM~5 MeV)
?? cascades, ?? omegas
The phi reconstruction studies have been done with a standalone
program. The kink and V0 codes have a similar functionality; the
V0 code is shared with the SVT.
There are two major goals now. One, move to gstar/g2t and MOAST
environments. Two, need database access for next generation of
cuts, fields, geometry, etc.
The most important needs are the following. One is the complete
separation of MC and real data structures (for evaluation
purposes). There should be "connecting structures". The second
need is common V0 structures with branches. These should flags
for the detector measuring the V0 and quality flags. The third
need is evaluation code, for embedding particles in "normal"
events, and to use the udecay and phasespace options to force
decays to occur in specific ranges. This is useful for
calculating efficiencies. Finally, a single standard V0 package
is needed.
Strangeness measurements with the SVT+TPC, K. Wilson
QGP is expected to enhance strangeness production.
- gluon fusion happens are larger rates than for associated
production.
- there is a rapid saturation of the strangeness phase space
in the QGP, the hadron gas scenario is slower.
Make event ensemble measurements of the (Pt,y) spectra for Ks,
Lambda, Cascade-, and Omega-. Make cross-section ratios for
AntiLambda/Lambda and AntiOmega/Omega. Study correlations of Ks
pairs and Lambda pairs. Do Lambda polarization too.
Discussed existing chain, and what revisions are necessary
to the various parts.
Wednesday, April 17, 1996 ("MOAST Session")
Return to the top of this document...
Some transparencies (on the STAF/MOAST Preview) are here,
and some more (on the Production plans) are here.
Introductory remarks, D. Olson
MOAST has no event loop, this is done with KUIP. KUIP does not
have the same lifetime as STAR, will need to look to the future
for this part (Java?).
Discussed timelines:
- 2-3/96 MOAST alpha-test ends.
- 4-5/96 MOAST beta-testing
- End 6/96 MOAST Tutorial Workshop (near TPC Tracking Workshop)
- 5-9/96 BFC in MOAST
- 7/96 (?) MOAST ASP Workshop
Analysis Modules, C. Tull
Physics Analysis Modules (PAMs) are the analysis engine of
STAF. A module package is a collection of PAMs. The Interface
Definition Language (IDL) is a purely descriptive language that
is part of CORBA. It is similar to C. The STAR IDL Compiler
(STIC) compiles IDL files into f77, C, C++. CORBA is the Common
Object Request Broker Architecture, which is a standard for
distributing objects across computer systems in a manner that is
transparent to the users. We have adopted this as the interface
standard for the PAMs etc. In the future, we will use more of
CORBA's capabilities than we are using now.
Then the following topics were described in detail. For more
detailed information on these topics, please see the WWW under
the SOFI News section.
- Defining tables
- IDL PAM example
- Writing analysis modules
- F77 PAM example
- Building MOAST
- Makefiles
- Calling analysis modules
- TAS to MOAST
- Schizophrenic analysis modules
- Dynamic memory allocation
Analysis Service Packages (ASPs), C. Tull
ASPs are the heart of MOAST.
They are a CORBA-compliant C++ class library which serve a
single purpose or a set of purposes. These are normally independent
of other ASPs. Each can be included or excluded, and they are
not specific to particular tables. ASPs are basically all just
interfaces to something - every interface is an ASP.
The current alpha-ASPs are:
ASU analysis service utilities
SOC service and object catalog (mandatory)
SPX service package example
TDM table and dataset memory
DUI dataset unix-like interface
TBR table browser (motif version by H.Ward)
DIO dataset input/output
AMI analysis module interface
The future (beta-) ASPs are:
EML error and message logger
This is a CORBA-compliant version of MSG
THB tables to Hbook
This allows NTuples->Tables, and Tables->Ntuples
EVR environment and version registry
This deals with version information on ASPs, PAMS, etc.
Also allows one to get environment variables etc.
The Long-term ASPs
May be needed to deal with any independent package of
software which requires interaction with other packages
in ways more complicated than through tables.
Suggestions are welcome. The projected needs include:
- pad monitor
- event visualizer
- mass storage access
- DFM/Oracle databse access
- filters
- relational database
Reports from the alpha-testers, M. Lisa, B. Moskowitz, D. Irmscher
These people described their experience in porting TAS modules
to MOAST, and in running MOAST. Changing subroutines to go from
TAS to MOAST takes 15-20 minutes each. Each alpha-tester showed
detailed lists of the steps that need to be taken to move a
module to MOAST, and to use MOAST. For more detailed
information, see the SOFI News WWW pages.
Dataset Hierarchy, D. Olson
The DataSet Library (DSL) arranges tables hierarchically in
memory in a way that is similar to a file system.
The hierarchal structure needs to be defined. The structure
should be "logical" and meet all requirements for
- event data
- calibration data
- configuration and control data
- temporary data
- I/O streams
Beta-Test Goals, D. Olson
- Review KUIP commands, possible changes before v.1.
- Analysis module interface, possible changes before v.1.
- Test table memory allocation in modules
- Design dataset heirarchy
- Design the Kumacs: for the event loop, but also for the
detector-specific parts. need to define standard default variable
definitions for all of the subdetectors.
- Identify the needed ASP functions (more KUIP commands)
Data Dictionary, D. Olson
Goodbye informix. Good riddance.
new data dictionary consists of of IDL files stored in "type"
packages in the CVS library.
We must decide on the proper positioning of these "type"
packages. Proposed one "type" package for each branch (ana,sim,
sys,phy,onl,daq,trg,ofl).
We must decide on the naming conventions.
Thursday, April 18, 1996
Return to the top of this document...
EEMC/ESMD Analyses, K. Medved
Described DFS (Dirty Fast Simulator), which is functionally
the same as the planned EFS (EMC Fast Simulator) except that it
lacks the interface to g2t. Need to install EFS in MOAST, using
the input information from g2t.
The lateral and longitudinal profiles of Geant showers have
been parameterized for 0-20 GeV gammas. The parameter set used
in EFS will be that which reproduces the SPEMC test beam data
for pi, mu, and e. Presently working on this.
Claimed that hadron showers might be very simply simulated in
the code, since most pass right through the EMC. Comments from
the audience disagreed, on the basis that there are orders of
magnitude more pions than electrons in central Au+Au events.
There will thus be significant numbers of hits/event from hadrons
that look quite a bit like electron hits.
The CPU time/event when the full EMC geometry is used was
compared to that when the EMC envelope is filled only with air.
This implied that the largest possible increase in speed in the
GSTAR step that we can expect when going from Geant showering to
EFS is a factor of four.
In the EEMC, approximately 85% of the gammas are fully
contained in single towers. EFS parameterizations can thus be
directly applied to simulate these. For the remaining 15%, it
would be more realistic to let Geant do the showering
(microscopically). A realistic description of the cracks and
cuts in the geometry defined in the simulation is clearly
needed. Also, Gstar would need to be revised slightly, so that
it would know which hits EFS will shower, and which hits it has
to shower. This is simply a fast check on the presence of nearby
cracks or cuts, using a parameter to control how close to edges
one chooses to force Geant to do the showering. The needed flags
control the size of the tower-fiducial regions and indicate
which tracks were considered tower-fiducial (EFS is then called
for this track), or not (Geant showers are used).
Peripheral Collisions in STAR, S. Klein
Basic topics are gamma-gamma physics, gamma-gluon fusion, and
gamma-pomeron interactions. An important need is calculations of
the basic cross sections for gamma-pomeron interactions.
The basic properties of the desired events are low
multiplicity, low total Et, and low total Pt. One tries to
separate the coherant from the incoherant interactions using the
Pt.
Simulations have used Venus and Fritiof. It is not clear how
accurate these are for impact parameters above ~12fm. Haven't
simulated many events yet. Need more work on the event generation
in general.
Various background processes were discussed. A Monte-Carlo
program for gamma-nucleon interactions is badly needed.
gamma-gamma physics - results in any spin 0 or 2 final state
that contains charge, e.g. rho0-rho0 at threshold (a resonant
process), f0(980, ..., 1590), fj.
Described the analysis technique for gamma-pomeron physics,
e.g. gamma + pomeron -> J/Psi -> e+ e- + nothing. One uses a low
multiplicity trigger, and makes the following cuts: clean 2 track
event, each track is high momentum, no track stubs, no gamma in
the EMC, nothing in the FTPC, and total Pt < 100 MeV/c.
Another example is eta -> K0* K- pi+. This is a harder search;
there are expected to be 70 of these per year in the acceptance.
The rate estimates assume that the triggers for these events are
10% of all of the Level-2 accepts.
These events are small, so the actual event data is a small
fraction of the overhead. Need to try to separate this, so that
peripheral event data can be more concisely recorded. Need to be
careful with zero-suppression.
Interfaces, R. Bossingham
Showed detailed "bubble" diagrams of the TPC-related
connections between HC, DAQ, ONL, and SAS. The HC data stream is
separate from the full data stream. Some discussion centered on
how these two streams are coordinated - with a crossing number
or a time stamp?
The DAQ-SAS interfaces for the TPC were described. There is run
oriented data and event oriented data. For further information,
see the document by Schambach, Ray, and Tull, which is on the
WWW under the pages for the DAQ Workshop of 1/96.
The SAS-DAQ interfaces for the TPC were described. The
simulated data needed by DAQ includes 10-bit ADC pixels (for
ASIC testing), and 8-bit gain corrected pedestal subtracted
pixels (for testing the i960 cluster finder). The on-line
downloadable data includes the 10 to 8-bit conversion, gain
factors, problem channel lists, and space-point conversion
information. This last type of information is the tricky part,
as it includes the magnetic field non-uniformities, the drift
velocities etc.
Need to coordinate all of the interfaces with the DataSet
Library scheme. To do this, we need lists of the information
that needs to be passed, and the best way to organize this
information in hierarchal structures.
Offline Production Session, D. Olson
Started with a discussion of the ROCOCO-2 report.
Bruce Gibbard has been appointed the interim head of RHIC
computing.
In the near future, BNL plans to install a pentium-pro
farm, probably running Solaris, and a tape robot.
The status of PDSF is on the WWW at the address
http://www.lbl.gov/NERSC/PDSFpages.html. This system includes 64
HPs, 32 Suns, and 32 SGI CPUs (in 8 boxes). There is also 1 TB
of 8mm tape and disks.
The immediate goals involve building the TPC chain w/ gstar/g2t
and running it in MOAST. Then run this chain on both the PDSF
machines and the BNL farm.
Need to continue M. Bloomer work. Start building event
database, including generated events, events processed through
gstar/g2t, and DSTs.
WWW interfaces to databases were discussed. It is easy to
retrieve data this way, but inserting data this way is harder.
Discussions continued concerning how to handle starlib in the
context of new versions of modules that now work with gstar/g2t
and/or MOAST. It was decided that module owners should "tag" the
versions of their modules that work with the old geant and TAS.
To do this, one does a "CVS rtag SL96a ', e.g. 'CVS
rtag SL96a tpt'. One should then send a message to
starlib@bnl.gov, which alerts Bruce Moskowitz and Tom Nguyen
that your module(s) were tagged with SL96a.
A more detailed description of this tagging business
can be found here.
If for some reason, one needs to drop back from the
gstar/g2t/MOAST software to the old gxintX11/mct/TAS software
(this will be rare we hope), one can get the old code using
sl_retrieve_pkg and the tag SL96a.
Friday, April 19, 1996
Return to the top of this document...
STAR Software Survey Summary, W. Llope
STAR-SAS is the hardest subgroup in STAR to manage effectively
for several reasons. We must attempt to forecast the future
software and simulations needs so that these can be met in time,
despite the limited manpower. Such forecasting is only as
accurate as the information upon which it is based.
Current and complete information of this kind was collected via
the STAR Software Survey. 71 responses were received from 10
subsystems and 21 institutions. Respondants were asked to rate
their skills, present efforts, and future efforts in ~20
categories on scales from 0-10. This numerical data is the
majority of the survey data. A text section was also part of the
survey, but this part will take more time to distill.
Should be careful to keep in mind that the survey data is
subjective. Some specific observables are less sensitive to
this. Concentrate on subsystem and other kinds of sums and
averages of these quantities. The survey data will always be
kept confidential, and, whenever necessary, it will be handled
in good faith.
A number of results were shown graphically. A few important
observations were made. The group is overall the weakest in both
database programming and using databases. These areas were noted
as major needs in a number of talks at this Workshop.
Significant increases in manpower were projected for both the
EMC and SVT. However, this increase comes primarily from Russian
institutions, so this increase won't be fully realized until
sufficient computing hardware is somehow made accessible. A
significant decrease in manpower in Geant infrastructure was
observed (needed is a Geometry Czar and a GSTAR Steward). These
positions have been advertised in STAR, but there is no news
yet. Depending on the observable used, we project an overall
40-50% increase in STAR software manpower. The principal goal is
to mobilize this new manpower by providing the necessary tools,
documentation, and prioritized lists of open or undermanned
software projects.
The Survey will be a living document. Projecting the future
software needs and the general direction of the group will
continue.
Convenors' List of Major Action Items
Return to the top of this document...
- Review and finalize the g2t tables, in particular the "superevent" table.
- Everyone should start using gstar/g2t, and continue to move towards MOAST.
- Study capabilities to do "new" analyses and to improve existing analysis
packages. One example includes net baryon number analyses E-by-E, i.e.
include PID information in SVT-TPC matching to see if this helps the
matching efficiency for low Pt protons. Other needs are listed in the
Notes above.
- Tag the latest and final gxintX11/mct/tas versions of all /ana and /sim
packages. Use SL96a as the tag name. SOFI makes instructions available to
SAS (see here.)
- Begin design of Dataset Hierarchy model.
- Begin Data Dictionary definitions for new IDL tablels for all eight
branches of the library.
- Begin Offline<->DAQ and Offline<->HC interface definitions for SVT, FTPC,
CTF, EMC, and Trigger.
- Build TPC MOAST chain for MOAST testing and prototype production farm
development.
- Collect software manpower survey information.