Beta Wishlist

This page is under construction.
Other pages: [Main Beta page] [ Analysis tools Hypernews page] [Physics and analysis page]

Recent Changes

• 14 Aug, 1998 -- Major update - Bob J
• 7 Dec, 1996 -- Created page, moved stuff from main Beta page - Bob J

Existing features

Missing features

• Access to candidates by "particle type", direct indexing of types, daughters, etc
• Clean, semi-automatic handling of charged conjugate modes

Project list

1. With the handle idiom, there should be no BtaCandBase objects allocated automatically; they should all be allocated via new. This permits the use of class-specific new and delete. Its been suggested that this could allow a number of improvements:
   1. By "registering" BtaCandBase objects as they are created and destroyed, it would be possible to provide a summary of all leaked objects.
   2. Various enquiry functions could be imagined, for example "find all existing candidates representing a D+"
   3. A memory manager could be made specific to the size & reuse patterns of candidates, which might gain efficiency.
   It will take significant investigation to see if these benefits can be obtained without changing the semantics of BtaCandidate.
2. Beta has a simple automated test, but we need one for the full BetaUser executable
3. Sample code at various levels. In particular, we need lots of little "idiom examples" that we can present to people with commentary about the bad & good ways of doing certain things.
4. "Walk-up" and "walk-down" navigation of the mother-daughter links to allow you to find a MC truth particle, etc. There are several patterns that could work here, but we want to limit the variability in the candidate itself. Maybe the Visitor pattern? Note the Paul Dauncey has made some suggestions about how to move this type of operation _outside_ the Candidate itself.

• Clean, semi-automatic handling of charged conjugate modes under user control. Its not clear how to do this, and some examples would really help. Perhaps it can be built into the PDT interface? Perhaps people should just structure their programs in terms of separate pi+ and pi- lists, and run everything twice? (It is a CP-violation experiment after all) Some things are CP eigenstates, and how to handle them should be carefully thought out. K0, D0 -> K0 pi+ pi-, etc. Gautier has suggested that this could fit well in the "Selector" architecture.

Getting BetaAslund to work well

1. AslundInputModule should make GTracks correctly, so event display, etc, can work. Currently, its not filling in vertex or particle type information, which makes it impossible to run the G3TrkLoad, etc, modules, afterwards.
2. AslundInputModule should make TrkRecoTracks "properly" so that the graphics, etc, work.
3. AslundInputModule should get the track and neutral object's error matrix from Aslund, which as gone to some trouble to calculate it. This will probably require a new BtaCandidate subclass to handle the neutral, or at least an upgrade to the Aslund dummy neutral class, AslNeutral.
4. The other systems, beyond DIRC and DCH, should have simple PID implementations.
5. ThereÕs a problem with disabling all of the various modules created to run simulation and reconstruction when running in Aslund mode. Various of these will have problems in the begin() and end() Framework entry points because not everything is being run, and its hard to get all that stuff set up right. Currently, we get around this by not allowing users to build an executable that includes Aslund plus anything else. A better solution would be greatly desirable.

Getting BetaReco to work well

1. Need a "bbsim info" (GTrack, stdhep, etc) to Candidate module, including production and decay vertex position, genealogy, particle type and MC truth structure. See the BetaMC package, which should finally be made to work.
2. The BtaMcTruth class is intended for storing additional MC truth information. It should be fleshed out by looking at what's in a stdhep entry, and figuring out how to store that. Many quantities go in the MC candidate itself, but things like decay mode should go in the McTruth object. Access to the GVertex objects that formed the production and decay vertex should be provided.