News: (Richard)
New time for us Due to child-chauffeuring duties right around 11 AM Eastern time, Heather will not be able to make the usual start time of this meeting. Is it ok with everyone to move to 8:30 Pacific, 11:30 Eastern? [Richard himself has a meeting at 9 every other week. No one else voiced any concerns and there was rejoicing on the part of sluggards like me. ed.]
GR updates: (Richard) Tracker alignment reinstatement (it was inadvertantly turned off on July 16), spacecraft alignment and trapezoid patches are all ready or near-ready.
(Anders) Concerning tracker alignment there are several possibilities. It's up to C & A to decide how quickly to move:
(Toby) It's clear from plots Marshall made, comparing psf from the two eras (days 1-15 with tracker alignment; days 16-55 without), that the alignment makes a significant difference at higher energies.
(Richard) Is Reprocessing ready to take on the task of redoing the several weeks of data originally processed without applying Tracker alignment? [Thanks to Tom for detailed response below:]
The reprocessing development has passed a milestone in that two runs of ~1.7M events each have been successfully reprocessed using GR-v15r39. The main missing component is that SVAC ntuples are not yet created. The processing rate starting with DIGIs is about 4Hz on a fell-class batch machine (that is up from ~2.5Hz using GR-v15r24). The total processing time required comes out to about 108 fell-hours per run (roughly 80 minutes on 80 machines). Although this recent test demonstrated the mechanism for reprocessing, it was not a validation of the results. And while much of the system is functional, there are lot of details to clean up before this could be considered "production quality", including updates to xroot, the skimmer, SVAC code, the pipeline and the dataCatalog.
Setting up a reprocessing task with re-activated alignment and, possibly, other changes should be straight forward and would be a good step toward validating the processing. Assuming essentially the same configuration as for the above tests, this project of 18 runs per day for 3 weeks suggests an ideal processing load of 18x21x108 = 40,824 fell-hours. With 100 machines, this would take ~17 days. With 400 machines 4.25 days. With crashes and rollbacks, the actual time will be somewhat more. Finally, there are still sufficient rough edges that the results should not be considered production quality. Also, end-of-summer vacation schedules may introduce some delays.
(Leon) There may be a short-cut. Tracker Recon pattern recognition, which is to say most of the work of Tracker Recon, does not make use of alignment. That takes place later. It might be possible to redo just this latter bit. (Richard) asked Leon and Tom to pursue this further to see if it's really feasible. [And so they have, together with Tracy, who has supplied the details below.]
The general idea, is that the alignment doesn't come into play until the track fit stage, and it's pattern recognition that takes all the time. So, one could run off the recon files and just refit the existing tracks. Then you would need to re-do all the downstream stuff like the vertexing, classification, and, importantly, remaking the output ntuple. This last is a bit of an issue since the ntuple violates the "though shall be able to recreate everything from the root output" dictum. The way around this is to resurrect some JO files that we worked on before launch which read input recon and merit files, re-fit, re-vertex, re-classify and then redo the affected part of the merit file. Then output everything again.
(Richard) On trapezoids: Heather says "There is a new build of GR HEAD1.1171.4.2, rh9_gcc32opt, which is a branch off v15r39 and now includes the latest xmlGeoDbs for the ACD trapezoids." (Johann) requests simulation runs using this tag.
ScienceTools See the weekly report.
SCons: (Navid) provided the following summary:
There wasn't much to report. I'm almost done converting the 3 parts of the RM to using non-gui parts of Qt. This conversion allows GoGui and RM to interact with each other easier and also gets rid of 3 out of the 4 external libraries that the RM depends on. I have completed about 90% of the conversion and plan to finish the other 10% today; by the end of the week all the code should be tested and working. At that point I'll turn my attention back to the SCons files themselves to address issues GoGui has discovered as well as add some new features to our SCons builds.
(Emmanuel) continues to work on building GlastRelease with SCons; that is, making sure that SConscript files and the like are done in such a way that all packages build properly. About 30 packages are done with perhaps 40 left to go; however fixes tend to occur in bunches: a fix for one package often applies to a few others. The whole process might take another week or so.
(Joanne) has made a GoGui status page in Confluence with one list of currently implemented features and another list of those which she intends to implement. [Additions to or comments on the latter are hereby solicited. Just add them to the page.] High-priority items include
previous | minutes index | next |