Core Minutes 1/8/2008

• Big run: (Richard) Shortly before winter break the Big Run using GR v13r5p6 was halted. Bill found problems with ACD which he could not work around. Eric managed to find and fix them for v13r7. Also included in that release, thanks to Tracy's efforts, is OBF 1-0-6. Bill managed to find another ACD anomaly. Eric provided a fix incorporated into v13r8, but there was another improvement which will go into v13r9 along with filter tracks. This incarnation will be used to make a short background run, suitable for Bill's Pass 6 and for GRB algorithm parameter tuning. Meanwhile, back at the ranch in Pisa, Nicola will be finishing up the sky model. With yet another release incorporating this sky model we'll make a long backgrounds run which will be suitable for OpsSim2.

  Over break our minimum allocation of 400 cores was temporarily increased to 800. In practice we got as much as 1200-1400! We will have the increased allocation through January; not clear what happens after that (Richard is working on it).

  There is a Service Challenge Steering Committee meeting tomorrow; the Committee may decide that OpsSim 2 will precede Big Run. We still need to demonstrate that Interleave works. Big Run should complete somewhere in the last half of March.

• Onboard Filter: (Tracy) We recently updated to FSW release B1-0-6 (over Christmas break). With this update we have also upgraded the GSW OnboardFilter package to allow it to set the "configuration" for each of the filters (and have also included the output of the diagnostic filter in the ntuple). Currently, am in the process of extracting the code which mates XZ and YZ projections to form a "best" track from the FSW GRB filter code. The goal is to provide more accurate track pointing for GRB filter optimization with the code used for the Big Run.

  We need to be able to pick up filter configuration at run time, especially for the diagnostic filter, which has only a primitive default.

  (Richard) Tracy has been struggling to incorporate Flight Software code into Windows. This has been a requirement (that all this code run on Windows) but at some point it may become impossible. We, particularly Windows developers, are invited to consider the implications of separating out Onboard Filter processing and running it only on Linux.

• SCons status: (Navid) He hasn't worked on SCons proper since before the holidays; instead his focus has been on getting SCons-cognizant RM up and running. The workflow part is now done; he estimates about 1/3 of the work remains which he hopes to finish this week before he leaves on vacation (he leaves on Friday the 11th, returns the 16th). (Toby) found and fixed a number of problems in order to be able to use SCons on Windows. He was surprised to discover that SCons is significantly slower than CMT (about 1/2 a minute versus a few seconds) when initializing for a build: parsing all the SConscript files as compared with CMT and requirements files. (Navid) Yes, 1/2 a minute sounds about right. SCons central is working on this; newer releases will probably show some improvement. However, he doesn't expect it will ever be as fast as CMT is for this stage since CMT is compiled whereas the comparable SCons code is in python, hence scripted. However, building will be significantly faster with SCons since it makes use of the knowledge obtained by analyzing the building process as described in the SConscript files to know when compiles can safely be done in parallel.

• Timing studies: Leon has been looking into per-event processing time in the hopes of finding a way to screen out the really long ones before all the time is expended on them; they're typically useless for analysis anyway. With some help from David Chamont, who wrote a working example, Leon was able to make use of the Gaudi Auditor class. His results are nicely written up in this presentation.

• Miscellaneous software notes: (Toby) Has made a new version of FluxSvc. Now you can import the whole sky model by just specifying a couple job options. It works, but one component (libary of AGNs) needs so much memory that he can't run it very long even on a relatively resource-rich Windows machine. Jim will examine the relevant code for memory leaks. [Post-meeting comments from Jim: There was a leak in the celestialSOurces/eblAtten package, in a function for the EBL attenuation that was not used in previous sky runs. It would have affected any extragalactic source, e.g., GRBs as well as blazars. This has been fixed in celestialSOurces/eblAtten v0r5.]

  Toby also refactored flux recently, specifically CompositeSource, in an attempt to find out why there are occasional duplicate event times. The code is now easier to read and debug but CompositeSource was apparently not the source of the problem, which, Jim notes, still exists. [Hot off the presses from Toby: the bug comes from using a single precision random number to pick a time interval within one hour. The resulting subdivision into 215 microsecond-wide intervals isn't fine enough. [And Jim adds: The cause of the duplicate event times is still under discussion.]]

  (David C.) announced a new version of the Skimmer, v3r10, is ready which will create a Root file containing the merged jobinfo tuples. [Some additional comments from David after the meeting: "As usual the new release is installed at SLAC. Until it is integrated in the Web Front End one could use it directly through its command-line interface as described in the Confluence documentation."]

  (Toby) has installed support for Visual Studio 2005 for non-Gaudi development at UW and highly recommends it as a development environment. In particular support for inspecting standard template classes is much improved.

• AOB: Thanks to diversification of programs, the outlook for SLAC (2008 and beyond) is perhaps not as bleak as for Fermilab but that's not saying much. See the text of Persis' All Hands speech, given Monday morning.

previous

minutes index

next

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