Core Minutes 10/8/2013

• ScienceTools: (Jim) No updates this week. A first meeting to discuss event types and classes, organized by Matthew Wood, will take place at 10 this morning.

• Pass7: Reprocessing (Tom G.) did a backfill up to last Friday.

  Comparison (Tracy) The initial comparison was between a P202 reprocessing run, made on rhel4 with a GR (call it gr17 for short) built optimized, no debug symbols, and a GR (lp57) built on rhel5 optimized with debug symbols. Due to the different OSes/compilers, some externals, notably gaudi, were also different. Both builds were made with SCons and the runs used the same digi input. It was not surprising that there were some differences in recon output, but Philippe made a histogram demonstrating differences beyond what could be attributed to round-off. About 1% of the events have significant divergence. For some TKR results are entirely different, and similarly for CAL.

  For the TKR story we now take you to Tracy's email to the C & A list:

  I believe I found the reason for why the track reconstruction can be different between gr17. The executive summary is that a feature intended to improve cpu performance in the G4 Propagator performs an equality test on some double precision quantities that, in certain cases, were calculated from different paths. Apparently, it can be possible for there to be slight differences in the results depending on whether or not the code is built with/without debug symbols and with/without optimization. This can result in a difference in the tracking, in some cases causing the code to "find" different tracks...

  True aficionados should read the complete email

  Philippe now has the tools to investigate CAL discrepancies; stay tuned. Tracy suspects it will ultimately boil down to round-off error. (Leon)... (Richard) Is there a cut-off date? (Tracy) would presume before release of Pass 8; has not really been discussed.

• Pass8 reprocessing: (Tom) is now 72-73% complete. We need to validate a GR which supports the new ACD calibrations. (In particular, need to make change to job options to request L1current flavor.) (Heather) We're currently reprocessing with 20-09-02 but the most recent main branch tag is now 20-09-04. Should the new reprocessing tag include just the change for ACD calibrations or other significant changes, such as improved ACD geometry? Her proposal is to make a branch tag off of 20-09-02, including just the jo change to pick up ACD calibrations, and also make a new tag on the main branch, including all the new stuff. (Tracy) would prefer to use a enw GR including all the latest stuff, but we would need to validate to make sure it doesn't impact recon significantly (that would include updates which whould improve simulation). (Leon) notes there are possibly significant updates going from 20-09-02 to 20-09-04 which could affect recon.

  Interested parties should keep an eye on JIRA LPATE-165.

• Hardware: (Tom G.) Four old glastlnx machines have been retired (ISOC machines), for a total of 8 out of 25.

• Core talk:

  • gr17 debug build (Heather) thought it would be good to have one for posterity. The Computer Center still had a rhel4 machine lying around that she could use, but it's apparently not configured the way the old public rhel4 boxes were. SCons was confused and could not figure out how to find everything needed to compile C++. She has given up on this gambit, at least for now. (Joanne) Wouldn't it be good enough to build it on rhel5 but with the rhel4 compiler? Tracy and I have done this successfully. The set up is not difficult:

    1. Set GLAST_EXT for rhel4 32-bit
    2. Use SCons options --with-cc and --with-cxx to choose proper compiler.
    3. Use SCons --variant option to make the build look like it was done on a rhel4 machine (optional).

    The last two can be done from within GoGui. We could check to see that an optimized no-debug build made this way behaves just as the actual rhel4 build does to within round-off errors. (Richard) Is the glibc version different? (Joanne) To be investigated. [I looked into it some after the meeting. On rhel5 both compilers are linked against libc.so.6 (which, FWIW, is a sym link to libc-2.5.so) and C++ executables for both compilers use libstdc++.so.6.0.8, the minimum version required for gcc41. gcc34 requires at least 6.0.3. I don't see any problems in this area.]

    (Heather) In the future, we could consider creating VM appliances (perhaps via RM?) for important GR releases. Computer Center would like to switch over to rhel6 for batch farm. We would still need rhel5 boxes to build. (Joanne) Or perhaps we could build on rhel6 using rhel5 externals and compiler, as we've just done with rhel5/rhel4. Would need to be validated.

  • Rhel6 and ISOC (Warren) There is still no ISOC build which is compatible with rhel6.

  • Mac Pro (Tom S.) was able to build Qt, both 32-bit and 64-bit, but could not build a 32-bit RM. There were complaints about incompatibility of pointer types. He will switch to working on 64-bit. The bitness of RM is independent of that of the applications it builds. And, anyway, he believes FSSC only supports 64-bit builds for Mountain Lion (confirmed by Joe).

    CVS is currently another stumbling block: he can't get to the repository from the new machine.

  • Release diffs (Tom S.) Creating the diffs should be straightforward. Difficulties if any will be in the presentation. How should it be organized? (Heather) Probably by package. Those with opinions on this subject should see and possibly edit or comment upon the Confluence page she started.

previous

minutes index

next

J. Bogart, Last Modified: