ScienceTools: Seth presented the report.
FSSC Report: (Eric W.) Still working on porting v9r11. Under the hood, they've added the ability to make and distribute static as well as dynamic libraries. They also added gtexposure to the list of tools to be distributed as part of their release.
Pass7 reprocessing: See definition of what's involved and current status, and also Tom's notes.
Retune CT's (Bill) is moving from GR v17r16 to v17r17 (typically takes about a day for such a move). He can see differences, but overall performance is very similar. (Richard) Is it possible for Nicola to be finalizing event classification variables in parallel? (Bill) doesn't agree with class definitions (e.g., exclusion of CAL-only events) but that may just be a symptom of his being out of touch with what users want. (Seth) CAL-only events will not be used (this time around) to make IRFs, but otherwise are not excluded. See class definitions proposal. (Richard, summarizing) Aim for Bill to finish at end of week; work on class definitions will be done in parallel.
merit tuple(Tom) [kindly supplied the following summary of the discussion]
It was discovered that the reprocessing does not currently produce modern output merit files. Rather, it reads in an existing merit file, modifies its content, then writes it back out without adding any new columns. For example, the EvtEventFlags variable was introduced some weeks after 4 August 2008. It is desired to have a consistent set of merit files (same columns) for the entire LAT data set; this problem is being investigated.
FT1 (Tom) The task to make FT1 had been run in the past but hasn't been looked at in a while. (Richard) Expect a new FITS file for electrons.
FT2 (Warren) has implemented everything discussed at the Data Handling meeting on Friday. (Anders) Since there seems to be a demand for it, will make 1-second version available as well as 30-second. 30-second will be the default. (Seth) For exposure calculations, 30-second interval is more than adequate.
we have been compilling code with the G4_STORE_TRAJECTORIES flag on, causing "extra" info about a given particle's track to be stored. There were hooks in our code that accessed this info but it turns out we never use any of that code. Turning it off certainly helped the memory usage on Windows, I hope we see that on linux too![Thanks to Tracy for the post-meeting detail.]
previous | minutes index | next |