Adding a new feature extracting class to the trigger package

Introduction

First you have to ssh to a particular lxplus machine (where the RDO is stored), then choose the athena version and the name of the test area folder, then create the folder, cd to it and setup athena.

Follow the instructions from AdrianBuzatuAthenaSetup.

Then make sure we have an RDO file by following the instructions from AdrianBuzatuAthenaRDO.

Create the class TrigBjetFexNEW

cd ~/$TEST_AREA/$ATHENA_VERSION/Trigger/TrigHypothesis/TrigBjetHypo/src
cp TrigBjetFex.cxx TrigBjetFexNEW.cxx
sed -i 's/TrigBjetFex/TrigBjetFexNEW/g' TrigBjetFexNEW.cxx
cd ~/$TEST_AREA/$ATHENA_VERSION/Trigger/TrigHypothesis/TrigBjetHypo/TrigBjetHypo
cp TrigBjetFex.h TrigBjetFexNEW.h
sed -i 's/TrigBjetFex/TrigBjetFexNEW/g' TrigBjetFexNEW.h
sed -i 's/TRIGBJETFEX_H/TRIGBJETFEXNEW_H/g' TrigBjetFexNEW.h

Since we are going to add new code in this class, optionally you could replace these lines in both the .cxx and .h files

// AUTHOR:   Andrea Coccaro                                                                                                                                                                                         
// EMAIL:    Andrea.Coccaro@ge.infn.it

with these lines

// AUTHOR:   Adrian Buzatu                                                                                                                                                                                          
// EMAIL:    Adrian.Buzatu@glasgow.ac.uk

Now we have to add a line with TrigBjetFexNEW to the _entries.cxx file from the src/components directory for each line that contains TrigBjetFex.

cd ../src/components
emacs -nw TrigBjetHypo_entries.cxx

The file will look like this

#include "GaudiKernel/DeclareFactoryEntries.h"
#include "TrigBjetHypo/TrigBjetHypo.h"
#include "TrigBjetHypo/TrigBjetFex.h"
#include "TrigBjetHypo/TrigBjetFexNEW.h"
#include "TrigBjetHypo/TrigLeptonJetHypo.h"
#include "TrigBjetHypo/TrigLeptonJetFex.h"
#include "TrigBjetHypo/TrigLeptonJetFexAllTE.h"

DECLARE_ALGORITHM_FACTORY( TrigBjetHypo )
DECLARE_ALGORITHM_FACTORY( TrigBjetFex )
DECLARE_ALGORITHM_FACTORY( TrigBjetFexNEW )
DECLARE_ALGORITHM_FACTORY( TrigLeptonJetHypo )
DECLARE_ALGORITHM_FACTORY( TrigLeptonJetFex )
DECLARE_ALGORITHM_FACTORY( TrigLeptonJetFexAllTE )

DECLARE_FACTORY_ENTRIES( TrigBjetHypo ) {

    DECLARE_ALGORITHM( TrigBjetHypo )
    DECLARE_ALGORITHM( TrigBjetFex )
    DECLARE_ALGORITHM( TrigBjetFexNEW )
    DECLARE_ALGORITHM( TrigLeptonJetHypo )
    DECLARE_ALGORITHM( TrigLeptonJetFex )
    DECLARE_ALGORITHM( TrigLeptonJetFexAllTE )
}

Compile the package

cd ../../cmt
gmake

There was no need to run "cmt config" because we did not modify the requirements file with new include libraries.

Running

cd ~/$TEST_AREA/$ATHENA_VERSION/Trigger/TrigHypothesis/TrigBjetHypo/run
athena.py ~/TriggerOptions.py >& test_trigger_bothFex.log

By comparing the log file with the previous log file we realize that the new Fex algorithm did not run. In order to do it we have to modify python configuration scripts in another package, Trigger/TriggerCommon/TriggerMenuPython.

We need also a new package

Since we are running in the nightly version rel_1, we need to see first what is the exact tag of this package that goes with this Athena release, so that we check out precisely this package. For this we use the NICOS webpage for our release.

cd ~/$TEST_AREA/$ATHENA_VERSION
cmt co -r TriggerMenuPython-00-20-62 Trigger/TriggerCommon/TriggerMenuPython
cd Trigger/TriggerCommon/TriggerMenuPython
ls
cd python
ls
emacs -nw BjetDef.py

We will run run both the old and the new fex algorithms at the same time. In the python class "ChainTemplate_Bjet" we see the for the EF (event filter, or level 3 of the trigger)

        self.continueSequence(fexes.ef_bjet_tracks + \
                              [ EFHistoPrmVtx_Jet(), fexes.ef_VxSecondary_EF,
                                #[ fexes.ef_HistoPrmVtx_Jet,                                                                                           
                                fexes.ef_bjet, ef_hypo ], self.ef.chain_name).addSignature('EF')

From this we learn that first the code runs the fex "fexes.ef_bjet" and then the hypo "ef_hype", which we will search for in the code and we will find them towards the beginning of the file.

fexes.ef_bjet = EFBjetFex()

Here we will create a new fex for our new class.

fexes.ef_bjetNEW = EFBjetFexNEW()      # added by ADRIAN & DANILO

Then we go back to the code above and also add this fex to be run. The new line will look like this.

        self.continueSequence(fexes.ef_bjet_tracks + \
                              [ EFHistoPrmVtx_Jet(), fexes.ef_VxSecondary_EF,
                                #[ fexes.ef_HistoPrmVtx_Jet,                                                                                           
                                fexes.ef_bjet, fexes.ef_bjetNEW, ef_hypo ], self.ef.chain_name).addSignature('EF')

Note that the ef_hypo should be at the end. In the future we would create as well a new "ef_hypoNEW" for the "fexes.ef_bjetNEW".

Q: I am puzzled at this point, since the class I created was called TrigBjetFexNEW and was copied from TrigBjetFex, so it had Trig instead of EF! A: This is a python class, not a C++ class. And we will create this python class ourselves (see below how we do it).

Now we search for "EFBjetFex" and we find it towards the beginning at

from TrigBjetHypo.TrigBjetFexConfig  import EFBjetFex

Q: I am puzzled why we needed this line in the first place, since a few lines above we had this line

from TrigBjetHypo.TrigBjetFexConfig  import *

A: Good observation, the line above was redundant, but it helps us pedagogically know in the feature in what config file the "EFBjetFex" was present. But to keep with it to learn for the future how to add a new import, we replace the line above with

from TrigBjetHypo.TrigBjetFexConfig  import EFBjetFex, EFBjetFexNEW

Compiling the new package

Now we need to compile the new package. It is true we did not change any C++ code, but running gmake does more than just compiling C++ (which is not necessary here), but also linking the python code (which we modified) to the install area (from where Athena will read them when running).

cd ../cmt
gmake

We did not have to do "cmt config" because we did not modify the "requirements" file or because we did not change the path of our package folder. These are the two situations when we need to run this command before running "gmake".

Modifying the old package

Now we need to make sure that TrigBJetFexConfig (a python configurationf file) knows about "EFBjetFexNEW" (a python class). This file is in the python folder of our original package.

cd ~/$TEST_AREA/$ATHENA_VERSION/Trigger/TrigHypothesis/TrigBjetHypo/python
ls
emacs -nw TrigBjetFexConfig.py

In the first lines we need to include this file which knows about the python classes that are automatically generated when we compiled the C++ code of the new class I created.

from TrigBjetHypo.TrigBjetHypoConf import * # added by ADRIAN & DANILO

Then we search for "EFBjetFex", as we need to create a similar class named "EFBjetFexNEW". We find it at the end of the file and see it inherits from another class called "TrigEFBjetFex".

class EFBjetFex (TrigEFBjetFex):
    __slots__ = []
    def __init__(self, name = "EFBjetFex"):
        super( EFBjetFex, self ).__init__( name )

        self.AlgoId         = 1

We search in the file for this name and we find this class and we see it inherits from another class called "TrigBjetFexTuningEFID". We search for this name and find it in the import lines at the beginning of the file with the classes automatically generated when we compile the C++ code, implicitely from the C++ class "TrigBjetFex". Therefore, we will skip these extra steps and create a new class "EFBjetFexNEW" that will inherit directly from "TrigBjetFexNEW", the C++ I created.

# added by ADRIAN & DANILO                                                                                                                                      
# TRIGBjetFexNEW is created automatically when compiling the C++ code                                                                                  
class EFBjetFexNEW (TrigBjetFexNEW):
    __slots__ = []
    def __init__(self, name = "EFBjetFexNEW"):
        super( EFBjetFexNEW, self ).__init__( name )
#        self.AlgoId         = 1

Compiling the old package

cd ~/$TEST_AREA/$ATHENA_VERSION/Trigger/TrigHypothesis/TrigBjetHypo/cmt
gmake

Now we check that indeed we have a python class called "TrigBjetFexNEW" generated automatically by compiling the C++ code (actually this time no C++ recompilation was made, as no C++ changes were made, but only the python links were made automatically). We compiled more to be on the safe side, as it was not really needed at this point.

cd ../genConf
ls
cd TrigBjetHypo
ls
emacs -nw TrigBjetHypoConf.py

At the top of the file we see the statement that the file was automatically generated and the timestamp. In the file we will see our class "TrigBjetFexNEW".

Running again

cd ~/$TEST_AREA/$ATHENA_VERSION/Trigger/TrigHypothesis/TrigBjetHypo/run
athena.py ~/TriggerOptions.py >& test_trigger_newFex.log
tail -f test_trigger_newFex.log

To look for the printout for each event, search in the .log file for "start processing event".