Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add LST and LSTCore #30

Draft
wants to merge 847 commits into
base: master
Choose a base branch
from

Conversation

ariostas
Copy link
Member

Here's a draft of the LSTCore package, but now using real files. Here are some notes about it.

  • The data directory is temporary and should be removed before we submit the PR to the main CMSSW repo. We should get started populating RecoTracker-LSTCore.
  • I added a standalone directory, following Slava's suggestion. I adapted the scripts so that you can compile and run as before. One important thing to note is that you need to run setup.sh right before compiling/running (we can make it more seamless later).
  • I made the LSTCore commit be co-authored by all contributors to TrackLooper so that we all can get some credit once it goes into CMSSW.

I tested running both standalone and CMSSW, and everything seems fine.

@ariostas
Copy link
Member Author

This is a replacement of #29. This is still a draft since it includes all the data files, which should be removed. There's also many files that were added just for the standalone part, and I'm not sure if that's fine.

@VourMa
Copy link
Collaborator

VourMa commented May 29, 2024

Will check it out tonight and maybe test it and report back. Thanks!

@slava77
Copy link

slava77 commented May 29, 2024

The data directory is temporary and should be removed before we submit the PR to the main CMSSW repo. We should get started populating RecoTracker-LSTCore.

these will likely trigger an issue of increasing the git repo by too much and will need to be removed from the git history.

Is it a matter of getting CI to know where to take the data files?
We could already populate the master in a fork of cms-data in https://github.com/SegmentLinking/RecoTracker-LSTCore and just have the CI do git clone https://github.com/SegmentLinking/RecoTracker-LSTCore.git $CMSSW_BASE/src/RecoTracker/LSTCore/data

@ariostas ariostas force-pushed the CMSSW_14_1_0_pre3_LST_X_LSTCore_realfiles branch 2 times, most recently from f173c6b to 8ced0f1 Compare May 29, 2024 18:41
@ariostas
Copy link
Member Author

these will likely trigger an issue of increasing the git repo by too much and will need to be removed from the git history.

Yeah, I removed them from the git history

Is it a matter of getting CI to know where to take the data files?

Yeah, I'll do that. Thanks!

Copy link
Collaborator

@VourMa VourMa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I foresee a comment at the review about the many commits with "invalid states", e.g. when the LST was included as an external package, something that was/will never be useful for CMSSW. Based on this, shall we squash the commits? Maybe two commits would make sense, the one that Added LSTCore and one with the rest of the commits in the cmssw repo.

RecoTracker/FinalTrackSelectors/plugins/TrackListMerger.cc Outdated Show resolved Hide resolved
RecoTracker/LST/src/alpaka/ES_ModulesDev.cc Outdated Show resolved Hide resolved
RecoTracker/LST/test/LSTAlpakaTester.py Outdated Show resolved Hide resolved
RecoTracker/LST/test/LSTInputTester.py Outdated Show resolved Hide resolved
RecoTracker/LSTCore/README.md Outdated Show resolved Hide resolved
RecoTracker/LSTCore/interface/alpaka/Constants.h Outdated Show resolved Hide resolved
RecoTracker/LSTCore/src/alpaka/Triplet.h Outdated Show resolved Hide resolved
else
export SCRAM_ARCH=el8_amd64_gcc12
fi
export CMSSW_VERSION=CMSSW_14_1_0_pre3
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this ok if we leave it like that? Maybe we should just grab the version of CMSSW we have set up?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's a standalone setup, somewhat tuned to available input file formats and other dependencies (like a test file format).

Also, aren't the following lines (from cmsrel) implying that the version is not known otherwise?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should have a better setup script. I only made the minimal modifications to get it to work.

@VourMa
Copy link
Collaborator

VourMa commented May 30, 2024

I also tried the standalone version within CMSSW. It compiles fine but it doesn't run because:

ERROR: Could not find the file = "/home/users/evourlio/LSTinCMSSW/movingFullyToCMSSW/CMSSW_14_1_0_pre3/src/RecoTracker/LSTCore/standalone/..//data/OT800_IT615_pt0.8/endcap_orientation.bin"

I guess this is because data files were removed from the history. Are there changes pending for things to work? Or is there some manual intervention required, like I need to clone the data files with an extra command? I see that this is still empty, so I can just push the data folder structure there? I noticed that Andres has already created an initial branch there, that is filled with data.

@slava77
Copy link

slava77 commented May 30, 2024

I also tried the standalone version within CMSSW. ...

we should probably decide what "standalone" would actually mean:

  • a setup that can compile and run sdl_cuda and such while also being able to run a cmsRun
  • or something more "restrictive" (with lower dependency stack) using a sparse checkout where only the libsdl_* and sdl_* bins are compiled and can run.

I guess this is because data files were removed from the history. Are there changes pending for things to work?

That's a bit related to the above:

  • if the standalone will operate inside CMSSW, we can default to what will be visible in $CMSSW_RELEASE_BASE/external/el8_amd64_gcc12/data/RecoTracker/LSTCore/data
  • or assume some local checkout path; in this case the LST_BASE environment will need to be set

@slava77
Copy link

slava77 commented May 30, 2024

  • we can default to what will be visible in $CMSSW_RELEASE_BASE/external/el8_amd64_gcc12/data/RecoTracker/LSTCore/data

and if that path is not available, to add a git clone/checkout from https://github.com/SegmentLinking/RecoTracker-LSTCore

@VourMa
Copy link
Collaborator

VourMa commented May 31, 2024

we should probably decide what "standalone" would actually mean:

  • a setup that can compile and run sdl_cuda and such while also being able to run a cmsRun
  • or something more "restrictive" (with lower dependency stack) using a sparse checkout where only the libsdl_* and sdl_* bins are compiled and can run.

In principle both can work with small changes to the current state of the code, I believe.

For the first case, all we need is to modify:

std::string trackLooperDir() {
const char* path_lst_base = std::getenv("LST_BASE");
const char* path_tracklooperdir = std::getenv("TRACKLOOPERDIR");
std::string path_str;
if (path_lst_base != nullptr) {
path_str = path_lst_base;
} else if (path_tracklooperdir != nullptr) {
path_str = path_tracklooperdir;
path_str += "/../";
} else {
// FIXME: temporary solution, will need to pass a value from FileInPath or CMSSW search path
// in the `LSTProducer` or a related ES producer
path_str = std::getenv("CMSSW_BASE");
path_str += "/src/RecoTracker/LSTCore";
}
return path_str;
}

to point to a different directory according to your comment:

and if that path is not available, to add a git clone/checkout from https://github.com/SegmentLinking/RecoTracker-LSTCore

For the second case, I did:

git clone --filter=blob:none --no-checkout --depth 1 --sparse --branch CMSSW_14_1_0_pre3_LST_X_LSTCore_realfiles https://github.com/SegmentLinking/cmssw.git
cd cmssw/
git sparse-checkout add HeterogeneousCore/AlpakaInterface RecoTracker/LSTCore
git checkout

Given the absence of the $CMSSW_RELEASE_BASE/external/el8_amd64_gcc12/data/RecoTracker/LSTCore/data directory, I did:

cd RecoTracker/LSTCore
git clone git@github.com:SegmentLinking/RecoTracker-LSTCore.git data
cd data
git fetch origin initial
git checkout initial
cd ../../..

Then, the include directories are a bit off, because there is no proper $CMSSW_BASE. I fixed this by including -I../../.. or -I../../../.. in the Makefile and SDL/Makefile respectively. Doing so, I managed to run everything.
Of course, this was a "hack" at this stage. The proper solution to me would be to add a compilation flag to disable the LST_IS_CMSSW_PACKAGE flag, and change lines like:

#else
#include "Constants.h"
#include "Module.h"
#endif

to point to the appropriate directories, as these lines are useless right now, if also the standalone is in CMSSW.

UPDATE:

As of 6025567, the fix of the Makefiles has been applied, so the standalone package can be used without manual interventions.

@@ -0,0 +1,157 @@
#ifndef Constants_cuh
#define Constants_cuh
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will need compliant header guards; not sure it's an ovekill to do them with #ifdef LST_IS_CMSSW_PACKAGE;
otherwise

Suggested change
#define Constants_cuh
#define RecoTracker_LSTCore_alpaka_Constants_cuh

@@ -0,0 +1,7007 @@
#include "trktree.h"
trktree trk;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this auto-generated?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sgnoohc Perhaps you know/remember?

RecoTracker/LST/test/LSTAlpakaTester.py Outdated Show resolved Hide resolved
RecoTracker/LSTCore/interface/alpaka/Constants.h Outdated Show resolved Hide resolved
else
export SCRAM_ARCH=el8_amd64_gcc12
fi
export CMSSW_VERSION=CMSSW_14_1_0_pre3
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's a standalone setup, somewhat tuned to available input file formats and other dependencies (like a test file format).

Also, aren't the following lines (from cmsrel) implying that the version is not known otherwise?

float drt_InSeg = rtMid - rtIn;
float dz_InSeg = zMid - zIn;
float dr3_InSeg =
alpaka::math::sqrt(acc, rtMid * rtMid + zMid * zMid) - alpaka::math::sqrt(acc, rtIn * rtIn + zIn + zIn);
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

todo: pick up the update from SegmentLinking/TrackLooper#407

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in #44.

@ariostas
Copy link
Member Author

I foresee a comment at the review about the many commits with "invalid states"

Yeah, I think it makes sense to squash commits further. Let's also resolve all the discussions here by adding more commits to this branch and once it's in good shape we'll squash everything into 1-2 commits.

@ariostas
Copy link
Member Author

Here's a new branch with squashed commits. I can change the branch name and/or commit messages if you prefer.

https://github.com/SegmentLinking/cmssw/tree/LST_and_LSTCore

@VourMa
Copy link
Collaborator

VourMa commented May 31, 2024

Here's a new branch with squashed commits. I can change the branch name and/or commit messages if you prefer.

https://github.com/SegmentLinking/cmssw/tree/LST_and_LSTCore

Seems good to me. Should we force-push those commits in this branch, so that we can keep track of the discussions that we have already started here?

@ariostas
Copy link
Member Author

Should we force-push those commits in this branch, so that we can keep track of the discussions that we have already started here?

Yeah, sounds good. I wasn't sure about that so I made a separate one to be safe, but let's just stick with this branch for discussions.

@ariostas ariostas force-pushed the CMSSW_14_1_0_pre3_LST_X_LSTCore_realfiles branch from 83cc530 to 891eb11 Compare May 31, 2024 18:41
@ariostas
Copy link
Member Author

There are lots of changes after the force-push, but that's just because I re-synced with upstream master.

@slava77
Copy link

slava77 commented May 31, 2024

There are lots of changes after the force-push, but that's just because I re-synced with upstream master.

the actual diffs in the https://github.com/SegmentLinking/cmssw/pull/30/files look OK.

@ariostas
Copy link
Member Author

Should we close this PR now? It seems like it's no longer needed for discussions.

@VourMa
Copy link
Collaborator

VourMa commented Jun 13, 2024

Should we close this PR now? It seems like it's no longer needed for discussions.

I think that the point of this PR is to mirror the ones in CMSSW master, so that when the central one is merged, this is also merged automatically. At least that's what I had understood based on the mkFit model of development.

@slava77
Copy link

slava77 commented Jun 13, 2024

I think that the point of this PR is to mirror the ones in CMSSW master, so that when the central one is merged, this is also merged automatically. At least that's what I had understood based on the mkFit model of development.

yes, that's the idea.
In addition, it's a convenient place to have aside discussion about changes there.

Also, being able to run our CI here would also be helpful; although the comparisons would have to be with an earlier version of itself; so, perhaps more complicated. Would it be possible to at least run the linter part?

@VourMa
Copy link
Collaborator

VourMa commented Jun 28, 2024

Should I sync the SegmentLinking/cmssw master to the cms-sw/cmssw master? I guess that would allow us to see the conflicts also here?

cmsbuild and others added 30 commits September 10, 2024 09:18
fix `SiStripBadStrip_PayloadInspector` after merging of cms-sw#45795
Updated cms::Exception using modern C++
[DQM] Changes suggested by new llvm18 clang-format
…ang-format

[ALCA-UPGRADE] Changes suggested by new llvm18 clang-format
[Phase 2 L1T] fixing ASAN errors in Phase2L1CaloJetEmulator
Phase2-hgx360A Modify the V19 longitudinal structure of HGCal according to Meeting specification of 06/09/2024
rename modifier `run3_2024_L1T` to `stage2L1Trigger_2024`
Additional tracks filter for vertices (minimum no. strip hits)
Phase-2 GT interface update and slice test pattern writers
…g-format

[ALCA-DB-L1] Changes suggested by new llvm18 clang-format
Fix mismatch between EB and EE recHits in Phase2 supercluster producer configs
…atch

Better exception message if module label in ESInputTag doesn't match
…ormat

[ALCA-L1] Changes suggested by new llvm18 clang-format
Add 2024 HI eras to reco processing configuation
…TCore_realfiles_batch6

Batch 6 for updates to LST integration in cms-sw
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.