LSTCore rough proposal

[ariostas]

This PR should not be merged. It is meant for illustrative/comparison purposes. If we decide to go along this path I'll make a new, cleaner PR.

Here's a proof of concept for how we could proceed with the CMSSW integration while keeping the standalone version alive. I added a RecoTracker/LSTCore package that contains the LST code. The SDL and data directories were copied over from the TrackLooper repo and the rest of the structure was set up using symlinks.

Notes:

• Instead of including the SDL and data directories in this repo, it would probably be better to include the TrackLooper repo as a git submodule.
• Minimal changes needed to be done to the RecoTracker/LST package.
• Only a single change needed to be done to LST.cc so that it doesn't use the LST_BASE environment variable.

[slava77]

I was thinking of how to move forward in view of moving our code to CMSSW repo.

This setup shows that we do not need explicit edits in the files and can have everything necessary to run in cmssw with what's in the SDL directory (file copy and renaming aside).

On one hand, on a few months time scale we will need to be in cmssw tree. Why not relocate our code there already? We don't even have a setup that doesn't depend on cvmfs and cmssw already. To keep working in a standalone setup (without cmsRun) we would just need a script that does a (sparse) checkout.

To be more specific:

• everything currently in SDL will be in LSTCore interface/ and src/ (and for the time being data/ can be in the same repo for convenience)
• everything else will be in LSTCore/standalone
• sdl_make_tracklooper , run_sdl, and Makefiles will need some adjustments, but that's relatively simple

The main downside is git-related (new history)

Something less disruptive could rely on a script that copies files to the SegmentLinking/cmssw repo from SegmentLinking/TrackLooper. Perhaps it can even be done with a CI?

[VourMa]

On the first option (relocation to CMSSW), I think that a major part in even considering it is whether CMSSW "managers" would accept such a structure. Maybe this proposal is an argument to start discussing with them sooner than later?

[slava77]

for the structure, looking at other packages (e.g. DataFormats/BeamSpot/interface/alpaka/BeamSpotDevice.h), interface/alpaka should be used for alpaka-related files needed elsewhere.

softlinks to the same files in multiple places (e.g. both in the interface and src/alpaka) better be avoided and addressed by relevant changes in the include paths.

perhaps it's practical to add/expect a LST_STANDALONE or LST_CMSSW flag and then

#ifndef LST_STANDALONE
#include "HeterogeneousCore/AlpakaInterface/interface/config.h"

namespace ALPAKA_ACCELERATOR_NAMESPACE {

to comply a bit better with the cmssw alpaka parts.

[ariostas]

I'll make some tweaks and think how we could use the CI to glue things. I'll have a prototype for the Tuesday meeting.