In the following table, an example of the efficiencies of the STT pattern recognition, the STT+MVD PR and of the Kalman fit are reported:

STT alone PR: 87%

STT+MVD PR: 97%

KALMAN : 65%

STT alone PR: 87%

STT+MVD PR: 94%

KALMAN : 89%

The efficiency is calculated as (integral in peak)/(number of generated events), where the peak is defined as the range (mean-3sigma, mean+3sigma).

As you see, the high efficiency of the STT+MVD pattern recognition is reduced after the Kalman.

Two plots are attached to the message, showing the momentum distributions obtained with the STT alone (black), with the STT+MVD reconstruction (red) and after the Kalman (blue), again for muons at 0.3/1 GeV/c and theta = 40°.

As it is shown in the file "03GeV_40deg.pdf", the Kalman produces long tails in the momentum distribution, causing a lower efficiency in peak; these tails are not present in the other two distributions. In addition, the distribution is no more gaussian.

The tails are not present in the Kalman 1 GeV/c distribution; nevertheless, the efficiency is lower than the STT+MVD one also in this case.

Is there something going wrong in the Kalman?

Has someone already noticed this behaviour or has any idea/suggestion?

Is it possible for the detector experts to check if the recohit covariances are correct?

Thank you.

Ciao,

Susanna]]>

in the tracks that enter into the plot for the Kalman filter, do you check that the getStatusFlag() of the track rep is giving 0?

Cheers, Christian]]>

If the flag is <0, then the track is not included in the plot.

Isn't it enough?

Ciao,

Susanna]]>

what is the call and check you make, exactly?

Christian]]>

for (Int_t k = 0; k < kalfit->GetEntriesFast(); k++) { kalTrack = (PndTrack*) kalfit->At(k); if (!kalTrack) continue; if (kalTrack->GetFlag() < 0) continue;

where kalfit is the TClonesArray of PndTracks produced by the Kalman:

TClonesArray *kalfit = new TClonesArray("PndTrack"); reco->SetBranchAddress("SttMvdGenTrack", &kalfit);

Then, if the track is a primary track (I check the MCTrackId of the corresponding TrackCand), I fill the histogram of the momentum distribution:

hgen->Fill(kalTrack->GetParamFirst().GetMomentum().Mag());

Susanna]]>

I see. Could you please check how this PnTrack::GetFlag() relates to the GFTrack::getStatusFlag() of GENFIT?

Cheers, Christian]]>

The PndTrack flag can be filled both in PndRecoKalmanFit and in PndGenfitAdapters, with the following values:

i) -10 if pz=1e-9

ii) -2 if the conversion from GenfitTrack to PndTrack has failed

iii) -1 if the the number of degrees of freedom (NDF) = 0

iv) 1 if NDF != 0

Concerning fStatusFlag, it's a data member of GFAbsTrackRep. I see that in GFKalman it is set to 1 if you catch an exception in processHits(); then there is a continue and you go to the next rep.

So if I understand correctly, the values of these two flags do not seem to be related. Or am I wrong?

Susanna]]>

Therefore, reading the code, GFTrack::getStatusFlag() is not accessible from PndTrack at the moment.]]>

so you you please add GENFIT flag to the PndTrack? The important thing is: status==0 means everything is fine, status!=0 fit failed. Then please apply a cut on this flag and redo the momentum spectrum. I am wondering if the tails get smaller...

Cheers, Christian]]>

Anyway, I fear that applying a cut on this flag will influence only the distribution tails (in case) and will not affect at all the problem of the efficiency lowered by the Kalman. Do you have any idea about that?

Ciao,

Susanna]]>

-What fraction of tracks can be correctly fitted with GENFIT?

-Why are the tracks that are not fitted not fitted?

-Is it maybe due to false hits picked up in the pattern reco?

The last point you can check by looking at the efficiency after a MC truth pattern reco. If you implement the GEFIT flag, just make sure that the other cases the PndTrack flag can take (pz==1e-9, etc) do not superseed the GENFIT flag. When we isolate for which tracks GENFIT fails, we can try to find out why.

Cheers, Christian]]>

So this should not be the reason of the tails...

Concerning the other failures of Genfit, by looking at the flag implemented by Stefano, I found:

- 46 events with flag = -1 (NDF=0)

- 310 events with flag = -2 (GFTrack to PndTrack conversion failed).

As I told you, these events are rejected and do not enter in the plot.

Do you have any suggestion?

Ciao,

Susanna]]>

sorry for not replying earlier, I was out of office...

I see, the GENFIT flag does not explain things. There is one more thing that just came to my mind:

What values for the momentum and position initialization due you use for building the GeaneTrackRep objects that go into GENFIT?

I ask this because I remember a similar behavior in cases where the init pos and mom values were not very good in some test I did in the past. What was happening was that I was basically falling into the left-right ambiguity normal for drift chambers.

Cheers, Christian]]>

The momentum distribution of the PndTracks after the pattern recognition is the red one shown in the plots attached to the first message: it seems reasonable and without tails.

Then, before going into Genfit, the tracks are backpropagated to (0,0,0) but I don't have any plot for these.

Ciao,

Susanna]]>

could you try as a test to initialize the GeaneTrackRep with MC truth values for the position and the momentum. This way we can exclude that there are problems with the seed values for the Kalman fit.

Cheers, Christian]]>

did you find out more about this problem? Did the seed values have anything to do with your problem?

Bye, Christian]]>

As soon as I can perform the test, I will let you know the results.

Ciao,

Susanna]]>

The results are in the plot attached: the red histogram is the input one, with the MC values; the blue one is the Kalman output.

Also with the true values as input, the results are not good...

Any suggestion?

Ciao,

Susanna]]>