sPHENIX tracking discussion

["Osborn, Joe" <osbornjd AT ornl.gov>]

Hi Christof,

> Btw. does ACTS insist to store the field as a map internally or could we replace the map lookup with a function lookup?

Right now it is stored internally. The map is accessed with a lookup function but I suspect it would require nontrivial changes to the Acts code to change this (i.e. I don't get the sense from discussions with Andi that it would be as simple as a function call swap).

> Sure. That would help. I can already point you to my first attempt at a Track Seed class. Check /phenix/u/bogui/data/GitErrPara/coresoftware/offline/packages/trackbase_historic/SvtxTrackSeed.h

> Not much more than a suggestion for the time being, but maybe a start. 

I already have something this morning, I will make a PR when I have the object and corresponding SeedMap(Vector?) finished so that we can have comment/discussion on github before I go change all the corresponding seed code.

Joe

---------------------------

Joe Osborn, Ph.D.

Associate Research Scientist

Oak Ridge National Laboratory

osbornjd AT ornl.gov

(859)-433-8738

---

From: Christof Roland <christof.roland AT cern.ch>
Sent: Wednesday, April 6, 2022 10:28 AM
To: Osborn, Joe <osbornjd AT ornl.gov>
Cc: Hugo Pereira Da Costa via sPHENIX-tracking-l <sphenix-tracking-l AT lists.bnl.gov>
Subject: Re: [EXTERNAL] [Sphenix-tracking-l] roadmap and todo list for memory reduction

 

Hi Joe, 

On 6. Apr 2022, at 14:02, Osborn, Joe <osbornjd AT ornl.gov> wrote:

Hi Christof,

Thanks for the slides, this is a helpful summary of our discussion on Monday. A few scattered thoughts below:

It looks like the most "invasive" change will be moving the clusterkey to to a short int instead of a uint64 with the indices separated by hitsetkey (or surface/detector element I assume is the intent here). We have a lot of places in the seeding where we look up cluster keys from the cluster container which will be affected by this.

Yeah, I thougt about this as well, we can leave this a one of the last changes, but I think the actual interface will stay exactly identical, even if we change the layout of the clusterkey.

I think we can pull it of with just changing a few functions/definitions in TrkDef, TpcDef and the clustercontainer.

Currently the ClusteKey is one uint32 for the clusternumber in the set and one uint32 for the hitsetkey.

We have ~1200 hitsets (physical detector elements) so a short is more than enough to address them. 

We should store them in a vector and keep the index as a short int hitsetkey to address them. 

Then we just need one or two lookup tables to tell us which index is which layer, side and sector.

For the clusternumber a short is good enough as well. We should check again, but I think we can squeeze more than 65k clusters in a given detectorplane.

the outer sectors of the TPC have  192 pad *249 tbin =  47808 pixels.

By the way, I think Acts also uses vectors over any other storage container for both speed+memory improvements. Generally their containers are accessed solely by index, so it requires careful bookkeeping but I guess this is also your suggestion for the longer term to move away from maps.

Yes, David Rohr also strongly suggested to move to vectors.

Regarding the field map, I learned that the way Acts stores the field values is simply in a vector of double value Eigen3 vectors. These are then accessed by (again, an indexed) cell value when the magnetic field element is called in e.g. the fitter. Discussing with Andi we came to the conclusion it would be a useful feature to have float vs. double option. We load the magnetic field into Acts at the very beginning of the clustering when doing the geometry building. Out of curiosity, do we know to what precision the actual magnetic field mapping will have (e.g. will it really have double precision)?

I would be severely impressed of the CERN field mapping crew had hall probes that measure with 10^-16 precision. 

floats will be more than good enough, half float might do the trick as well if permill precision is good enough. 

We have to be carefull though, if you have non monotonic or step behaviour in the field map the runge kutta integration

commonly used to do propagation in a magnetic field may become unstable. 

Btw. does ACTS insist to store the field as a map internally or could we replace the map lookup with a function lookup?

We might still use the field interpolation tool David has offered to us.

We could also see if the graularity we store the field in matches the actual gradients in the map. There are a lot of games we could play.  

I think my studies over the last couple of days indicate that we won't be able to do much better on the silicon seed purity in AuAu than what we have now, as the seeds that are produced are not obvious duplicates and as such we need to treat them as real tracklet possibilities.

This is probably to be expected.

The only other way here is to iterate. Get the silicon seeds that satisfy the tightest possible quality criteria first, match them to the TPC. 

Remove the hits of the matched seeds from the cluster container and rerun with loser criteria on reduced combinatorics.

So I can work on creating the track seed object and corresponding SvtxTrack changes since you have already been working on the cluster parameterization. 

Sure. That would help. I can already point you to my first attempt at a Track Seed class. Check 

/phenix/u/bogui/data/GitErrPara/coresoftware/offline/packages/trackbase_historic/SvtxTrackSeed.h

Not much more than a suggestion for the time being, but maybe a start. 

cheers

   Christof