1 / 70

StiVmc

StiVmc. V. Perevoztchikov Brookhaven National Laboratory,USA. StiTGeo helper. StiVmc is based on TGeo representation of geometry. But there is no direct dependency between them. All the communication goes thru StiTGeo helper class. This class contains:

petra
Download Presentation

StiVmc

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. StiVmc V. Perevoztchikov Brookhaven National Laboratory,USA

  2. StiTGeo helper • StiVmc is based on TGeo representation of geometry. But there is no direct dependency between them. All the communication goes thru StiTGeo helper class. This class contains: • Simple array of pointers to StVoluInfo objects. TGeoVolume::GetNumber() used as an index. These objects keep specific Sti information, related to each volume. • Contains global StiHit container, only for hits used in SeedFinder. • Map container of StHitPlane(s) with HardwarePosition of StHit as a key StarSoft local

  3. StVoluInfo class • For each TGeoVolume could be related one StVoluInfo object which contains: • Some flags, like: • It is a module, like TPCE,SVTT; • It is a Module with Hits; • Active module; • It is a HitPlane : StarSoft local

  4. StHitPlaneInfo class • StHitPlaneInfo inherited from StVoluInfo class and used instead of it for sensitive volumes : • Center of Hit plane in mother system; • Direction of Hit plane in mother system; • Hit container, simultaneously sorted by two variables, like Phi/Z Phi/Rxy etc…; • Pointer to functor, which provides activity of sensitive sub volume. • Map container of StHitPlane objects. These ones related to each TGeoVolume instantiation. It is sorted by TGeo path of founded object. : StarSoft local

  5. StiHitPlane class This class represents concrete sensitive detector. It’s functionality close to StiDetector. Contains: • Center of Hit plane in global system; • Direction of Hit plane in global system; • Hit container, simultaneously sorted by two variables, like Phi/Z Phi/Rxy etc…; • Pointer to functor, which provides activity of sensitive sub volume. • Container of StHitPlane and StHitTube classes. These classes : StarSoft local

  6. StiHitLoader Loading of hits is made maximally independent of hit nature and origin. To add into StiVmc new detector there is no need to modify even one line of code. No more StiSsd, StiSvt, StiTpc, StiRnD and StiXXX classes. StiHitLoader does the following: • Iterate via StEventHitIteriterator; • Adds it to StTGeoHelper object; • StTGeoHelper tries to find according StHitPlane in StHitPlane map container by StHit hardware position. • If not found, search volume it in TGeoManager by x,y,z. • If not found, hit ignored; • Get volume id and get according StHitPlaneInfo; • Get StHitPlane by path and save it into StHitPlane map. • Save hit into StHitPlane object. : StarSoft local

  7. StiHitLoader(2) If geometry is not aligned, some hits could not find their volume. How many? StiMaker:INFO - StTGeoHelper::AddHit : Hit in /HALL_1/CAVE_1/TPCE_1/TPGV_1/TPSS_3 Not Found StiMaker:INFO - StTGeoHelper::AddHit : Hit in /HALL_1/CAVE_1/TPCE_1/TPGV_1/TPSS_3 Not Found StiMaker:INFO - StTGeoHelper::AddHit : Hit in /HALL_1/CAVE_1/TPCE_1/TPGV_1/TPSS_3 Not Found StiMaker:INFO - StTGeoHelper::AddHit : Hit in /HALL_1/CAVE_1/TPCE_1/TPGV_1/TPSS_3 Not Found StiMaker:INFO - StTGeoHelper::AddHit : Hit in /HALL_1/CAVE_1/TPCE_1/TPGV_1/TPSS_3 Not Found StiMaker:INFO - StTGeoHelper::AddHit : Hit in /HALL_1/CAVE_1/TPCE_1/TPGV_1/TPSS_9 Not Found StiMaker:INFO - StiHitLoader::LoadHits : Loaded 14711 good and failed 25 Tpc hits StiMaker:INFO - StiHitLoader::LoadHits : Loaded 14711 good and failed 25 of all hits So in case of pp2009a 0.2% of hits lost. So not aligned TPC geometry does not affect reconstruction. : StarSoft local

  8. StiSeedFinder StiSeedFinder in StiVmc used similar to Sti algorithm. The difference only different hit container. In StiVmc used 3 keys map container. In the following pictures: • Seeds + unused TPC outer hits; • Only unused TPC outer hits; • You can see that new StiSeedFinder is rather good. • On the picture with only unused hits you can not notice the real tracks. : StarSoft local

  9. Seeds + all hits : StarSoft local

  10. Unused hits • . : StarSoft local

  11. Hit Errors D w StarSoft local

  12. Hit error parameterization • Track direction T. StarSoft local

  13. Hit error + diffusion • Electron cloud around the track increased due to diffusion. Diffusion along Z and in X,Y directions is different and additional dispersion could be written as: Resulting parameterization is: StarSoft local

  14. Old Sti Hit errors • Comparing this with the previous it is unfortunately evident that old Sti error parameterization is completely wrong. All our production was made with wrong errors. Fortunately it does not mean that results are wrong, but accuracy is not such good as it could be. It could affect only such very precise physics as D0. StarSoft local

  15. DCA plane hit errors • It will be shown later that the best plane for a fit is DCA plane. • DCA plane is a plane orthogonal track direction and includes hit point and DCA point to this hit. Projecting hit errors on detector plane into DCA plane along the track direction gives errors: • You see, these formulas are much simpler than in detector plane and there is no any bad divisions by zero, like in previous case. So DCA plane is much better for fit. All these formulas were tested by Monte-Carlo, which gave exactly same result. StarSoft local

  16. Navigation • StiNavigate class provides navigation thru geometry volumes. In current version it is based on VMC navigation but in future probably directly on Tgeo. StiNavigate: • Initialized by current space point, direction and momentum; • Navigates thru volumes. On each volume: • Updates matrix of derivatives, using helix approximation; • Calculates energy loss and multiple scattering; • If volume is sensitive and active, navigation is stopped; • Then get from StiHitPlane double sorted StiHit container, StiHitPlane direction, passed length, accumulated material info, position, track parameters and errors, volume path, derivative matrix. • Fitting started. StarSoft local

  17. Fitting Let consider simplified, 2d case. Hitting plane along Y axis, track crossed Y axis with angle α wrt X axis. So : • global track parameter α projected into local Y and proportional to sin(α). • when α << 1, then sin(α ) = α – α**3/6, second term is very small and projection from global to local system is linear. • Projections of error matrix is also linear. In local frame fit is linear. Back transformation of fitted parameters and errors is linear too. When α is small then curvature ρ is also projected into local Y linearly. So life is good. But when α >1 , life is bad. Linearization is wrong, linear fit is wrong, Backward transformation into global is also wrong. All the times, when I saw unstable fit in Sti, it was α >1 StarSoft local

  18. Fit continue Could we do something with bad fit with α > 1? Yes, we can! Why we fit in local frame? There are only two reasons: • We know that track is crossing our hit plane; • We know hit errors on this plane; Let invent another local frame, where linearization is working always. The evident candidate is DCA frame. This frame is: Plane perpendicular to the track and crossing the hit point. Look the following picture. StarSoft local

  19. DCA Frame d α D β α δd δD StarSoft local

  20. Picture caption • Vertical bold line: Hit Plane; • Green star: Hit on hit plane; • Red star: DCA point of track wrt hit (green star). Arrow is a predicted track with the parameters in DCA point. • Blue star is a new position of track with the modified parameters in this point; • α is a crossing angle of the predicted track; • β is an angle between predicted track and fitted o α ne; • α+β is a crossing angle of the fitted track; • D is the distance between hit and crossing point of the predicted track; • D+δD is the distance between hit and crossing point of the fitted track; StarSoft local

  21. Picture caption continue • d is the distance between hit and DCA point of the predicted track; • d+δd is the distance between hit and fitted track point in DCA plane; StarSoft local

  22. Fitting in DCA frame In DCA frame, linearization with β and d is correct, track is perpendicular to DCA plane. In hit plane we minimizing the: ((D+δD) / σ)**2 where σis a hit error. Let express it in DCA parameters. Looking on the previous picture and using sine rule: (D+δD) / cos(β) = (d+δd) / cos(α+β) In linearization β is small and cos(β) = 1 Then: ((D+δD) / σ)**2 == ((d+δd) / (σ* cos(α+β) )**2 StarSoft local

  23. Fitting in DCA frame(2) ((D+δD) / σ)**2 == ((d+δd) / (σ* cos(α+β) ))**2 So now we can minimize: ((d+δd) / (σ* cos(α+β) ))**2 It still does not look like much better. Still cos(α+β) when α is not small could not be linearized. But now is a time to remember that for TPC and for all other detectors: σ = σ0/ cos(α+β) So cos(α+β) is canceled out. We minimize: ((d+δd) / σ0)**2 without any loss of accuracy. StarSoft local

  24. Local or DCA frame? From the discussion above it is clear that fit in DCA frame always is better than in local one. In addition , fit in DCA frame is irrelevant to hit plane orientation. It is proper for TPC, FTPC and all other detectors. But amount of computation in DCA is slightly bigger. I propose to use strategy: • TPC like detector: |α| < 0.5 use local frame fit. It is about 90% of all tracks; • TPC like detector: |α| > 0.5 use DCA frame fit. • Not a TPC like detector: use DCA frame fit. StarSoft local

  25. The role of alignment We see, that for fit, we need only: • To know the space position of the hits; • Hit errors. These errors are calculated from hit plane orientation and predicted track parameters; Hit plane position is not used at all. Hit errors are proportional to 1/cos(α). So for small α to know precise orientation of hit plane is not too important. Some inaccuracy arise only for |α| > 1. But even here it is not dangerous. Even completely wrong errors do not lead to the shifted estimate. Only estimation error are increased in this case. So some inaccuracy in the hit errors is not too critical. Precise alignment of hit planes is not important for fit. StarSoft local

  26. The role of alignment(2) The correct geometry description is important for accounting energy loss and multiple scattering. We see it Sti, which does not work properly for UPC, due to wrong Sti geometry. In the same time alignment of dead material volumes also not important. The correct, “ideal” geometry is absolutely enough for the material accounting. Precise Geometry alignment is not important for reconstruction. StarSoft local

  27. What is already done(Old) • StEvent StHit iterator; • TGeoVolume iterator; • StiTGeo helper class; • Multi key (2 & 3) sorted container. 3 key global hit container used in seed finder. 2 key hit container in each hit plane. • SeedFinder based on 3 key sorted container. • Helix derivatives matrix • StiNavigate is ready. • Multiple scattering and energy loss accounting implemented and working also for geometry comparison. StarSoft local

  28. What is already done(Now) • StiHitLoader, no dependency of detectors ; • StiDefault Seed Finder. Now tuned for TPC but only tuned; • StiGeometryLoader, with no detector dependency; • Propagation thru TGeo using TGeant3 + derivatives and errors • HitErrorCalculator with two modes: • Standard detector plane errors • DCA plane errors StarSoft local

  29. StiHitLoader Loading of hits is made maximally independent of hit nature and origin. To add into StiVmc new detector there is no need to modify even one line of code. No more StiSsd, StiSvt, StiTpc, StiRnD and StiXXX classes. StiHitLoader does the following: • Iterate via StEventHitIteriterator; • Adds it to StTGeoHelper object; • StTGeoHelper searches according StHitPlane in StHitPlane map container by StHit hardware position. • If not found, search volume it in TGeoManager by x,y,z. • If not found, hit ignored; • Get volume id and get according StHitPlaneInfo; • Get StHitPlane by path and save it into StHitPlane map. : StarSoft local

  30. Seeds + all hits : StarSoft local

  31. Unused hits • . : StarSoft local

  32. Geant track propagation : StarSoft local

  33. What is needed to be done • StiTrackFinder (copy & paste from old Sti); • StiTrackFitter (copy & paste from old Sti); • StiRefit (copy & paste from old Sti); • Total reshape. When: with free hands, beginning of June. But free hands is impossible, so +1 month. : StarSoft local

  34. Fitted tracks propagation : StarSoft local

  35. Status Jul 2010 To avoid clashes with Sti new Sti is renamed to Stv. Now alpha version of Stv is ready. What is included? • Hit loader; • Seed Finder; • Track finder , based on Kalman fitter/filter; • Vertex finder (not PPV); • StEvent filler; • Pull filler What is not: • No backward track finder; • No smoother or refit; • No primary track fitter; StarSoft local

  36. Comparison and testing Right now real comparison is not possible yet. It is related to new hit error model. Before testing, we must obtain hit error parameters. For Sti StiFiterr application is used. There is no such application for Stv yet. During this week I hope the new StvFitErr will be ready. Then the end of Jul and Aug I will perform the testing and comparison. In parallel all the “NO” points above will be implemented. If above will be successful, in September, the massive testing will be performed StarSoft local

  37. Local Y pull distribution StarSoft local

  38. lZPull StarSoft local

  39. lYHit StarSoft local

  40. lZHit StarSoft local

  41. Status Nov 2010 Geometry loader: • Loads TGeo geometry. Automatically recognize sensitive volumes, their orientations, positions. Creates structures to support hits Hit Loader: • Loads hits. Automatically recognition to which volume each hit belongs. No need for RND developer to create specific software for each version of detector. Geant geometry is enough. Seed finder & Track reconstruction is ready. Track smoother or refit is ready; Primary track assignment and fitting in process. Right now is mainly tuning and testing StarSoft local

  42. Fitted tracks propagation : StarSoft local

  43. Unused hits • . : StarSoft local

  44. Status Feb 2011 Alpha version is finished. Now testing. For test was selected file st_physics_10169042_raw_4030001.daq First 10000 events was used. Sti has 260 good globals per event. Stv 349. 34% more Sti has 10 good primary per event. Stv 17. 70% more Sti has 4% primaries per global. Stv 5% Sti 28 hits per global. Stv 21. Stv 25% less Sti 32 hits per Primary. Stv 22. Stv 32% less (???) Sti Dca00, DcaXY & DcaZ are much worse then Stv ones(???) StarSoft local

  45. Sti/Stv: good globals & primaries StarSoft local

  46. Sti/Stv: Hits globals & primaries . StarSoft local

  47. Sti/Stv: Dca globals of primaries . StarSoft local

  48. Status Feb 2011. Discussion Sti has more globals but less hits per global. Why? Let us count total amount of global hits. Sti = 260*28 = 7280 Stv= 349*22 = 7678. It looks like Sti steals hits from other tracks. Then these robbed tracks became bad (<15 hits) Now the same for primaries: Sti=10*32 = 320 Stv=17*22 = 374. The previous guess works here as well Now why Dca’s for Sti are such bad? The same explanation fits. Wrong hits stolen by Sti deteriorate Dca’s Of course, it is only guess. StarSoft local

  49. Status Nov 2012. Problems: • Fixing wrong pulls; • Shortage of short tracks (nHits<15); • K-Nearest Neighbor seed finder StarSoft local

  50. Fixing wrong pulls In current case pulls are the difference between fitted parameter and simulated one, divided by fitted error. If everything is correct, this value should be distributed around zero with width =1. We had something different. See pulls for Sti and Stv on the next page StarSoft local

More Related