Core Minutes 5/20/2008
Core Minutes 5/20/2008April/May priorities: (Richard) See them all in Confluence.
GR validation (Richard) v14r11 (Pass 6) and v15rX (Pass 7 development) are in validation.
Filter bits (Heather) About done. She will put her new stuff on a branch so as not to interfere with Tracy. Leon will also have updates.
On-the-fly Filter config. (Tracy) has been having most likely irrelevant library mismatch problems on Linux when trying to use a few packages (notablye OnboardFilter and OnboardFilterTds) against a standard GlastRelease. He reports
So, at the start of the next event when the data stores are cleared and ObfFilterStatus' destructor is called the code ends up in RootConvert (which isn't even part of the JO for this test job). Since an earlier version of OnboardFilter ran successfully against FSW B1-0-8 on linux and the current version runs happily on Windows, I'm confident that tagging the packages and getting a consistent build from the RM will solve the problem.(Joanne) The (Online) code which stores the information Tracy needs has been written and debugged for the most part. Jim Panetta may still be finishing up his end. Then it has to run the gauntlet of one or more CCB's. The (Offline) code for making the queries comes in three sections:
[As of Wednesday morning, 1 is done, 2 is written but not tested, and 3 is expected to be about a day's work.]
ROOT upgrades (Heather) ROOT 5.18c has xrootd fixes for writing to xrootd. We need additional fixes on Linux which are incorporated into 5.18c-gl1, so that's what we'll use there, but it doesn't build on Windows and there is no reason to spend any more time trying to make it compile: 5.18c does everything we need there.
GCR crash (Anders) has only been seen — and only intermittently — in the L1 Pipeline for both real data and MC data (which in L1 appear as real data); the problem does not arise when running recon directly on MC events. Tracy found a potential cause in G4 and put in a fix.
Dataset versioning (Dan) [kindly provided the following summary]
The short story is that I estimate I've written half the code [to support dataset versioning in the Data Catalog]. I've already written the new table definitions and a script for migrating existing data from the old tables. I am trying to get it into DEV ASAP so Warren can test it this week, and we can hopefully put it into PROD early next week.
Hard Freeze (Richard) as of June 1.
Interleave (Richard) 3 problems have been detected. (Tracy) The first was the St9_badalloc issue, understood and fixed as of last week. [Thanks to Tracy for providing these details for the true aficionados:]
problem 1 manifested itself by jobs crashing with an "St9_badalloc" error on linux, which means the jobs were running out of space for dynamic memory allocation. In the end this was traced to a change made to enlarge the TBasket size (to fix a different problem), this was raised to 30 kb. What this means is that when the input ntuple is large enough, or if you have enough input ntuples queued up (like with interleave), root tries to pre-allocate enough memory to be sure to handle the incoming events. With a large TBasket, and hundreds of ntuple variables, this is quite a big chunk of memory. This problem was finally correctly diagnosed when Luca Latronica had jobs crash which were reading very large input ntuples made from the skimmer. This problem could be reproduced on the root command making it clear it wasn't glast code. With the problem reproducible at will, it didn't take Heather long to figure it out and apply a fix.
[and this post-meeting summary of the other Interleave issues]
The second interleave problem was seen in comparing background to signal in the GRB grid runs where it was noted that the FT1ra and FT1dec variables, in particular, appeared to not have the "correct" values for the interleaved events. In sleuthing this problem we first ran into the PointingInfoAlg vs PtValsAlg discussed in detail at the meeting (where both use something called PointingInfo which is essentially replicated in three packages - astro, FluxSvc and AnalysisNtuple - but none of which are exactly identical leaving one with some unease over what to do). This is A problem; it's not THE problem so more sleuthing followed... in the end the issue was that InterleaveAlg is responsible for reading the background row and then it "fails" the gaudi algorithm filter forcing execution down the interleave sequencer branch. Here are lined up several algorithms, including FTValsAlg, which re-calculate variables which depend on the event. Unfortunately, InterleaveAlg was calling RootTupleSvc's "saveRow" method, which immediately fills the tuple, and not "setStoreRowFlag" which causes RootTupleSvc's end of event handler to fill the tuple row. So, all the calculations that were done on the interleave branch ended up in the NEXT event, not the current one. Life is well again in interleave land.
Pass 6 reprocessing (Richard) Liz noticed repeated events in some runs. In the log for such a run are complaints about opening an event. The code (in nTupleSvcWriter) apparently puts out the complaint, then proceeds on its way, re-using the previous event. Heather has changed this behavior (v13r9p23) so that the job will give up at this point.
Science Tools : Seth went through the Science Tools Update for May 20th.
(Richard) provided this post-meeting note concerning microQuasar:
microQuasar was setting a random seed for its own bursts, but using a static function to do so - hence setting it for everyone. I have removed that and tagged a new version.
There was an issue with the latest obssim run in which it was getting zero intervals. And removing the microQuasar source allowed the run to proceed. I did try a year's run on my source trapping on <= 0 intervals but found none.
Data handling: (Dan) Went over the material in the Data Handling report; follow the links for details.
Documentation: (Chuck)Work on How-to-fix continues. Focus is on finishing the FASTCopy output section. He also hopes to get the main infrastructure section done before launch. Pictures from the last collaboration meeting have been posted.
Request for updates (Heather) The Confluence page has been a help in keeping things straight; we are urged to continue to put requests there. (Leon) will request an update for TkrUtil. The new tag can handle alignment calibrations. There are two kinds, one for inter-tower alignment and another for alignment of components internal to a tower. They are kept separate because they are measured at different times and with different frequency. There is a set of constants recently produced by Michael which have been designated vanilla. Leon has demonstrated that distributions are tighter with these constants than
We have not been using any alignment to date for L1. The old alignment handling still works (for, e.g. Beamtest). [calibration infrastructure needed for alignement in CalibData, CalibSvc and calibUtil went in about a week ago. ed.].
GR tag interpretation (Heather) Note that, contrary to the usual rule, we did not institute the v15 series because of major changes to external libraries; changes are internal to our own code. Hearing no objections [there were none] Heather will continue to use patch tags to indicate upgrades along a branch.
Filter status bits (again) (Heather) Form of information in flight-computed bits is not quite the same as those computed offline. We need tools to compare them. (Tracy) recommends adding an interface layer to the offline version if need be to match fsw presenation rather than the other way around.
New RM, SCons (Navid) 64bit compiles of ST with SCons are now working. There's one problem with the astro package that I contacted Toby about. He's given me permission to modify the package and I will do so shortly. Other than that apparently AMD 64bit processors need the -fPIC compile option specified even when building a static library. I'll have to modify SCons to include that when building on an AMD 64bit machine. With that change I expect ST to compile on 64bit linux with no problems.
With that I'll turn my attention to Intel mac builds. I've requested afs disk space for that and compiled a few of the external libraries for Intel macs. Once that is done I'll run a few test compiles and if I can get our mac machines into lsf I'll start up builds on the mac. [thanks to Navid for writing this all up]
previous
|
minutes index
|
next
 |
J. Bogart, Last Modified:
01-Jun-2010 15:46:27 -0700
