Tuesday, May 29, 2007

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.

Wednesday, May 16, 2007

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.

Monday, May 14, 2007

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.

Initial Post

I intend to make this blog my research log. I'm currently working on reconstruction of V0 particles for the CMS experiment at CERN using the CMSSW software framework.

I'll try to keep this up to date as I continue work.