Twiki setup athena

For me this was user It has not been tested. This works as long as you don't recompile anything in your environment between jobs, you can change the joboptions. First you need to find the name of the previous library. Say we want to reuse the library built in ganga job given a job ID: Either: in ganga: In [19]:jobs In subsequent job options you can set: j.

Topic revision: r15 - - GraemeStewart. Log In or Register. Colloquially these are known as nightly builds , but they might well happen during daylight hours.

The results of a nightly build cmake configuration, build status and tests is accessible via the NICOS nightly build page. These nightly builds are usually used as a base on which to develop code changes, so knowing how to set them up is important.

You should find someone who has produced MC recently possibly via the conveners and check with them that you have the most up-to-date standard settings.

For each datasets to be produced you will need: - A dataset number RunNumber - A cross section - A job option probably using pythia or herwig that Evgen can run on - A few validation plots on a twiki from after the Evgen step You will have to run the Evgen step presumably locally and produce a few plots per dataset to 'validate' the setup.

Pythia and Herwig are part of Athena, so if you have a Pythia card then you should be able to run Evgen directly on that. Normally, the SuperRoi is initialized and flagged as composite, i.

The tracking is then performed in the SuperRoI. In order to perform a fullscan tracking, we therefore need this super RoI to span the entire ID. At first, an attempt was carried out to force the fullscan tracking by disabling the 'composite' flag of the SuperRoI and disabling the loop that adds the individual jet RoIs to it.

This resulted into RoI of zero size and of course no tracks. In addition, the composite flag and the loop adding constituent RoIs were both disabled. The procedure developed here can be integrated into Athena packages once completed. This file contains events out of which the hacked bjet trigger fired on In total over tracks were found in the fullScan, and written into the ntuple as one track per entry.

The leafs are: run number, event number, eta, phi, pT, z0, a0, chi2, dof, errors of eta, phi, pT, z0, a0. Lowering pT cut on the pattern recognition in the triggering algorithm led, somewhat counterintuitively, to fewer rather than more tracks reconstructed by the trigger. All Track pT for various cuts on pattern recognition Reference-matched Track pT for various cuts on pattern recognition This is investigated by Mark.

We might need to use beamspot chain instead of bjet if this is not resolved. Beamspot histat sample Until the problems with bjet chain are resolved, we will use the beamspot chain for the fullscans. This chain does not have the internal pT cut problems. The input file was the same as for the bjet chain above. FullScanner class A class called FullScanner was incorporated into the rmain.

It can apply cuts and combine the tracks in each event into B candidates. Invariant mass plots combining fullscans of all events are shown with visible B-peak under preliminary pT and delta Z cuts.

It was observed that approx. This was fixed by introducing separate masses for pi and K 4-vectors. Truth track variable distributions: These are the above distributions resulting from truth tracks only: The SV position distribution, that is clearly shifted to positive X, Y values, was due to the beamline correction wasn't carried out for some reason.

This was later fixed by forcing the correction there, and the distribution went back to the origin: Truth plots below this point include this correction.

Truth track variable distribution: Is our d0 sign convention opposite to what it should be? These plots pointing angle, lxy, decay length would suggest that Same thing happens with the trigger tracks matched to these truth tracks: The way in which the SV are obtained: The track parameters used to parametrize the straight lines in the transverse plane our approximation to the actual tracks are phi and d0.

The SV is obtained as an intersection of two tracks. The d0 is signed to resolve the ambiguity, as otherwise there would be two tracks parametrized by a singe unsigned impact parameter and phi.

The convention for signing the d0 used here is: sgn R x pT. The goal is to get the line parametrization based on the d0 sign, so that we can search for their intersections. Obtaining background sample Decision was made to use HLT tracks obtained from running the ID trigger on jet data as a background sample to estimate the rates.

This proved to be extremely difficult, if not impossible in Athena release After countless failed attempts with There is a job in 22 which casts the tracks from an AOD into the track ntuple. First, we had to see if the FS tracking looks the same in release 22 as it did in Comparing FS tracking in