Core Minutes 12/18/2007
Core Minutes 12/18/2007Hip 2.0 (Richard) It's going really well! The surgeon is pleased with the outcome: full range of movement, etc. Richard is now down to one crutch and able to work half-days, more or less, with time left over to document the process.
Big run: (Richard) Tom pushed the button 3-4 days ago. Tony found a couple Oracle queries which, one would think, would have been automatically optimized, but apparently not. Since he fixed them usage of the farm went way up, with long periods where the average was around 1000 cores, however more recently it seems to have reached a plateau of around 500. If we could recover the better performance, the big background run would complete around Dec. 26. (Tom) would say more like Dec. 29. We're about 1/4 of the way through so far.
(Tom) All-gammas are being run at Lyon thanks to much effort on the part of Francesco and Claudia; it has been an uphill battle. The first batch are about done; these will be compared with the same runs done at SLAC. Assuming all is well, Lyon will go on to produce about 10 times more all-gammas.
(Richard) Nicola has been working on GRBs, improving performance significantly.
(Richard) Taking into account, among other things, that the holidays are coming up, so that several people will be gone or offline, end of January is a realistic date for completion of the Big Run.
xrootd, data access: (Heather) Now that we've moved entirely to xrootd, what is the impact on data access? (Tom) You can't browse in the old manner. Means of access are still evolving; see this FAQ. If you encounter problems, please notify Tom, Tony, and/or Wilko. It is possible to get at xrootd directly from ROOT, but only if you are inside the SLAC firewall. (Toby) would like to get at job info. (David C.) This is not yet handled by the Skimmer; he asks that Toby email him information about exactly what is required.
GR news (Heather) GR v13r5p6 is being used for the backgrounds. There is yet another release, v13r6p1, for TVAC. It has updated tags of Trigger and configData as well as a fix from Tracy and Joanne, fixing the problem seen on Windows with ACD calibrations. (Heather, Joanne) The root cause is visible — that is, in a public include file, even if a private class member — static data structures in a (non-component) shareable, in this case CalibData. On Linux at run time there is only one copy of such a thing; on Windows you may end up with more if the relevant include file is included and used in different components, leading to the possibility of a copy being used without being initialized. Tracy's fix was to bury the static data structure in a singleton class in a package-private implementation file. The lesson: Visible static data structures and shareables don't mix!
Composite Event Lists and Interleave: (David C.) Just committed code supporting a new way to read a CEL, known as a "deep read", which should be suitable for Interleave. Feedback would be much appreciated! (Tracy) hasn't had a chance to work on Interleave recently but now expects to. CEL isn't a show-stopper in any case. (Richard) But would be nice for, e.g., event display. (Tracy) Yes, but other parts of Interleave are more critical; could start testing these parts while CEL settles down.
OnboardFilter: (Tracy) Diagnositic filter is supported as of build 1-0-5. There is yet another fsw release which, JJ warns, will require more work to incorporate into Offline. (Richard) understands TDS for onboard filter needs some work. (Tracy) Yes. Julie noticed tracking is only about 40% as efficient as it should be. Most critical fix was to filter status word. See notes from last week concerning that and the energy issue. But there is another problem due to the fact that tracks may now cross tower boundaries. Our algorithm needs to be modified to handle this properly. The good news is there is at least one trap we have not fallen into: obf code doesn't necessarily zero out obsolete data structures and we have avoided copying such meaningless stuff into the TDS.
Remember hadd? (Heather) does. The verdict after consultations with Rene was that with our large, sparse CAL arrays, we'd do better with a larger basket size. This has the pleasant side effect of decreasing output file sizes significantly. We may want to change default auto-save behavior to save less often. Rene also suggested a new ROOT mechanism which would be a good match for our use case, but heedful Heather will wait until said mechanism has had a good work-out elsewhere.
SCons: (Heather, Navid) We've settled on a new convention for tag names, readily sortable and in all other ways suitable for the new regime:
myPackage-XX-YY-ZZ
where XX, YY, ZZ are major version, revision and patch numbers, always present and always two digits (zero fill). To start with, RM will automatically generate a tag of this form whenever it sees one of the old-style tags. Later users will make new-style tags and RM will automatically add an old-style one. Ultimately we'll stop making old style tags altogether. This change has a huge effect on documentation; we don't want to embark on those changes until we're sure this is a format we can stick with.
(Toby) has looked over some of the ScienceTools SConscript files and noticed the lack of anything for test programs. Are package owners supposed to take care of this? (Navid) is hoping they will since it's too much work for him to handle alone in a timely fashion. He's available for questions, of course, and will be documenting procedures imminently: tonight or tomorrow [done].
(Heather) What about GR? Or is that too far off to worry about just yet? (Navid) It shouldn't be that far off, especially if package owners use the working example of ScienceTools and the documentation to figure out how to do the conversions on their own, consulting with Navid as needed.
previous
|
minutes index
|
next
 |
J. Bogart, Last Modified:
01-Jun-2010 15:47:48 -0700