WIP: Proof of concept for zip-based track (after the track fit)

discussion points:

• Currently different track types are different c++ types. I'm not 100% convinced anymore this is a good idea. While views/facades/skins can hide the differences, this also hides the potential gains of dropping track type abstraction.

see also the corresponding MR in Rec

Starting to have a look at this.

My first reaction is a completely agree with you that I don't like the fact you have different types for different track types. This will massively complicate things in the reconstruction sequences (RICH, CALO etc.) after the tracking, and apriori I don't think I really see a good reason for it.

I also think, as discussed in the meeting last week, you are perhaps worrying about too much at first. For instance, as far as the usage of the tracks in the HLT2 sequence I would guess the nice 'SOA' view of the track data is probably not required, these algorithms would be better off operating directly on the underlying data containers, and just zipping together with is needed in each case as required. The SOA view is I think just a distraction here, and only really needed once we get to the user level, so after the reconstruction.

I would focus on one thing at a time, so get the basic data containers for the track data defined, and make sure these containers can be directly used by the HLT2 sequences, independently of whatever SOA like view comes later on.

what is this file for ? I don't think it should be added at the root level of the main project.

It's used to trigger a Gitlab-CI job on every commit, to trigger a Gitlab-CI job on another project, but it's pretty obscure what the other project is supposed to do... (part of the confusion comes from a copy+paste without changing variable names)

what is this file for ?

IIUC, this is a configuration file for "YouCompleteMe" (code completion for Vim and may be other editors).

It looks pretty specific (fix LCG version etc.)... it shouldn't be in the repository.

This MR is also mixing up two things that I think should be separate MRs. One is adding kernel/SOAContianer and the other is the new track event model classes. Can these two things be separated ?

One other question. How does the SOA code you add here interact with the headers already part of LHCbKernel ?

~/LHCbCMake/Feature/LHCb > ls ./Kernel/LHCbKernel/Kernel/*SOA*
./Kernel/LHCbKernel/Kernel/VectorSOAIterator.h  ./Kernel/LHCbKernel/Kernel/VectorSOAMatrixView.h  ./Kernel/LHCbKernel/Kernel/VectorSOAStore.h

We should avoid diverging things into two different places.

added 217 commits

• 6d894711...291be022 - 184 commits from branch lhcb:master
• 1e12a3d0 - rough initial commit
• 5622d264 - build fixups
• 6ba2db24 - additional states constructor
• 578b4444 - compilation failures intermediate step
• 9582e5a8 - ironing build out
• 85188808 - backwards compatibility links
• 31a4e6ea - fixups
• d6c73bee - Update AdditionalStates constructor to not rely on old Track
• ac8b1518 - consider non-long tracks
• 039aa610 - fixups
• 160592d3 - draft SOA skins
• c4d211f9 - draft constructor
• 89583e54 - soacontainer for longtracks
• 1858bec7 - include
• 158c4562 - depend on SOA
• 86db67f1 - fixup
• 4486ef19 - fixup
• 7bbc90fd - confusion about zip-skins fixed according to SOA tests
• c1317137 - port ycm fixup
• 2e5da0a1 - advice from Manuel
• 448e5709 - fixup
• 74e2b502 - CI
• dcfcc60f - triggering CI
• 5adde54e - move SOA Container to LHCb and specify project resident directories
• b6cc8084 - attempt to cover all tracks in conversion (other than velo)
• 21e8d7a8 - fixup
• f1e62925 - fixups
• e37ca512 - templating
• aead9968 - simultaneous rich pid
• c1db7a25 - fixup
• c46a54a1 - hack Event YCM
• 4585657f - adapt namespacing convention from Track v1
• cfb1d499 - rich reco example

Compare with previous version

added 1 commit

• 896d2f77 - adding copyright notice

Compare with previous version

added 1 commit

• 070f255b - copyright on SOAContainer -- NB: upstream should confirm

Compare with previous version

added 1 commit

• 0f606216 - copyright on SOAContainer -- NB: upstream should confirm

Compare with previous version

added 57 commits

• 0f606216...bfa8a134 - 22 commits from branch lhcb:master
• 852d8d96 - rough initial commit
• 43c9469c - build fixups
• ead7b5c6 - additional states constructor
• a10391fe - compilation failures intermediate step
• 8cc21303 - ironing build out
• b6740889 - backwards compatibility links
• 19db0586 - fixups
• 07320796 - Update AdditionalStates constructor to not rely on old Track
• 462dec7f - consider non-long tracks
• 05cafc28 - fixups
• 93ecb079 - draft SOA skins
• 9f972b26 - draft constructor
• c4b9e05d - soacontainer for longtracks
• 1a1d701d - include
• 34490d5f - depend on SOA
• 595b2b7b - fixup
• 4520bec9 - fixup
• ce270ada - confusion about zip-skins fixed according to SOA tests
• b2ca76a2 - port ycm fixup
• 1e2a0469 - advice from Manuel
• 04df96e6 - fixup
• 6654fb37 - CI
• a1572fef - triggering CI
• e5396f06 - move SOA Container to LHCb and specify project resident directories
• 13d8062f - attempt to cover all tracks in conversion (other than velo)
• 30ddaca6 - fixup
• bd2fe605 - fixups
• 27fba814 - templating
• 045d6523 - simultaneous rich pid
• 2eaee5b7 - fixup
• a20af551 - hack Event YCM
• 38c63388 - adapt namespacing convention from Track v1
• 1fdcc940 - rich reco example
• e3b1f14a - adding copyright notice
• 73a851a8 - copyright on SOAContainer -- NB: upstream should confirm

Compare with previous version

closed