April priorities: (Richard) See them all in Confluence. Hitting some of the highlights —
(Joanne) Report from the MOOT side is less rosy. Given a "software key", MOOT can store information about all constituents and make and archive xml representations of some of them, including filter configurations (probably not of interest to OnboardFilter but needed for Mission Planning). However, the routine which does all this needs to be called from Online code owned by Jim Panetta, who is out of town until approximately the end of April, so it's hard to imagine that this can happen before launch. Furthermore, the configuration information that Tracy is after from MOOT is the association between filters and handlers (e.g., which variant of the gamma filter is currently in use). Ultimately Mission Planning will store this information in MOOT, but that is still further down the road. (Richard) Wasn't Bryson's code going to store associations in MOOT as seen from the data? (Joanne) Yes, that's the plan, but it's not possible until they are visible from DFI [at which point OnboardFilter could look them up itself]. That would be in some DFI release after the one now in dev.
(Tracy) Martin is interested in prescale values. These are readily available to OnboardFilter so Tracy can and will put them in the TDS [they could also be read from the xml files MOOT archives, if only the MOOT service to archive them were called first].
(Tom) There was another oddity in v14r1: it produced a sampled day background file in which the first two events are both labelled with EvtEventId = 0, then skipped to EvtEventId=2, so event 1 was missing. Philippe also reported a problem with one of the Pt variables in those first two events.
Science Tools report: Jim went through the Science Tools Update for April 15th.
(Navid) Concerning the CLHEP item — we have been linking to a static library for ScienceTools, which works fine. Executables linked to it are slightly larger than if we used a shareable. He'll ask Eric Winter about the shareables he's built, particularly the 64-bit Linux version.
Documentation: (Chuck) Main focus continues to be How-to-fix doc and will be for some time to come. This overview provides one possible starting point. The How to Fix Confluence page delineates possible points of failure, how to test them and, if something seems amiss, what to do about it. Other pages will follow a similar pattern.
Yet another point of view is provided by the Failure Symptoms page. As new failures are encountered, information will be added at the top. Older entries, tending to be of less interest as the underlying problems get fixed, will sink to the bottom. Chuck plans to get started on Pipeline section with Dan's help.
Core talk: (Heather) What to do about Pass 7 code? Incorporating it shouldn't affect Pass 6, but... (Richard) would prefer to hold off until L1 release is firm.
Leon and Heather agree AnalysisNtuple branches could become confusing; need somewhere to keep track of their raison d'être.
Skimmer (Tom for David Chamont)New RM, SCons (Navid) When calling SCons from RM on Windows he gets a crash with no diagnostic information, perhaps having to do with lack of working directory. He is going to try a new approach, more similar to what's done on Linux. He has already made changes to get the Linux RM to submit jobs on Windows. Meanwhile Emmanuel is working on Mac build with SCons.
cfitsio (Jim) reports that packages built against the new version can't always find it. Emmanuel and Toby volunteered to look into it.
Stellar aberration (Toby) This well-known effect has been ignored in both simulation and reconstruction up until recently. Now underlying utilities in the astro package have been written and Leon has laid the ground work for their use in recon, however at this sensitive time we probably need to hold off. See Toby's status page and follow the link at the top to his SciOps talk for more information.
previous | minutes index | next |