-- ParasNaik - 2022-01-31


FOR THE LEGACY TWiki PAGES (Run 2) , see the LHCb RICH mirrors' alignment Run 2 TWiki

RICH mirror alignment monitoring via software by the use of real data (Online, in real-time) for LHCb Run 3

Known Holidays and Changes in Work Status

  • Paras - "Unavailable" 29 Aug - 12 Sep (though will take laptop with me) ; Unavailable 12-28 Nov
  • Alex - Unavailable 18-19 Aug, 29 Aug - 3 Sep
  • Jake R - Unavailable 26 Aug - 3 Sep ; 3 Sep - 16 Sep "available" but focused on STFC summer school
  • Anatoly - no planned holidays until October
  • Jake A - Unavailable 20-27 July; after 22nd August available to help but focused on Industry placement for CDT
  • Richard - Taking ~one week off at the end of Aug or beginning of Sep ; possible other sporadic days off; decreasingly available as thesis work ramps up

  • Florian (Velo Alignment +) - Unavailable 18-22 July
  • Sophie (SciFi Alignment) - Unavailable 15-31 July

Who is doing what (generally)

  • Jake R & Jake A - Panel Alignment
  • Alex, Paras - Iterator
  • Richard, Jake A, Paras - Reconstruction (a.k.a. RichAnalyzer producing 2D histograms for alignment and 1D histograms for monitoring)
  • Jake R & Paras - Monitoring
  • Richard, Anatoly - Updated HLT line selection
  • Anatoly - Core code


History, ideas, and implementations

For all historical information see the LHCb RICH mirrors' alignment Run 2 TWiki. Full details on how the mirrors' alignment was performed in the past can also be found on the LHCb RICH mirrors' alignment Run 2 TWiki. This TWiki only contains content relevant to Run 3.

In Run 3 an effort was made to... (we'll finish this story later)

Return to the Top of this TWIki

Basic description of how the mirror alignment should work online

Provide a python Configuration

Start the steering script

This script first:

  • prepares an YAML version of the Conditions database (may have to use XML first)
  • creates a local copy of only the file(s) relevant to us --> convert to YAML if needed

Then it starts a loop, each iteration of which consists of:

  • preparing the detector conditions (convert to XML if needed) that need to be prepared in order to perform the reconstruction
  • launching a highly parallelized Moore (Run 3) job (using the HLT Event Filter Farm at the pit) running over:
    • during first iteration - RAW (a.k.a. MDF) data files from the HLT line and writing RAW output files
    • during any further iteration - the same
  • and Moore produces Δ$\theta$ vs. $\varphi$ distributions for every combination of one spherical and one flat mirror out of the list defined by the Rich/RichFutureRecMonitors/src/RichSIMDAlignment.cpp in the Rec project, that is set up and used by Moore options;

  • fitting these histograms and extract the total tilts around Y and Z axes;

  • using calculated in advance magnification coefficients (for each segment) solve a system of linear equations and obtain individual tilt of of every segment;

  • subtracting (algebraically) each tilt from the existing misalignment correction for the corresponding segment just used by Moore during reconstruction at the current iteration;

  • if all the obtained corrections to the previous misalignment corrections are (by absolute value) less than an empirically determined set of tolerances, then just exit, but if not -
    • replace the numbers in the YAML and subsequently re-create the the local copy of only the files relevant to us.
    • proceed to the next iteration of the loop.

  • If a correction of the database needs to be made, we place the final version(s) of the file(s) relevant to us in a local directory [linked by the Online team to git]. The decision should eventually be fully automatic, save several sanity checks; thus we choose when to update the DB. Thus the newest mirror alignment is always available for processing data in HLT2 (and for some analyses (Turbo), this data is then immediately ready for physics analysis!).

  • Full Online monitoring of our alignment should be available and may be used to identify any issues with the mirror alignment.

  • The constants are also eventually moved to the git CONDDB for use in an future Offline processing.

Return to the Top of this TWIki

CERN e-groups

  • Bristol-only RICH mirror alignment discussions lhcb-rich-mirror-alignment-development
    • Mailing list for software development (i.e. Bristol) only
      • Private list
    • Details of code modifications
    • Discussions of possible issues with the alignment
    • Discussions of future improvements
    • Post news of any new software releases here

  • LHCb RICH mirror alignment news lhcb-rich-mirror-alignment
    • General mirror alignment mailing list
      • lhcb-general members may ask to be added to this list
    • Advertise accomplishments
    • Discuss ongoing studies / questions that have to do with our integration into LHCb
    • Discuss any urgent issues
    • Inquiries
    • So far we haven't used this much

  • Also subscribe to the RICH Software mailing list lhcb-rich-software and perhaps also good to subscribe to the RICH mailing list lhcb-rich.

Return to the Top of this TWIki

Who's Who

  • Experts (or soon-to-be-experts) for the Run 3 Real-Time Analysis implementation of the RICH mirrors' alignment

  • Key contacts for Run 3
    • Sneha Malde & Silvia Borghi
      • Real-Time Analysis (RTA) (leader of Work Package 4: Alignment & Calibration)
    • Chris Jones
      • RICH software
    • Sajan Easo & Bartosz Malecki
      • RICH databases
    • Markus Frank, Clara Gaspar, Beat Jost
      • Online
    • Florian Reiss, Rosen Matev
    • Chris Jones, Rosen Matev
      • Moore
    • (will need to talk to all sorts of people as time goes on....)

  • Others from Bristol involved in the Run 3 Implementation
    • Jonas Rademacker & Kostas Petridis
      • Helping to maintain organization and providing support.


  • Helpful people outside of Bristol, who helped ensure the success of our Run 3 alignments (noted for thank-you purposes, and some possibly to be invited/considered as authors of our Run 3 paper)
    • OPG / Alignment
      • Silvia Gambetta
      • Silvia Borghi
      • Sneha Malde
      • Florian Riess
    • RICH
      • Chris Jones (Helped everywhere)
      • Sajan Easo
      • Bartosz Malecki
    • Online / Pit resources team
      • Beat Jost
      • Clara Gaspar
      • Markus Frank
    • HLT
      • Rosen Matev
    • Perhaps others who we did not mean to forget...

Return to the Top of this TWIki

Legacy Twikis

LHCbRichMirrorAlign (Run 2)

LHCbRichMirrorAlignLegacy (Run 1)

Incomplete List of Accomplishments for Run 3


  • Jake Reich upgraded Vidar's XML<--->YAML to handle different condition sets and names
  • Alex changed histogram names in the core code, added Rich/RichMirrCombinFit/src/rich_align_opts.inc which includes the list of mirror pairs, and converted XML to YAML in the core code.
  • Richard created the draft HLT1 line
  • Jake Amey can produce and fit 1D CK angle histograms with wide photon backgrounds, and also adjust the panel alignment


  • Alignment Histograms moved from Rich/RichAlignment to Rich/RichFutureMonitors and rewritten by Anatoly with help from Chris Jones
  • Vidar wrote an XML<--->YAML converter, and also rewrote some parts of our python scripts to handle YAML

Return to the Top of this TWIki

Status of our Software and Documentation

Which code has actually been deployed online

It is absolutely critical for us to know what code has been deployed Online in our code area `/group/rich/sw/alignment/stack/`. This should always be kept up-to-date:


NEW - Note that we now specify branch names rather than version tags... we may go back to version tags someday... Project: MooreOnline *master [ /group/rich/sw/cmtuser/AlignmentOnlineDev_v12r1 on plus ]

  • Plug-in: Rich/RichMirrorAlignmentOnline : Panoptes branch master
  • Plug-in: Rich/RichMirrCombinFit : Panoptes branch master
  • Plug-in: Rich/RichMirrAlign : Panoptes branch master
  • All other projects come from default location

We need to keep our code current. List code that needs to be upgraded here:

  • Everything

Return to the Top of this TWIki

Detailed status of code and documentation that we are responsible for

Formal Written Documentation

We'll come back to this later..., but if you need info feel free to read these notes

Run 2 Mirror Alignment Paper draft

  • Plan
    • Let's get this into a circulatable state.
    • After local comments are accounted for, we should circulate it more widely
      • This will also motivate Silvia and Roel to finish up the alignment paper, if there is going to be one
    • Account for new comments
    • Post the paper to the arXiv OR post it as a public note to CDS (following LHCb rules, of course).
  • Is someone working on the note now: YES
    • Who: Claire, Paras (in communication)
    • For what purpose: In preparation for paper draft / public note release, provide material for the Run 2 real-time alignment paper
    • For how long: Until it is done

Run 1 Mirror Alignment Internal Note (SVN instructions)

  • Newest Stable Version: Release Notes PDF (2016-01-31)
  • Is someone working on the note now: Anatoly
    • Who: N/A
    • For what purpose: N/A
    • For how long: N/A
    • What should be done: "Revert" note to Run 1-only note (leaving in updated explanations), which is complemented by the existing RICH performance paper. Run 2 improvements will all be covered in the Run 2 public note.

Run 2 Mirror Alignment Paper Draft in git

Project page: https://gitlab.cern.ch/cprouve/RichAlignmentNote2

If you want to work on this, ask Claire to make you a Developer.

All instructions are here: https://gitlab.cern.ch/cprouve/RichAlignmentNote2/blob/master/README.md

STAY IN CONTACT when working on this; though if you push and pull OFTEN things will be OK. If not, then ask Claire to sort out a merge request to bring diverging versions back in line. Once they are back in line, use the command sequence:

git fetch --all

git reset --hard origin/master

locally to sync to the current version of the repository.

Run 2 Mirror Alignment Paper Draft in SVN (DEPRECATED!)

Run 1 Mirror Alignment Internal Note in SVN

ALL involved in the nitty-gritty of the RICH mirror alignment procedure should know where to find the note. The most recent version should be kept here on the TWiki at the "Current RICH Mirror Alignment Note" link above.

To view/edit the note on lxplus, you may find the LaTeX by the following command set:

cd [to whatever directory you want to check out the note in, preferably with an identifiable name like AlignmentNote ]
svn co svn+ssh://svn.cern.ch/reps/lhcbdocs/Notes/INT/2013/007
cd 007/latest/latex
evince SoftwareMirrorAlignment.pdf &          [or pick a saved/committed version, like SoftwareMirrorAlignment _2016-01-31.pdf]

If you do edit the note, please:

  • make sure it the LaTeX compiled, hopefully with no warnings (right now there is only one, which is explained in the release notes)
  • Update 007/latest/doc/release.notes
  • Copy 007/latest/latex/SoftwareMirrorAlignment.pdf to 007/latest/latex/SoftwareMirrorAlignment_YYYY-MM-DD.pdf (where YYYY-MM-DD is the date of commit e.g. 2016-02-31)
  • Commit the changes

Figure 3 in the RICH Mirror Alignment note probably has the wrong horizontal axis label. A correct scale plot is shown in https://indico.cern.ch/event/325126/contribution/1/material/slides/0.pdf Perhaps someone can help in producing updated plots. --- i.e. this will probably never be corrected

Panoptes (https://gitlab.cern.ch/lhcb/Panoptes)

NOTE: In git the formal idea of tagging packages is GONE. We currently have an informal system based on when the release.notes for a package is updated. We should try to keep this informal versioning going... i.e. please update the release notes and "tag" new version there.

Rich/RichMirrorAlignmentOnline (Project Panoptes, plug-in to AlignmentOnline)

  • Newest Stable Version: v4r4
  • Is someone working on updates to the MASTER version now: YES
    • Who: Paras+
    • For what purpose: Preparation for Run 3
    • For how long: N/A

Rich/RichMirrCombinFit (Project Panoptes)

  • Newest Stable Version: v17r1
  • Is someone working on the MASTER version now: YES
    • Who: Anatoly+
    • For what purpose: Preparation for Run 3
    • For how long: N/A

Rich/RichMirrAlign (Project Panoptes)

  • Newest Stable Version: v20r1
  • Is someone working on the MASTER version now: YES
    • Who: Anatoly+
    • For what purpose: Preparation for Run 3
    • For how long: N/A

Rec (https://gitlab.cern.ch/lhcb/Rec)

Rich/RichFutureRecMonitors (Project Rec, plug-in to Brunel) we are fully responsible for this; others working on the RICH may use this

Moore (https://gitlab.cern.ch/lhcb/Moore)


Allen (https://gitlab.cern.ch/lhcb/Allen)


Hlt (https://gitlab.cern.ch/lhcb/Hlt)


We are responsible for our Mirrors HLT Line and the settings. We must communicate with the HLT Operations group if there is any change.

Return to the Top of this TWIki

JIRA tasks

LHCbRichMirrorAlignJIRA - outdated

LHCbRun3RichMirrAlignJIRA - not created

Instructions for how to perform various code-related tasks

You will find instructions for various important code-related tasks on our private mattermost pages (usually pinned)





However we have tried to place the most important instructions here:


HLT1 Line

The HLT1 Line for the mirror alignment is absolutely crucial to getting the photons we need, specifically reflecting in the mirror combinations that we use to perform the mirror alignment.

We use an HLT line that selects whole events, where one track has very low pseudo rapidity and very high momentum. This populates the "outer mirrors" (i.e. least-populated mirrors combinations) quickly enough to ensure the mirror alignment can be performed per run/fill (depending on the allowed rate of the HLT line), but we get many more tracks than we need this way. So, we could still reduce the number of events we need to populate the mirrors with photons by two orders of magnitude, which would make the mirror alignment lightning-quick. However, since the current processing speed was sufficient we did not do this. It could be considered for Run 3, but we will first prioritize getting our code working in the Run 3 Real-Time Analysis framework.

Richard (with help from Paras) installed the line, which is based on the one track trigger and has selection criteria from Run 2. Anatoly is currently refining the selection criteria for Run 3. People from the Allen group have been helping us with calibrating the line. Allen Developers Mattermost

Our HLT1 lines are implemented into Allen, and are called ????Hlt1CalibRICHMirror (RICH1) and ????Hlt1CalibRICHMirror (RICH2).

The lines are configured in ??? of the ??Hlt project.

ROUTING BIT ??54 provides the data to be accessible Online (i.e. written to the "local disk(s)").

More information on this dedicated TWiki: LHCbRun3RichMirrAlignHLT

Return to the Top of this TWIki

Online mirror alignment instructions

LHCbRun3RichMirrAlignRunOnline - Follow the instructions here to run the rich mirror alignment online on the HLT Event Filter Farm

  • Please set System = "Alignment" whenever posting to the ELOG
  • All new alignments should be documented on the ELOG!

LHCbRun3RichMirrAlignCodeOnline - Read this to learn about the alignment package and the online code

Training Sessions

AlignmentView (Online mirror alignment results)

Check it out, live streaming worldwide mirror alignments!


Location of the output files

Our most recent alignments are always here on plus:
Our past alignments are stored here:

Editing the AlignmentView PHP script

On 26/05/17 15:46, Michael McCann wrote:

The web pages are a bit more difficult to edit now we've moved to our own server, but not much. Thinking about it I could probably have made it identical, but I stuck with the method the admin used when he migrated us.

Anyway, all the files are hosted locally on lbrich, and in the directory /web/sites/lbrich/. The alignment php script is alignmentview.php. The machine doesn't have access to /home so some editors (like emacs) get unhappy, vim works fine though (although moans when you exit).


Each column in the table has an associated function write*Element($summary), which just writes an html table data element 'value' with a particular class and value, and returns a boolean of whether the value should be considered ok. $summary is a dictionary that contains anything in the summary text file parsed such that a line in the file "foo = bar" can be accessed $summary["foo"] = "bar" (everything as a string and external white space stripped). Basically all that's needed is to pick the class based on the value in whatever why you want.

The classes I've put in are "good", "bad", "expert", "unknown". "bad" and "expert" are identical at the moment, but are conceptually different (something definitely bad vs something to inform an expert about). "unknown" is used when the required info isn't in the summary (e.g. your old summary files don't contain all the fields).

The general form of the functions is

function writeSomeParameterElement($summary) { $style = 'unknown'; $value = $summary['Some Parameter']; if ($value) { //some code to select $style from $value, e.g if (intval($value) < 12345) $style = "good"; else $style = bad; } echo ''.$value.''; return ($style ='good'); }

but you're free to implement it however you like.

If you want to add a new column, look in the function writeAlignmentSummary($richfiles, $fills). If you want your column to appear in the autogenerated log entry, you will need to add a line of the form

$isgood['some parameter'] = writeSomeParameterElement($summary);

with the rest, where writeSomeParameterElement is a function you've written and obeys the specification above. You also need to add an element $badtext['some parameter'], of what you want written to the log if it isn't ok. For prettiness you should increment the "colspan" attribute to the summary panel a few lines below too. Don't forget to add a title to the table header.

Oh, if you make changes please run the script /group/rich/scripts/back-up.sh in the /web/sites/lbrich/ directory. It will update /group/rich/backup/lbrich/latest to reflect the changes.

Return to the Top of this TWiki

Making the trend plots manually

Trend plots are being made automatically every fill, and can be found in AlignmentView.

The automatic plots are made in the "hollow" style (points are hollow, unless an update was made during a particular fill, in which case the points are solid) and available with the LHCb fill numbers on the x-axis or the alignment date/time on the x-axis. The plots with fill numbers on the x-axis are also attached to the RICH ELOG alignment summaries.

To manually produce the trend plots do the following:

Create a new directory somewhere on plus (let's call this directory '/home/your_username/trendplots/' for now, but it could be anything)

cd into that '/home/your_username/trendplots/' directory

Then copy some files using these commands:

cp /group/rich/sw/cmtuser/AlignmentRelease/Rich/RichMirrorAlignmentOnline/python/PyMirrAlignOnline/fileFinder.py .
cp /group/rich/sw/cmtuser/AlignmentRelease/Rich/RichMirrorAlignmentOnline/python/PyMirrAlignOnline/LHCbStyle.py .
cp /group/rich/sw/cmtuser/AlignmentRelease/Rich/RichMirrorAlignmentOnline/python/PyMirrAlignOnline/tiltObj.py .
cp /group/rich/sw/cmtuser/AlignmentRelease/Rich/RichMirrorAlignmentOnline/python/PyMirrAlignOnline/trendHelper.py .

Then edit your local version of trendHelper.py and check/change these things:

  • change the startDate and the endDate for RICH1 and RICH2 to fit whatever date ranges of mirror alignments you wish to plot
  • also, in the line that looks like
self.file_name = "/home/pnaik/2018trendplots/Rich"+str(self.whichRich)+"_allin1_"+str(self.plot_type)+"_"+str(self.trend_Xaxis)+"_current.pdf"
change /home/pnaik/2018trendplots/ to your '/home/your_username/trendplots/'

Then, just run:

source /group/rich/sw/cmtuser/AlignmentRelease/setup.x86_64-centos7-gcc62-opt.vars
python trendHelper.py > out.txt

and you will see that many plots are produced.

Trend plots will be produced for both RICH1 and RICH2 in combinations of the following formats:

  • plotType
    • "hollow" - points are hollow, unless an update was made during a particular fill, in which case the points are solid
    • "default" - points are solid, if an update was made then all points collapse to the zero line
  • trendXaxis
    • "Fills" - plotted by Fill Number
    • "Dates" - plotted by Date/Time
    • "Numbers" - plotted by Alignment Number (i.e. order in self.alignments)

You can also look at out.txt for the complete printout from the plotting code (for example, if you want to know the Alignment Name corresponding to an alignment number).

Return to the Top of this TWiki

Overall Online calibration and alignment procedures (for all detector alignments)


Calibration and Alignment Procedures

First calibration and alignment procedures for 2016 restart

Return to the Top of this TWIki

What all of the settings mean (also applicable to Offline)

Check Configuration.py deep within Rich/RichMirrorAlignmentOnline for descriptions of the latest settings.

Some settings shown with example values. Note that some of the example values are strings. Please see an actual settings files for examples on actual implentations. These are just shown here to help elucidate the settings.

### workDir = /afs/cern.ch/user/p/pnaik/RichAlignment/2015/2015_R1_EM_Down_1250k_ev/

  • this is the alignment working directory, your settings file and all major output will go here

### dDDB_tag = dddb-20150703

  • together with the condDB_tag, specifies the detector conditions and alignments

### condDB_tag = cond-20150716

  • together with the dDDB_tag, specifies the detector conditions and alignments

### date = 1436546246000000000

  • this is an "epoch" date, in nanoseconds. It should fall within the range of dates of the data sample that you use for alignment. See http://www.epochconverter.com/ for more information

### localCondDB_tag =

  • we do not use this. not yet sure if this is obsolete. please leave this in the code

### setupProjectBrunelOpts =

  • options for setting up Brunel... don't need this right now

### eventSelectorInputFile = /afs/cern.ch/user/p/pnaik/ReduceRawFiles/EM/RICH1/10GeV/R1_10GeV_EM_Down.py

  • equivalent to ioHelperInputFile, this file contains the locations of the data files that we will run over to get the alignment

### LHCbVersion =

  • just use the default

### brunelVersion = v48r0

  • the Brunel version we want to use to process out data

### brunelEvtMax = 12376

  • the maximum number of events to run over per Ganga subjob. Offline, this is automatically calculated from the number of files and number of events you wish to use for alignment. See the settings file.

### brunelPrintFreq = 1000

  • frequency for printouts

### brunelInitialInputType = RAW

  • Type of data we are running over

### messageSvcOutputLevel = 3

  • standard, don't touch

### splitFilesPerJob = 5

  • Number of files per subjob. Offline, this is automatically calculated from the number of files you wish to use for alignment. See the settings file.

### splitMaxFiles = 99999999

  • standard, don't touch

### backEnd = dirac

  • standard, don't touch

### diracCPUTime = 100000

  • standard, don't touch

### mirrCombinSubset = Rich1CombAndMirrSubsets _20m16c_p0p1p2p3fix.txt

  • This is chosen automatically depending on richDetector. It defines the mirrors that are used in the alignment procedure.

### thisCase = 2015_R1_EM_Down_1250k_ev

  • A string used to identify the alignments. We usually make this the same as our working directory name.

### dataVariant = Collision15

  • For 2015, don't touch

### minAverageBinPop = 6.0

  • The minimum average population of the deltaTheta bins in a single bin of phi. Leave this as 6.0

### deltaThetaWindow = 4.0

  • Chosen automatically depending on richDetector. The window in deltaTheta.

### coeffCalibrTilt = 0.3

  • The size of the purposeful mirror tilts used in the alignment. Leave this as 0.3 for now

### useTruth =

  • The current version of the code has not been validated for use with Monte Carlo

### useOffsetsFromMC = false

  • Not sure what this is, again don't use with MC yet.

### alignHPDs = false

  • always false, do not touch

### AddedDB = []

  • a python list of strings that tell the alignment where to look for database slices that are newer than what is in the conddb and dddb. If you need them we will tell you.

### usePremisaligned = false

  • leave this alone for now.... have to come back to this later

### useSpecificAlignment = true

  • if this is true, then we want to substitute a specific mirror alignment for what is in the existing conddb.

### specificAlignment = /afs/cern.ch/user/p/pnaik/cmtuser/Panoptes_HEAD/Rich/RichMirrorAlignmentGanga/files/2015Alignments/2015_EM_MagDown/Rich1CondDBUpdate_Mp6Wi4.0Fv3Cm2Sm1_online_Collision15_i3.xml

  • if useSpecificAlignment is true, then this is the location of the alignment that we will use as our starting (zeroth iteration) alignment.

### combinFitVariant = 3

  • always 3, don't touch. FitSurface fitting technique for the 2D deltaTheta vs. phi histograms

### maximumNumberOfIterations = 10

  • we usually leave this alone. The alignment should converge well within 10 iterations if there is enough data

### richDetector = 1

  • IMPORTANT ... this is the rich (1 or 2) you wish to align

### solutionMethod = 1

  • always 1 for now. Algebraic method

### home = /afs/cern.ch/user/p/pnaik/

  • your home directory

### userReleaseArea = /afs/cern.ch/user/p/pnaik/cmtuser/

  • your cmtuser area

### pathToScripts = /afs/cern.ch/lhcb/software/releases/LBSCRIPTS/prod/InstallArea/scripts/

  • defined automatically

### RICHMIRRALIGNROOT = /afs/cern.ch/user/p/pnaik/cmtuser/Panoptes_HEAD/Rich/RichMirrAlign/

  • defined automatically

### RICHMIRRCOMBINFITROOT = /afs/cern.ch/user/p/pnaik/cmtuser/Panoptes_HEAD/Rich/RichMirrCombinFit/

  • defined automatically

### RICHMIRRORALIGNMENTGANGAROOT = /afs/cern.ch/user/p/pnaik/cmtuser/Panoptes_HEAD/Rich/RichMirrorAlignmentGanga/

  • defined automatically

### SQLITEDBPATH = /afs/cern.ch/lhcb/software/DEV/nightlies/DBASE/Det/SQLDDDB/db/

  • defined automatically

### previousJobNumbers = [23, 24, 25, 26, 27, 28, 29, 30, 31]

  • this is formed from information in the settings file, so refer to that. It is only needed if the first Reconstruction job is skipped

### startFromIteration = 0

  • you can start from any iteration. so if something broke you can start again from the beginning of that iteration by changing this number

### skipFirstRecoJob = 0

  • If the Reconstruction job in a broken iteration completed, or was completely submitted, then set this to 1

### skipFirstMergeJob = 0

  • If the Reconstruction job in a broken iteration completed and the files were merged but RichMirrCombinFit did not finish running, then set this to 1 as well as the previous

### skipFirstCombinFit = 0

  • If the Reconstruction job in a broken iteration completed and the files were merged and RichMirrCombinFit was run, then set this to 1 as well as the previous two

### justGlobalFit = 0

  • always leave this a zero... it's a legacy option that we'll get rid of later


  • we never use this... need to look into it

### thisAppConfigBrunelOpts = Default

  • we never use this... need to look into it

### stopTolerance = 0.1

  • RichMirrAlign will stop the alignment when all of the mirror tilts shift less than this amount from the previous iteration

### warningFactor = 20

  • A warning is given if any of the mirror tilts is greater than 20*stopTolerance. Right now there is no automatic mechanism to stop the alignment if this is the case, it's just a warning. This may change in the future.

### phiBinFactor = 3

  • Group the bins in phi, to reduce the total number of bins in phi by a factor of phiBinFactor. Brunel v47r9 uses 20 bins in phi. Brunel v48r0 and later uses 60 bins in phi. When that happens we set phiBinFactor to 3 to get 60/phiBinFactor = 20 bins in phi.

Return to the Top of this TWIki

We should be able to answer the following questions about every alignment we perform!


* (about the data)

  • what is the magnet polarity of the data?

* (from the HLT line)

  • what is the momentum cut on the trigger track of the line? (currently 30 GeV for Rich1 and 60 GeV for Rich2)

* (in the Brunel options)

  • What is the momentum cut on the tracks of the events? (currently 30 GeV for Rich1 and 60 GeV for Rich2)
  • What kind of tracks do we require? [for now it's LONG tracks only]

* (in Rich/RichFutureRecMonitors)

  • Which version of Rich/RichFutureRecMonitors are we using? (hint: it's tied to the version of Rec that Moore depends on)
  • What's the number of bins in phi produced by this version? (60 bins)
  • Are we using Chris's track selection to reduce photon background? (yes we are)

* (in the settings of configuration file or printed in the startup of the alignment, so easiest to find)

  • Which version of Moore are we using?
  • what added databases (i.e. detector conditions, including alignments that come before us in the chain) are we using, if any?
  • what are the CondDB and DDDB tags?
  • what is the epoch time?
  • what is the coeffCalibrTilt? [0.3 for both RICH1 and RICH2 for now]
  • what is the minAverageBinPop? [6.0 for both RICH1 and RICH2 for now]
  • what is the stopTolerance? (different for each type of rotation)
  • what is the phiBinFactor? (3)

Return to the Top of this TWIki

Python script to compare two XML files

/afs/cern.ch/user/p/pnaik/cmtuser/Panoptes_HEAD/Rich/RichMirrorAlignmentGanga/scripts/XMLcompare.py on lxplus, and use python XMLcompare.py -h for help.
NOTE: This script creates temporary files, therefore you cannot run it from a directory where you do not have permissions!!!

For your convenience, here is the content of that script if you just want to copy it into a blank XMLcompare.py:

import os, re, argparse
parser = argparse.ArgumentParser(description='Compares two XML files or a single diff between XML files. Usage is "python XMLcompare.py " OR "python XMLcompare.py &lt;diff_between_two_xmls.txt&gt;". Designed only to compare Y and Z tilts for all alignment parameters in the XML file. Does not tell you the name of each parameter, only draws attention to those that differ by more than 0.1 mrad. Tilts are ROUNDED not truncated.')
parser.add_argument('files', metavar='FILE', type=str, nargs='+',
                   help='the file with the diff OR the two files you want to diff')
parser.add_argument('-w', action="store", default = 0.1, dest="warningPrecision", type=float, help='the precision of differences at which warnings are provided, default is 0.1')
parser.add_argument('-p', action="store", default = 2, dest="displayPrecision", type=int, help='the number of digits after the decimal point printed for output numbers, default is 2')
args = parser.parse_args()

warningPrecision = args.warningPrecision
displayPrecision = str(args.displayPrecision)

#Actually, the parser will tell you that you didn't provide enough arguments, so we don't need this next bit
# if (len(args.files)==0):
#     print "I need files."
#     raise SystemExit ("I need files.")
if (len(args.files)==1):
    file = args.files[0]
    print "pre-diffed input file: " + file
if (len(args.files)==2):
    file = args.files[0]
    file2 = args.files[1]
    tempfile = "temp_XMLcompare.txt"
    print "first XML file to diff: " + file
    print "second XML file to diff: " + file2
    os.system("diff "+file+" "+file2+" &gt; "+tempfile)
    file = tempfile

# what we're gonna do, is search through it line-by-line
# and parse out the numbers, using regular expressions

# what this basically does is, look for any number of characters
# that aren't digits or '-' [^-\d]  ^ means NOT
# then look for 0 or 1 dashes ('-') followed by one or more decimals
# and a dot and decimals again: [\-]{0,1}\d+\.\d+
# and then the same as first..
with open (file, "r") as myfile:
    data2 = myfile.read()

data = re.sub(r"([a-z]+)", r"\n \1", data2)

#print data

# use http://www.myezapp.com/apps/dev/regexp/show.ws to translate
pattern = re.compile(r"[^-\d]*([\-]{0,1}\d+\.\d+)[^-\d]*")

results = []
for line in data.split("\n"):
    match = pattern.match(line)
    if match:
# summary: looks for things like 0.3333 or -2.2344 and only keeps those

# print results

sets = []
i = 0
end = len(results)
while i &lt; end - 1:
    sets.append((results[i+0], results[i+1], results[i+2], results[i+3], results[i+4], results[i+5]))
    i += 6

print " Y and Z tilt differences for all parameters. Note that numbers are ROUNDED not truncated. "
for t in sets:
    #    print t
    a = float(t[4]) - float(t[1]) # Y
    b = float(t[5]) - float(t[2]) # Z
    str1 = "                                           "
    str2 = "                                           "
    for i in (0,int(displayPrecision)):
        str1 += " "
        str2 += " "
    if abs(a) &gt; warningPrecision:
        str1str = ", warning: this Y tilt difference is %7."+displayPrecision+"f mrad"
        str1 = str1str % a
    if abs(b) &gt; warningPrecision:
        str2str = ", warning: this Z tilt difference is %7."+displayPrecision+"f mrad"
        str2 = str2str % b
    printString = " %7."+displayPrecision+"f , %s, %7."+displayPrecision+"f , %s "
    print printString % (a, str1, b, str2)

if (len(args.files)==2):
    os.system("rm -rf "+tempfile)

Return to the Top of this TWIki

How to view our IOVs in the git ONLINE DB (since 2017)


In principle you can view these in the CondDBBrowser, but in Run 2 after 2017 there is a subtlety in the git ONLINE DB that makes it look like we keep reverting back from the assigned mirror alignment for a run to a "default" alignment in-between the runs. This "default" alignment is actually the (only) mirror alignment that was used throughout 2016. They are partly there to maintain compatibility with the old COOL DB.

Presuming Marco Clemencic doesn’t alter this “default” condition to something else, if you ever need to view the IOVs properly for:

Return to the Top of this TWIki


If you ever need this:

e.g. dirac-bookkeeping-file-path --File LHCbCollision16Beam6500GeV-VeloClosed-MagUpRealDataTurbo0394000000CHARMTWOBODYMDST.py --GroupBy RunNumber | grep RunNumber > MagUpRunsCollision16Turbo03.txt
  • then import into excel, plot them in a scatter plot, and use the cursor to pick off the run numbers

Get the dates from the ELOG

Return to the Top of this TWIki

SHIFTER'S INSTRUCTIONS (i.e. Alignment Piquets and Data Managers)


Return to the Top of this TWIki

Basic Training

Code policies

  • Follow all LHCb coding conventions
  • Code "hacks" should never be left alone and forgotten, you should actively seek to make them part of the LHCb software in a proper way as soon as possible.


Use git (except for the Run II Public Note draft which is still on SVN, though it should be migrated to git).

The following resources will help you git started, and understand how we use git in the Mirror Alignment group:

Using git to develop LHCb software
git for LHCb Users - might be old now

Return to the Top of this TWIki

Latest LHC Schedule

You should always know the LHC Schedule if you are working on Mirror Alignment. You may find it for this year and for future years here:

LHC Schedule

Return to the Top of this TWIki

Previous Mirror Alignment Training Sessions

Look here for slides from previous mirror alignment training sessions:

Return to the Top of this TWiki

Important talks (Run 3)

We've done a poor job of keeping track of these since early 2016. You'll just have to search for talks given by Anatoly, Paras, Richard, Jake Amey, Jake Reich, Vidar Marsh, or Alex Marshall in Indico.

Return to the Top of this TWIki


TWIKI PAGE (this document):

Claire Prouve's thesis (pretty much everything about the Run 2 mirror alignment is discussed here, except the full automation) Framework for Distributed Alignment (Beat Jost, others) Most Recent Stable RICH Mirror Alignment Note (Anatoly Solomin, others) Tom Hampsons's thesis
  • https://cds.cern.ch/record/1670276?ln=en
  • Read p. 51 of Tom's thesis (CERN-THESIS-2013-291) for a clear description and derivation of the key angles used in the RICH mirror alignment. Noting that the small angle approximation is used, and the optical path (l) gets/is dropped on both sides of the equations, will make it easier to understand.
HLT map description (from a draft of Andrew Cook's thesis) Software Architecture of the HLT

Return to the Top of this TWIki

Key Meetings

  • Regular RICH Mirror Alignment meeting (only held when needed)
    • 14:30 UK / 15:30 CERN, weekly on Wednesdays
  • LHCb Bristol meetings
    • 9:00 UK / 10:00 CERN scheduled for 120 minutes, weekly on Fridays
  • RICH Software meetings
    • Don't exist right now
  • Operations Planning Group (OPG) meetings
    • 15:00 UK / 16:00 CERN scheduled for 135 minutes, weekly on Thursdays (?????)
  • LHCb Weeks, A&S Weeks, RICH Regular meetings (give an update when asked)
  • RTA WP4 Meeting (give an update when asked, or we have one)
    • Thursday morning and afternoon (alternating) 10:30 CERN time and 15:30 CERN time, in alternating weeks
  • RICH Operations/Commissioning meetings (give an update when asked)
    • RICH Ops/Commissioning meetings are typically Wednesday mornings
  • Various ad-hoc meetings

We need to attend as many of these as possible, to increase visibility and stay on target. Ad hoc meetings tend to be the most productive. If you need an ad-hoc meeting, call an ad-hoc meeting. We should be interacting and presenting our progress in the relevant meetings. Someone active on RICH mirror alignmnent should attend each required meeting.

Return to the Top of this TWIki

Basics and Information

This probably needs to be updated with StarterKit stuff (except the first one), etc...

Using git to develop LHCb software (MUST READ!!!)

LHCb Software Tutorials (VERY USEFUL!!!) LHCb Software Development (MUST READ!!!) Python Tutorial GitLab JIRA RICH Mirror Alignment component issues page The LHCb Nightly Builds system CondDB How-To page (not sure if this is still relevant) Convert degrees to pseudorapitity Embedding Python in another application HLT Tracking Twiki Online Twiki LHCb SVN Guidelines (With Tutorial for Developers... still a MUST READ!!!)

Return to the Top of this TWIki

Useful Shell Commands

Enable read access to anyone in LHCb (z5)

fs setacl -acl cern:z5 rl -dir `find . -type d`

Enable read access to a particular person (in this case, pnaik)

fs setacl -acl pnaik rl -dir `find . -type d`

Check permissions

fs listacl

Return to the Top of this TWIki

ROOT Color Palette for nice "2D heat maps"

UInt_t Number = 3;
Double_t Red[Number]    = { 0.00, 0.00, 1.00};
Double_t Green[Number]  = { 0.00, 1.00, 0.00};
Double_t Blue[Number]   = { 1.00, 0.00, 0.00};
Double_t Length[Number] = { 0.00, 0.50, 1.00 };
Int_t nb=50;

Return to the Top of this TWIki


I---The following should be moved to the proper places above and/or to a separate TWiki---I


Advice from Roel

Various words of wisdom from Roel

"Re: Issue with loading HPD QE" E-mail thread, 19 April 2017-ish

Advice 1

To look at the histograms being produced by one of the subfarms, pointing the presenter at one of the subfarms and see if you get anything:

$> presenter -P LHCbA -D hltf12

Tools -> Page Editor Online

Click on hltf12 in the top right to see if the adder (or other jobs) show up, open them, tick some histograms (if available), right-click and select "Add checked to page".

If you don't get any tasks with histograms or histograms, you can try seeing with $> HistTest.exe Adder hltf12 NB: Paras never got this command to work That gives a list of task names, select the one you want, and run with that as a first argument to see how many histograms there are.

Advice 2

At the level of the iterator, you can print what you want from the python.

If you want to be sure you see everything that is printed by a single process, you can log in to the host where it run (the iterator runs on hlt02) and start: $> errlog -m $HOST

If that command is now known, you'll have to: $> source /group/online/dataflow/scripts/shell_macros.sh

If you think the alignment worker is stalled, you can try to log in to the node as user online and start $> top press 'c' to see long command lines. If the letter in the column marked S is not R, but D, it's probably stuck on some cvmfs operation.

Remember the PID (process-id) of the process you are interested in from the listing in top, or use $> ps -lf -u online to find it.

If the letter is R, but no CPU is consumed, you can try to attach gdb to it. The gdb version that comes with lcg 88 is recent and has python support which is rather useful when debugging the iterator

$> lb-run LCG/88 bash --norc $> export PYTHONPATH=/home/raaij/software/Python-2.7.10/Tools/gdb:$PYTHONPATH $> /cvmfs/lhcb.cern.ch/lib/lcg/releases/LCG_88/gdb/7.12.1/x86_64-centos7-gcc62-dbg/bin/gdb --args YOURPID (gdb) python import libpython press ctrl+d (gdb) py-bt

For the analyzers, this can be simplified to: $> lb-run LCG/88 bash --norc $> ps -lf -u online find the PID of the process $> /cvmfs/lhcb.cern.ch/lib/lcg/releases/LCG_88/gdb/7.12.1/x86_64-centos7-gcc62-dbg/bin/gdb --args YOURPID (gdb) thread apply all bt

If the traceback shows that thread processing events (probably thread 1) is somewhere in the reconstruction sequence, do (gdb) continue wait a little bit and press ctrl+c (gdb) thread apply all bt

The processing thread should now be somewhere different. If not, try again, and if it's still in the same place, it's probably hanging there.

Advice 3 : (move to RUN troubleshooting)

To be practical, if it's just a few nodes, just exclude them and run with the rest.

If new nodes with problems pop up or it looks systematic to for example an entire subfarm, it helps the sysadmins if you report it with a mail to lbonsupp@cernNOSPAMPLEASE.ch, which will create a ticket. Don't do this for individual nodes, there are generally a lot of tickets and a few broken nodes is not urgent.

Cheers, Roel

Advice from Roel : (move to RUN troubleshooting)

If the worker jobs are in state RUNNING and still consuming CPU, they are still processing events. If most jobs are already paused for a while, and only few are still running, perhaps the maximum number of events is too high and there are a few nodes that happen to have a lot of events for the range of runs you have selected. If all of the jobs are PAUSED, but no histograms are arriving after a few minutes, there might be a problem with the adders.

pre-automization RICH mirror alignment plan

It has been decided that our full automatic update sequence (Rich mirror alignment decison, Decision sent to Clara, Clara sends to HLT2, and it is immediately used by HLT2) is postponed after middle of August.

It is agreed to run in the following way for the next 3 weeks:

(1) The Rich alignment will continue to run automatically, take a decision if needed or not to update. If the latter the new version of the alignment (new V) is given a temporary file name. (2) Regardless of the decision the current V will be sent to Clara. (3) The current V will thus be immediately propagated to HLT.

Rich alignment experts (Sam or Matt, maybe both when possible) should check the output of the alignment for each fill (~ every 12 hours). If the Cherenkov angle resolution changes more than the variation between the 2 magnet polarity (Rich1 >0.050 mrad; Rich2 >0.008 mrad) or the variation of the constants is > 2 times the set tolerances (i.e. the number on any mirror on the first page of AlignMonitor.pdf is 2 or higher), Sam and Matt should discuss with Claire and Rich experts (Chris J., Mike, Silvia Gambetta) and Silvia Borghi (phone 160973) the need for applying an update. From the mirror alignment side we should certainly update in either of these cases.

If an update should be applied, Sam or Matt should move the temporary V to v{N+1}.xml. It will be used from the next fill.

SPECIAL CASE: After the magnet polarity switch, HLT automatic will stay on, but Clara’s automatic reading of the update will be OFF. The alignment experts should provide the new version to be used for the new magnet polarity and re label it v{N+1}.xml. This should be provided within 1 day after the first fill (with at least 1500 b) with the new polarity. If this polarity switch is foreseen in advance, the rich mirror alignment experts should be informed. The new version numbers will be sent to Clara by email to be used by HLT. Please note, any change of polarity is not seen in the next 2 weeks. If possible, an email will be sent to the rich alignment expert and hlt piquet a bit in advance. Otherwise a polarity change warning will come up in the email sent at the start of an alignment.

In case of doubts for this procedure, please contact Silvia Borghi (Operations Coordinator) on the phone 160973.

More on the XML files and this procedure

Edit | Attach | Watch | Print version | History: r12 < r11 < r10 < r9 < r8 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r12 - 2022-12-01 - ParasNaik
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LHCb All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright &© 2008-2023 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback