Difference: CustomReconstruction (10 vs. 11)
Revision 112014-06-18 - KennyWraight
| Line: 1 to 1 | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Customising IBL Reconstruction | |||||||||||||||
| Line: 6 to 6 | |||||||||||||||
Overview | |||||||||||||||
| Changed: | |||||||||||||||
| < < | To make a custom reconstruction you will need appropriate =gear=, config, and steering files. If possible, ask the author or someone who might know where to get these files as it is much easier to edit working code than to invent your own. | ||||||||||||||
| > > | To make a custom reconstruction you will need appropriate gear, config, and steering files. If possible, ask the author or someone who might know where to get these files as it is much easier to edit working code than to invent your own. | ||||||||||||||
The gear file defines the positions and orientation of the devices present: Mimosas and devices under test (DUTs). The config file sets the essential variable values which the reconstruction code will need to find and write files and run the code successfully. The main part of the of the reconstruction comes in calling the appropriate sub-routines via the steering files. | |||||||||||||||
| Line: 92 to 92 | |||||||||||||||
| |||||||||||||||
| Deleted: | |||||||||||||||
| < < | If you editing the steering files you must be careful that the correct referencing is done between the values set in the config file and the values used in the steering files. Problems are often generated when directories or values defined in the config file are not properly referenced or simply hard-coded in the steering file. The code will fail if files, directories or values mentioned in the steering files do not exist. Always check the error messages if running jobsub fails.
Be sure to replace hard-coded references with values set in config file, e.g.:
someplacewithgeomfile
change to
@GeometryPath
where both variables GeometryPath and GearFile are set in config.cfg:
# Geometry file
GearFile = my_gear_file.xml
# Path to the geometry file
GeometryPath = %(BasePath)s
| ||||||||||||||
Common Features
Steering files for each run or set of runs are produced on execution from the template files (found in the steering-templates directory). The general templates become specific when the variables in specified in the config files are substituted into the templates. To check the of specific executions are correct use the jobsub -dry-run option on execution. This will copy the steering files used for each run to the current directory. | |||||||||||||||
| Line: 122 to 100 | |||||||||||||||
Each steering file has several sections in common. To begin there is an execute section where the list of all processes to be run is defined. There is also a global section where the global (e.g. gear file location) from the config file are passed. The rest of the file is taken up with setting the variables of each processor defined in the execute section. The task specific parameters (e.g. FiringFrequency) are passed to the processors in these sections. | |||||||||||||||
| Changed: | |||||||||||||||
| < < | Converter read DUT to into EUTelescope framework | ||||||||||||||
| > > | Converter Read DUT to into EUTelescope framework | ||||||||||||||
EUDaq processor is used to record testbeam data in organised fashion, however this organisation is not standard, rather it is specific to categories of device (e.g. Atlas Pixel, "APIX"). Converters can be found in $EUTELESCOPE/external/eudaq/tags/v01-00-00/main/src/ (NB slight differences in directory structure between versions). For current (!) testbeam data APIX-CT-ConverterPlugin.cc is the converter used. Any manipulation of data as it enters the EUTelescope software framework should take place here. As EUDAq is separate from EUTelescope, i.e. the converter is not an EUTelescope processor, you cannot read in variables through the variables through the steering file. | |||||||||||||||
| Changed: | |||||||||||||||
| < < | Clustering Manipulating DUT pixels | ||||||||||||||
| > > | Clustering Manipulating DUT pixels | ||||||||||||||
| Changed: | |||||||||||||||
| < < | Clustering collects pixels into clusters according to some constraints (such as minimum and maximum cluster size). It also contains a correlation processor which can be used to check the orientation of the DUTs with respect to one another. NB Correlations at the clustering stage are done on a pixel-to-pixel basis. | ||||||||||||||
| > > | Clustering collects pixels into clusters according to some constraints (such as minimum and maximum cluster size). It also contains a correlation processor which can be used to calculate the orientation of the DUTs with respect to one another. NB Correlations at the clustering stage are done on a pixel-to-pixel basis. | ||||||||||||||
| Using the ROOT file | |||||||||||||||
| Line: 150 to 126 | |||||||||||||||
| The correlation plots compare pixels based on their X or Y position. If pixels are correctly orientated with respect to one another then the correlations should be positive, i.e. greatest intensity from bottom left to top right: in the case of comparing devices with the same number of pixels, correctly orientated devices will produce a correlation running up the central diagonal; any offset in the devices will displace the diagonal. Devices which are flipped with respect to one another will produce an anti-correlation, i.e. greatest intensity from bottom left to top right: similar comments apply for case when devices have the same number of pixels. Devices which are rotated will lose correlation, such that for 90 rotation case no correlation will be seen. Changes to orientation are made in the gear file, either by the XY-rotation matrix or individual rotation parameters. | |||||||||||||||
| Changed: | |||||||||||||||
| < < | This is an example of an X-correlation map between planes 0 and 1 in the telescope. The correlation can be seen in the increasing in the positive direction as the diagonal line between corresponding pixels. Here it runs for x=y as planes are well aligned and orientated and devices have same number of pixels. | ||||||||||||||
| > > | This is an example of an X-correlation map between planes 0 and 1 in the telescope. The correlation can be seen in the increasing in the positive direction as the diagonal line between corresponding pixels. Here it runs for x=y as planes are well aligned and orientated and devices have same number of pixels. NB changes in orientation will not be seen in clustering tep as this only deals with pixels not global orientation of devices. Changes in orientation will have affect in hitmaker. | ||||||||||||||
This is an example of an X-correlation map between planes the above DUT and plane 0 in the telescope. The correlation here is positive but offset (as is typical), there is also a mismatch in axes bins due to the difference in detector geometries. | |||||||||||||||
| Line: 163 to 142 | |||||||||||||||
This is the corresponding X-correlation shift plot (and corresponding projection) for the above DUT and plane 0 in the telescope. | |||||||||||||||
| Added: | |||||||||||||||
| > > | |||||||||||||||
 | |||||||||||||||
| Added: | |||||||||||||||
| > > | The correlation shift plots are used to identify the offset peaks. Cutting around these peaks is used by the prealign processor in hitmaker to improve track fitting. The peak parameters are used in the PreAligner and Correlator processors in the ResidualsXMax, ResidualsXMin, ResidualsYMax and ResidualsYMin vectors.
Hitmaker Changing to global telescope geometry
Hitmaker moves the detector planes and DUTs into the global geometry of the telescope so that alignment can be preformed. It also contains a correlation processor which can be used to check the orientation of the DUTs with respect to one another. NB Correlations at the hitmaker stage are done on a pitch-to-pitch basis i.e. the pixels are translated into the global coordinate system of the telescope.
Using the ROOT file
The hitmaker root file has similar hitmaps for each mimosa plane and DUT as the clustering output but with axes translated into the global telescope geometry. Changes to correlations due to gear file gemometry parameters will be seen in the correlations and hitmaps.
These are the local an global hitmaps corresponding to the above DUT.
These are correlation and shift plots corresponding to the above DUT. Note the cuts around the peaks.
There are also plots from the pre-alignment which show the same results as the shift plots. Here are plots for the plane 1 and DUT20 offset with respect to plane 0.
 | ||||||||||||||
(Integrate this section later.) | |||||||||||||||
| Line: 173 to 181 | |||||||||||||||
| Tips | |||||||||||||||
| Changed: | |||||||||||||||
| < < | In general, make sure any definition of the number of planes is correct: #plane = #mimosas + #DUTs. | ||||||||||||||
| > > | If you editing the steering files you must be careful that the correct referencing is done between the values set in the config file and the values used in the steering files. Problems are often generated when directories or values defined in the config file are not properly referenced or simply hard-coded in the steering file. The code will fail if files, directories or values mentioned in the steering files do not exist. Always check the error messages if running jobsub fails.
Be sure to replace hard-coded references with values set in config file, e.g.: | ||||||||||||||
| Added: | |||||||||||||||
| > > |
someplacewithgeomfile
change to
@GeometryPath
where both variables GeometryPath and GearFile are set in config.cfg:
# Geometry file
GearFile = my_gear_file.xml
# Path to the geometry file
GeometryPath = %(BasePath)s
In general, make sure any definition of the number of planes is correct: #plane = #mimosas + #DUTs. | ||||||||||||||
In the steering files where number of planes is defined (e.g. in DafFitter processor in align-tmp, fitter-tmp) by TelescopePlanes, the set-up can be defined in two ways. Firstly all planes (mimosas & DUTs) can be defined in one ordered vector (gear file is not used for z-ordering here). This uses all planes for the fitting. Alternatively, only mimosa planes can be defined and DUTs can be referenced in the DutPlanes. If this is done the FitDuts parameter mus be set true. Either way the RequireNTelPlanes parameter should be appropriately set (e.g. to 6 if the mimosa planes alone are used). | |||||||||||||||
| Line: 208 to 237 | |||||||||||||||
| |||||||||||||||
| Added: | |||||||||||||||
| > > |
| ||||||||||||||
View topic | History: r14 < r13 < r12 < r11 | More topic actions...
Copyright © 2008-2025 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding TWiki? Send feedback