Core Minutes 5/25/2004
Present: Joanne Bogart, Anders
Borgland, Toby Burnett, David Chamont, Jim Chiang, Johann Cohen-Tanugi, Seth Digel, Richard Dubois,
Dan Flath, Warren Focke, Riccardo Giannitrapani, Berrie Giebels, Navid Golpayegani, Heather
Kelly, Michael Kuss, Julie McEnery, Pat Nolan, James Peachey, Dirk
Petry, Leon Rochester, Bob Schaefer, Alex
Schlessinger, Tom Stephens
-
Money: (Richard) We've been authorized
to purchase an additional 5 terabytes of disk and also to hire (rent? borrow?)
a tech writer for a year. (Toby) Is replacing the motherboard of
glast-ts; the zippier cpu should make a substantial difference.
-
Gleam tuple: (Julie)
She requests that exposure information be added to the tuple or,
at the very least, that the cuts used to select events for the merit tuple and
for the exposure tree be the same. (Richard) For real data the information
will come from different places and on a different timetable; are we planning
to do the interpolation of exposure for each event as we go? Otherwise putting
all the information together for MC events is unrealistic. Toby volunteers to
satisfy Julie's request. About the tuple: there is no mechanism to remove
variables, only to add them. May want to review what's in
there, get rid of deadwood.
- ROOT news: (Heather)
- ROOT
provides a BuildIndex method. Last time it was tried, we were using an
older version of ROOT which had problems; should work now, however, with
minimal effort. This will make it easy to ask for events by (run number, event
id) from the gui, or elsewhere.
- Heather is in the process of verifying that Ursula's new RootCnvSvc is ready to go;
given the testing Ursula has already done, this is likely the case.
- NFS disk access: (Richard)
Up to now access to our nfs space has been an all or nothing affair. He
proposes that different disks be used for different functions, and that
developers be given write permission to a particular partition only when they're
expected to need it. Additionally, a few people will have permissions on
all partitions so that at least one such person will be available to deal with
problems at all times.
- Installers:
Richard provided the
promised description of requirements for same. Pat noted that if we insist
on the same technology for both OSes, there are only a couple commercial
products that do the job and they're expensive. The following discussion
brought up several issues and possibilities without coming to any sort of
conclusion.
- Up till now we've been thinking about the problem in terms of a small set
of large objects (GlastRelease, ScienceTools, Externals, CMT); Pat suggests it
might be more productive to consider a finer granularity.
- Riccardo had suggested using a scripting language such as Python or Ruby
which includes built-in support for http protocol.
- How about RPMs for Linux? In the past there has been a problem for
remote Linux users without root access on their own machine. This is only
required so that the (local OS) system database keeping track of installed
RPMs can be updated; alternatively, could make a private GLAST database, not
requiring root privilege, on such machines. Alex has seen problems with
dependencies among RPMs.
- For externals, Julie has had good experience with the rsync command
(as long as it's issued with the right options) for keeping things up to date
essentially automatically. She will provide instructions or a simple
script demonstrating how this is done. rsync is available on Windows
machines if they have cygwin.
- James suspects that we can't afford the time and resources to implement
something which satisfies all of the requirements and goals in Richard's
documents, and that it may not be necessary. Developers should be able to
continue to operate more or less as they have, checking out what they need
from CVS (with CMT to help them determine what that is). External libraries
have been among the biggest headaches for new developers [and perhaps clear
information on how to use rsync will take care of this]. End users
need little more than a tarball and a procedure for setting some environment
variables (on Linux; something more or at least different will be needed for
Windows).
- Toby agreed with James' remarks. He's noticed that new developers
could use more and better diagnostics when something goes wrong. CMT can
help with this.
-
JIRA: (Johann) See his
report on
current status. He's set up (from coarsest to finest division) some
categories, projects and components. What he has so far is incomplete and may
also need some reorganization, but this will be relatively painless since JIRA
is very flexible in this regard. For example, need a place for MC-specific
issues, G4, FRED, MrVCMT,... Division of geometry by subsystem is
questionable. The Glast Infrastructure category
is for issues which span Simulation/Reconstruction and Science Tools.
Some people have already been given accounts; others should sign up on
their own. We need experience with this tool in order to understand how best
to configure it for our purposes.
Note: be sure to
use the url
http://jira.slac.stanford.edu. Mail messages sent to some people with
new accounts included a url for a now-defunct installation.
userid for accounts should be identical to SLAC (computer) userid, but
password should not be since JIRA passwords are not encrypted.
(Julie) How does this work? Who gets notified when a new issue is
submitted? How does the issue get handled?(Johann) Anyone with an account can
ask to be notified about issues (by category, project or component).
Furthermore, there will be managers to assign issues to the appropriate person
for resolution. (Julie) Could we send notification to helpsoftlist when a new
issue is submitted? (Richard) Maybe initially; could be confusing if people
don't know which system to pay attention to.
-
Flight Integration: The
weekly run-down:
- Pipeline: (Dan) As of this morning, fixed some remaining bugs.
Now he's ready to start up sample pipeline. Some minor changes to the
database are still needed.
- EngineeringModel: (Heather) No change since last Thursday in the
EngineeringModel package. She's hard at work on a unit test for LDF so we
can confirm the data we see after conversion to ROOT is the same as what
Online sees.
- Calibration database interface: (Joanne) Highest priority
functionality (queries and insert of new entry) is there; much polishing
could be done and new functionality, such as ability to update, will be
added eventually. In the short run it's most important to document what's
there and make sure it's not too difficult for the intended users to get it
up and running in their environment.
- Personals: Follow
Tracy's progress;
unfortunately for Tracy, there was not much wind initially, but things picked
up on
Day 3. Matt is doing well after his surgery.
- Document effect of MC pruning options (Riccardo) (8/5/2003) It's
documented in the code; Tracy will look into putting the information in a
more accessible place. (9/2/2003)
- Write up, and perhaps present at a future meeting, hints on debugging.
(02/18/03) Some combination of Toby and Tracy will provide
something for Windows.(7/22/03)
- Overhaul documentation altogether by about November (Heather and ??) (9/2/2003)
In progress; not yet done (01/13/04)
- Resolve calibration/timestamp issue. (11/20/02) Online folk have not yet thought about
putting timestamp information into EM data, but, thanks to Richard's
inquiry, may now do so. (2/25/03) We can probably live without a realistic
system for EM, but we will put it on the agenda for the DC1
workshop.(5/6/03) At the DC1 Workshop Steve Ritz promised to find an
authoritative reference for timestamp format and pass it on. (7/17/03) Now
that events have "real" timestamps, Joanne needs to reassess
situation with Calibration (9/2/2003) Timestamp exists in EM data. Needs to
be fetched by Calibration (1/13/04)
Put on hold until formats settle down. (3/16/04)
J. Bogart Last Modified:
04-Aug-2004 15:40:41 -0700