@sawenzel, @qgp , @shahor02 , @mconcas, @davidrohr

Some additional comments.

1. The code of this PR isolated by the ENABLE_UPGRADES. Thus CMakeFiles.txt for the GPU library gained duplicated entries to include EC0Tracking library accordingly. Which I am not satisfied and surely David will not like it as well. I wonder if we should find a way to encapsulate the upgrades in a way that does not mess with GPU CMakeFiles. Perhaps a library that is basically empty when ENABLE_UPGRADES=OFF?

2. Detectors/Upgrades will host Detectors that will actually not be running together. With the addition of PostLS4 detectors in O2, this directory will host detectors for ALICE 2.1 (IT3) and ALICE 3.0 (assuming the naming scheme proposed by Jochen). Although I suggested above to join the IT3 and PostEndCaps endcaps to take advantage of the ITS/MFT common templated structure, it may also make sense so separate different versions of the ALICE detector by distinct compiler options. I.e. instead of the single ENABLE_UPGRADES, say ENABLE_ALICE2.1 and ENABLE_ALICE3.0?

Hi @rpezzi, one general question: do we really need to replicate the whole ITSMFT directory tree right now?
Especially for what concern ITS code I'd prefer to duplicate->mutate only the required parts, like I was doing for the IT3.

Both for ITS3 and subsequents developments of ITS, at least, I will add, time by time, only code that

• works and is needed in the context of the upgrade
• is required to be kept separate from the rest of the production code base
• is not related to GPU: it is not and will not be ready in the near future

In general, IMHO, a bottom-up approach where the code for the upgrade is developed and implemented upon requirement would keep minimal number of files that are really needed.

Concerning the approach for enabling specific configurations of detectors, as long as every detector is represented by its own libraries, its usage is anyways driven at runtime or in other pieces of code that are specialised to work in a certain configuration.
Therefore, for the time being I think that being granular (many small libraries whenever needed) and linear (not forward-porting and replicating with evident reasons entire trees) should be the most efficient option, also from a development perspective.

This is my take, let me know if I overlooked something.

Cheers,
Matteo

Hi @mconcas ,
thanks for the feedback. Indeed there is a lot to prune here. The GPU part I ported in preparation for its use by MFT and should not find its way to the Upgrade directory. All the rest I ported to ensure functional full simulation and reconstruction of the new detector while I am not able to decide what is really needed. Well... that's why this is a draft WIP PR.

I am not sure is if the templates for the common ITSMFT should be used for the PostLS4 detector. Anyway, I will not put any effort in removing the existing namespace hierarchy and templates to let other detectors use it if necessary. I will rename the namespaces to let it open to the central barrel upgrade decide whether to use or not to use it. My take: itsmft -> alice3; its -> ec0.

Thanks again for the feedback,
Rafael

This PR did not have any update in the last 30 days. Is it still needed? Unless further action in will be closed in 5 days.