Core Minutes 2/22/2005  

Present:    Pol d'Avezac, Joanne Bogart, Anders Borgland, Toby Burnett, James Chiang, Johann Cohen-Tanugi, Seth Digel, Richard Dubois, Zachary Fewtrell, Riccardo Giannitrapani, Berrie Giebels, Navid Golpayegani, Tony Johnson, Heather Kelly, Matt Langston, Chuck Patterson, Leon Rochester, Tom Stephens, Tracy Usher

• Data Handling: (Tony)
  • System Tests No news since the release of a new version last week.
  • Pipeline Dan was sick last week; no news.
  • Data Server Planning a meeting with Jean-Paul Lefevre.
• GlastRelease: (Richard) Focus is on making a GlastRelease tag which will form a suitable base for EM tag which I&T can use with the new hardware being assembled. (Toby) has been making new tags to incorporate the latest and greatest Tracker code, but backed out some CalRecon changes since the plan is to separate this upgrade from the Tracker upgrade. He will ask Julie to run System Tests on the most recent, v6r2 (but see note below about clone of CalValsTool). (Richard) Still some concern on the following fronts: memory leaks, increased processing time, and significant differences in output (e.g., number of tracks). In the new calorimeter code, CalDigi takes about 20 times longer than it used to, about 1/3 second per event for 100 MeV events. First stage of TkrRecon may also be somewhat slower.
• Tracker: Tracy has been tracking down memory leaks. After switching to a newer, better version of ValGrind (thanks to Anders for the suggestion), he found three new leaks in TkrRecon. He also fixed a problem causing very long processing time in those (infrequent) events where a particle was near a boundary and had a trajectory making a shallow angle with the boundary. He noted there have been changes to the combinatoric pattern recognition, causing it to find more tracks, so it is not surprising that processing time in this stage would increase, or that results would be somewhat different.

  Meanwhile Leon has been busy on several fronts:

  • A week ago he introduced a bug into TkrUtil while making changes to accommodate, Tower A, which had no CAL. It broke code that calculated CAL volume identifiers when there was a CAL. This is now fixed in the latest tag of TkrUtil.
  • There is a clone of the (AnalysisNtuple) CalValsTool class in CalRecon, presumably to avoid dependence on AnalysisNtuple. However changes needed for new TkrRecon were not completed on this clone. Leon has finished the job and committed the changes to CVS, but will leave the task of tagging to someone more versed in the current state of CalRecon branches.
  • In order to see if the modified pattern recognition logic was affecting processing time, he tried backing it out (on his Windows laptop). Didn't appear to make much difference.
  • Using a GUI event display (the old one or FRED) makes a huge difference in per-event memory leaking. Without a GUI, after all Tracy's work, we're down to about 800 bytes/event. With a GUI, it's more like 100 Kbytes!
• Calorimeter: Berrie reported that a first check on CalRecon with 10 GeV photons generated by the system tests on v6r1p2 shows results consistent with those of v4r5p1. Compare for example this v4r5p1 plot with the v6r1p2 version. We applauded and Berrie bowed..
• Readiness for I&T: (Anders) I&T would like to get the new TkrRecon into EM as soon as possible, but it is clear there are issues. They will discuss the options today. Some data may be taken today. (Richard) What version of EM is currently being used? Answer: v3r0407p3. They plan to wait until there is a more useful tag available, rather than jumping on p10. (Heather) p11 will be made available and will include the new GEM; then there will be a new tag of EM for the new TkrRecon. (Leon) He has new calibration code on his laptop. There is a remaining defect in that missing strips can result in broken tracks. The point is that there will still be some unsatisfactory aspects to the new code...not mysterious, but it will need work. Kalman energy is also a work in progress. (Richard) We all knew what we were getting into when we signed up to provide new code to I&T - chins up..this is to be expected.
• RM: (Navid) Concerning the Windows version, he saw in CMT source code that it uses _chdir, which can only handle paths of the form: X:\blah,  meaning samba mounts would have to be mapped to a windows drive...But LSF on windows does not accept network mapped drives.

  Work continues to sort out the cause of the slowness when accessing the RM over the web. You can see from this plot that web queries via the production SLAC server are always somewhat slower than web queries via glast02 (which are uniformly very fast); often they are much slower. As Navid said in an accompanying mail message,

  "web query on www.slac.stanford.edu from noric05" is the most interesting one. I assume it's a fairly busy server, so it's normal for the wall clock time of the cgi script to vary more than the other 2. What's unusual, though, is that it's varying by such a big amount. Some queries do run in reasonable time (<1sec) while others are taking a long time. There are a few outliers in there that I cut off from the graph. Some queries on www.slac.stanford.edu took up to 100 seconds to reply.

• Personnel: (Richard) told Human Resources to stop accepting applicants for the Alex replacement. We plan to make an offer to David Brock; after this meeting we have one last interview with Samuel Johnson.

Action Items

• Toby will branch or retag CalRecon (Berrie says ok) to put in the repaired CalValsTools clone.
• Tracy & Leon will continue looking at TKR to see if they can find plausible cause for the increase in processing time.
• Zach will track down cause of increases in processing for CalDigi.

previous

minutes index

next

J. Bogart & H. Kelly, Last Modified: 01-Jun-2010 15:45:00 -0700