Skip to Content.
Sympa Menu

sphenix-tracking-l - Re: [Sphenix-tracking-l] Need to update software and macros

sphenix-tracking-l AT lists.bnl.gov

Subject: sPHENIX tracking discussion

List archive

Chronological Thread  
  • From: Anthony Frawley <afrawley AT fsu.edu>
  • To: Alex Lebedev <lebedev AT iastate.edu>
  • Cc: "sphenix-tracking-l AT lists.bnl.gov" <sphenix-tracking-l AT lists.bnl.gov>
  • Subject: Re: [Sphenix-tracking-l] Need to update software and macros
  • Date: Tue, 12 Jul 2022 23:46:41 +0000

Hi Sasha,

The way that cluster keys are stored for tracks has changed with the new seeding scheme. The track is now composed of two track seeds that keep their own list of clusters, and the track has pointers to the track seeds. To get the clusters you have to do something like this:


        std::vector<TrkrDefs::cluskey> clusters;
        auto siseed = track->get_silicon_seed();
        for (auto iter = siseed->begin_cluster_keys();
             iter != siseed->end_cluster_keys();
             ++iter)
          {
            TrkrDefs::cluskey cluster_key = *iter;
            clusters.push_back(cluster_key);
          }
        auto tpcseed = track->get_tpc_seed();
        for (auto iter = tpcseed->begin_cluster_keys();
             iter != tpcseed->end_cluster_keys();
             ++iter)
          {
            TrkrDefs::cluskey cluster_key = *iter;
            clusters.push_back(cluster_key);
          }

I am not sure about the association with the CEMC, I have emailed Joe about it.

Tony

From: Alex Lebedev <lebedev AT iastate.edu>
Sent: Tuesday, July 12, 2022 6:46 PM
To: Anthony Frawley <afrawley AT fsu.edu>
Cc: sphenix-tracking-l AT lists.bnl.gov <sphenix-tracking-l AT lists.bnl.gov>
Subject: Re: [Sphenix-tracking-l] Need to update software and macros
 
Hi Tony, everyone,
I've updated my macros and generated some Pythia6 events with Upsilons. 
But there seems to be something wrong with tracking.

I can clearly see reconstructed electron/positron tracks from Upsilons (they make 
correct invariant mass together), but E/p ratios for them are less than 0.1.
This is true for booth CEMC cluster energy and 3x3 energy around track projection.
Has someone checked that recently? It used to work a few weeks ago.

Also, When I look at number of hits in mvtx and tpc like this:

    int nmvtx = 0; int nintt = 0; int ntpc = 0;
    for (SvtxTrack::ConstClusterKeyIter iter = track->begin_cluster_keys();
                                        iter != track->end_cluster_keys(); ++iter)
    {
      TrkrDefs::cluskey cluster_key = *iter;
      int trackerid = TrkrDefs::getTrkrId(cluster_key);
      if(trackerid==0) nmvtx++;
      if(trackerid==1) nintt++;
      if(trackerid==2) ntpc++;
    }

I get zero number of mvtx and tpc hits.

Can someone check this?

Sasha.

P.S. The macro I run is
/sphenix/user/sphnxpro/embed_new/Fun4All_G4_sPHENIX_pythiaupsilons.C


On Wed, Jul 6, 2022 at 10:45 AM Anthony Frawley via sPHENIX-tracking-l <sphenix-tracking-l AT lists.bnl.gov> wrote:
Hi All,

This is a heads-up for trackers.

Chris has just merged coresoftware PR#1555 and macros PR#529. These modify the TPC clustering to use (and store in the cluster) arrival time instead of z as the local coordinate.  That is how the real data will be handled. The details of converting time to global z value are all handled internally by the ActsGeometry class. That change required that the TpcDefs class be moved from packages/tpc to packages/trackbase, since ActsGeometry needs to get the side from the cluster key. You will need to update your coresoftware and rebuild, or your tracking code will break. Also update your macros area to get changes to G4_TPC.C, G4_Tracking.C, and G4_Input.C.

Conversion of TPC cluster time to z position needs the drift velocity. I decided to make ActGeometry the keeper of the (reconstruction, see below) drift velocity, and have any module that needs it request it from ActsGeometry. This is to avoid having the drift velocity be defined in multiple places. The only exception is the utility class tpc/TpcClusterZCrossingCorrection, where I have not yet figured out how to get the (static) drift velocity from ActsGeometry, so it is set from the macro.

When we have data, the drift velocity used in reconstruction will be determined from the data and will not be the same as the one we use in simulations. Following PR#529, the TPC macro defines different drift velocities for the simulations and reconstruction modules. Currently they are set at 8 cm/ns for both, but they can be specified independently in the macro.

 Cheers
Tony

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



Archive powered by MHonArc 2.6.24.

Top of Page