Difference: SWGuideAlignmentPositionErrorEstimator (1 vs. 24)

Revision 242019-08-01 - MariusTeroerde

Line: 1 to 1
 
META TOPICPARENT name="SWGuideAlignmentAlgorithms"

Alignment Position Error (APE) Estimator

Complete: 5
Line: 96 to 96
 

Configuration of the Cluster Parameter Estimator (CPE)

Changed:
<
<
The configuration of the CPE which should be used in the refit is given in Alignment/APEEstimation/python/TrackRefitter_38T_cff.py. There it is chosen which PixelCPE and which StripCPE should be used. The recent one in use is called TTRHBuilderAngleAndTemplate (from CMSSW_10_0_X on), but of course the parameters can be changed also in the specific cfg.py, your configuration. But you need to ensure that it is also included in the refit definition, see below.
>
>
The configuration of the CPE which should be used in the refit is given in Alignment/APEEstimation/python/TrackRefitter_38T_cff.py. There it is chosen which PixelCPE and which StripCPE should be used. The recent one in use is called TTRHBuilderAngleAndTemplate , but of course the parameters can be changed also in the specific cfg.py, your configuration. But you need to ensure that it is also included in the refit definition, see below.
 

Configuration of the Refit

Changed:
<
<
The refit itself is also defined in Alignment/APEEstimation/python/TrackRefitter_38T_cff.py. There the CPE has to be specified by its ComponentName, which is for the one mentioned above WithAngleAndTemplate (again, from CMSSW_10_0_X on. For older CMSSW versions, you have to change it manually to WithAngleAndTemplate). Very important parameters which might have an influence on the results are the ones steering the hit rejection (outliers and bad pixel template fits). Again, this can be overwritten in your specific configuration.
>
>
The refit itself is also defined in Alignment/APEEstimation/python/TrackRefitter_38T_cff.py. There the CPE has to be specified by its ComponentName, which is for the one mentioned above WithAngleAndTemplate. Very important parameters which might have an influence on the results are the ones steering the hit rejection (outliers and bad pixel template fits). Again, this can be overwritten in your specific configuration.
  For the refitter, a sequence is defined which needs to be included in the cfg.py, since the refit also needs the offlineBeamSpot. It also contains the selection of tracks flagged as of highPurity, since in many alignment tasks only those are selected, and so it is done here. There, one could also apply the track selection instead of within the ApeEstimator, but in the present configuration this is not done, it selects only for highPurity.
Line: 152 to 152
 The DB objects are stored in Alignment/APEEstimation/hists/measurementName/apeObjects/. Always use the one named apeIter14.db as final result, the one named apeIter15.db is only produced due to the automation.

Autosubmitter to automatically manage measurements

Changed:
<
<
Starting from CMSSW_10_2_X (more features from CMSSW_10_3_X on, migration to condor instead of LSF from CMSSW_10_4_X on), the APE tool includes the autosubmitter in test/autoSubmitter/, which handles all steps of an APE measurement and is configured with a .ini file. It is possible to stop and resume the autosubmitter in order to add new measurements when others are already running. The autosubmitter is also used to do the required baseline measurements that are necessary for APE determination. For this, one has to use a data set with the flag isMC=True and an alignment object with the flag isDesign=True.
>
>
The APE tool includes the autosubmitter in test/autoSubmitter/, which handles all steps of an APE measurement and is configured with a .ini file. It is possible to stop and resume the autosubmitter in order to add new measurements when others are already running. The autosubmitter is also used to do the required baseline measurements that are necessary for APE determination. For this, one has to use a data set with the flag isMC=True and an alignment object with the flag isDesign=True.
 The currently running measurements are stored and updated in a shelve file. Measurements that fail or finished are logged in /test/autoSubmitter/history.log. Currently, the following options can be used to run autoSubmitter.py:

  • -c <config.ini>: The config from which the measurements are to be loaded
Line: 169 to 168
 
fileNames Names of input .root files, separated by whitespaces. on can use ranges [A-B] with integer numbers inside to add multiple files. Multiple ranges per filename are allowed. has to be defined
maxEvents Number of events to be analyzed per input file -1 (which means run over entire input file)
isMC Determines whether file contains simulated events or data False
Changed:
<
<
condition Implemented as "condition record=source tag". Replaces a record with the object found for a given tag in the source. Multiple conditions are possible.  
>
>
condition Implemented as "condition record=source tag" or "condition tag:source" in which case the record is guessed. Replaces a record with the object found for a given tag in the source. Multiple conditions are possible.  
  Alignment object configuration:
Option Description Default value
Line: 177 to 176
 
alignmentName Name of alignment record to load in apeEstimator_cfg.py only needs to be be specified if no condition TrackerAlignmentRcd is used
baselineDir Name of directory from which to load baseline for APE measurement Design
isDesign Determines whether the alignment object contains an ideal alignment False
Changed:
<
<
condition Implemented as "condition record=source tag". Replaces a record with the object found for a given tag in the source. Multiple conditions are possible. An alignment object needs either an alignmentName or a condition for a TrackerAlignmentRcd. If both are defined, the condition is used and the alignmentName is ignored.  
>
>
condition Implemented as "condition record=source tag" or "condition tag:source" in which case the record is guessed. Replaces a record with the object found for a given tag in the source. Multiple conditions are possible. An alignment object needs either an alignmentName or a condition for a TrackerAlignmentRcd. If both are defined, the condition is used and the alignmentName is ignored.  
  In conditions, one can use shortcuts for the source. Possible shortcuts are "mpXXXX", "mpXXXX_jobmY", "hpXXXX_iterY", "smXXXX_iterY", and "prod". Further shortcuts can be added as regular expressions in the header of autoSubmitter.py.
Line: 242 to 241
 

New python scripts for result plots

Changed:
<
<
Starting with CMSSW_10_4_X, result plots can be created using scripts in test/plottingTools/. For now, these include drawResults.py for the graphical representation of APE measurements and their comparison with other measurements and with default values, and drawIterations.py for the graphical representation of the development of APE values over different iterations. Result plots can now be automatically be generated by the autoSubmitter tool. The granularity of these plots can be configured in granularity.py, and basic functionality for the representation of uncertainties is provided with systematicErrors.py, which can be used to display symmetric and asymmetric uncertainties in result plots.
>
>
Result plots can be created using scripts in test/plottingTools/. For now, these include drawResults.py for the graphical representation of APE measurements and their comparison with other measurements and with default values, and drawIterations.py for the graphical representation of the development of APE values over different iterations. Result plots can now be automatically be generated by the autoSubmitter tool. The granularity of these plots can be configured in granularity.py, and basic functionality for the representation of uncertainties is provided with systematicErrors.py, which can be used to display symmetric and asymmetric uncertainties in result plots.
 

Addtional Tools

Revision 232019-04-05 - MariusTeroerde

Line: 1 to 1
 
META TOPICPARENT name="SWGuideAlignmentAlgorithms"

Alignment Position Error (APE) Estimator

Complete: 5
Line: 198 to 198
  These arguments are to be added with whitespaces separating them, using the structure argument1=value1 argument2=value2.
Changed:
<
<
It is also possible to separately define result plots that wait for different measurements to finish (these measurements have to run in the same instance of autoSubmitter). You can also load results from .root files with stored APE values. The configuration starts with a section defnition: [resultPlot:resultPlotName].
>
>
It is also possible to separately define result plots that wait for different measurements to finish (these measurements have to run in the same instance of autoSubmitter). You can also load results from .root files with stored APE values. The configuration starts with a section defnition: [resultplot:resultPlotName].
  The following options can be configured:
Option Description Default value

Revision 222018-12-20 - MariusTeroerde

Line: 1 to 1
 
META TOPICPARENT name="SWGuideAlignmentAlgorithms"

Alignment Position Error (APE) Estimator

Complete: 5
Line: 242 to 242
 

New python scripts for result plots

Changed:
<
<
Starting with CMSSW_10_4_X, result plots can be created using scripts in test/plottingTools/. For now, these include drawResults.py for the graphical representation of APE measurements and their comparison with other measurements and with default values, and drawIterations.py for the graphical representation of the development of APE values over different iterations. Result plots can now be automatically be generated by the autoSubmitter tool. The granularity of these plots can be configured in granularity.py, and basic functionality for the representation of uncertainties is provided with systematicErrors.py, which can be used to create symmetric and asymmetric uncertainties in result plots.
>
>
Starting with CMSSW_10_4_X, result plots can be created using scripts in test/plottingTools/. For now, these include drawResults.py for the graphical representation of APE measurements and their comparison with other measurements and with default values, and drawIterations.py for the graphical representation of the development of APE values over different iterations. Result plots can now be automatically be generated by the autoSubmitter tool. The granularity of these plots can be configured in granularity.py, and basic functionality for the representation of uncertainties is provided with systematicErrors.py, which can be used to display symmetric and asymmetric uncertainties in result plots.
 

Addtional Tools

Revision 212018-12-20 - MariusTeroerde

Line: 1 to 1
 
META TOPICPARENT name="SWGuideAlignmentAlgorithms"

Alignment Position Error (APE) Estimator

Complete: 5
Line: 52 to 52
 

Default Creation

Changed:
<
<
In order to allow parallelisation and fast iterations, a private skim of files is created from the AlCaReco files. The event content is minimised to the needs for the ApeEstimator, a tighter preselection is also applied, and the files are split in size for optimising between number of files and number of events inside. To do so, the file Alignment/APEEstimation/test/batch/skimProducer.bash is run on the batch farm. It uses the configuration in Alignment/APEEstimation/test/SkimProducer/skimProducer_cfg.py. There, the used track selection is defined in Alignment/APEEstimation/python/AlignmentTrackSelector_cff.py, and the trigger selection in Alignment/APEEstimation/python/TriggerSelection_cff.py.
>
>
In order to allow parallelisation and fast iterations, a private skim of files is created from the AlCaReco files. The event content is minimised to the needs for the ApeEstimator, a tighter preselection is also applied, and the files are split in size for optimising between number of files and number of events inside. Skimming is done using the configuration in Alignment/APEEstimation/test/SkimProducer/skimProducer_cfg.py. There, the used track selection is defined in Alignment/APEEstimation/python/AlignmentTrackSelector_cff.py, and the trigger selection in Alignment/APEEstimation/python/TriggerSelection_cff.py (the trigger selection is disabled by default).
 The event content is defined in Alignment/APEEstimation/python/PrivateSkim_EventContent_cff.py.

Which dataset to process is steered via a configurable parameter using the VarParsing, which also allows a local test run.

Deleted:
<
<
In order to have the file names correct for the automated workflow, it is necessary to run after the skim production the script Alignment/APEEstimation/test/SkimProducer/cmsRename.sh.
 After having run those two scripts for each dataset that one wants to process, the skim is ready for the automated workflow of the APE estimation.
Deleted:
<
<
However, the folder of the CAF user diskpool to store the output, and later read it in, is not automated. This needs to be adjusted by the user.
 
Changed:
<
<

Parallel Skimming

>
>
It is recommended use /test/batch/startSkim.py to start skims. This script automatically runs skims, renames the output file to match the _N.root naming scheme, and, if configured in /test/SkimProducer/skimProducer_cfg.py, copies the files to a desired location. The script takes -s as an argument, where an arbitrary number of sample names is allowed. It is also possible to define sample names with ranges, for example -s Sample[1-3,ONE,TWO,THREE] will input the sample names Sample1, Sample2, Sample3, SampleONE, SampleTWO, SampleTHREE which will be passed to /test/SkimProducer/skimProducer_cfg.py. Note that for this definition to be parsed correctly, the may be no whitespaces in a sample name definition. For multi-IOV campaigns with many different data sets, a sample name option iov is already defined in skimProducer_cfg.py, which can then be further parsed to get the correct input and output file names etc. The skimming of more than one sample will be done with parallel processes, unless -c is also passed, in which case the skims will be done in a consecutive way. While it is possible to have an arbitrary number of parallel skims in one session, it is recommended to not skim more than 20 samples per ssh-session in order to quickly finish the skims. Using the option -n ncores, one can limit the maximum number of skims to run in parallel (by default, all samples are skimmed at the same time.
 
Changed:
<
<
If multiple samples have to be skimmed, one can use /test/batch/startSkim.py. This script automatically runs skims, renames the output file to match the _N.root naming scheme, and, if configured in /test/SkimProducer/skimProducer_cfg.py, copies the files to a desired location. The script takes -s as an argument, where an arbitrary number of sample names is allowed. It is also possible to define sample names with ranges, for example -s Sample[1-3,ONE,TWO,THREE] will input the sample names Sample1, Sample2, Sample3, SampleONE, SampleTWO, SampleTHREE which will be passed to /test/SkimProducer/skimProducer_cfg.py. Note that for this definition to be parsed correctly, the may be no whitespaces in a sample name definition. For multi-IOV campaigns with many different data sets, an sample name option iov is already defined there. This can then be further parsed in skimProducer_cfg.py to get the correct input files etc. The skimming of more than one sample will be done with parallel processes, unless -c is also passed, in which case the skims will be done in a consecutive way. While it is possible to have an arbitrary number of parallel skims in one session, it is recommended to not skim more than 20 samples per ssh-session in order to quickly finish the skims.
>
>
Alternatively, the bash script /test/batch/skimProducer.bash can be used for skims.
 

The APE Estimation Tool

Line: 151 to 146
  Be aware that the APE DB object of the iteration called iteration 14 is your final result, and not the APE DB object of the one called iteration 15!
Changed:
<
<
All output except of the DB object is stored in Alignment/APEEstimation/hists//iter*/, where the * corresponds to the number of the given iteration.
>
>
All output except of the DB object is stored in Alignment/APEEstimation/hists/measurementName/iter*/, where the * corresponds to the number of the given iteration.
 The important ones are iter0 (containing the validations with zero APE), iter14 (containing the results concerning the estimated final APE values), and iter15 (containing the validations with the final APE).
Changed:
<
<
The DB objects are stored in Alignment/APEEstimation/hists//apeObjects/. Always use the one named apeIter14.db as final result, the one named apeIter15.db is only produced due to the automation.
>
>
The DB objects are stored in Alignment/APEEstimation/hists/measurementName/apeObjects/. Always use the one named apeIter14.db as final result, the one named apeIter15.db is only produced due to the automation.
 
Changed:
<
<

Autosubmitter for multiple parallel measurements

>
>

Autosubmitter to automatically manage measurements

 
Changed:
<
<
Starting from CMSSW_10_2_X (more features from CMSSW_10_3_X on, migration to condor instead of LSF from CMSSW_10_4_X on), the APE tool includes the autosubmitter in test/autoSubmitter/, which handles all steps of an APE measurement and is configured with a .ini file. It is possible to stop and resume the autosubmitter in order to add new measurements when others are already running. For this, the current measurements are stored and updated in a shelve file. Measurements that fail or finished are logged in /test/autoSubmitter/history.log. Currently, the following options can be used to run autoSubmitter.py:
>
>
Starting from CMSSW_10_2_X (more features from CMSSW_10_3_X on, migration to condor instead of LSF from CMSSW_10_4_X on), the APE tool includes the autosubmitter in test/autoSubmitter/, which handles all steps of an APE measurement and is configured with a .ini file. It is possible to stop and resume the autosubmitter in order to add new measurements when others are already running. The autosubmitter is also used to do the required baseline measurements that are necessary for APE determination. For this, one has to use a data set with the flag isMC=True and an alignment object with the flag isDesign=True. The currently running measurements are stored and updated in a shelve file. Measurements that fail or finished are logged in /test/autoSubmitter/history.log. Currently, the following options can be used to run autoSubmitter.py:
 
  • -c <config.ini>: The config from which the measurements are to be loaded
  • -d <dump.shelve>: Defines the .pkl file in which the current measurements are to be stored. Can be customized in case one wants to have multiple instances of autoSubmitter.py running in different sessions.
  • -r <dump.shelve>: Resume measurements from a .pkl file.
  • -k/-p <measurement.Name>: Kill or purge (kill and remove folders) a measurement with a certain name. For this, you obviously need to also resume the measurement from a .pkl file.
Added:
>
>
Data set configurations start with a section declaration [dataset:datasetName], while alignment object names start with [alignment:alignmentName].
 Data set configuration:
Option Description Default value
baseDirectory Directory to read files from, usually some /eos directory has to be defined, can be empty if path is included in fileNames
Line: 187 to 185
  measurementName: datasetName alignmentName optionalArguments
Changed:
<
<
The measurement name is also used as a folder name in hists/, where all results and ape object related to the measurement are stored.
>
>
The measurement name is also used as a folder name in hists/, where all results and ape objects related to a measurement are stored.
  While optionalArguments can be empty, there are the following possible parameters:
Option Description Default value
Line: 195 to 193
 
maxIterations Number of Iterations to run 15
maxEvents Number of events to be analyzed per input file. Overwrites whatever is defined in dataset configuration. from dataset
resultPlotDo Determines whether to do result plots after finishing the measurement False
Changed:
<
<
resultPlotTitle Title of the result plots ""
>
>
resultPlotTitle Title of the result plots. Cannot contain whitespaces. If you wish to include whitespaces, use ~ instead ""
 
resultPlotOutPath Path where to save the result plots path of the measurement
Changed:
<
<
These arguments are to be added with whitespaces between them and with the structure argument=value.
>
>
These arguments are to be added with whitespaces separating them, using the structure argument1=value1 argument2=value2.

It is also possible to separately define result plots that wait for different measurements to finish (these measurements have to run in the same instance of autoSubmitter). You can also load results from .root files with stored APE values. The configuration starts with a section defnition: [resultPlot:resultPlotName].

The following options can be configured:

Option
<!-- -->
Sorted ascending
Description Default value
granularity Granularity of plots as defined in test/plottingTools/granularity.py. Defines how to group the different sectors in the plots. standardGranularity
load label:path/to/file.root loads APE values from a .root file and includes them in result plot using the label "label". Labels cannot contain whitespaces. If you wish to include whitespaces, use ~ instead. Multiple entries are possible.  
outPath output path for the plots hists/resultPlotName
title Title of the result plots ""
wait label:name waits for measurement "name" to finish, will then include it in result plot using the label "label". Labels cannot contain whitespaces. If you wish to include whitespaces, use ~ instead. Multiple entries are possible.  

  The different options for the configuration of the .ini file can also be found as comments in /test/autoSubmitter/config.ini, which includes an example configuration.

Revision 202018-12-18 - MariusTeroerde

Line: 1 to 1
 
META TOPICPARENT name="SWGuideAlignmentAlgorithms"

Alignment Position Error (APE) Estimator

Complete: 5
Line: 31 to 31
 cmsenv
Changed:
<
<
If you want to run quickly the tool with the current configuration without knowing anything about details, you can read only Setting up the Tool, Scripts for Automated Workflow and Scripts producing Validation Plots, and read the other parts only if you need them.
>
>
If you want to run quickly the tool with the current configuration without knowing anything about details, you can read only Setting up the Tool, Autosubmitter for multiple parallel measurements and Scripts producing Validation Plots, and read the other parts only if you need them.
 

Setting up the Tool

After setting up the CMSSW area, do the following:
Line: 171 to 171
 
fileNames Names of input .root files, separated by whitespaces. on can use ranges [A-B] with integer numbers inside to add multiple files. Multiple ranges per filename are allowed. has to be defined
maxEvents Number of events to be analyzed per input file -1 (which means run over entire input file)
isMC Determines whether file contains simulated events or data False
Added:
>
>
condition Implemented as "condition record=source tag". Replaces a record with the object found for a given tag in the source. Multiple conditions are possible.  
  Alignment object configuration:
Option Description Default value
Line: 178 to 179
 
alignmentName Name of alignment record to load in apeEstimator_cfg.py only needs to be be specified if no condition TrackerAlignmentRcd is used
baselineDir Name of directory from which to load baseline for APE measurement Design
isDesign Determines whether the alignment object contains an ideal alignment False
Added:
>
>
condition Implemented as "condition record=source tag". Replaces a record with the object found for a given tag in the source. Multiple conditions are possible. An alignment object needs either an alignmentName or a condition for a TrackerAlignmentRcd. If both are defined, the condition is used and the alignmentName is ignored.  

In conditions, one can use shortcuts for the source. Possible shortcuts are "mpXXXX", "mpXXXX_jobmY", "hpXXXX_iterY", "smXXXX_iterY", and "prod". Further shortcuts can be added as regular expressions in the header of autoSubmitter.py.

  Measurements are defined in the [measurements] section of the config file. They are added in structure

measurementName: datasetName alignmentName optionalArguments

Changed:
<
<
Optional arguments configuration:
>
>
The measurement name is also used as a folder name in hists/, where all results and ape object related to the measurement are stored.

While optionalArguments can be empty, there are the following possible parameters:

 
Option Description Default value
firstIteration Iteration in which to start the measurement 0
maxIterations Number of Iterations to run 15
maxEvents Number of events to be analyzed per input file. Overwrites whatever is defined in dataset configuration. from dataset
Added:
>
>
resultPlotDo Determines whether to do result plots after finishing the measurement False
resultPlotTitle Title of the result plots ""
resultPlotOutPath Path where to save the result plots path of the measurement

These arguments are to be added with whitespaces between them and with the structure argument=value.

 
Changed:
<
<
The different options for the configuration of the .ini file can be found as comments in /test/autoSubmitter/config.ini, which includes an example configuration. The way to define a measurement is to define a dataset and an alignment and combine them with a measurement name, which will be the folder name in /hists/.
>
>
The different options for the configuration of the .ini file can also be found as comments in /test/autoSubmitter/config.ini, which includes an example configuration.
 

Scripts producing Validation Plots

Revision 192018-12-18 - MariusTeroerde

Line: 1 to 1
 
META TOPICPARENT name="SWGuideAlignmentAlgorithms"

Alignment Position Error (APE) Estimator

Complete: 5
Line: 12 to 12
 

Introduction

The tool is called ApeEstimator and resides in Alignment/APEEstimation. The code was implemented into the official release in CMSSW_7_6_0. Working versions can be found for CMSSW_7_4_X, CMSSW_7_5_X.

Changed:
<
<
It also uses subtools located in Alignment/CommonAlignmentAlgorithm and Alignment/TrackerAlignment and contains several scripts to run the procedure and to produce validation plots.
>
>
It also uses subtools located in Alignment/TrackerAlignment and contains several scripts to run the procedure and to produce validation plots.
 

Recipe for CMSSW_9_4_X

Line: 73 to 73
  In order to allow parallel processing, the tool is based on two different modules. The first one (ApeEstimator) reads the events and gathers all relevant information in several .root-files. The second one (ApeEstimatorSummary) then calculates the APE values afterwards, requiring to merge the files from the first step. The tool is automated and based on 4 scripts, which need to be run sequentially, starting the next one only after all actions initiated by the previous one have finished successfully. Since the method is a local method, iterations are necessary, so the chain needs to be repeated. In the following, the configuration of the two modules is explained, the scripts to run are explained in a later section.
Changed:
<
<
In general, all configurations should be done in your final apeEstimator_cfg.py, apeEstimatorSummary_cfg.py and apeEstimatorLocalSetting_cfg.py in Alignment/APEEstimation/test/cfTemplate. The _cfi.py files in Alignment/APEEstimation/python define the configurable parameters, mainly without doing any selection, and should never be changed, they are only templates. The _cff.py files in the same folder give the default settings, and should only be changed in exceptional cases.
>
>
In general, all configurations can be done in your final apeEstimator_cfg.py, apeEstimatorSummary_cfg.py and apeEstimatorLocalSetting_cfg.py in Alignment/APEEstimation/test/cfgTemplate. The _cfi.py files in Alignment/APEEstimation/python define the configurable parameters, mainly without doing any selection, and should never be changed, they are only templates. The _cff.py files in the same folder give the default settings, and should only be changed in exceptional cases.
 
Added:
>
>
Usually, all necessary configurations for APE measurements can be made in the .ini file that is used to configure the autoSubmitter. Therefore, it is recommended to use the config provided to autoSubmitter.py, except for in cases where exotic configurations are required. The different conigurables and their default values are documented in test/autoSubmitter/config.ini.
 

Configuration of ApeEstimator

Line: 144 to 145
  The output of the tool are the following files. There is a .root-file containing a set of validation plots important for the APE estimate. In the mode setting the baseline, the baseline .root-file mentioned above is produced. In the mode for calculating the APE, the .root-file for the iterations of the APE value and the ASCII-file with the APE values used for producing a DB object as mentioned above is produced. Additionally, a root file similar to the one for the iterations is included which contains the default APEs from the global tag before aplying the tool.
Changed:
<
<

Scripts for Automated Workflow

The automated workflow is based on four scripts, which need to be run in the specific order, starting the next one only after all actions of the previous one have finished successfully. They are run for each iteration, and do the following action:

  • createStep1.bash iterationNumber [ lastIteration ]
This produces all relevant scripts defining the ApeEstimator step. It creates scripts for parallel processing, one for each regarded skimmed file. The scripts can be found in Alignment/APEEstimation/test/batch/workingArea/. It is the only script which needs to be adjusted, the other three are identical for each possible operation. The samples which should be read, and the alignment geometry, are specified here. But in fact, there are only parameters specified which are then used in the config template Alignment/APEEstimation/test/cfgTemplate/apeEstimator_cfg.py, using the VarParsing. So what is really selected is coded in the config template.

  • startStep1.bash
The scripts produced in the previous step are sent to the batch farm, i.e. the ApeEstimator is run parallelised, based on the config template Alignment/APEEstimation/test/cfgTemplate/apeEstimator_cfg.py. In order to gain speed, the optimised skimmed files as explained above are copied to the batch machine and processed there locally. The output is stored in Alignment/APEEstimation/hists/workingArea/.

  • createStep2.bash iterationNumber [ setBaseline ]
This script does all necessary preparatory action for the final calculations. The final output directory is created which is specific for baseline setting or APE calculation mode, and in the latter case also to the iteration number. All .root-files which are the result of the first step are merged using hadd, the merged file is moved to the final output directory. The script needed for the second iteration is created, which is Alignment/APEEstimation/test/batch/workingArea/summary.bash. The script is based on the template Alignment/APEEstimation/test/cfgTemplate/summaryTemplate.bash. In case of iterations the .root-file containing the APE value of the previous iteration is copied to the final output directory.

  • startStep2.bash
This script runs the script prepared in the previous step. This means running the ApeEstimatorSummary based on the template Alignment/APEEstimation/test/cfgTemplate/apeEstimatorSummary_cfg.py, and the output is stored in the final output directory created in the previous step. Furthermore, in case of APE calculation mode, it runs the creation of the DB object, based on the template Alignment/APEEstimation/test/cfgTemplate/apeLocalSetting_cfg.py. Finally it does a cleanup of all scripts used in this iteration (produced in the two create-steps). In case of the creation of a DB object for the APEs (APE calculation mode), the printout of the cmsRun job shows one error. This is expected, since the DB object creation is based on the AlignmentProducer, which is a generic tool and expects some information which is not given and not necessary for writing the APE object. The DB object should be created correctly.

The way of how to use these scripts is explained in the following for setting the baseline respectively calculating APEs.

Set Baseline from Design Simulation

The scripts are in Alignment/APEEstimation/test/cfgTemplateDesign/. But only the createStep1.bash is also in this folder in the release, the others are copied from Alignment/APEEstimation/test/cfgTemplate/, since they are identical for all possible operations.

The scripts need to be run only once, since iterations make no sence for setting the baseline. Do the following steps:

  • cd Alignment/APEEstimation/test/cfgTemplateDesign/workingArea/
  • bash ../createStep1.bash 0
  • bash ../startStep1.bash
  • bash ../createStep2.bash 0 True
  • bash ../startStep2.bash

The final output directory where all files end up is Alignment/APEEstimation/hists/Design/baseline/.

Calculate APE Parameters

There is one directory prepared for calculating APEs on MC using misaligned geometries, and one directory for calculating APEs on data. Depending on what you want to analyse, do for MC:

  • cd Alignment/APEEstimation/test/cfgTemplateMc/workingArea/

or do for real data:

  • cd Alignment/APEEstimation/test/cfgTemplateData/workingArea/

The relevant scripts are placed in this folder, but only the createStep1.bash is also in this folder in the release, the others are copied from Alignment/APEEstimation/test/cfgTemplate/, since they are identical for all possible operations.

For all but the last iteration, do the following steps, where iterationNumber needs to be replaced by the number of the iteration, starting with 0:

  • bash ../createStep1.bash iterationNumber
  • bash ../startStep1.bash
  • bash ../createStep2.bash iterationNumber
  • bash ../startStep2.bash

For the last iteration, do:

  • bash ../createStep1.bash iterationNumber True
  • bash ../startStep1.bash
  • bash ../createStep2.bash iterationNumber
  • bash ../startStep2.bash
>
>

Validation plots

  In the first iteration (called iteration 0), also validation plots of the analyzer mode of ApeEstimator are created automatically. During the iterations, this is not done, only the relevant things for the iterations are produced. If you specified your last iteration as stated above, again a set of validation plots is created. This allows the comparison and the automated production (see later) of validation plots, comparing the distributions before iterations (with APE=0) to distributions after iterations (final APE as estimated by the tool). The tool is normally used with 15 iterations, so running iteration 0,...14 with the first set of commands, and then running iteration 15 with the second set of commands. This very last iteration (called iteration 15) is not to do another iteration, but to get the validation on the APE after the 15 iterations 0,...14. If you would like to use another number of iterations, it is not a problem, but some of the automated scripts producing validation plots as explained later need to be adjusted.

Be aware that the APE DB object of the iteration called iteration 14 is your final result, and not the APE DB object of the one called iteration 15!

Changed:
<
<
All output except of the DB object is stored in Alignment/APEEstimation/hists/workingArea/iter*/, where the * corresponds to the number of the given iteration.
>
>
All output except of the DB object is stored in Alignment/APEEstimation/hists//iter*/, where the * corresponds to the number of the given iteration.
 The important ones are iter0 (containing the validations with zero APE), iter14 (containing the results concerning the estimated final APE values), and iter15 (containing the validations with the final APE).
Changed:
<
<
The DB objects are stored in Alignment/APEEstimation/hists/workingArea/apeObjects/. Always use the one named apeIter14.db as final result, the one named apeIter15.db is only produced due to the automation.

For a more automated workflow there are scripts which can be run via

  • bash ../run15Iterations.bash

or

  • bash ../run10Iterations.bash

if one finds that 10 iterations are sufficient. These scripts automatically sleep until the sent batch jobs are finished. If one wishes to manually set the sleep time for batch jobs to finish, one can instead run

  • bash ../run10Iterations_manual.bash
  • bash ../run15Iterations_manual.bash

depending on the desired number of iterations.

>
>
The DB objects are stored in Alignment/APEEstimation/hists//apeObjects/. Always use the one named apeIter14.db as final result, the one named apeIter15.db is only produced due to the automation.
 

Autosubmitter for multiple parallel measurements

Changed:
<
<
Starting from CMSSW_10_2_X (more features from CMSSW_10_3_X on), the APE tool includes the autosubmitter in test/autoSubmitter/, which handles all steps of an APE measurement and is configured with a .ini file. This tool is good for parallel measurements as it does not have to use /hists/workingArea/. It is possible to stop and resume the autosubmitter in order to add new measurements when others are already running. For this, the current measurements are stored and updated in a pkl file. Measurements that fail or finished are logged in /test/autoSubmitter/history.log. Currently, the following options can be used to run autoSubmitter.py:
>
>
Starting from CMSSW_10_2_X (more features from CMSSW_10_3_X on, migration to condor instead of LSF from CMSSW_10_4_X on), the APE tool includes the autosubmitter in test/autoSubmitter/, which handles all steps of an APE measurement and is configured with a .ini file. It is possible to stop and resume the autosubmitter in order to add new measurements when others are already running. For this, the current measurements are stored and updated in a shelve file. Measurements that fail or finished are logged in /test/autoSubmitter/history.log. Currently, the following options can be used to run autoSubmitter.py:
 
  • -c <config.ini>: The config from which the measurements are to be loaded
Changed:
<
<
  • -d <dump.pkl>: Defines the .pkl file in which the current measurements are to be stored. Can be customized in case one wants to have multiple instances of autoSubmitter.py running in different sessions.
  • -r <dump.pkl>: Resume measurements from a .pkl file.
>
>
  • -d <dump.shelve>: Defines the .pkl file in which the current measurements are to be stored. Can be customized in case one wants to have multiple instances of autoSubmitter.py running in different sessions.
  • -r <dump.shelve>: Resume measurements from a .pkl file.
 
  • -k/-p <measurement.Name>: Kill or purge (kill and remove folders) a measurement with a certain name. For this, you obviously need to also resume the measurement from a .pkl file.
Added:
>
>
Data set configuration:
Option Description Default value
baseDirectory Directory to read files from, usually some /eos directory has to be defined, can be empty if path is included in fileNames
fileNames Names of input .root files, separated by whitespaces. on can use ranges [A-B] with integer numbers inside to add multiple files. Multiple ranges per filename are allowed. has to be defined
maxEvents Number of events to be analyzed per input file -1 (which means run over entire input file)
isMC Determines whether file contains simulated events or data False

Alignment object configuration:

Option Description Default value
globalTag Global tag to load None, will load an auto tag depending on whether data or simulation is used
alignmentName Name of alignment record to load in apeEstimator_cfg.py only needs to be be specified if no condition TrackerAlignmentRcd is used
baselineDir Name of directory from which to load baseline for APE measurement Design
isDesign Determines whether the alignment object contains an ideal alignment False

Measurements are defined in the [measurements] section of the config file. They are added in structure

measurementName: datasetName alignmentName optionalArguments

Optional arguments configuration:

Option Description Default value
firstIteration Iteration in which to start the measurement 0
maxIterations Number of Iterations to run 15
maxEvents Number of events to be analyzed per input file. Overwrites whatever is defined in dataset configuration. from dataset
 The different options for the configuration of the .ini file can be found as comments in /test/autoSubmitter/config.ini, which includes an example configuration. The way to define a measurement is to define a dataset and an alignment and combine them with a measurement name, which will be the folder name in /hists/.

Scripts producing Validation Plots

Line: 264 to 218
  If one wants to overlay the resulting APE values for different geometries, this can be done with the corresponding root-macro, no explicit script exists. The macro is Alignment/APEEstimation/macros/commandsDrawComparison.C.
Added:
>
>

New python scripts for result plots

 
Added:
>
>
Starting with CMSSW_10_4_X, result plots can be created using scripts in test/plottingTools/. For now, these include drawResults.py for the graphical representation of APE measurements and their comparison with other measurements and with default values, and drawIterations.py for the graphical representation of the development of APE values over different iterations. Result plots can now be automatically be generated by the autoSubmitter tool. The granularity of these plots can be configured in granularity.py, and basic functionality for the representation of uncertainties is provided with systematicErrors.py, which can be used to create symmetric and asymmetric uncertainties in result plots.
 

Addtional Tools

Line: 286 to 242
 The method used for the APE estimation is described in the following two documents:

Changed:
<
<
  • PhD Thesis of Johannes Hauk "Measurement of Associated Z-Boson and b-Jet Production in Proton-Proton Collisions with the CMS Experiment"
>
>
  • PhD Thesis of Johannes Hauk "Measurement of Associated Z-Boson and b-Jet Production in Proton-Proton Collisions with the CMS Experiment" (Chapter 4)
 

-- JohannesHauk - 24-Jul-2012

Revision 172018-09-26 - MariusTeroerde

Line: 1 to 1
 
META TOPICPARENT name="SWGuideAlignmentAlgorithms"

Alignment Position Error (APE) Estimator

Complete: 4
Line: 64 to 64
 After having run those two scripts for each dataset that one wants to process, the skim is ready for the automated workflow of the APE estimation. However, the folder of the CAF user diskpool to store the output, and later read it in, is not automated. This needs to be adjusted by the user.
Added:
>
>

Parallel Skimming

If multiple samples have to be skimmed, one can use /test/batch/startSkim.py. This script automatically runs skims, renames the output file to match the _N.root naming scheme, and, if configured in /test/SkimProducer/skimProducer_cfg.py, copies the files to a desired location. The script takes -s as an argument, where an arbitrary number of sample names is allowed. It is also possible to define sample names with ranges, for example -s Sample[1-3,ONE,TWO,THREE] will input the sample names Sample1, Sample2, Sample3, SampleONE, SampleTWO, SampleTHREE which will be passed to /test/SkimProducer/skimProducer_cfg.py. Note that for this definition to be parsed correctly, the may be no whitespaces in a sample name definition. For multi-IOV campaigns with many different data sets, an sample name option iov is already defined there. This can then be further parsed in skimProducer_cfg.py to get the correct input files etc. The skimming of more than one sample will be done with parallel processes, unless -c is also passed, in which case the skims will be done in a consecutive way. While it is possible to have an arbitrary number of parallel skims in one session, it is recommended to not skim more than 20 samples per ssh-session in order to quickly finish the skims.

 

The APE Estimation Tool

In order to allow parallel processing, the tool is based on two different modules. The first one (ApeEstimator) reads the events and gathers all relevant information in several .root-files. The second one (ApeEstimatorSummary) then calculates the APE values afterwards, requiring to merge the files from the first step. The tool is automated and based on 4 scripts, which need to be run sequentially, starting the next one only after all actions initiated by the previous one have finished successfully. Since the method is a local method, iterations are necessary, so the chain needs to be repeated. In the following, the configuration of the two modules is explained, the scripts to run are explained in a later section.

Line: 205 to 209
 All output except of the DB object is stored in Alignment/APEEstimation/hists/workingArea/iter*/, where the * corresponds to the number of the given iteration. The important ones are iter0 (containing the validations with zero APE), iter14 (containing the results concerning the estimated final APE values), and iter15 (containing the validations with the final APE).
Changed:
<
<
The DB objects are stored in Alignment/APEEstimation/hists/apeObjects/. Always use the one named apeIter14.db as final result, the one named apeIter15.db is only produced due to the automation.
>
>
The DB objects are stored in Alignment/APEEstimation/hists/workingArea/apeObjects/. Always use the one named apeIter14.db as final result, the one named apeIter15.db is only produced due to the automation.
  For a more automated workflow there are scripts which can be run via
Line: 222 to 226
  depending on the desired number of iterations.
Added:
>
>

Autosubmitter for multiple parallel measurements

Starting from CMSSW_10_2_X (more features from CMSSW_10_3_X on), the APE tool includes the autosubmitter in test/autoSubmitter/, which handles all steps of an APE measurement and is configured with a .ini file. This tool is good for parallel measurements as it does not have to use /hists/workingArea/. It is possible to stop and resume the autosubmitter in order to add new measurements when others are already running. For this, the current measurements are stored and updated in a pkl file. Measurements that fail or finished are logged in /test/autoSubmitter/history.log. Currently, the following options can be used to run autoSubmitter.py:

  • -c <config.ini>: The config from which the measurements are to be loaded
  • -d <dump.pkl>: Defines the .pkl file in which the current measurements are to be stored. Can be customized in case one wants to have multiple instances of autoSubmitter.py running in different sessions.
  • -r <dump.pkl>: Resume measurements from a .pkl file.
  • -k/-p <measurement.Name>: Kill or purge (kill and remove folders) a measurement with a certain name. For this, you obviously need to also resume the measurement from a .pkl file.

The different options for the configuration of the .ini file can be found as comments in /test/autoSubmitter/config.ini, which includes an example configuration. The way to define a measurement is to define a dataset and an alignment and combine them with a measurement name, which will be the folder name in /hists/.

 

Scripts producing Validation Plots

Scripts for producing validation plots based on root-macros can be found in Alignment/APEEstimation/macros/. There are two different scripts to run. First do:

Revision 162018-01-24 - MariusTeroerde

Line: 1 to 1
 
META TOPICPARENT name="SWGuideAlignmentAlgorithms"

Alignment Position Error (APE) Estimator

Complete: 4
Line: 95 to 95
 

Configuration of the Cluster Parameter Estimator (CPE)

Changed:
<
<
The configuration of the CPE which should be used in the refit is given in Alignment/APEEstimation/python/TrackRefitter_38T_cff.py. There it is chosen which PixelCPE and which StripCPE should be used. The recent one in use is called TTRHBuilderGeometricAndTemplate, but of course the parameters can be changed also in the specific cfg.py, your configuration. But you need to ensure that it is also included in the refit definition, see below.
>
>
The configuration of the CPE which should be used in the refit is given in Alignment/APEEstimation/python/TrackRefitter_38T_cff.py. There it is chosen which PixelCPE and which StripCPE should be used. The recent one in use is called TTRHBuilderAngleAndTemplate (from CMSSW_10_0_X on), but of course the parameters can be changed also in the specific cfg.py, your configuration. But you need to ensure that it is also included in the refit definition, see below.
 

Configuration of the Refit

Changed:
<
<
The refit itself is also defined in Alignment/APEEstimation/python/TrackRefitter_38T_cff.py. There the CPE has to be specified by its ComponentName, which is for the one mentioned above WithAngleAndTemplate. Very important parameters which might have an influence on the results are the ones steering the hit rejection (outliers and bad pixel template fits). Again, this can be overwritten in your specific configuration.
>
>
The refit itself is also defined in Alignment/APEEstimation/python/TrackRefitter_38T_cff.py. There the CPE has to be specified by its ComponentName, which is for the one mentioned above WithAngleAndTemplate (again, from CMSSW_10_0_X on. For older CMSSW versions, you have to change it manually to WithAngleAndTemplate). Very important parameters which might have an influence on the results are the ones steering the hit rejection (outliers and bad pixel template fits). Again, this can be overwritten in your specific configuration.
  For the refitter, a sequence is defined which needs to be included in the cfg.py, since the refit also needs the offlineBeamSpot. It also contains the selection of tracks flagged as of highPurity, since in many alignment tasks only those are selected, and so it is done here. There, one could also apply the track selection instead of within the ApeEstimator, but in the present configuration this is not done, it selects only for highPurity.

Revision 152018-01-23 - MariusTeroerde

Line: 1 to 1
 
META TOPICPARENT name="SWGuideAlignmentAlgorithms"

Alignment Position Error (APE) Estimator

Complete: 4
Line: 14 to 14
 The tool is called ApeEstimator and resides in Alignment/APEEstimation. The code was implemented into the official release in CMSSW_7_6_0. Working versions can be found for CMSSW_7_4_X, CMSSW_7_5_X. It also uses subtools located in Alignment/CommonAlignmentAlgorithm and Alignment/TrackerAlignment and contains several scripts to run the procedure and to produce validation plots.
Changed:
<
<

Recipe for CMSSW_8_0_X

>
>

Recipe for CMSSW_9_4_X

 
Changed:
<
<
export SCRAM_ARCH=slc6_amd64_gcc530
>
>
cmsrel CMSSW_9_4_0_pre3
 
Changed:
<
<
cmsrel CMSSW_8_0_3_patch1

cd CMSSW_8_0_3_patch1/src

>
>
cd CMSSW_9_4_0_pre3/src
  cmsenv

git cms-addpkg Alignment/APEEstimation

Deleted:
<
<
git cms-addpkg Alignment/CommonAlignmentAlgorithm
 git cms-addpkg Alignment/TrackerAlignment

scram b

Revision 142018-01-10 - MariusTeroerde

Line: 1 to 1
 
META TOPICPARENT name="SWGuideAlignmentAlgorithms"

Alignment Position Error (APE) Estimator

Complete: 4
Line: 104 to 104
 

Configuration of the Refit

Changed:
<
<
The refit itself is also defined in Alignment/APEEstimation/python/TrackRefitter_38T_cff.py. There the CPE has to be specified by its ComponentName, which is for the one mentioned above WithGeometricAndTemplate. Very important parameters which might have an influence on the results are the ones steering the hit rejection (outliers and bad pixel template fits). Again, this can be overwritten in your specific configuration.
>
>
The refit itself is also defined in Alignment/APEEstimation/python/TrackRefitter_38T_cff.py. There the CPE has to be specified by its ComponentName, which is for the one mentioned above WithAngleAndTemplate. Very important parameters which might have an influence on the results are the ones steering the hit rejection (outliers and bad pixel template fits). Again, this can be overwritten in your specific configuration.
  For the refitter, a sequence is defined which needs to be included in the cfg.py, since the refit also needs the offlineBeamSpot. It also contains the selection of tracks flagged as of highPurity, since in many alignment tasks only those are selected, and so it is done here. There, one could also apply the track selection instead of within the ApeEstimator, but in the present configuration this is not done, it selects only for highPurity.
Line: 254 to 254
  If one wants to overlay the resulting APE values for different geometries, this can be done with the corresponding root-macro, no explicit script exists. The macro is Alignment/APEEstimation/macros/commandsDrawComparison.C.
Added:
>
>

Addtional Tools

The following tools are not needed for measuring Ape or creating validation plots but provide extra functions that are useful.

Writing and reading Ape payloads

Using Alignment/APEEstimation/test/createTrackerAlignmentErrorExtendedRcd_cfg.py, one can read/write Ape payloads from/to db files. This is useful if one wishes to define a custom Ape based on measurements. The Ape payloads themselves are configured in Alignment/APEEstimation/macros/writeAPEsInASCII.C, where one can set the individual Ape values for an arbitrary granularity. These values are then written to an ASCII file that is used by the cfg.py.

Writing Ape payload to Tree

In the case that one wishes to plot existing Ape payloads using the Ape comparison tools, these payloads have to be converted to .root format first. One possibility is to load one payload as reference in Alignment/APEEstimation/test/cfgTemplate/apeEstimatorSummary_cfg.py using ESPrefer. However this requires you to run at least one iteration of a measurement (including sending and retrieving batch jobs) and only allows for one Ape payload to be converted. For a more convenient workflow, Alignment/APEEstimation/test/apeTreeCreateDefault_cfg.py can be used. In this file, the used global tag, IOV and Ape tag can be specified along with the desired granularity. Note that all trees that are compared to each other need to have the same granularity with the same sector definitions. The sectors are defined in Alignment/APEEstimation/python/SectorBuilder_cff.py.

 

References

The method used for the APE estimation is described in the following two documents:

Revision 132017-11-13 - MariusTeroerde

Line: 1 to 1
 
META TOPICPARENT name="SWGuideAlignmentAlgorithms"

Alignment Position Error (APE) Estimator

Complete: 4
Line: 220 to 220
 
  • bash ../run10Iterations.bash
Changed:
<
<
if one finds that 10 iterations are sufficient. These scripts include sleep times to wait for the jobs on the batch farm to be finished. The time these jobs need might be different depending on the file size of the sample one is running on. Therefore, one should first test how long it takes for all jobs to finish and adapt the sleep time in the bash files accordingly (with some extra time as a reserve since in some cases single jobs might take longer than usual).
>
>
if one finds that 10 iterations are sufficient. These scripts automatically sleep until the sent batch jobs are finished. If one wishes to manually set the sleep time for batch jobs to finish, one can instead run

  • bash ../run10Iterations_manual.bash
  • bash ../run15Iterations_manual.bash

depending on the desired number of iterations.

 

Scripts producing Validation Plots

Revision 122016-04-08 - ChristianSchomakers

Line: 1 to 1
 
META TOPICPARENT name="SWGuideAlignmentAlgorithms"

Alignment Position Error (APE) Estimator

Complete: 4
Line: 11 to 11
 

Introduction

Changed:
<
<
The tool is called ApeEstimator and resides in Alignment/APEEstimation. The code is currently not yet in the official release, but should be included soon. Working versions can be found for CMSSW_7_4_X, CMSSW_7_5_X and CMSSW_7_6_X. It also uses subtools located in Alignment/CommonAlignmentAlgorithm, Alignment/CommonAlignmentProducer and Alignment/TrackerAlignment and contains several scripts to run the procedure and to produce validation plots.
>
>
The tool is called ApeEstimator and resides in Alignment/APEEstimation. The code was implemented into the official release in CMSSW_7_6_0. Working versions can be found for CMSSW_7_4_X, CMSSW_7_5_X. It also uses subtools located in Alignment/CommonAlignmentAlgorithm and Alignment/TrackerAlignment and contains several scripts to run the procedure and to produce validation plots.
 
Changed:
<
<

Latest working version of code for CMSSW_7_6_0_pre2

>
>

Recipe for CMSSW_8_0_X

 
Changed:
<
<
cmsrel CMSSW_7_6_0_pre2
>
>
export SCRAM_ARCH=slc6_amd64_gcc530
 
Changed:
<
<
cd CMSSW_7_6_0_pre2/src
>
>
cmsrel CMSSW_8_0_3_patch1

cd CMSSW_8_0_3_patch1/src

  cmsenv

Changed:
<
<
git pull https://github.com/cschomak/cmssw.git CMSSW_7_6_0_pre2_APETool
>
>
git cms-addpkg Alignment/APEEstimation

git cms-addpkg Alignment/CommonAlignmentAlgorithm

git cms-addpkg Alignment/TrackerAlignment

 
Changed:
<
<
scram b -j8
>
>
scram b
  cmsenv

Revision 112015-08-11 - ChristianSchomakers

Line: 1 to 1
 
META TOPICPARENT name="SWGuideAlignmentAlgorithms"

Alignment Position Error (APE) Estimator

Changed:
<
<
Complete: 3
>
>
Complete: 4
 
Line: 11 to 11
 

Introduction

Changed:
<
<
The tool is called ApeEstimator and is located in the /UserCode here. It contains several subtools needed in addition to the one which really calculates APE parameters, and several scripts to run the procedure and to produce validation plots.
>
>
The tool is called ApeEstimator and resides in Alignment/APEEstimation. The code is currently not yet in the official release, but should be included soon. Working versions can be found for CMSSW_7_4_X, CMSSW_7_5_X and CMSSW_7_6_X. It also uses subtools located in Alignment/CommonAlignmentAlgorithm, Alignment/CommonAlignmentProducer and Alignment/TrackerAlignment and contains several scripts to run the procedure and to produce validation plots.
 
Changed:
<
<

Latest working version of code for CMSSW_7_4_0_pre7 (Under development)

>
>

Latest working version of code for CMSSW_7_6_0_pre2

 
Changed:
<
<
cmsrel CMSSW_7_4_0_pre7
>
>
cmsrel CMSSW_7_6_0_pre2

cd CMSSW_7_6_0_pre2/src

  cmsenv

Changed:
<
<
git pull https://github.com/ajaykumar649/APETools.git testing
>
>
git pull https://github.com/cschomak/cmssw.git CMSSW_7_6_0_pre2_APETool
  scram b -j8
Line: 30 to 32
 If you want to run quickly the tool with the current configuration without knowing anything about details, you can read only Setting up the Tool, Scripts for Automated Workflow and Scripts producing Validation Plots, and read the other parts only if you need them.

Setting up the Tool

Added:
>
>
After setting up the CMSSW area, do the following:
 
Changed:
<
<
The current setup is tested and used with CMSSW_4_2_5. The recent tag is V02-01-03. After setting up the CMSSW area, do the following:

  • cvs co -r V02-01-03 -d Alignment UserCode/JohannesHauk/ApeAndCpeStudies/FullVersion/Alignment
  • cvs co -r V02-01-03 -d ApeEstimator UserCode/JohannesHauk/ApeAndCpeStudies/FullVersion/ApeEstimator
  • scram b
  • bash ApeEstimator/ApeEstimator/scripts/initialise.bash
>
>
  • bash Alignment/APEEstimation/scripts/initialise.bash
 
Changed:
<
<
The last command creates all relevant folders needed for the outputs, thus automated procedures in the scripts. It also copies some scripts for easier handling.
>
>
The command creates all relevant folders needed for the outputs, thus automated procedures in the scripts. It also copies some scripts for easier handling.
 
Changed:
<
<
Now, it is necessary to create a .root-file containing the TTree with all relevant information about the silicon modules of the tracker. This is done by a simple standalone tool, placed in Alignment/TrackerTreeGenerator, which uses the ideal geometry. The ideal geometry is chosen, since it guarantees that selections of modules via their position space coordinates chose always the same modules. E.g. TOB modules on the same rod have the same design position in phi, but misalignment could cause a selection choosing only some modules if the cut is by accident selected around the nominal position. The file is created with:
>
>
Now, it is necessary to create a .root-file containing the TTree with all relevant information about the silicon modules of the tracker. This is done by a simple standalone tool named TrackerTreeGenerator, placed in Alignment/TrackerAlignment, which uses the ideal geometry. The ideal geometry is chosen, since it guarantees that selections of modules via their position space coordinates chose always the same modules. E.g. TOB modules on the same rod have the same design position in phi, but misalignment could cause a selection choosing only some modules if the cut is by accident selected around the nominal position. The file is created with:
 
Changed:
<
<
  • cmsRun Alignment/TrackerTreeGenerator/test/trackerTreeGenerator_cfg.py
>
>
  • cmsRun Alignment/TrackerAlignment/test/trackerTreeGenerator_cfg.py
 
Changed:
<
<
The .root-file containing the TTree can be found and browsed in Alignment/TrackerTreeGenerator/hists/TrackerTree.root, and there it is read from in the APE calculation.
>
>
The .root-file containing the TTree can be found and browsed in Alignment/TrackerAlignment/hists/TrackerTree.root, and there it is read from in the APE calculation.
  Now, the tool is set up and the procedure for calculating APEs can be configured and started. However, in order to allow fast iterations and parallelisation, a private skim of the files which should be used is created, as explained in the following step.
Line: 52 to 50
 

Default Creation

Changed:
<
<
In order to allow parallelisation and fast iterations, a private skim of files is created from the AlCaReco files. The event content is minimised to the needs for the ApeEstimator, a tighter preselection is also applied, and the files are split in size for optimising between number of files and number of events inside. To do so, the file ApeEstimator/ApeEstimator/test/batch/skimProducer.bash is run on the batch farm. It uses the configuration in ApeEstimator/ApeEstimator/test/SkimProducer/skimProducer_cfg.py. There, the used track selection is defined in ApeEstimator/ApeEstimator/python/AlignmentTrackSelector_cff.py, and the trigger selection in ApeEstimator/ApeEstimator/python/TriggerSelection_cff.py. The event content is defined in ApeEstimator/ApeEstimator/python/PrivateSkim_EventContent_cff.py.
>
>
In order to allow parallelisation and fast iterations, a private skim of files is created from the AlCaReco files. The event content is minimised to the needs for the ApeEstimator, a tighter preselection is also applied, and the files are split in size for optimising between number of files and number of events inside. To do so, the file Alignment/APEEstimation/test/batch/skimProducer.bash is run on the batch farm. It uses the configuration in Alignment/APEEstimation/test/SkimProducer/skimProducer_cfg.py. There, the used track selection is defined in Alignment/APEEstimation/python/AlignmentTrackSelector_cff.py, and the trigger selection in Alignment/APEEstimation/python/TriggerSelection_cff.py. The event content is defined in Alignment/APEEstimation/python/PrivateSkim_EventContent_cff.py.
  Which dataset to process is steered via a configurable parameter using the VarParsing, which also allows a local test run.
Changed:
<
<
In order to have the file names correct for the automated workflow, it is necessary to run after the skim production the script ApeEstimator/ApeEstimator/test/SkimProducer/cmsRename.sh.
>
>
In order to have the file names correct for the automated workflow, it is necessary to run after the skim production the script Alignment/APEEstimation/test/SkimProducer/cmsRename.sh.
  After having run those two scripts for each dataset that one wants to process, the skim is ready for the automated workflow of the APE estimation.
Changed:
<
<
However, the folder of the CAF user diskpool to store the output, and later read it in, is not automised. This needs to be adjusted by the user.

Specific Creation using in addition a List of Good Tracks

In order to allow another event and track selection based on event contents which are already excluded in the AlCaReco files, the configuration defined in ApeEstimator/ApeEstimator/test/SkimProducer/skimProducer_cfg.py allows to read in a event-and-track list in a specific format. Thus, one can apply an event and track selection on the corresponding RECO file (if available...) or on the AOD file if the content is enough for the selection (should be always available), which can of course be done via CRAB.

The list is a TTree in a .root-file, several outputs in case of parallel processing can simply be merged using hadd. The corresponding tools for generating the list respectively reading in the list and select only chosen tracks are placed in ApeEstimator/Utils.

In fact this was used to produce the recent private skims on 2011 data placed in /store/caf/user/hauk/data/DoubleMu/ (the folder name is misleading, in fact the dataset is not obtained using DoubleMu triggers, but SingleMu triggers), and on 2011 MC placed in /store/caf/user/hauk/mc/Summer11/, since the old AlCaReco selection was not optimal (especially the selection on "isolated muons", which had a big fake rate); thus the new one which was applied later to the official streams is applied using this workaround.

>
>
However, the folder of the CAF user diskpool to store the output, and later read it in, is not automated. This needs to be adjusted by the user.
 

The APE Estimation Tool

In order to allow parallel processing, the tool is based on two different modules. The first one (ApeEstimator) reads the events and gathers all relevant information in several .root-files. The second one (ApeEstimatorSummary) then calculates the APE values afterwards, requiring to merge the files from the first step. The tool is automated and based on 4 scripts, which need to be run sequentially, starting the next one only after all actions initiated by the previous one have finished successfully. Since the method is a local method, iterations are necessary, so the chain needs to be repeated. In the following, the configuration of the two modules is explained, the scripts to run are explained in a later section.

Changed:
<
<
In general, all configurations should be done in your final blah_cfg.py. The files blah_cfi.py define the configurable parameters, mainly without doing any selection, and should never be changed, they are only templates. The files blah_cff.py give the default settings, and should only be changed in exceptional cases.
>
>
In general, all configurations should be done in your final apeEstimator_cfg.py, apeEstimatorSummary_cfg.py and apeEstimatorLocalSetting_cfg.py in Alignment/APEEstimation/test/cfTemplate. The _cfi.py files in Alignment/APEEstimation/python define the configurable parameters, mainly without doing any selection, and should never be changed, they are only templates. The _cff.py files in the same folder give the default settings, and should only be changed in exceptional cases.
 

Configuration of ApeEstimator

Changed:
<
<
The ApeEstimator module is coded in ApeEstimator/ApeEstimator/plugins/ApeEstimator.cc, having the configuration template in ApeEstimator/ApeEstimator/python/ApeEstimator_cfi.py with documentation of the configurable parameters, and the default settings in ApeEstimator/ApeEstimator/python/ApeEstimator_cff.py.
>
>
The ApeEstimator module is coded in Alignment/APEEstimation/plugins/ApeEstimator.cc, having the configuration template in Alignment/APEEstimation/python/ApeEstimator_cfi.py with documentation of the configurable parameters, and the default settings in Alignment/APEEstimation/python/ApeEstimator_cff.py.
 
Changed:
<
<
For testing purposes there is one configuration file ApeEstimator/ApeEstimator/test/testApeestimator_cfg.py, but the general configuration used in the automated workflow can be found elsewhere as explained later.
>
>
For testing purposes there is one configuration file Alignment/APEEstimation/test/testApeestimator_cfg.py, but the general configuration used in the automated workflow can be found elsewhere as explained later.
 

Event, Track and Hit Selections

Line: 99 to 89
 

Granularity of APEs: Sector Definition

Changed:
<
<
A group of modules which should be analysed combined, and for which the same APE value is calculated and assigned, is called "sector". The sectors can be defined based on all module information stored in the TTree produced by the standalone tool mentioned above. The sector definitions need to be given to the ApeEstimator using the parameter Sectors, which is a VPSet. An empty template, not selecting anything but defining all selection parameters, is in ApeEstimator/ApeEstimator/python/SectorBuilder_cfi.py, explaining the possible arguments. Each sector is defined as a PSet, already defined sectors for the subdetectors are given in ApeEstimator/ApeEstimator/python/SectorBuilder_Bpix_cff.py, ApeEstimator/ApeEstimator/python/SectorBuilder_Fpix_cff.py, ApeEstimator/ApeEstimator/python/SectorBuilder_Tib_cff.py, ApeEstimator/ApeEstimator/python/SectorBuilder_Tid_cff.py, ApeEstimator/ApeEstimator/python/SectorBuilder_Tob_cff.py, ApeEstimator/ApeEstimator/python/SectorBuilder_Tec_cff.py. Further subdefinitions should be built in the same way as shown there. It is important to assign to each sector a name reflecting clearly the exact definition, because this can be found in all .root-files and in printouts and also histogram names, in order to see which sector the results are for. All sector definitions are then gathered in the only file to include, ApeEstimator/ApeEstimator/python/SectorBuilder_cff.py. There, the two important sector definitions (VPSets) which are used at present can be found, it is ValidationSectors for the tool in analyzer mode having the full set of validation plots, and should contain only those sectors where one wants to have a closer look at, and RecentSectors, which defines the granularity for the APE calculations, and should span the whole tracker.
>
>
A group of modules which should be analysed combined, and for which the same APE value is calculated and assigned, is called "sector". The sectors can be defined based on all module information stored in the TTree produced by the standalone tool mentioned above. The sector definitions need to be given to the ApeEstimator using the parameter Sectors, which is a VPSet. An empty template, not selecting anything but defining all selection parameters, is in Alignment/APEEstimation/python/SectorBuilder_cfi.py, explaining the possible arguments. Each sector is defined as a PSet, already defined sectors for the subdetectors are given in SectorBuilder_Bpix_cff.py, SectorBuilder_Fpix_cff.py, SectorBuilder_Tib_cff.py, SectorBuilder_Tid_cff.py, SectorBuilder_Tob_cff.py, SectorBuilder_Tec_cff.py in Alignment/APEEstimation/python. Further subdefinitions should be built in the same way as shown there. It is important to assign to each sector a name reflecting clearly the exact definition, because this can be found in all .root-files and in printouts and also histogram names, in order to see which sector the results are for. All sector definitions are then gathered in the only file to include, Alignment/APEEstimation/python/SectorBuilder_cff.py. There, the two important sector definitions (VPSets) which are used at present can be found, it is ValidationSectors for the tool in analyzer mode having the full set of validation plots, and should contain only those sectors where one wants to have a closer look at, and RecentSectors, which defines the granularity for the APE calculations, and should span the whole tracker.
 

Configuration of the Cluster Parameter Estimator (CPE)

Changed:
<
<
The configuration of the CPE which should be used in the refit is given in ApeEstimator/ApeEstimator/python/TrackRefitter_38T_cff.py. There it is chosen which PixelCPE and which StripCPE should be used. The recent one in use is called TTRHBuilderGeometricAndTemplate, but of course the parameters can be changed also in the specific cfg.py, your configuration. But you need to ensure that it is also included in the refit definition, see below.
>
>
The configuration of the CPE which should be used in the refit is given in Alignment/APEEstimation/python/TrackRefitter_38T_cff.py. There it is chosen which PixelCPE and which StripCPE should be used. The recent one in use is called TTRHBuilderGeometricAndTemplate, but of course the parameters can be changed also in the specific cfg.py, your configuration. But you need to ensure that it is also included in the refit definition, see below.
 

Configuration of the Refit

Changed:
<
<
The refit itself is also defined in ApeEstimator/ApeEstimator/python/TrackRefitter_38T_cff.py. There the CPE has to be specified by its ComponentName, which is for the one mentioned above WithGeometricAndTemplate. Very important parameters which might have an influence on the results are the ones steering the hit rejection (outliers and bad pixel template fits). Again, this can be overwritten in your specific configuration.
>
>
The refit itself is also defined in Alignment/APEEstimation/python/TrackRefitter_38T_cff.py. There the CPE has to be specified by its ComponentName, which is for the one mentioned above WithGeometricAndTemplate. Very important parameters which might have an influence on the results are the ones steering the hit rejection (outliers and bad pixel template fits). Again, this can be overwritten in your specific configuration.
  For the refitter, a sequence is defined which needs to be included in the cfg.py, since the refit also needs the offlineBeamSpot. It also contains the selection of tracks flagged as of highPurity, since in many alignment tasks only those are selected, and so it is done here. There, one could also apply the track selection instead of within the ApeEstimator, but in the present configuration this is not done, it selects only for highPurity.
Line: 121 to 111
 

Configuration of ApeEstimatorSummary

Changed:
<
<
The ApeEstimator module is coded in ApeEstimator/ApeEstimator/plugins/ApeEstimatorSummary.cc, having the configuration template in ApeEstimator/ApeEstimator/python/ApeEstimatorSummary_cfi.py with documentation of the configurable parameters, and the default settings in ApeEstimator/ApeEstimator/python/ApeEstimatorSummary_cff.py. The module needs as input a file (parameter InputFile) produced with the ApeEstimator.
>
>
The ApeEstimator module is coded in Alignment/APEEstimation/plugins/ApeEstimatorSummary.cc, having the configuration template in Alignment/APEEstimation/python/ApeEstimatorSummary_cfi.py with documentation of the configurable parameters, and the default settings in Alignment/APEEstimation/python/ApeEstimatorSummary_cff.py. The module needs as input a file (parameter InputFile) produced with the ApeEstimator.
 
Changed:
<
<
For testing purposes there is one configuration file ApeEstimator/ApeEstimator/test/testApeestimatorSummary_cfg.py, but the general configuration used in the automated workflow can be found elsewhere as explained later.
>
>
For testing purposes there is one configuration file Alignment/APEEstimation/test/testApeestimatorSummary_cfg.py, but the general configuration used in the automated workflow can be found elsewhere as explained later.
 

Choose between Calculation of APEs or Setting the Baseline from Design MC

When setting the flag setBaseline = True, the nominal residual width for each defined sector is estimated. I.e. that not APE values are calculated, but the nominal residual width which returns exactly APE=0 is estimated. This should be done on design MC only, to get this as a reference instead of a fixed assumption of the nominal residual width. A .root-file containing a TTree is created, specified by parameter BaselineFile.

Changed:
<
<
If the flag is not set, APEs are calculated. If a baseline .root-file was produced and is specified by BaselineFile, then the nominal residual width is read from this file for each sector. If no such file is found, the assumption of residual width equal to 1 is used for each sector. The calculated APE values are also stored in a TTree of a .root-file, specified by IterationFile. However, this file is not created newly when you run the tool again, since it is used for iterations of the APE. If it is found, the last stored entry is assumed to be the squared APE as estimated in the previous iteration, and the estimated squared correction is added to it and gives the new APE, which is stored as new entry in the TTree. The APE values for each module contained in a sector are written to an ASCII-file specified by ApeOutputFile in the format needed to use the module Alignment/CommonAlignmentAlgorithm/python/ApeSettingAlgorithm_cfi.py to create a DB object. The configuration of the tool creating the DB object as it is used during the automated workflow can be found in ApeEstimator/ApeEstimator/test/cfgTemplate/apeLocalSetting_cfg.py.
>
>
If the flag is not set, APEs are calculated. If a baseline .root-file was produced and is specified by BaselineFile, then the nominal residual width is read from this file for each sector. If no such file is found, the assumption of residual width equal to 1 is used for each sector. The calculated APE values are also stored in a TTree of a .root-file, specified by IterationFile. However, this file is not created newly when you run the tool again, since it is used for iterations of the APE. If it is found, the last stored entry is assumed to be the squared APE as estimated in the previous iteration, and the estimated squared correction is added to it and gives the new APE, which is stored as new entry in the TTree. The APE values for each module contained in a sector are written to an ASCII-file specified by ApeOutputFile in the format needed to use the module Alignment/CommonAlignmentAlgorithm/python/ApeSettingAlgorithm_cfi.py to create a DB object. The configuration of the tool creating the DB object as it is used during the automated workflow can be found in Alignment/APEEstimation/test/cfgTemplate/apeLocalSetting_cfg.py.
 

Parameters steering the APE Calculation

Line: 145 to 135
 

Output

Changed:
<
<
The output of the tool are the following files. There is a .root-file containing a set of validation plots important for the APE estimate. In the mode setting the baseline, the baseline .root-file mentioned above is produced. In the mode for calculating the APE, the .root-file for the iterations of the APE value and the ASCII-file with the APE values used for producing a DB object as mentioned above is produced.
>
>
The output of the tool are the following files. There is a .root-file containing a set of validation plots important for the APE estimate. In the mode setting the baseline, the baseline .root-file mentioned above is produced. In the mode for calculating the APE, the .root-file for the iterations of the APE value and the ASCII-file with the APE values used for producing a DB object as mentioned above is produced. Additionally, a root file similar to the one for the iterations is included which contains the default APEs from the global tag before aplying the tool.
 

Scripts for Automated Workflow

The automated workflow is based on four scripts, which need to be run in the specific order, starting the next one only after all actions of the previous one have finished successfully. They are run for each iteration, and do the following action:

  • createStep1.bash iterationNumber [ lastIteration ]
Changed:
<
<
This produces all relevant scripts defining the ApeEstimator step. It creates scripts for parallel processing, one for each regarded skimmed file. The scripts can be found in ApeEstimator/ApeEstimator/test/batch/workingArea/. It is the only script which needs to be adjusted, the other three are identical for each possible operation. The samples which should be read, and the alignment geometry, are specified here. But in fact, there are only parameters specified which are then used in the config template ApeEstimator/ApeEstimator/test/cfgTemplate/apeEstimator_cfg.py, using the VarParsing. So what is really selected is coded in the config template.
>
>
This produces all relevant scripts defining the ApeEstimator step. It creates scripts for parallel processing, one for each regarded skimmed file. The scripts can be found in Alignment/APEEstimation/test/batch/workingArea/. It is the only script which needs to be adjusted, the other three are identical for each possible operation. The samples which should be read, and the alignment geometry, are specified here. But in fact, there are only parameters specified which are then used in the config template Alignment/APEEstimation/test/cfgTemplate/apeEstimator_cfg.py, using the VarParsing. So what is really selected is coded in the config template.
 
  • startStep1.bash
Changed:
<
<
The scripts produced in the previous step are sent to the batch farm, i.e. the ApeEstimator is run parallelised, based on the config template ApeEstimator/ApeEstimator/test/cfgTemplate/apeEstimator_cfg.py. In order to gain speed, the optimised skimmed files as explained above are copied to the batch machine and processed there locally. The output is stored in ApeEstimator/ApeEstimator/hists/workingArea/.
>
>
The scripts produced in the previous step are sent to the batch farm, i.e. the ApeEstimator is run parallelised, based on the config template Alignment/APEEstimation/test/cfgTemplate/apeEstimator_cfg.py. In order to gain speed, the optimised skimmed files as explained above are copied to the batch machine and processed there locally. The output is stored in Alignment/APEEstimation/hists/workingArea/.
 
  • createStep2.bash iterationNumber [ setBaseline ]
Changed:
<
<
This script does all necessary preparatory action for the final calculations. The final output directory is created which is specific for baseline setting or APE calculation mode, and in the latter case also to the iteration number. All .root-files which are the result of the first step are merged using hadd, the merged file is moved to the final output directory. The script needed for the second iteration is created, which is ApeEstimator/ApeEstimator/test/batch/workingArea/summary.bash. The script is based on the template ApeEstimator/ApeEstimator/test/cfgTemplate/summaryTemplate.bash. In case of iterations the .root-file containing the APE value of the previous iteration is copied to the final output directory.
>
>
This script does all necessary preparatory action for the final calculations. The final output directory is created which is specific for baseline setting or APE calculation mode, and in the latter case also to the iteration number. All .root-files which are the result of the first step are merged using hadd, the merged file is moved to the final output directory. The script needed for the second iteration is created, which is Alignment/APEEstimation/test/batch/workingArea/summary.bash. The script is based on the template Alignment/APEEstimation/test/cfgTemplate/summaryTemplate.bash. In case of iterations the .root-file containing the APE value of the previous iteration is copied to the final output directory.
 
  • startStep2.bash
Changed:
<
<
This script runs the script prepared in the previous step. This means running the ApeEstimatorSummary based on the template ApeEstimator/ApeEstimator/test/cfgTemplate/apeEstimatorSummary_cfg.py, and the output is stored in the final output directory created in the previous step. Furthermore, in case of APE calculation mode, it runs the creation of the DB object, based on the template ApeEstimator/ApeEstimator/test/cfgTemplate/apeLocalSetting_cfg.py. Finally it does a cleanup of all scripts used in this iteration (produced in the two create-steps). In case of the creation of a DB object for the APEs (APE calculation mode), the printout of the cmsRun job shows one error. This is expected, since the DB object creation is based on the AlignmentProducer, which is a generic tool and expects some information which is not given and not necessary for writing the APE object. The DB object should be created correctly.
>
>
This script runs the script prepared in the previous step. This means running the ApeEstimatorSummary based on the template Alignment/APEEstimation/test/cfgTemplate/apeEstimatorSummary_cfg.py, and the output is stored in the final output directory created in the previous step. Furthermore, in case of APE calculation mode, it runs the creation of the DB object, based on the template Alignment/APEEstimation/test/cfgTemplate/apeLocalSetting_cfg.py. Finally it does a cleanup of all scripts used in this iteration (produced in the two create-steps). In case of the creation of a DB object for the APEs (APE calculation mode), the printout of the cmsRun job shows one error. This is expected, since the DB object creation is based on the AlignmentProducer, which is a generic tool and expects some information which is not given and not necessary for writing the APE object. The DB object should be created correctly.
  The way of how to use these scripts is explained in the following for setting the baseline respectively calculating APEs.

Set Baseline from Design Simulation

Changed:
<
<
The scripts are in ApeEstimator/ApeEstimator/test/cfgTemplateDesign/. But only the createStep1.bash is also in this folder in CVS, the others are copied from ApeEstimator/ApeEstimator/test/cfgTemplate/, since they are identical for all possible operations.
>
>
The scripts are in Alignment/APEEstimation/test/cfgTemplateDesign/. But only the createStep1.bash is also in this folder in the release, the others are copied from Alignment/APEEstimation/test/cfgTemplate/, since they are identical for all possible operations.
  The scripts need to be run only once, since iterations make no sence for setting the baseline. Do the following steps:
Changed:
<
<
  • cd ApeEstimator/ApeEstimator/test/cfgTemplateDesign/workingArea/
>
>
  • cd Alignment/APEEstimation/test/cfgTemplateDesign/workingArea/
 
  • bash ../createStep1.bash 0
  • bash ../startStep1.bash
  • bash ../createStep2.bash 0 True
  • bash ../startStep2.bash
Changed:
<
<
The final output directory where all files end up is ApeEstimator/ApeEstimator/hists/Design/baseline/.
>
>
The final output directory where all files end up is Alignment/APEEstimation/hists/Design/baseline/.
 

Calculate APE Parameters

There is one directory prepared for calculating APEs on MC using misaligned geometries, and one directory for calculating APEs on data. Depending on what you want to analyse, do for MC:

Changed:
<
<
  • cd ApeEstimator/ApeEstimator/test/cfgTemplateMc/workingArea/
>
>
  • cd Alignment/APEEstimation/test/cfgTemplateMc/workingArea/
  or do for real data:
Changed:
<
<
  • cd ApeEstimator/ApeEstimator/test/cfgTemplateData/workingArea/
>
>
  • cd Alignment/APEEstimation/test/cfgTemplateData/workingArea/
 
Changed:
<
<
The relevant scripts are placed in this folder, but only the createStep1.bash is also in this folder in CVS, the others are copied from ApeEstimator/ApeEstimator/test/cfgTemplate/, since they are identical for all possible operations.
>
>
The relevant scripts are placed in this folder, but only the createStep1.bash is also in this folder in the release, the others are copied from Alignment/APEEstimation/test/cfgTemplate/, since they are identical for all possible operations.
  For all but the last iteration, do the following steps, where iterationNumber needs to be replaced by the number of the iteration, starting with 0:
Line: 210 to 200
  Be aware that the APE DB object of the iteration called iteration 14 is your final result, and not the APE DB object of the one called iteration 15!
Changed:
<
<
All output except of the DB object is stored in ApeEstimator/ApeEstimator/hists/workingArea/iter*/, where the * corresponds to the number of the given iteration.
>
>
All output except of the DB object is stored in Alignment/APEEstimation/hists/workingArea/iter*/, where the * corresponds to the number of the given iteration.
 The important ones are iter0 (containing the validations with zero APE), iter14 (containing the results concerning the estimated final APE values), and iter15 (containing the validations with the final APE).
Changed:
<
<
The DB objects are stored in ApeEstimator/ApeEstimator/hists/apeObjects/. Always use the one named apeIter14.db as final result, the one named apeIter15.db is only produced due to the automation.
>
>
The DB objects are stored in Alignment/APEEstimation/hists/apeObjects/. Always use the one named apeIter14.db as final result, the one named apeIter15.db is only produced due to the automation.

For a more automated workflow there are scripts which can be run via

  • bash ../run15Iterations.bash

or

  • bash ../run10Iterations.bash

if one finds that 10 iterations are sufficient. These scripts include sleep times to wait for the jobs on the batch farm to be finished. The time these jobs need might be different depending on the file size of the sample one is running on. Therefore, one should first test how long it takes for all jobs to finish and adapt the sleep time in the bash files accordingly (with some extra time as a reserve since in some cases single jobs might take longer than usual).

 

Scripts producing Validation Plots

Changed:
<
<
Scripts for producing validation plots based on root-macros can be found in ApeEstimator/ApeEstimator/macros/. There are two different scripts to run. First do:
>
>
Scripts for producing validation plots based on root-macros can be found in Alignment/APEEstimation/macros/. There are two different scripts to run. First do:
 
Changed:
<
<
  • cd ApeEstimator/ApeEstimator/macros/
>
>
  • cd Alignment/APEEstimation/macros/
  The first script produces all validation plots of iteration 0, and prints them in .pdf-files. This is done for the design MC (the baseline), and for the geometry under study (data or misaligned MC). They are mainly used for optimising the track and hit selection. These validation plots can only be obtained for the sectors which are defined in the analyzer mode module of the ApeEstimator, but there are also files with specific validation plots which are produced for each sector defined in the APE calculation of the ApeEstimator. To produce them run:

  • bash ./apeOverview.sh
Changed:
<
<
The output is stored in ApeEstimator/ApeEstimator/hists/plots/, the subfolder ideal/ contains those of the design MC, the subfolder data/ those of the geometry under study.
>
>
The output is stored in Alignment/APEEstimation/hists/plots/, the subfolder ideal/ contains those of the design MC, the subfolder data/ those of the geometry under study.
  The other script produces single .eps-files containing one histogram each, and overlays them for design geometry, and geometry under study. These are the most important plots, but others could in principle be added in the root-macros. To produce them run:

  • bash ./drawPlotAndIteration.sh
  • bash ./sortPlots.sh
Changed:
<
<
The output is stored in ApeEstimator/ApeEstimator/hists/workingArea/iter*/plots/, where the * stands for 0, 14 or 15, corresponding to the iteration where they are obtained from. They are sorted in subfolders. Important are the following plots in the following subfolders.
>
>
The output is stored in Alignment/APEEstimation/hists/workingArea/iter*/plots/, where the * stands for 0, 14 or 15, corresponding to the iteration where they are obtained from. They are sorted in subfolders. Important are the following plots in the following subfolders.
 
  • The calculated APE values can be found in iter14/plots/result/.
  • The important validation plots are in iter15/plots/Sector/ and iter15/plots/Track/.
Line: 240 to 240
  The last bullet (iter0) is not that important, since the distributions are also overaid in the the one above (iter15), together with the distributions of the final APE. But there the distributions are not scaled to integral, in order to see the absolute number of events/tracks/hits, thus the statistics of the modelling.
Changed:
<
<
If one wants to overlay the resulting APE values for different geometries, this can be done with the corresponding root-macro, no explicit script exists. The macro is ApeEstimator/ApeEstimator/macros/commandsDrawComparison.C.
>
>
If one wants to overlay the resulting APE values for different geometries, this can be done with the corresponding root-macro, no explicit script exists. The macro is Alignment/APEEstimation/macros/commandsDrawComparison.C.
 

References

Revision 102015-03-25 - AjayKumar

Line: 1 to 1
 
META TOPICPARENT name="SWGuideAlignmentAlgorithms"

Alignment Position Error (APE) Estimator

Changed:
<
<
Complete: 5
>
>
Complete: 3
 
Line: 13 to 13
  The tool is called ApeEstimator and is located in the /UserCode here. It contains several subtools needed in addition to the one which really calculates APE parameters, and several scripts to run the procedure and to produce validation plots.
Added:
>
>

Latest working version of code for CMSSW_7_4_0_pre7 (Under development)

cmsrel CMSSW_7_4_0_pre7

cmsenv

git pull https://github.com/ajaykumar649/APETools.git testing

scram b -j8

cmsenv

 If you want to run quickly the tool with the current configuration without knowing anything about details, you can read only Setting up the Tool, Scripts for Automated Workflow and Scripts producing Validation Plots, and read the other parts only if you need them.

Setting up the Tool

Revision 92014-05-02 - AjayKumar

Line: 1 to 1
 
META TOPICPARENT name="SWGuideAlignmentAlgorithms"

Alignment Position Error (APE) Estimator

Complete: 5

Revision 82012-12-12 - JohannesHauk

Line: 1 to 1
 
META TOPICPARENT name="SWGuideAlignmentAlgorithms"

Alignment Position Error (APE) Estimator

Complete: 5
Line: 233 to 233
 The method used for the APE estimation is described in the following two documents:

Changed:
<
<
  • PhD Thesis of Johannes Hauk "Measurement of Associated Z-Boson and b-Jet Production in Proton-Proton Collisions with the CMS Experiment"
>
>
  • PhD Thesis of Johannes Hauk "Measurement of Associated Z-Boson and b-Jet Production in Proton-Proton Collisions with the CMS Experiment"
 

-- JohannesHauk - 24-Jul-2012

Revision 72012-08-06 - JohannesHauk

Line: 1 to 1
 
META TOPICPARENT name="SWGuideAlignmentAlgorithms"

Alignment Position Error (APE) Estimator

Complete: 5
Line: 17 to 17
 

Setting up the Tool

Changed:
<
<
The current setup is tested and used with CMSSW_4_2_5. The recent tag is V02-01-02. After setting up the CMSSW area, do the following:
>
>
The current setup is tested and used with CMSSW_4_2_5. The recent tag is V02-01-03. After setting up the CMSSW area, do the following:
 
Changed:
<
<
  • cvs co -r V02-01-02 -d Alignment UserCode/JohannesHauk/ApeAndCpeStudies/FullVersion/Alignment
  • cvs co -r V02-01-02 -d ApeEstimator UserCode/JohannesHauk/ApeAndCpeStudies/FullVersion/ApeEstimator
>
>
  • cvs co -r V02-01-03 -d Alignment UserCode/JohannesHauk/ApeAndCpeStudies/FullVersion/Alignment
  • cvs co -r V02-01-03 -d ApeEstimator UserCode/JohannesHauk/ApeAndCpeStudies/FullVersion/ApeEstimator
 
  • scram b
  • bash ApeEstimator/ApeEstimator/scripts/initialise.bash

Revision 62012-07-31 - JohannesHauk

Line: 1 to 1
 
META TOPICPARENT name="SWGuideAlignmentAlgorithms"

Alignment Position Error (APE) Estimator

Complete: 5
Line: 17 to 17
 

Setting up the Tool

Changed:
<
<
The current setup is tested and used with CMSSW_4_2_5. The recent tag is V02-01-01. After setting up the CMSSW area, do the following:
>
>
The current setup is tested and used with CMSSW_4_2_5. The recent tag is V02-01-02. After setting up the CMSSW area, do the following:
 
Changed:
<
<
  • cvs co -r V02-01-01 -d Alignment UserCode/JohannesHauk/ApeAndCpeStudies/FullVersion/Alignment
  • cvs co -r V02-01-01 -d ApeEstimator UserCode/JohannesHauk/ApeAndCpeStudies/FullVersion/ApeEstimator
>
>
  • cvs co -r V02-01-02 -d Alignment UserCode/JohannesHauk/ApeAndCpeStudies/FullVersion/Alignment
  • cvs co -r V02-01-02 -d ApeEstimator UserCode/JohannesHauk/ApeAndCpeStudies/FullVersion/ApeEstimator
 
  • scram b
  • bash ApeEstimator/ApeEstimator/scripts/initialise.bash
Line: 147 to 147
 This script does all necessary preparatory action for the final calculations. The final output directory is created which is specific for baseline setting or APE calculation mode, and in the latter case also to the iteration number. All .root-files which are the result of the first step are merged using hadd, the merged file is moved to the final output directory. The script needed for the second iteration is created, which is ApeEstimator/ApeEstimator/test/batch/workingArea/summary.bash. The script is based on the template ApeEstimator/ApeEstimator/test/cfgTemplate/summaryTemplate.bash. In case of iterations the .root-file containing the APE value of the previous iteration is copied to the final output directory.

  • startStep2.bash
Changed:
<
<
This script runs the script prepared in the previous step. This means running the ApeEstimatorSummary based on the template ApeEstimator/ApeEstimator/test/cfgTemplate/apeEstimatorSummary_cfg.py, and the output is stored in the final output directory created in the previous step. Furthermore, in case of APE calculation mode, it runs the creation of the DB object, based on the template ApeEstimator/ApeEstimator/test/cfgTemplate/apeLocalSetting_cfg.py. Finally it does a cleanup of all scripts used in this iteration (produced in the two create-steps).
>
>
This script runs the script prepared in the previous step. This means running the ApeEstimatorSummary based on the template ApeEstimator/ApeEstimator/test/cfgTemplate/apeEstimatorSummary_cfg.py, and the output is stored in the final output directory created in the previous step. Furthermore, in case of APE calculation mode, it runs the creation of the DB object, based on the template ApeEstimator/ApeEstimator/test/cfgTemplate/apeLocalSetting_cfg.py. Finally it does a cleanup of all scripts used in this iteration (produced in the two create-steps). In case of the creation of a DB object for the APEs (APE calculation mode), the printout of the cmsRun job shows one error. This is expected, since the DB object creation is based on the AlignmentProducer, which is a generic tool and expects some information which is not given and not necessary for writing the APE object. The DB object should be created correctly.
  The way of how to use these scripts is explained in the following for setting the baseline respectively calculating APEs.
Line: 196 to 196
  Be aware that the APE DB object of the iteration called iteration 14 is your final result, and not the APE DB object of the one called iteration 15!
Changed:
<
<
All output except of the DB object is stored in ApeEstimator/ApeEstimator/hists/workingArea/iter*, where the * corresponds to the number of the given iteration.
>
>
All output except of the DB object is stored in ApeEstimator/ApeEstimator/hists/workingArea/iter*/, where the * corresponds to the number of the given iteration.
 The important ones are iter0 (containing the validations with zero APE), iter14 (containing the results concerning the estimated final APE values), and iter15 (containing the validations with the final APE).

The DB objects are stored in ApeEstimator/ApeEstimator/hists/apeObjects/. Always use the one named apeIter14.db as final result, the one named apeIter15.db is only produced due to the automation.

Revision 52012-07-26 - JohannesHauk

Line: 1 to 1
 
META TOPICPARENT name="SWGuideAlignmentAlgorithms"

Alignment Position Error (APE) Estimator

Changed:
<
<
Complete: 4
>
>
Complete: 5
 
Line: 17 to 17
 

Setting up the Tool

Changed:
<
<
The current setup is tested and used with CMSSW_4_2_5. The recent tag is V02-01-00. After setting up the CMSSW area, do the following:
>
>
The current setup is tested and used with CMSSW_4_2_5. The recent tag is V02-01-01. After setting up the CMSSW area, do the following:
 
Changed:
<
<
  • cvs co -r V02-01-00 -d Alignment UserCode/JohannesHauk/ApeAndCpeStudies/FullVersion/Alignment
  • cvs co -r V02-01-00 -d ApeEstimator UserCode/JohannesHauk/ApeAndCpeStudies/FullVersion/ApeEstimator
>
>
  • cvs co -r V02-01-01 -d Alignment UserCode/JohannesHauk/ApeAndCpeStudies/FullVersion/Alignment
  • cvs co -r V02-01-01 -d ApeEstimator UserCode/JohannesHauk/ApeAndCpeStudies/FullVersion/ApeEstimator
 
  • scram b
  • bash ApeEstimator/ApeEstimator/scripts/initialise.bash
Line: 199 to 199
 All output except of the DB object is stored in ApeEstimator/ApeEstimator/hists/workingArea/iter*, where the * corresponds to the number of the given iteration. The important ones are iter0 (containing the validations with zero APE), iter14 (containing the results concerning the estimated final APE values), and iter15 (containing the validations with the final APE).
Changed:
<
<
FIXME: where to store DB objects, and always use the one of iteration 14 as final result
>
>
The DB objects are stored in ApeEstimator/ApeEstimator/hists/apeObjects/. Always use the one named apeIter14.db as final result, the one named apeIter15.db is only produced due to the automation.
 

Scripts producing Validation Plots

Line: 229 to 228
  If one wants to overlay the resulting APE values for different geometries, this can be done with the corresponding root-macro, no explicit script exists. The macro is ApeEstimator/ApeEstimator/macros/commandsDrawComparison.C.
Added:
>
>

References

The method used for the APE estimation is described in the following two documents:

  • AN 2012/235 (link needs iCMS login)
  • PhD Thesis of Johannes Hauk "Measurement of Associated Z-Boson and b-Jet Production in Proton-Proton Collisions with the CMS Experiment"
 

-- JohannesHauk - 24-Jul-2012

Revision 42012-07-26 - JohannesHauk

Line: 1 to 1
 
META TOPICPARENT name="SWGuideAlignmentAlgorithms"

Alignment Position Error (APE) Estimator

Complete: 4
Line: 176 to 176
 
  • cd ApeEstimator/ApeEstimator/test/cfgTemplateData/workingArea/
Added:
>
>
The relevant scripts are placed in this folder, but only the createStep1.bash is also in this folder in CVS, the others are copied from ApeEstimator/ApeEstimator/test/cfgTemplate/, since they are identical for all possible operations.
 For all but the last iteration, do the following steps, where iterationNumber needs to be replaced by the number of the iteration, starting with 0:

  • bash ../createStep1.bash iterationNumber
Line: 225 to 227
  The last bullet (iter0) is not that important, since the distributions are also overaid in the the one above (iter15), together with the distributions of the final APE. But there the distributions are not scaled to integral, in order to see the absolute number of events/tracks/hits, thus the statistics of the modelling.
Added:
>
>
If one wants to overlay the resulting APE values for different geometries, this can be done with the corresponding root-macro, no explicit script exists. The macro is ApeEstimator/ApeEstimator/macros/commandsDrawComparison.C.
 

-- JohannesHauk - 24-Jul-2012

Revision 32012-07-25 - JohannesHauk

Line: 1 to 1
 
META TOPICPARENT name="SWGuideAlignmentAlgorithms"

Alignment Position Error (APE) Estimator

Complete: 4
Line: 13 to 13
  The tool is called ApeEstimator and is located in the /UserCode here. It contains several subtools needed in addition to the one which really calculates APE parameters, and several scripts to run the procedure and to produce validation plots.
Changed:
<
<

Setting up the tool

>
>
If you want to run quickly the tool with the current configuration without knowing anything about details, you can read only Setting up the Tool, Scripts for Automated Workflow and Scripts producing Validation Plots, and read the other parts only if you need them.

Setting up the Tool

  The current setup is tested and used with CMSSW_4_2_5. The recent tag is V02-01-00. After setting up the CMSSW area, do the following:
Line: 79 to 81
 

Choose between APE Calculation and Control Plots

Changed:
<
<
Furthermore, there are two important switches, since the module can be used for the calculation of APE values, but also as analyzer only, producing zillions of control plots. Calculating APEs is defined in the cff.py as the module ApeEstimator, setting the switch calculateApe = True. Using the analyzer is defined in the cff.py as the module ApeAnalyzer, setting the switch analyzerMode = True. In principle, one could use both things simultaneously in one module, but this often makes no sense due to the sector definitions explained later: the APEs should be calculated for the whole tracker, while the huge amount of detailed validation plots should be chosen for some exemplary regions. The APE calculation also contains some validation plots which are in principle not necessary for the calculation, but since these are the most important basic validation plots, they are implemented there in order to understand the general quality of the estimated APEs.
>
>
Furthermore, there are two important switches, since the module can be used for the calculation of APE values, but also as analyzer only, producing zillions of control plots, including plots for track parameters. Calculating APEs is defined in the cff.py as the module ApeEstimator, setting the switch calculateApe = True. Using the analyzer is defined in the cff.py as the module ApeAnalyzer, setting the switch analyzerMode = True. In principle, one could use both things simultaneously in one module, but this often makes no sense due to the sector definitions explained later: the APEs should be calculated for the whole tracker, while the huge amount of detailed validation plots should be chosen for some exemplary regions. The APE calculation also contains some validation plots which are in principle not necessary for the calculation, but since these are the most important basic validation plots, they are implemented there in order to understand the general quality of the estimated APEs.
 

Granularity of APEs: Sector Definition

Line: 105 to 107
 

Configuration of ApeEstimatorSummary

Added:
>
>
The ApeEstimator module is coded in ApeEstimator/ApeEstimator/plugins/ApeEstimatorSummary.cc, having the configuration template in ApeEstimator/ApeEstimator/python/ApeEstimatorSummary_cfi.py with documentation of the configurable parameters, and the default settings in ApeEstimator/ApeEstimator/python/ApeEstimatorSummary_cff.py. The module needs as input a file (parameter InputFile) produced with the ApeEstimator.

For testing purposes there is one configuration file ApeEstimator/ApeEstimator/test/testApeestimatorSummary_cfg.py, but the general configuration used in the automated workflow can be found elsewhere as explained later.

Choose between Calculation of APEs or Setting the Baseline from Design MC

When setting the flag setBaseline = True, the nominal residual width for each defined sector is estimated. I.e. that not APE values are calculated, but the nominal residual width which returns exactly APE=0 is estimated. This should be done on design MC only, to get this as a reference instead of a fixed assumption of the nominal residual width. A .root-file containing a TTree is created, specified by parameter BaselineFile.

If the flag is not set, APEs are calculated. If a baseline .root-file was produced and is specified by BaselineFile, then the nominal residual width is read from this file for each sector. If no such file is found, the assumption of residual width equal to 1 is used for each sector. The calculated APE values are also stored in a TTree of a .root-file, specified by IterationFile. However, this file is not created newly when you run the tool again, since it is used for iterations of the APE. If it is found, the last stored entry is assumed to be the squared APE as estimated in the previous iteration, and the estimated squared correction is added to it and gives the new APE, which is stored as new entry in the TTree. The APE values for each module contained in a sector are written to an ASCII-file specified by ApeOutputFile in the format needed to use the module Alignment/CommonAlignmentAlgorithm/python/ApeSettingAlgorithm_cfi.py to create a DB object. The configuration of the tool creating the DB object as it is used during the automated workflow can be found in ApeEstimator/ApeEstimator/test/cfgTemplate/apeLocalSetting_cfg.py.

Parameters steering the APE Calculation

How the weight of the individual intervals in the residual resolution for the APE calculation within one sector should be estimated is specified by apeWeight, where the variant with "entriesOverSigmaX2" works best.

The minimum number of hits for using an interval in the calculation is defined by minHitsPerInterval.

The parameter sigmaFactorFit was used earlier to use a two-step Gaussian fit procedure, but it caused some instabilities due to obvious non-Gaussian behaviour in several intervals. Thus it is not used at all in the present implementation of the code, except for additional plots. In the recent implementation, a Gaussian is fit to each residual distribution in each interval spanning the full range. This second fit should then fit only the core, with +- the specified factor times the width of the first fit around the mean of the first fit.

The parameter correctionScaling is used as the damping factor to avoid overestimations and thus convergence problems due to the correlations of the APEs of all modules penetrated by a track. The estimated squared correction is scaled with this factor.

 
Added:
>
>
The two parameters smoothIteration and smoothFraction should not be used and removed from the code. This was another implementation of the damping factor for the iterations, which is mathematically equivalent.
 
Added:
>
>

Output

The output of the tool are the following files. There is a .root-file containing a set of validation plots important for the APE estimate. In the mode setting the baseline, the baseline .root-file mentioned above is produced. In the mode for calculating the APE, the .root-file for the iterations of the APE value and the ASCII-file with the APE values used for producing a DB object as mentioned above is produced.

Scripts for Automated Workflow

The automated workflow is based on four scripts, which need to be run in the specific order, starting the next one only after all actions of the previous one have finished successfully. They are run for each iteration, and do the following action:

  • createStep1.bash iterationNumber [ lastIteration ]
This produces all relevant scripts defining the ApeEstimator step. It creates scripts for parallel processing, one for each regarded skimmed file. The scripts can be found in ApeEstimator/ApeEstimator/test/batch/workingArea/. It is the only script which needs to be adjusted, the other three are identical for each possible operation. The samples which should be read, and the alignment geometry, are specified here. But in fact, there are only parameters specified which are then used in the config template ApeEstimator/ApeEstimator/test/cfgTemplate/apeEstimator_cfg.py, using the VarParsing. So what is really selected is coded in the config template.
 
Added:
>
>
  • startStep1.bash
The scripts produced in the previous step are sent to the batch farm, i.e. the ApeEstimator is run parallelised, based on the config template ApeEstimator/ApeEstimator/test/cfgTemplate/apeEstimator_cfg.py. In order to gain speed, the optimised skimmed files as explained above are copied to the batch machine and processed there locally. The output is stored in ApeEstimator/ApeEstimator/hists/workingArea/.
 
Changed:
<
<

Scripts for automated workflow

>
>
  • createStep2.bash iterationNumber [ setBaseline ]
This script does all necessary preparatory action for the final calculations. The final output directory is created which is specific for baseline setting or APE calculation mode, and in the latter case also to the iteration number. All .root-files which are the result of the first step are merged using hadd, the merged file is moved to the final output directory. The script needed for the second iteration is created, which is ApeEstimator/ApeEstimator/test/batch/workingArea/summary.bash. The script is based on the template ApeEstimator/ApeEstimator/test/cfgTemplate/summaryTemplate.bash. In case of iterations the .root-file containing the APE value of the previous iteration is copied to the final output directory.

  • startStep2.bash
This script runs the script prepared in the previous step. This means running the ApeEstimatorSummary based on the template ApeEstimator/ApeEstimator/test/cfgTemplate/apeEstimatorSummary_cfg.py, and the output is stored in the final output directory created in the previous step. Furthermore, in case of APE calculation mode, it runs the creation of the DB object, based on the template ApeEstimator/ApeEstimator/test/cfgTemplate/apeLocalSetting_cfg.py. Finally it does a cleanup of all scripts used in this iteration (produced in the two create-steps).

The way of how to use these scripts is explained in the following for setting the baseline respectively calculating APEs.

 

Set Baseline from Design Simulation

Added:
>
>
The scripts are in ApeEstimator/ApeEstimator/test/cfgTemplateDesign/. But only the createStep1.bash is also in this folder in CVS, the others are copied from ApeEstimator/ApeEstimator/test/cfgTemplate/, since they are identical for all possible operations.

The scripts need to be run only once, since iterations make no sence for setting the baseline. Do the following steps:

  • cd ApeEstimator/ApeEstimator/test/cfgTemplateDesign/workingArea/
  • bash ../createStep1.bash 0
  • bash ../startStep1.bash
  • bash ../createStep2.bash 0 True
  • bash ../startStep2.bash

The final output directory where all files end up is ApeEstimator/ApeEstimator/hists/Design/baseline/.

 

Calculate APE Parameters

Added:
>
>
There is one directory prepared for calculating APEs on MC using misaligned geometries, and one directory for calculating APEs on data. Depending on what you want to analyse, do for MC:

  • cd ApeEstimator/ApeEstimator/test/cfgTemplateMc/workingArea/

or do for real data:

  • cd ApeEstimator/ApeEstimator/test/cfgTemplateData/workingArea/

For all but the last iteration, do the following steps, where iterationNumber needs to be replaced by the number of the iteration, starting with 0:

  • bash ../createStep1.bash iterationNumber
  • bash ../startStep1.bash
  • bash ../createStep2.bash iterationNumber
  • bash ../startStep2.bash

For the last iteration, do:

  • bash ../createStep1.bash iterationNumber True
  • bash ../startStep1.bash
  • bash ../createStep2.bash iterationNumber
  • bash ../startStep2.bash

In the first iteration (called iteration 0), also validation plots of the analyzer mode of ApeEstimator are created automatically. During the iterations, this is not done, only the relevant things for the iterations are produced. If you specified your last iteration as stated above, again a set of validation plots is created. This allows the comparison and the automated production (see later) of validation plots, comparing the distributions before iterations (with APE=0) to distributions after iterations (final APE as estimated by the tool). The tool is normally used with 15 iterations, so running iteration 0,...14 with the first set of commands, and then running iteration 15 with the second set of commands. This very last iteration (called iteration 15) is not to do another iteration, but to get the validation on the APE after the 15 iterations 0,...14. If you would like to use another number of iterations, it is not a problem, but some of the automated scripts producing validation plots as explained later need to be adjusted.

 
Added:
>
>
Be aware that the APE DB object of the iteration called iteration 14 is your final result, and not the APE DB object of the one called iteration 15!

All output except of the DB object is stored in ApeEstimator/ApeEstimator/hists/workingArea/iter*, where the * corresponds to the number of the given iteration. The important ones are iter0 (containing the validations with zero APE), iter14 (containing the results concerning the estimated final APE values), and iter15 (containing the validations with the final APE).

FIXME: where to store DB objects, and always use the one of iteration 14 as final result

 

Scripts producing Validation Plots

Added:
>
>
Scripts for producing validation plots based on root-macros can be found in ApeEstimator/ApeEstimator/macros/. There are two different scripts to run. First do:

  • cd ApeEstimator/ApeEstimator/macros/

The first script produces all validation plots of iteration 0, and prints them in .pdf-files. This is done for the design MC (the baseline), and for the geometry under study (data or misaligned MC). They are mainly used for optimising the track and hit selection. These validation plots can only be obtained for the sectors which are defined in the analyzer mode module of the ApeEstimator, but there are also files with specific validation plots which are produced for each sector defined in the APE calculation of the ApeEstimator. To produce them run:

  • bash ./apeOverview.sh

The output is stored in ApeEstimator/ApeEstimator/hists/plots/, the subfolder ideal/ contains those of the design MC, the subfolder data/ those of the geometry under study.

The other script produces single .eps-files containing one histogram each, and overlays them for design geometry, and geometry under study. These are the most important plots, but others could in principle be added in the root-macros. To produce them run:

  • bash ./drawPlotAndIteration.sh
  • bash ./sortPlots.sh

The output is stored in ApeEstimator/ApeEstimator/hists/workingArea/iter*/plots/, where the * stands for 0, 14 or 15, corresponding to the iteration where they are obtained from. They are sorted in subfolders. Important are the following plots in the following subfolders.

  • The calculated APE values can be found in iter14/plots/result/.
  • The important validation plots are in iter15/plots/Sector/ and iter15/plots/Track/.
  • For the modelling of data, look at iter0/plots/Sector/ and iter0/plots/Track/.
 
Added:
>
>
The last bullet (iter0) is not that important, since the distributions are also overaid in the the one above (iter15), together with the distributions of the final APE. But there the distributions are not scaled to integral, in order to see the absolute number of events/tracks/hits, thus the statistics of the modelling.
 

Revision 22012-07-25 - JohannesHauk

Line: 1 to 1
 
META TOPICPARENT name="SWGuideAlignmentAlgorithms"

Alignment Position Error (APE) Estimator

Complete: 4
Line: 67 to 67
  The ApeEstimator module is coded in ApeEstimator/ApeEstimator/plugins/ApeEstimator.cc, having the configuration template in ApeEstimator/ApeEstimator/python/ApeEstimator_cfi.py with documentation of the configurable parameters, and the default settings in ApeEstimator/ApeEstimator/python/ApeEstimator_cff.py.
Changed:
<
<
FIXME: For testing purposes one cfg file, but general cfg placed in cfgTemplate
>
>
For testing purposes there is one configuration file ApeEstimator/ApeEstimator/test/testApeestimator_cfg.py, but the general configuration used in the automated workflow can be found elsewhere as explained later.
 

Event, Track and Hit Selections

Line: 83 to 83
 

Granularity of APEs: Sector Definition

Added:
>
>
A group of modules which should be analysed combined, and for which the same APE value is calculated and assigned, is called "sector". The sectors can be defined based on all module information stored in the TTree produced by the standalone tool mentioned above. The sector definitions need to be given to the ApeEstimator using the parameter Sectors, which is a VPSet. An empty template, not selecting anything but defining all selection parameters, is in ApeEstimator/ApeEstimator/python/SectorBuilder_cfi.py, explaining the possible arguments. Each sector is defined as a PSet, already defined sectors for the subdetectors are given in ApeEstimator/ApeEstimator/python/SectorBuilder_Bpix_cff.py, ApeEstimator/ApeEstimator/python/SectorBuilder_Fpix_cff.py, ApeEstimator/ApeEstimator/python/SectorBuilder_Tib_cff.py, ApeEstimator/ApeEstimator/python/SectorBuilder_Tid_cff.py, ApeEstimator/ApeEstimator/python/SectorBuilder_Tob_cff.py, ApeEstimator/ApeEstimator/python/SectorBuilder_Tec_cff.py. Further subdefinitions should be built in the same way as shown there. It is important to assign to each sector a name reflecting clearly the exact definition, because this can be found in all .root-files and in printouts and also histogram names, in order to see which sector the results are for. All sector definitions are then gathered in the only file to include, ApeEstimator/ApeEstimator/python/SectorBuilder_cff.py. There, the two important sector definitions (VPSets) which are used at present can be found, it is ValidationSectors for the tool in analyzer mode having the full set of validation plots, and should contain only those sectors where one wants to have a closer look at, and RecentSectors, which defines the granularity for the APE calculations, and should span the whole tracker.

Configuration of the Cluster Parameter Estimator (CPE)

The configuration of the CPE which should be used in the refit is given in ApeEstimator/ApeEstimator/python/TrackRefitter_38T_cff.py. There it is chosen which PixelCPE and which StripCPE should be used. The recent one in use is called TTRHBuilderGeometricAndTemplate, but of course the parameters can be changed also in the specific cfg.py, your configuration. But you need to ensure that it is also included in the refit definition, see below.

 

Configuration of the Refit

Added:
>
>
The refit itself is also defined in ApeEstimator/ApeEstimator/python/TrackRefitter_38T_cff.py. There the CPE has to be specified by its ComponentName, which is for the one mentioned above WithGeometricAndTemplate. Very important parameters which might have an influence on the results are the ones steering the hit rejection (outliers and bad pixel template fits). Again, this can be overwritten in your specific configuration.
 
Changed:
<
<

Configuration of the CPE

>
>
For the refitter, a sequence is defined which needs to be included in the cfg.py, since the refit also needs the offlineBeamSpot. It also contains the selection of tracks flagged as of highPurity, since in many alignment tasks only those are selected, and so it is done here. There, one could also apply the track selection instead of within the ApeEstimator, but in the present configuration this is not done, it selects only for highPurity.
 
Added:
>
>

Configuration of the Geometry and the GlobalTag

 
Changed:
<
<

Configuration of the Geometry

>
>
The global tag and the geometry need to be specified in the cfg.py. But never change the APE, this always has to be the design one with zero APE everywhere. During the iterations of the automated workflow, the correct APE object as created in the previous iteration is taken automatically.
 
Added:
>
>

Output

 
Added:
>
>
The final output of the ApeEstimator is one file containing the relevant distributions for the second step, the ApeEstimatorSummary, and all validation plots. The output is structured in numerated folders for the defined sectors. Within each folder there is a histogram z_name, which contains only the name given to the sector and allows its identification.
 

Configuration of ApeEstimatorSummary

Revision 12012-07-24 - JohannesHauk

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="SWGuideAlignmentAlgorithms"

Alignment Position Error (APE) Estimator

Complete: 4

Goal of this page

Description of the configuration and operation of the tool for estimating the Alignment Position Error (APE).

Introduction

The tool is called ApeEstimator and is located in the /UserCode here. It contains several subtools needed in addition to the one which really calculates APE parameters, and several scripts to run the procedure and to produce validation plots.

Setting up the tool

The current setup is tested and used with CMSSW_4_2_5. The recent tag is V02-01-00. After setting up the CMSSW area, do the following:

  • cvs co -r V02-01-00 -d Alignment UserCode/JohannesHauk/ApeAndCpeStudies/FullVersion/Alignment
  • cvs co -r V02-01-00 -d ApeEstimator UserCode/JohannesHauk/ApeAndCpeStudies/FullVersion/ApeEstimator
  • scram b
  • bash ApeEstimator/ApeEstimator/scripts/initialise.bash

The last command creates all relevant folders needed for the outputs, thus automated procedures in the scripts. It also copies some scripts for easier handling.

Now, it is necessary to create a .root-file containing the TTree with all relevant information about the silicon modules of the tracker. This is done by a simple standalone tool, placed in Alignment/TrackerTreeGenerator, which uses the ideal geometry. The ideal geometry is chosen, since it guarantees that selections of modules via their position space coordinates chose always the same modules. E.g. TOB modules on the same rod have the same design position in phi, but misalignment could cause a selection choosing only some modules if the cut is by accident selected around the nominal position. The file is created with:

  • cmsRun Alignment/TrackerTreeGenerator/test/trackerTreeGenerator_cfg.py

The .root-file containing the TTree can be found and browsed in Alignment/TrackerTreeGenerator/hists/TrackerTree.root, and there it is read from in the APE calculation.

Now, the tool is set up and the procedure for calculating APEs can be configured and started. However, in order to allow fast iterations and parallelisation, a private skim of the files which should be used is created, as explained in the following step.

Creation of Private Skim

Default Creation

In order to allow parallelisation and fast iterations, a private skim of files is created from the AlCaReco files. The event content is minimised to the needs for the ApeEstimator, a tighter preselection is also applied, and the files are split in size for optimising between number of files and number of events inside. To do so, the file ApeEstimator/ApeEstimator/test/batch/skimProducer.bash is run on the batch farm. It uses the configuration in ApeEstimator/ApeEstimator/test/SkimProducer/skimProducer_cfg.py. There, the used track selection is defined in ApeEstimator/ApeEstimator/python/AlignmentTrackSelector_cff.py, and the trigger selection in ApeEstimator/ApeEstimator/python/TriggerSelection_cff.py. The event content is defined in ApeEstimator/ApeEstimator/python/PrivateSkim_EventContent_cff.py.

Which dataset to process is steered via a configurable parameter using the VarParsing, which also allows a local test run.

In order to have the file names correct for the automated workflow, it is necessary to run after the skim production the script ApeEstimator/ApeEstimator/test/SkimProducer/cmsRename.sh.

After having run those two scripts for each dataset that one wants to process, the skim is ready for the automated workflow of the APE estimation. However, the folder of the CAF user diskpool to store the output, and later read it in, is not automised. This needs to be adjusted by the user.

Specific Creation using in addition a List of Good Tracks

In order to allow another event and track selection based on event contents which are already excluded in the AlCaReco files, the configuration defined in ApeEstimator/ApeEstimator/test/SkimProducer/skimProducer_cfg.py allows to read in a event-and-track list in a specific format. Thus, one can apply an event and track selection on the corresponding RECO file (if available...) or on the AOD file if the content is enough for the selection (should be always available), which can of course be done via CRAB.

The list is a TTree in a .root-file, several outputs in case of parallel processing can simply be merged using hadd. The corresponding tools for generating the list respectively reading in the list and select only chosen tracks are placed in ApeEstimator/Utils.

In fact this was used to produce the recent private skims on 2011 data placed in /store/caf/user/hauk/data/DoubleMu/ (the folder name is misleading, in fact the dataset is not obtained using DoubleMu triggers, but SingleMu triggers), and on 2011 MC placed in /store/caf/user/hauk/mc/Summer11/, since the old AlCaReco selection was not optimal (especially the selection on "isolated muons", which had a big fake rate); thus the new one which was applied later to the official streams is applied using this workaround.

The APE Estimation Tool

In order to allow parallel processing, the tool is based on two different modules. The first one (ApeEstimator) reads the events and gathers all relevant information in several .root-files. The second one (ApeEstimatorSummary) then calculates the APE values afterwards, requiring to merge the files from the first step. The tool is automated and based on 4 scripts, which need to be run sequentially, starting the next one only after all actions initiated by the previous one have finished successfully. Since the method is a local method, iterations are necessary, so the chain needs to be repeated. In the following, the configuration of the two modules is explained, the scripts to run are explained in a later section.

In general, all configurations should be done in your final blah_cfg.py. The files blah_cfi.py define the configurable parameters, mainly without doing any selection, and should never be changed, they are only templates. The files blah_cff.py give the default settings, and should only be changed in exceptional cases.

Configuration of ApeEstimator

The ApeEstimator module is coded in ApeEstimator/ApeEstimator/plugins/ApeEstimator.cc, having the configuration template in ApeEstimator/ApeEstimator/python/ApeEstimator_cfi.py with documentation of the configurable parameters, and the default settings in ApeEstimator/ApeEstimator/python/ApeEstimator_cff.py.

FIXME: For testing purposes one cfg file, but general cfg placed in cfgTemplate

Event, Track and Hit Selections

The module contains the possibility of a dedicated hit and cluster selection. However, the cluster selection is common for all pixel modules, respectively common for all strip modules. Some selections are applied to both pixel and strip hits. These selections are based on intervals, you need to specify always pairs of numbers to select specific intervals, e.g for one interval (0.3,0.4) or for three intervals (0.3,0.4, 1.8,1.9,-1.7,-1.5). In case of integers, a single number can be selected by e.g. (3,3). If no number is given, no selection is applied.

The track selection is hardcoded and can only be switched on and off. This has historical reasons, and should probably be excluded, and instead the official AlignmentTrackSelector should be used before the applied refit. This would also guarantee, that the track selection is identical during the iterations, since the change of the APE values might lead to small migrations of the track parameters inside/outside the selection window due to the refit.

Some additional selections and configurations can be applied.

Choose between APE Calculation and Control Plots

Furthermore, there are two important switches, since the module can be used for the calculation of APE values, but also as analyzer only, producing zillions of control plots. Calculating APEs is defined in the cff.py as the module ApeEstimator, setting the switch calculateApe = True. Using the analyzer is defined in the cff.py as the module ApeAnalyzer, setting the switch analyzerMode = True. In principle, one could use both things simultaneously in one module, but this often makes no sense due to the sector definitions explained later: the APEs should be calculated for the whole tracker, while the huge amount of detailed validation plots should be chosen for some exemplary regions. The APE calculation also contains some validation plots which are in principle not necessary for the calculation, but since these are the most important basic validation plots, they are implemented there in order to understand the general quality of the estimated APEs.

Granularity of APEs: Sector Definition

Configuration of the Refit

Configuration of the CPE

Configuration of the Geometry

Configuration of ApeEstimatorSummary

Scripts for automated workflow

Set Baseline from Design Simulation

Calculate APE Parameters

Scripts producing Validation Plots

-- JohannesHauk - 24-Jul-2012

META TOPICMOVED by="hauk" date="1343128893" from="CMSPublic.SWGuideAlignmentParameterErrorEstimator" to="CMSPublic.SWGuideAlignmentPositionErrorEstimator"
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback