Instructions for how to prepare CMS documents (papers, notes etc):
Before the migration to GitLab, the CMS document repository URL looks like:
After the migration to GitLab, the CMS document repository URL looks like:
One of the lines in The Zen of Python says “There should be one — and preferably only one — obvious way to do it”. But there are more than 10 different ways to set up virtual environments in Python, some of them no longer applicable for Python 3. This Red Hat Developer blog explains the best practices for working with pip and venv: https://developers.redhat.com/blog/2018/08/13/install-python3-rhel/.
From the TL;DR section:
$ mkdir ~/pydev
$ cd ~/pydev
$ python3 -m venv py36-venv
$ source py36-venv/bin/activate
(py36-venv) $ python3 -m pip install ...some modules...
Note that venv is preferred to virtualenv in Python 3 (as explained here). Also, virtual environments are preferred to pip --user (as explained here).
The various Phase-2 geometry descriptions are documented in Configuration/Geometry/README.md.
Available RelVal workflows for all geometries can be found by doing runTheMatrix.py -w upgrade -n. (The possible -w arguments are listed in Configuration/PyReleaseValidation/python/).
Related to this, the various pileup scenarios are detailed in Configuration/StandardSequences/python/Mixing.py. The ‘auto’ conditions are detailed in Configuration/AlCa/python/autoCond.py. The ‘era’ parameters are detailed in Configuration/StandardSequences/python/Eras.py.
For Phase-2 L1T Upgrade TDR studies, I used geometry Extended2023D41, era Phase2C8_timing_layer_bar, beamspot HLLHC14TeV, conditions auto:phase2_realistic, pileup AVE_200_BX_25ns.
When you fork a repository on GitHub, you get a copy of the upstream repository. But the forked repository doesn’t receive future updates from the upstream repository. You would have to do that manually. GitHub has some useful help pages:
Suppose you start by forking a repo, and git clone from the forked repo (as opposed to the upstream repo). If you do git remote -v in your working area, you should see something like:
git remote -v
# origin git@github.com:YOUR_USERNAME/YOUR_FORK (fetch)
# origin git@github.com:YOUR_USERNAME/YOUR_FORK (push)
Now, you want to add the upstream as a new remote:
git remote add upstream git@github.com:ORIGINAL_OWNER/ORIGINAL_REPOSITORY
To verify that you have added it successfully, you can do git remote -v again.
Suppose the branch you want to update is the ‘master’ branch. In your working area, the master branch is pointing to the fork remote, not to the upstream remote. This can be confusing. To avoid the confusion, I suggest to rename the existing master branch into something else:
git branch -m YOUR_BRANCH
To verify that you have renamed it successfully, you can do git branch.
Push this branch to the fork remote:
git push -u origin YOUR_BRANCH
Then, check out the master branch from the upstream remote. From now on, the master branch is pointing to the upstream remote:
git fetch upstream
git checkout -t upstream/master
Push this recreated master branch to your fork remote, overwriting what is currently there:
git push --force origin master
In the future, to receive updates from the upstream master branch, and apply those updates to your local repo and your fork repo:
# Pull from upstream, but push to origin (a.k.a. fork)
git checkout master
git pull
git push origin master