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.

  Action Items 

• 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)

previous

minutes index

next

J. Bogart Last Modified: 01-Jun-2010 15:46:40 -0700