search

cms-patatrack / pixeltrack-standalone

Standalone Patatrack pixel tracking
Apache License 2.0
17 stars 35 forks source link

rename "Alpaka" to "Heterogeneous" #278

Open fwyzard opened 2 years ago

fwyzard commented 2 years ago

After merging the open PRs, I would propose to rename classes/structs/usings from Alpaka to Heterogeneous:

BeamSpotAlpaka
BeamSpotToAlpaka
CAHitNtupletAlpaka
PixelTrackAlpaka
PixelTrackSoAFromAlpaka
PixelVertexProducerAlpaka
PixelVertexSoAFromAlpaka
SiPixelClustersAlpaka
SiPixelDigiErrorsAlpaka
SiPixelDigisAlpaka
SiPixelRecHitAlpaka
TrackingRecHit2DAlpaka
ZVertexAlpaka

Or maybe Portable ?

fwyzard commented 2 years ago

@makortel what do you think ?

makortel commented 2 years ago

I'm going to think out loud separately the data formats

BeamSpotAlpaka
PixelTrackAlpaka
SiPixelClustersAlpaka
SiPixelDigiErrorsAlpaka
SiPixelDigisAlpaka
SiPixelRecHitAlpaka
TrackingRecHit2DAlpaka
ZVertexAlpaka

and modules

BeamSpotToAlpaka
CAHitNtupletAlpaka
PixelTrackSoAFromAlpaka
PixelVertexProducerAlpaka
PixelVertexSoAFromAlpaka

For data formats the Alpaka postfix would certainly become misleading, because they should become generic-enough to not have a direct dependence on Alpaka. I would maybe try to emphasize their SoA nature.

For modules, the Alpaka postfix is not technically needed because the classes go to Alpaka-specific namespaces anyway. In light of possibly using some other portability technology later, having a generic postfix could be easier ("could avoid configuration changes") or more confusing ("e.g. during migration period half of the modules in a job use Alpaka and other half use something else leading the two sub-DAGs to not talk to each other via device memory"). I suppose I don't have a strong preference to either way.

On Heterogeneous vs. Portable I find the latter more clear, because we seem to be (currently) aiming for portable modules that do all/majority of their work on one "device" (except for the interaction with the framework, launching the work, etc) rather than trying to orchestrate their work to be run on many "devices" concurrently. (i.e. something along "while the full application would be heterogeneous, the modules are portable")

fwyzard commented 2 years ago

On Heterogeneous vs. Portable I find the latter more clear [...]

... and easier to spell :-)

fwyzard commented 2 years ago

For data formats the Alpaka postfix would certainly become misleading, because they should become generic-enough to not have a direct dependence on Alpaka. I would maybe try to emphasize their SoA nature.

Here is a breakdown of what we currently have in pixeltrack-standalone:

BeamSpotAlpaka

SiPixelDigisAlpaka

SiPixelDigiErrorsAlpaka

SiPixelClustersAlpaka

TrackingRecHit2DAlpaka

PixelTrackAlpaka

ZVertexAlpaka

Looks like migrating to a common approach should be quite high on our TO DO list :-(

fwyzard commented 2 years ago

For modules, the Alpaka postfix is not technically needed because the classes go to Alpaka-specific namespaces anyway.

I didn't realise at first, but there are two set of modules that may need different naming scheme:

CAHitNtupletAlpaka
SiPixelRecHitAlpaka
PixelVertexProducerAlpaka

could easily become

PortableCAHitNtuplet[Producer]
PortableSiPixelRecHit[Producer]
PortablePixelVertexProducer

I'm a bit less sure about

BeamSpotToAlpaka
PixelTrackSoAFromAlpaka
PixelVertexSoAFromAlpaka

becoming

BeamSpotToPortable
PixelTrackSoAFromPortable
PixelVertexSoAFromPortable

But I think this ties into the other point on how the data structures should be organised.