sPHENIX discussion of software

[Ross Corliss <rcorliss AT mit.edu>]

Hi Hugo,

In https://indico.bnl.gov/event/5370/ and other meetings of the Inner Tracking taskforce there are updates on the TPC track pointing ( https://indico.bnl.gov/event/5370/contributions/25249/attachments/20902/28221/TPC_track_pointing_resolutions_11.28.2018.pdf ), in which we use only the inner tracking detectors for track reconstruction, but with the TPC present to compare extrapolations to the actual hits in the TPC, which is roughly what you're doing.  The code for this is likely in my fork of the collaboration code https://github.com/rccorliss/coresoftware, if you want to compare my implementation to yours.

As regards the error, it doesn't ring a bell (nor do I see it when I flick through my notes).  If you are defining a 3D point as having no uncertainty in one dimension (eg a hit on a fully-defined surface) you might get a problem with the covariance matrix not being positive definite, but I don't think MeasuredStateOnPlane should suffer from that.

-Ross

On Nov 19, 2019, at 2:15 PM, Hugo Pereira Da Costa <hugo.pereira-da-costa AT cea.fr> wrote:

Hi all, (especially Tony, Chris, Christof, Jin, Ross, etc.)

I wanted to report quickly on my (small) progress at working on the tracking in the TPC. Now that Quark Matter is over I could finally focus on this seriously for the last two weeks or so. 

What I have worked so far is starting from an outer detector prototype code from Tony, and consisting in two layers of silicon detectors hanging in the air around the TPC.

I have included them in the track finding and fitting. Tony, correct me if I am wrong: this was _not_ in the code you passed me, right ? first time I tried the truth track seeding (PHTruthTrackSeeding) it crashed because of not knowing were the outer tracker G4Hits were coming from, as for the full track finding (PHGenFitTrkProp) they were simply not looked up, because new layers were not accounted for. Tony, does that make sense ?

Now what I am doing is modify the kalman filter to be able to disable some layers (take them out from the fit), and look at residuals (track - clusters). The idea would then be to disable the entire TPC and look at the extrapolation power of the other detectors, with and without this extra outer tracker layers, using PHTruthTrackSeeding.

This seems to be working, and I should be able to report about this at the next software meeting. 

Now there are two things about which I'd need help/info/advice:

- Ross, I was told that you did perform similar studies in the past already. Correct ? If yes, do you have pointers to some presentations on the topic, to see how my numbers compare to what you have had so far ? that would help me make sure that what I have been doing is not completely crazy. 

- second, when running the truth track finding, I have a non negligible number of GenFit exception thrown of the following type: 

Error in <TDecompChol::Decompose()>: matrix not positive definite
genfit::Exception thrown with excString:
KalmanFitterInfo::calcAverageState: ill-conditioned covariance matrix.
in line: 149 in file: /phenix/u/phnxbld/workarea/sPHENIX_SL7.3/need_root_version/root-6.16.00/genfit/core/src/MeasuredStateOnPlane.cc
with fatal flag 0

These are not present when running the full track finding, and they seem to be responsible for spiky structures in my residuals distributions (rphi, or theta), also not seen with full track finding. 

Does this error ring a bell to anyone ? and if yes, any idea where it come from ? 

So far I have not been able to track the origin of the exception (nor to establish firmly the above correlation between error and spikes). So any input appreciated !

Hugo

_______________________________________________
sPHENIX-software-l mailing list
sPHENIX-software-l AT lists.bnl.gov
https://lists.bnl.gov/mailman/listinfo/sphenix-software-l