Core Minutes 10/19/2010ScienceTools: (Jim)
Reprocessing: (Tom G.) Pass 6 reprocessing is moving along, in fact is nearly done. We will soon have reprocessed data through September. (Richard) Is FSSC ready for the data? (Tom S.) I need to get a couple of sample files, via e-mail is fine, to test to make sure the ingest works. After that, we can just start transfering the data once the reprocessing is done. (Tom G.) suggests getting the files from xroot for greater flexibility.
FSSC: (Eric W.) Julie has blessed a release which includes data_clean IRFs in the caldb release tree. This would be the candidate release for November.
Documentation: (Chuck) sends the following:
I'm currently working on the revisions to the first section (i.e., the end-user section) of the workbook. Primarily these changes are being ported in from work done for the developer's section and adapted as appropriate. These changes can be thought of as creating the post-CMT/SCons version of the WB. The old CMT/pre-SCons versions will be linked in from the top-level navigation bars and therefore readily available if needed.
I hope to get everything linked together and working properly today, so that I can post both of the new sections to the web sometime tomorrow morning. I will then notify the core SW group by email in the hopes that they will review it at their earliest convenience to catch any egregious errors.
Pass8: (Tracy) Johan has written a new class in reconRootData as part of the Cal Clustering work but has been unsuccessful so far in writing out the classes's data to a ROOT file. [Heather says in email "I've peeked..Tracy peeked.. I'll try to peek again..all agree it's likely something small."]
(Tracy) has been investigating timing issues — that is, time the code takes to execute — on Linux. He separated sim and recon steps and execution times became more reasonable. This probably means there are techniques which need to be discovered and applied for memory-intensive events. This could take a while.
(Leon) was planning on setting or resetting jo properties in order to switch back and forth between cosmic ray code and regular, but the switch is not happening. Likely he will have to fall back on a less attractive alternate approach; there are a couple possibilities. [Post-meeting update: Leon reports problem is solved. Initial strategy works after all when there are no typos.]
GR tag (Heather) [One of several notes Heather submitted before the meeting since she can't make it today] There is a new tag, 15r47p12gr13, for L1proc to revert to older behavior in ROOT, where we determine the autoSave interval and buffer sizes. There was one run which failed an autoSave and caused the run to terminate prematurely. I'm fairly certain this is due to some oddness in the automated attempt to optimize the buffer size, but this is still under investigation.
Windows (mis)behavior (Heather) General oddness continues with our aging windows glastxx boxes, where this time the V: drive was not accessible. The reboot of the glastxx machines seems to have done the trick. We should check to see if there are any other GR or ST builds for SCons or CMT that should be retriggered. Apparently it may be possible to give us control over rebooting the glastxx machines — guess we'll see.. might be even more useful for the up and coming new win box. (Richard) ..which is now being actively work on: software is being installed, etc.
Debug gaudi (Heather) Joanne has requested a debug version of Gaudi v21r7 for linux — (we only have debug for windows as this is the only configuration officially supported — I'd have to hunt down opt windows versions of gaudi's external libs in order to provide optimized win builds - actually this has been the case since v18.)
CalibSvc (Heather) I committed what I had for CalibSvc where the unit test now runs, but the conversion from facilities::Timestamp to Gaudi::Time is not quite right. The day and the month seems to be agitated a little bit. Joanne is kindly trying to take a look (hence the desire for the debug version of Gaudi). (Joanne) Is able to build CalibSvc with SCons (see related discussion below) and is hopeful the time conversion bug will be straightforward to find once the debug gaudi is available [building now, as I type].
GuiSvc (Heather) It's now being built as a shareable. The rootmap step continues to fail...in a new spot now though. Now it's upset about Gaudi::Property, previously, it was having troubles with undefined symbols in the gui static - but that seems to have been fixed.
Snow Leopard (Heather) Yemi rebooted the Snow Leopard machine yesterday - but it sounds unrelated to attempts to get it hooked up into the batch queue. (Richard) The good news is that Yemi, the Mac guy, is back in town and on the job.
rootmaps (Joanne) Has managed, after a struggle, to get SCons to generate usable rootmaps. (A rootmap is an ascii file, generated from a shareable, with lines listing symbols of interest and the shareable where they may be found. Gaudi uses the file to find the shareables it needs to load dynamically.) The generated files are not yet ideal: they refer, via a relative path, to the shareable in the package's build directory rather than the copy in the common lib directory, so won't do for end-user builds installed remotely. It should be possible to generate the rootmap after the corresponding library has been installed. In that case the relative path would be correct as long as programs are run from the top-level directory (the one containing SConstruct). For a more general solution, one might add a post-processing step to insert the environment variable INST_DIR.
The current scheme for generating rootmaps with CMT has a similar problem: there the path to the shareable is absolute rather than relative and is completely resolved, even down to the nfs server.
SCons meeting (Heather) ..will take place on Wednesday at 10:30, as usual.
|
|
minutes index
|
next
|