- 55 day run: (Richard) As of last week
there were 3 problems in generating the sky model. It turns out the
orbit file was not compatible with with run parameters. When this
was fixed, 2 of the 3 problems somewhat mysteriously went away.
We still have the pulsar problem: initialization of pulsars goes
into an infinite loop, at least for the typical 4-second run. If
the 4-second limit is removed, initialization completes normally, another
mystery. Max Razzano, aka Mr. Pulsar, is looking into it. (Toby) would
volunteer to help debug but the problem doesn't occur at all on Windows.
(Richard) We're aiming for mid-June to have the sky model done. Adequate
Data Handling facilities should be ready on the same timescale.
(Richard) Tom is starting on binning, etc. needed for Interleave; still
has a ways to go.
- GlastRelease: (Toby) The new release, v11r6,
has
source name associated with each McParticle which should aid debugging.
(Heather) What about the not-so-random number problem? Are we going to
avoid it by limiting events per run and other quantities as necessary?
(Richard) Yes, for now. We have no one to work on the problem.
(Heather) In Beamtest a problem has been discovered with the
(non-)initialization
of McSourceName in
AnalysisNtuple. The same would be true in GR when
it's run on real data. (Leon) has made and tagged a fix in
Event. He also did some extra bullet-proofing
in AnalysisNtuple but it shouldn't be necessary
to incorporate it just yet. (Richard) would prefer not to upgrade
AnalysisNtuple now, while the 55-day run is
still in progress, since it also includes
changes in ACD variables. (Toby) MC variables don't belong in real
data runs altogether; they should be in their own tuple, but this is not
the time to make that kind of structural change. (Heather) We need to
revisit circumstances of creation of McEvent and be clear on where in
the code it's expected to exist.
Toby suggested we ought to have a package with unit test to verify that
Gleam can reconstruct real data (as opposed to MC).
In a similar vein, Leon would like to see a unit test for Fred. It
could exercise everything other than actually drawing a picture.
- EM and big runs: (Heather) In this
situation, after using very large amounts of memory EM crashes, if not
at the end of the run (Anders thinks not) then during checkpointing. She
will look into it, but probably only after slapping together a newer EM.
The current one is based on the now-ancient GR v9r13.
- Access to GEM configuration (Martin)
The code involved is split into a non-Gaudi portion in
configData, handling parsing
of the LATC XML representation of the GEM configuration,
and a Gaudi service, TrgConfigSvc,
in Trigger. By default Gleam will use
Toby's trigger configuration; the new methods (either direct from
specified configuration files or via the LATC key stored in the data and
lookup through MOOT) may be requested through
job options. Access via MOOT is disabled for now, awaiting addition
of mootCore to Gleam.
configData has been tagged but has not yet been
incorporated
into a HEAD build of Gleam. The Trigger
enhancements are committed but not yet tagged.
(Heather) Bryson has done his part to get the needed LATC key
stored in the data. [(Joanne) There is more to the MOOT route
than simply adding mootCore to Gleam, which
could be done any time. I plan to add another data service to
CalibSvc which will make the file paths
for all the LATC configuration files associated with the current
configuration (as determined from the LATC key mentioned above)
available to clients.]
- RM, Installer: (Richard) Will RM
build non-standard GR tags along a branch?
We need to separate patches of production
releases from ongoing development somehow. (Navid) RM ignores any
tags not of the form vXrYpZ. It used to build certain special kinds
of tags, but it was causing confusion so this functionality was
removed. (Heather) We could insist that new development tags always be
of the form vXrY and that patch tags be reserved for production
patches along a branch. Then RM as it currently exists would build
them all.
(Richard) Why, as of v11r5,
is the Installer release twice as big as it used to be? Does it have
to do with the addition of the static libraries? [Turns out this is
my doing: it's because debug symbols were reintroduced into optimized
builds. ed.]
(Toby) Is it feasible to run Gleam from, e.g., UW, using an RM build
resident on SLAC afs? Are Windows RM builds even available on afs?
(Richard) Currently, no, but we could put one there for experimentation.
No one is aware of use of this technique by, e.g., BaBar. Some suspect
performance would be poor.
- CMT replacement strategy (Heather)
CMT Action Committee had another meeting last week in which Riccardo
stated that it would take a few weeks to update MRStudio to use
an alternate build/package management system, assuming it meets
certain criteria. [See
in Heather's minutes and Jim's follow-up section towards the bottom of
the Confluence page
CMT Status for May 2007 for discussion of this and other issues].
Joanne has written a checklist
to aid in tracking progress of
the two alternatives in active development: SCons Enhanced and
NPMS. [And, post-meeting, Navid has created entries for NPMS.]
(Toby) notes SCons will build whatever we need with an appropriate
SConstruct file, but he is not yet satisfied that the forms in development
so far will serve.
- Geometry (Joanne) Tag v1r42 of
xmlGeoDbs includes the long-awaited approximation
of side tile shingling with suitably adjusted ribbons. It needs a little
testing to be sure it doesn't wreak havoc with
AcdDigi. See some pictures
for details.
- Καλó ταξíδι,
Buono viaggio (Richard)
I leave tomorrow at noon to Athens for a few days to poke around.
Then next week is a
conference
in the mountains of the Peloponnesus - no internet access.
Following Sunday, off to Frascati for "GLAST" symposium for 2.5 days,
then to Rome proper for 2 days with our LAT buddies at
Roma 1.
J. Bogart, Last Modified:
01-Jun-2010 15:45:39 -0700