rename "Alpaka" to "Heterogeneous"

[fwyzard]

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]

@makortel what do you think ?

[makortel]

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]

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

... and easier to spell :-)

[fwyzard]

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

• BeamSpotPOD is the basic type
• BeamSpotAlpaka is a wrapper that contains an AlpakaDeviceBuf<BeamSpotPOD>

SiPixelDigisAlpaka

• SiPixelDigisAlpaka is a SoA, and uses explicitly AlpakaDeviceBuf<T> for each column

SiPixelDigiErrorsAlpaka

• SiPixelDigiErrorsAlpaka is a SoA, and uses explicitly AlpakaDeviceBuf<T> for the data, and AlpakaDeviceBuf/AlpakaHostBuf for the SimpleVector wrapper

SiPixelClustersAlpaka

• SiPixelClustersAlpaka is a SoA, and uses explicitly AlpakaDeviceBuf<T> for each column

TrackingRecHit2DAlpaka

• TrackingRecHit2DAlpaka is a SoA, and uses explicitly AlpakaDeviceBuf<T> for each column, and AlpakaDeviceBuf/AlpakaHostBuf for the "view"

PixelTrackAlpaka

• pixelTrack::TrackSoA is the underlying SoA
• using PixelTrackAlpaka = AlpakaDeviceBuf<pixelTrack::TrackSoA>
• using PixelTrackHost = AlpakaHostBuf<pixelTrack::TrackSoA>

ZVertexAlpaka

• ZVertexSoA is a SoA
• using ZVertexAlpaka = AlpakaDeviceBuf<ZVertexSoA>
• using ZVertexHost = AlpakaHostBuf<ZVertexSoA>

---

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

[fwyzard]

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.