The producer module should be in release CMSSW_1_6_0. It's now located in

RecoVertex/V0Producer

The latest tags (as of today) for V0Producer are V00-00-03 (V0Producer) and V00-00-04 (DataFormats/V0Candidate.)


Until this point, I've been using filter modules to prune any events with nuclear interactions, etc. I now am simply looping over all the tracks and attempting a vertex fit using KalmanVertexFitter (using track parameter smoothing) for all oppositely-charged track pairs. This results in a significant slowing in compute time per event for high-multiplicity samples, so one of my next tasks is to implement some cuts that will be applied to the track collection before attempting vertex fits.

I am currently working on simulating some b-jet samples so that I can try to reconstruct these. I tried some initially after I changed the producer to loop over the tracks, but the lambda peaks were unusually broad; some reconstructed lambdas in fact had an invariant mass that was lower than the sum of the proton and pion masses, which is of course impossible.

I will post more when I know more about this.

The good news is that, even on high-multiplicity b-jet samples, my code is stable, although slow. This was pretty much what Steve Wagner was worried about, and as there are no showstoppers, I am fairly sure that the code will be in 1_6_0.

I've now got a working producer. I've implemented my own Candidate class, reco::V0Candidate, which will be included in CVS soon under DataFormats/V0Candidate. This was after long correspondence with Luca Lista.

I'm now starting work on making the producer take a generic TrackCollection and loop over the tracks to find the candidate oppositely-charged tracks to pass to the KalmanVertexFitter. We have various ideas about how to deal with cutting down the bad tracks that won't produce a good vertex, but I'm first going to implement the looping functionality. This is actually kinda nontrivial at this point, although I'm sure it's easier than I'm thinking.

The EDProducer is now working in its current form, namely, simple K0s->pi+ pi- events are being correctly reconstructed and written to the Event. I found that I had to manually load references to the original tracks and also manually load the refitted tracks into the reco::Vertex object before storage.

Plots also look better with the refitted tracks. The KalmanVertexFitter's track smoother apparently didn't work very well before, so it was non-functional until CMSSW_1_3_0. It seems to be working now.

I also found that I needed to be able to create references to tracks already stored in the event, so they can be referenced from the reco::Vertex object. These are also needed for Candidate objects, so it's good to know how to use them. Here's the code for creating references given a Handle:

reco::TrackRef trackRef1(theTrackHandle, 0);
reco::TrackRef trackRef2(theTrackHandle, 1);

The integer argument to the constructor above is the index of the TrackCollection containing the track you're interested in. (The TrackCollection is accessed through the Handle, which apparently can act just like an iterator.)

I'm most likely going to start coding my module using Candidates. I've yet to hear back from Steve on this, but it seems Candidates are the preferred data format for analysis in CMS these days, and the storage isn't bad, especially now that I can use track references.

I've begun work on the V0 EDProducer module outlined in the last post. I started off using the reco::Vertex class to store the information about the reconstructed V0s, but I'm having problems. I'm unable at this point to pull the reconstructed track information out of the reco::Vertex objects that I create. It seems, in fact, that they aren't being stored at all.

I've been in contace with Luca Lista, and he thinks that it would be good if we create a V0Candidate class that would inherit from CompositeCandidate. I'm researching more the capabilities of the ParticleCandidates for storing track references and the vertex information. I may write an alternate version of my class that would use the Candidate structure. Apparently, this is hoped to be the standard tool for analysis.

I just gave a talk at the Tracker DPG weekly meeting.

I outlined the next steps in getting a standard V0 reconstruction package into the CMSSW releases that will be run as part of the standard reconstruction chain, to be done by the end of June 07. This will involve the following (Steve Wagner's list):

need an EDProducter

takes arbritray list of tracks out of event

check to see if viable V0 candidate (overlap, angle between trks, charge, ...)

make every V0 fit for viable candidates

try 2 mass hypo (p+pi-, p-pi+, pi+pi-) and cut on mass

put successes into list

persist list (look thru DataFormats)

CMSSW/DataFormats/VertexReco/interface/Vertex.h good candidate

look thru existing documentation (Workbook, Vertex validation) to see
what people do already (b tagging group, Particle flow group)

generate package for module (EDProducer), make cfg, cfi, ...

add Workbook documentation so first thing CMS analyzer does is run default
-----------------------------------------------------------------------------

There was also some discussion about implementing TOB-TEC seeding for improved V0 reconstruction efficiency. We'd been looking at CMS IN-2007/017 for novel seeding algorithms, but Boris Magnano told me today that the CTF seeding is layer-agnostic, so we may be able to do TOB-TEC seeding without having to implement another full module -- might just have to make a new .cfi file that runs the seeding with whatever layers we want to use. This is down the road, though.

First priority is to get the check done, running right now, as to whether too many seeds being cleaned is the problem with RoadSearch efficiency in the 1_3_X series. I've run the standard 1_3_3 release, and it doesn't seem to have much of a positive effect (100 more events or so reconstructed of over 4000,) but Kevin Burkett gave me a couple of parameter changes, relaxing a vertex constraint AFAIK, and I'll see what the mass plots look like with these changes.

I'm also planning to shortly begin working on implementing the EDProducer module outlined above. The first step is to get some standard Monte Carlo samples (QCD jets will probably be the best bet) and loop over the tracks to find candidate charged track pairs to fit a vertex and do a mass cut to look for Vees. I'm going to start by implementing this in an EDAnalyzer, mainly because it's not clear yet which data format we should use to persist the reconstructed Vees into the Event.

RoadSearch problems in CMSSW_1_3_2

I've seemingly lost a lot of reconstruction efficiency in the 1_3_2 release, which may be due to a bug in that release. I'm currently running the simulation code in the 1_3_3 release, just installed at CERN today, IIRC. We'll see if that fixes the problem.

Summary to date

This work has been ongoing for the last year or so, off and on because of classes. I'll try to summarize what's been done so far in this post.

Talks that I've given on Kshort reconstruction, containing a lot of background info, are located at my colorado HEP website:

http://www-hep.colorado.edu/~drell/CMS-talks

I'm still doing fairly simple simulations of V0 events, namely 5 GeV Pt Kshorts coming from the IP. I've implemented an EDFilter, called KshortChargedDecayFilter, which looks at the simulated event and checks to see if it's a simple K0s->pi+pi- event. If it isn't, it stops processing for that event, i.e. reconstruction of that event does not take place. This filters out K0s->pi0pi0 as well as any events where the decay product charged pions undergo nuclear interactions within the silicon tracker material. We have a lot of material on CMS, so this happens fairly often. For a 10000 event sample in a recent release of CMSSW (CMSSW_1_2_3) I obtained 4675 good K0s->pi+pi- events with no nuclear interactions.

I then feed these good events into the different reconstruction algorithms, the Combinatorial Track Finder (CTF) and RoadSearch (RS). I've been running the reconstruction algorithms through a long history of CMSSW releases, starting with 0_6_0 and going all the way to the most recent release as of this post, CMSSW_1_3_3. I've been comparing reconstruction efficiency of the Kshort tracks across the two reconstruction algorithms.

I should note that the CTF has a couple of seeding algorithms implemented. The one that will be used in the mainline reconstruction chain is called the Mixed seeding algorithm. CTF also has a seeding algorithm that uses the silicon strip detectors instead of the inner pixel layers. The strip detectors have worse z-resolution, so the invariant mass plots generated using this seeding algorithm are broader, but the efficiency is much higher. This seeding algorithm was designed to be used for reconstruction during the engineering runs, when we were to have only a partial pixel detector installed, but as it seems that there will be no colliding beam in the engineering run, it's not clear to me what the pixelless seeding will be used for. It seems a good fit for V0 reconstruction, but the overhead is significantly higher, so it isn't likely to be included in the main reconstruction chain.

To reconstruct the Kshorts, after I use the CTF and RoadSearch, I take the reconstructed tracks and use the KalmanVertexFitter to vertex the tracks. From this, I can make invariant mass plots, etc.

I'm now trying to track down a loss of RS efficiency that may or may not be caused by a bug in the RS code in the CMSSW_1_3_2 release. So, I've upgraded to CMSSW_1_3_3, recently released on the CERN lxplus machines, and I'll attempt to see if we can regain the efficiency I'd seen in the CMSSW_1_2_3 release.