Core Minutes 3/5/2013

• ScienceTools: (Jim) No news this week under Science Tools Development Notes but there are several other items:

  • He discussed Likelihood refactoring with Steve last week. Steve has checked in development on UnbinnedLikelihood into a development branch of package.
  • He'll tag ST release today to make available improved memory handling in binned analysis from Jan 30. (Heather) It will use the new Root, already used by Pass8.
  • After a report from Alex at FSSC, he fixed a bug that crept into dmfit code inside of Likelihood. The dmfit developers added additional decay channels to their Fortran code, and Johann converted using f2c. Unfortunately, on the Mac, one also needs to remove by hand some extern declarations on a struct that is generated. This was missed by our builds, but might have been caught if we had a more recent version of gcc.
  • Related issue to the above: FSSC builds on a Ubuntu VM using gcc 4.7.2 encountered a compile error that I cannot reproduce on gcc 4.4.[47] (laptop or rhel6-64). Can we have automated builds with more recent version of gcc? (Richard) Can FSSC give you access to their VM, or export it for you to install elsewhere? (Tom S., Elizabeth) There are various barriers. It might not be possible. (Heather) can ask SLAC admins about installing a newer compiler somewhere. (Joanne) remembers bad experiences in the distant past with trying to use non-default compilers with redhat; we can hope things have improved since then. (Resolution for now) May investigate putting a newer gcc compiler somewhere, but do not expect to support automated builds with it.
  • Finally, I discussed with Heather (and Joanne and Tom via email) about spinning off separate checkout packages, one for irfs and another for "utilities", so that GR and ST can share IRFs. [See more discussion below in Core Talk]

• Reprocessing (Tom G.) There was a recent meeting to discus roll-out of the fully reprocessed Pass7 data. It's expected to occur somewhat after April 1 [post-meeting he learned the target is April 16]. He'll do another backfill (Dec. 11 to present) so that the final backfill needed will be small.

  C & A has agreed they can eliminate CAL file generation both in level 1 and in subsequent reprocessing. But they are reluctant to give up on the SVAC ntuple. Johan has agreed to put the SVAC ntuple on a reduction diet, if possible, to reduce its size. (He notes that SVAC has yet to be successfully generated by the Pass8 code.)

  (Leon) Office-mate Andy Hanushevsky suggested splitting output: write less popular stuff to tape. (Richard) New tape system is not performing as well as hoped. LCLS tape writes are not keeping up. (Richard, Heather) Could consider compression: either Root compression or just gzip. Hardly anyone needs recon output so it would be a good candidate for compression. [But see Tracy's remarks concerning Pass8 analysis below.]

• Pass 8 (Tracy) This week Johan, Philippe, Luca Baldini and Melissa are in town. They'll try to create a new model for the hit errors. Other items to be addressed include

  • Root output size: will try to avoid writing parts of tree-based tracking output which can be regenerated easily and will explore Root compression.
  • Verification: merit n-tuple should be exactly reproducible from recon output. It's close: vast majority is ok, but we are missing some smallish CAL objects which affects output for some events. And there are some questions about double versus double32.
  • Unguarded sort: Unlike earlier errors of this type, the latest manifestation shows up only when running Linux optimized builds.
  • Streamline: identify events not worth reconstructing early on

  We're aiming for March 21 (or fallback date of March 28) to get the last collection of things into Pass8 Recon. We expect event-level analysis will consist of 2 stages. The first stage, background analysis, will require the new recon output.

• Core talk:

  • New macs (Heather) Is there money? (Richard) No news yet. And we may need some money for tapes.

  • u52 and Windows permissions (Heather) They're fixed! zip files produced by RM are now readable with no manual intervention.

  • Jenkins (Heather) Tony has set up some of the necessary machinery for Windows builds.

    (Tom S.) Jenkins on the mac stops working if you don't log in for a day (but then revives if you do log in.)

  • Fermi-TS (Heather) has installed latest version of GR calibrations and so forth. We've asked for an account for Joanne; it may be time to do the same for Tracy, Leon and Bill.

  • SCons on Windows (Joanne) Latest collection of stuff (SCons-related code in GR 20-08-10, new version of GoGui is ready for beta-testing by Windows users. It should handle supersede as well as base-installation-only usage (at least it does for me). Steps required prior to developing in VS have been minimized. See the updated Recipe for GlastRelease and VS 2008 in Confluence.

  • Cleaning the Attic (Joanne) noticed that a significant percentage of recent stale lock problems occurred within OnboardFilter/flight. It has about 20 subdirectories, each of which has 4 or 5 subdirectories of their own. None of these directories contain any live files; all files were put in the cvs Attic years ago. It seemed likely that, when a specific GR tag was beinging checked out, CVS would spend a while looking through all these files for a matching tag which would never be found. We have no need for these files in any shape or form, so I wrote a script to safely remove the whole OnboardFilter/flight module and similar modules from the repository. Removing the modules appears not to have done any harm. It's not yet clear whether it's done much good.

  • Proposed new containers Heather summarized the situation in a recent email:

    Recently parts of the irfs package code has been copied over into the AnalysisNtuple package to satisfy needs for P8. Clearly not a very maintainable situation, and I'd rather not start pulling in the irfs packages directly into GR if we can help it.

    An idea was to create two new container packages that ST and GR could the share: one for utilities (facilities and friends) and another for the irfs. From the user's perspective those libraries would be treated similarly to externals and would be accessed via GLAST_EXT. An additional wrinkle is that irfs also uses the utilities so those two containers have a relationship and we would need to define the versions of the utilities container used by the irfs container that are built and available.

    (Joanne) Why not put irfs and the utilities together in one new container? (Jim) Expectation is that the utilities are relatively stable. Any scheme of this nature will require some reworking of how we sort out dependencies. (Joanne) We need to think through impact on that, on RM, and possibly other things.

previous

minutes index

next

J. Bogart, Last Modified: