BaBar reconstruction workshop, Orsay, June 23 and 24, 1997
A reconstruction workshop was held in Orsay on June 23 and 24, following the physics workshop. The emphasis was on technical discussions of specific problems and the solutions we are evolving, with emphasis on the areas of particle ID, the eventual
migration to event and calibration databases, and the ongoing Mock Data Challenge.
A complete set of scanned slides is available. This page also serves as informal minutes.
Recent Changes
- 7 July, 1997 -- Updated agenda to as-given, added minutes & slide pointer (Bob)
- 20 June, 1997 -- Updated location & agenda (Bob)
- 23 May, 1997 -- Created page (Bob)
During the course of the meeting, we recorded items that should appear on the schedule on a couple of slides. The reconstruction schedule has been updated to
include these.
Monday June 22, 9AM - 2PM, LAL Orsay building 200 room 129
- 9:00 - 10:30 AM PID
-
- Our PID model
- Reco vs Beta vs analysis code
The role of MC standin code
What's left to do?
- Recent changes to interfaces
- The new PdtPid class
The new PidMassHypo class
- IFR, EMC, joint calorimeter objects
Bob showed a few slides that caused much discussion, mostly to clarify the "line" between physics and reconstruction. Although there were several examples of
algorithms that people were sure were so correct that nobody could object to their being the only available one, none of them was acclaimed as the right answer, so we will continue to build in the current level of flexibility. Their was also some
discussion of providing "likelyhood" in addition to our current "consistency"; it is likely that this will come up again, as several people volunteered to right up a clear definition of what likelyhood means so that the systems could determine if they
could provide it.
Gautier's changes to the PID interface to provide "normalized probablility" and the ability to easily determine the most likely particle type were greatly
appreciated. Some discussion of particle-data information ensued. It seems that some systems ignore the charge of a particle data entry when doing PID calculations, while others (like the DIRC) insist on a correct charge assignment. One solution to this
would be to provide PDTentries corresponding to "an electron of either sign", etc. The new PdtPid class is a step toward this, and is expected to continue to evolve. There was also a desire for entries for "neutral B hadron", etc, for use during physics
analysis. The hardest part of this seems to be getting a complete set of expectations from the various users, and then writting all the various op == functions for properly comparing them. More work is clearly needed here.
Phil Strother presented the current EMC PID structure. Its complicated, because it has to handle the ambiguities of matching clusters observed in the EMC to
charged tracks observed elsewhere. It introduces a new "EmcCandidate" as containing one or more things observed in the EMC that are associated with a single "physics thing". Phil and Steve Gowdy will arrange for the associations and PID information to be
written to Beast for the July 1 release (a redesign since the workshop has delayed this).
As part of the EMC discussion, we agreed to change several base class names to reduce confusion about "Neutral". In particular, the AbsNeutral package will be replaced by the AbsCalo package, and the AbsRecoNeut class becomes the AbsRecoCalo class. The
new package will be available July 1, with the EMC and IFR to coordinate their migration after that.
Riccardo presented the IFR status. It uses a structure similar to that of the DIRC, based on charged tracks. Currently, these are the MC tracks pending the arrival
of a swimmer, but they hope to convert to reconstructed tracks soon.
One notable difference between the IFR and EMC approaches involves the role of "neutral" vs "charged" PID. Currently, the EMC basically handles these the same, while the IFR treats them very differently. Although this may reflect an essential
difference in the physics of the two systems, they are planning further discussions to understand the implications of this difference, particularly for joint reconstruction of neutral hadrons. The next step will be a jopint meeting at Bristol.
The DIRC, EMC, and IFR all have a structure based on internal "algorithms". To the extent that the system wants to provide multiple algorithms, it should be possible to produce multiple output lists corresponding to running more than one algorithm on a
single event (See below for more info on multiple lists in an event). This can be done by, for example, creating multiple instances of the module and selecting different algorithms using the parameters. What's important is the capability, not exactly how
its implemented.
- 11:00 - 12:30 AM Support for physics users
-
- Releases for physics users
- How are we going to support our users? Making features available via Beast
Discussion centered around testing releases so that they are more reliable, or we at least can tell people what's working and what's not. After some discussion, we developed a proposal:
- We'll do initial compile, link and run tests on Bear using small data samples.
- If those pass, we'll ask the production organization to run a few samples of 2K events:
- B to K pi, Bbar to nu nu
- B to pi0 pi0, Bbar to nu nu
- B to J/psi (mu mu) K0s (pi+ pi-)
- single gamma 50 to 500 Mev
- single gamma 500 MeV to 5 GeV
- single mu+ 50 to 500 Mev
- single mu+ 500 MeV to 5 GeV
- single K0L 50 to 500 Mev
- single K0L 500 MeV to 5 GeV
- single K+ 50 to 500 Mev
- single K+ 500 MeV to 5 GeV
- mu pairs, with real kinematics
The paw.ps and reco.rwend files from these will be kept, and once the set is done the reco system contacts will be emailed to tell them were to find them. They will (have somebody) look at these and reply within 48 hours as to whether there is a problem
or not, along with a short form-letter paragraph on resolutions, efficiencies, etc.
We also agreed that GNATs should not include link errors, as they are too likely to come from some other package, but should include compile and runtime errors so that they get fixed.
-
- Building on Beta
Andrei Salnikov reported on his experiences building BetaKfit on top of Beta. There were several things that did not match entirely, and some changes will have to be
worked out. In particular, the interface to specific information from different types of candidates was not sufficiently common: reco track candidates, calorimeter candidates, etc, all provide different information at the detailed level. Perhaps an
additional interface using differential numbers, or at least some of the technology from the tracking system, could help this? Also, he suggest that the candidates carry both initial and final vertices; this is certainly possible. We are also in desparate
need of error matrices in a number of places.
A long discussion of what "mothers and daughters" means became a discussion of the "overlaps" function. This is particularly confusing in the case of BetaKfit, which can create new candidates that represent the inidividual particles entering a
kinematic fit. The information content of each of these is entangled with all the others due to the constraints applied in the fit. Its important that "overlaps()" represent as much of this as possible, without becoming unusably slow. More work on this is
needed.
- 2:00 - 5:00 PM Databases (With David Quarrie via video)
- The various approaches: pro & con
How will developers work?
How will people run jobs & select data?
How are we going to get the system built?
David's presentation started a wide-ranging discussion, and was followed by a
few slides from Bob. A lot of work has been done to prototype using the Objectivity database to store event data, and the majority of the EMC data can now be read and written to a database. Some of the development tools are in place, and experts are
now able to code database access for a particular class with a reasonable amount of work.
But its not yet clear how ongoing development will be done, nor how we will spread knowledge of database operations and programming to those developers who will need it. Aiming to gain some experience with this, a number of steps were agreed to:
- People should start installing Objectivity at their local site ASAP. It should take less than one day to install; less than one week is typically seen.
- Starting July 8, we will be building "persistant releases" during the biweekly production builds in addition to the existing architectures. These will be separate, using a different BFARCH version much as we did during the conversion to the native
compiler. The goal is to sort out teething problems with the build process and multi-site development, and to ensure that none of our supported platforms lags too far behind.
- A set of system-specific contacts ("database programmers") need to be identified to work closely with Steve Gowdy and David Quarrie to handle the migration.
- We need to define an initial set of persistent classes (e.g. the contents of the database for reconstruction output) on the timescale of Bristol.
- The last release that we will guarantee can be built and/or used without a local copy of Objectivity will be August 26th. Note that this implies the releases in September may not be usable by some sites that are trying to prepare for the September
physics workshop, so the August 26th release should be a good one.
- As a compromise, we will eventually need to confine "schema updates" to only once per month. This means that changes to the way that data are stored to the database should be confined to a smaller set of release builds, similar to the way we are
(nominally) trying to confine large new features to the "early in the month" releases now.
Tuesday June 23, LAL Orsay building 200 room 129
- 9:00 - 10:30 AM Alignment and calibration
- The existing DIRC solution
Christophe Yeche gave a nice presentation on how this is done for the DIRC. Using Rogue Wave persistance to write out the needed information to a summary file, and
then doing the alignment by varying DetectorModel parameters in a MINUIT-based program, the DIRC's alignment needs can be met. Although there's a lot of additional work to do, this is a clear demonstration of an important capability. People who are
starting to think about alignment in their systems are encouraged to get in touch with Christophe and Gauter to benefit from their experiences.
- 11:00 - 12:30 AM Graphics
-
- Status & Demos
- How to drive the system
- How to add specific features
Serge Du and Anne-Marie Lutz gave a very complete walkthough and presentation. Its clear that the graphics support is coming along fast, and that people who want to add system-specific
information to the event display have a lot of capabilities to draw on. In particular, the ability to define new function at the level of a Module (an entire display), Observer/Selector (a particular window), and Representations (exactly what's drawn for
a particular system/object) allows a lot of flexibility. People should directly contact Serge and Anne-Marie if they need assistance implementing their specific display needs; several people have already written particular displays for their systems.
- 2:00 - 3:30 PM Other questions
- The release system
- Symbols & debug info in releases?
Improved communication again
Release 4.1.6 had just been built without symbols. Although nobody present had direct experience debugging with it, early reports indicated that the link times were enough shorter that relinking to get symbols was not a big issue. (Since the workshop,
several people have reported problems figuring out which package to recompile and link; this needs to be discussed). We'll keep removing the symbols for the next few releases at least, and investigate whether we can produce extra libraries with symbols.
- Details of coming changes
- The event migration
Other updates
Ed Frank has written a Hypernews on the event migration, and several systems have started. Bob will put an undergrad on the job of editting the remaining systems, with a goal of having the migration complete (including the AbsEvent changes) by the July 22
release. This is risky, as there will be people away at Bristol, but seems necessary to get the job done.
- AOB
We discussed the reconstruction "open access" policy. There was a clear consensus that physics analysis information should be protected, including code, although in
the interest of scientific collaboration we would probably grant access to others if asked. We have to think through what packages this applies to. There was also a concensus, though not unanimous, that the current policy of openness for the common code
and reconstruction code was appropriate. To make it clearer that BaBar is interested in collaboration in development, we will add the proposed updated header to our source files over the next month or so.
Return to BABAR reconstruction software page, BABAR Computing Home Page, or BABAR
Home Page.
Maintained by Bob Jacobsen,
Bob_Jacobsen@lbl.gov 510-486-7355
|
