Core Minutes 7/22/2008

• GR Fires

  • 64-bit event ids (Heather) Event ids in real data are 64 bits. To date we've never needed even as many as 32 bits, so that's what we store in various places, but it seems prudent to be ready for 64. Leon has written code to store a 64-bit event id as well as the old 32-bit version in the merit tuple. Other related updates are partially done. The whole thing should go into the next GlastRelease. In the meantime, some other items have been added to the merit tuple. What happens when files from both regimes are merged? Can't use default ROOT merge; it wouldn't populate the new branches. (Tom) have yo tried the Skimmer? (Heather) Not yet. (Leon) has been using a python script which compares ntuples and does something sensible when the tuples are structurally different, so it ought to be possible to deal with the merging problem.

  • Tracker calib crashes (Joanne) There are two problems. One has to do with a crash in ROOT having to do with "cleaning up". I made a tag of CalibSvc which might fix that problem, though I'm not confident it does...anyway it's probably better than what we have. Then there is a problem with two different flavors being fetched when Anders believes there should just be one. Joanne Bogart That doesn't have to do with CalibSvc, which only fetches flavors which are requested. That has to do with some interaction between job options and tracker code. [Leon was able to find and fix something in job options during the meeting; Anders confirms this is the sought-after fix. One fire less.]

  • G4 propagator (Tracy) There is a new tag.

  • OnboardFilter (Tracy) Latest OBF updates were aimed at MC. Fred Piron, who looks long and hard at the MIP filter, thought he saw some wrong results. After some digging Tracy discovered that an old kludge in the code, put in to handle a problem with older releases of fsw and which was no longer needed, was still in effect. The result was that a veto which should have been disabled wasn't (and it wasn't just MIP filter which had this problem). The fix is easy enough: take out the unnecessary old code.

    (Heather) As of last week Tracy had modified the OBF filter status TDS class had been modified to present bits as fsw does, however digiRootData hadn't gotten a comparable update. It's on the list, right after check-out of new fsw release on Linux (see fsw release below).

• CAL updates (Zach) He believes the updates for properly handling read-out modes (with the setting driven from Trigger, as it should be) are all ready to go. Johann (our new Trigger czar — thank you, Johann!) has determined that GltDigi, once used by CAL code but no longer, can be removed altogether.

• fsw release (Tracy) There is a new release, B1-1-0, which has a new gamma-filter configuration, in fact a new low energy cut. Tracy got almost all of it going on Windows, including all that is actually needed. (One bit includes assembler so it can't be ported, but fortunately doesn't need to be.) He has made suitable updates to OnboardFilter and it all seems ok. He needs to try it out on Linux also. The gamma filter status bits will be reshuffled yet again. He doesn't think there will need to be any changes to TDS structure, though.

  (Joanne) heard from Bryson that there will be some implications for MOOT. The call interface for the fsw-supplied function used to find the constituents (including in particular filter configurations) associated with a particular fsw build has changed. MOOT (online) invokes this function when a new fsw software build is registered.

• Trigger (Johann) There is some duplicated effort in TriggerAlg and TriRowBitsAlg. After the updates needed for Zach's CAL code are in place, Johann will see about eliminating the incarnation in TriggerAlg since having them both can only cause trouble.

• More tags (Heather) Updates needed for MC jobs to write OBF results to spots otherwise filled by real data are ready to go. In fact, there are quite a pile of new tags to be incorporated. She will send out an email with a summary of them all.

• Skimmer (Heather) For real data, indices get built at the end of processing a chunk (aka crumb) and then there is a merge of all the crumbs belonging to a run. Indices are not handled properly by the merge: there is only good information for the first crumb. She's added a new flag to RootIo, for now set to true by default, which says to rebuild the index when opening a file for read. This takes care of the problem but can be needlessly expensive in some cases. Ultimately we will be able to turn it off. She has been getting better acquainted with the Skimmer code and plans to add a similar settable flag there.

• Fred/WIRED : (Heather) v15r24p1 [of GR, I presume] will rebuild index, so Fred and Wired should be able to handle its output. But can't use output from current Skimmer. (Leon) Due to heroic efforts from Heather, builds for Linux and Windows of a newer version of OmniOrb (4.1.0) are ready to go. This is likely to fix the "large event" problem. (Heather) While we're at it, it would be nice to move to the very latest production release of OmniOrb. Any volunteers to build it? Here are some instructions.

• Reprocessing: (Richard) Dan completed a particular reprocessing task: rerunning makeFT1 on the L1 merit files to redefine CTBCLASSLEVEL so that the > 0,1,2,3 cuts were what people expected (in selecting transient, source and diffuse classes). How is the more general case going? (Tom) is working on a comprehensive reprocessing procedure with bookkeeping. It is comprised of some half dozen or so process steps. The first two have to do with set-up and bookkeeping. Then come the actual reprocessing steps (which have been demonstrated before so should not represent a development challenge). Finally come the data merge followed by some wrap-up bookkeeping and cleanup. He's hoping a crude demonstration of the entire chain will be possible within a week.

• Alignment: (Toby) Steve Ritz sent an email to various high-level people concerning this issue: how do we convert existing FT1, how do we get the orientation of incoming photons right in the first place. Code in FT1Alg will pick up the transformation from the calibration system (Joanne will create the necessary very simple calibration files and will provide example code fetching the calibration). (Richard)There is also the question of getting this approved. Typically requests to include new calibrations go through CCB. (Toby) Do we need approval every time there is an incremental change? (Richard) TBD. There is no precedent for calibrations with this kind of behavior.

• SCons: (Navid) The environment variables that are easy to change in GlastRelease have been modified and committed to CVS. Some package owners have already tagged their packages and RM has compiled and executed them mostly with no problems. One package that did have problems was GlastClassify where an include statement was missing. This has been fixed and committed and is awaiting a tag by the package owner. I'll be going over the remaining modified packages and see which still need to be tagged.

  While doing these easy env var changes I looked at the state of the job options files and other files. I've noticed that the JO files are mostly in the src directories but that convention isn't followed everywhere. I have a proposal that involves creating symlinks to make a seamless transition to a more organized package structure. I'll be sending an email out about that proposal to see what comments/suggestions I get.

  The changes I made to the environment variables weren't complete because there are many files that don't follow any convention (specifically job options files). As a result I left those alone and environment variables that refer to job options files continue to access them via $PACKAGEROOT. I posted a list of environment variables that are currently being used in GR that I don't know how to handle (if they need to be handled at all). They are in confluence at the bottom of the SCons page. I'm continuing work on the new RM.

  (Joanne) GoGui is somewhat stuck but I have a couple ideas of how to unstick it. I've been working on navigation section, using some code from Navid to find the interesting directories. It looks ok but won't do anything. Hope for better news next week.

  (Emmanuel) is working on finishing off remaining SConscript files for GlastRelease packages. He hopes to be done early next week.

• Documentation: (Chuck) I'm still working on populating the Data Access 'Help' (greenNavBar) section of the workbook. The latest addition, WIRED and the Data Catalog Tool, was posted late last week, and any/all feedback would be appreciated. I've also started the first pass of a systematic review of the workbook to address some of the more obvious/egregious problems. For example, there was a bad link off of the first button (GLAST Links —> Movies), so I took advantage of the opportunity to create a new GLAST Movies link page, which you might find useful. It provides easy access to some of the GLAST videos and animations, including the three different flavors of the High Definition Launch videos.

  Based on input from Karen, I'm currently working on the Get Connected section regarding a sequencing problem revolving around our use of Pat Nolan's database to verify membership in the collaboration. This has been a cause of confusion for people needing access to Confluence. So far, I've implemented Karen's recommendations, but still need to make changes to a couple of the navbars to improve the sequencing of the procedures. It's also time to create a new tag so Berrie can update the mirror site.

previous

minutes index

next

J. Bogart, Last Modified: 01-Jun-2010 15:48:33 -0700