SVT CONFIGURATION
This pages collects information about the software tools to generate maintain and manage the data needed to download SVT boards.
GENERAL INTRO
We are currently (Jan-00) putting everything in working order for Run II, setting up things in order to be able to download SVT correctly under Run_Control, following the experience of integration tests in the commissioning run.
During the commissioning, we used to download each SVT board in turn, under control of a run_control message constructed from the Hardware Database,
that sends out a single parameter ("metakey") , of type string, to each board to instruct it about how it should start up.
We initialize each board by reading data from diskfiles located in a fixed area. Each board may require more than one file: their name are obtained by appending to the message string some fixed extensions. For instance, an HB board receiving the message 'xxxxx' will load files xxxxx.HB-SSMAP and xxxxx.HB-AMMAP. When there are registers to be set, their values are stored in a file xxxxx.HB-REG.
Configuring SVT is done in two logical steps. The first is to create a high-level description of the desired configuration for SVT, taking the form of a set of files. They are defined in the high-level files description.
The second step is to produce a "machine-level" description of the data that must be downloaded into each board to achieve the desired configuration, taking the form of a different set of files, containing hex data : their formats are defined here
. In the commissioning stage, this information was stored in the online cvs repository, but the current plan is to move the high level files into the appropriate databases, and to generate as much as possible of the low-level files "on the fly" in crate CPU's during the board downloading operation.
Below you will find links to existing files and related code.
The same run-control messages must also initialize the spy-buffer monitor system; it is not yet clear that this can work with the current configuration, we need to investigate this more, and make changes where appropriate. One possibility we are considering is to keep both high- and low-level description of the board internal data together, so that each client subscribing to the message can pick what he needs for its own use.
PLANS/ONGOING WORK
See Bill's list for Run-Control and integration issues and Giovanni's list for issues related to the data that must go into the boards. They are probably mostly useful to the people actually involved.
WHERE IS THE STUFF
All software needed to create and manage config files is (will be) maintained in the CDF online CVS repository, under directory svt_config. (see cvs manual for help on cvs). Version numbers like vx.x will identify different releases.
There are three directories:
- data : config files.
- source : associated code. The main directory contains code shared by several executables. Subdirectories contain code specific of a given executable.
- doc : documentation, file formats, etc.
HOW TO MAKE SVT STARTUP IN A GIVEN CONFIGURATION
- Login as cdf_svt
- setup -q online cvs
- rm /cdf/code-common/cdfonline/svt_config/*
- cd /cdf/code-common/cdfonline
- cvs export -d svt_config -D today svt_config/data/config-name
If an older version is desired, set the -D option to the desired past date, or better use the -r option
with the appropriate release tag (it is mandatory to use either -r or -D).
This makes R_C load into SVT the configuration identified by config-name next time it is started.
Look below for a commented list of currently available configurations.
MAJOR CODE VERSIONS
- Version tagged v2-5 is the last one before an extensive reorganization to make everything sector-oriented. Most of the files are affected after this.
FILES PROVIDED FOR EACH CONFIGURATION
This is the current list of files available by board ('xxx' is the metakey):
There are some additional files around, mostly input files for the program that produces the above listed ones, and can generally be ignored. They are easily distiguished by the lack of a '-' character in the file extension, which is present in all downloadable files.
AVAILABLE DATA SETS
FILES FOR 2001 RUN
- Nominal detector geometry, no misalignments. Planes 0,1,2,3.
- Assumes coordinate-inverting HFs.
- Regular bins(~300um). The whole XFT is mapped into a single strip, so it can be used with dummy XFT tracks.
- Normal beam spot, placed in nominal (0,0) position.
- Barrel-crossers are allowed everywhere.
Nominal performance (on GEANT simulation):
- Pattern coverage: ~90% (I haven't pushed it).
- Actual efficiency will depend on misalignments, and it is likely to be pretty low.
- SVT data are "similar" to what they will be after final alignment: this is probably the main motivation for this config.
- Nominal detector geometry, no misalignments. Planes 0,1,2,3.
- The whole XFT is mapped into a single strip. Usable at cold startup. Nota Bene: besides being useful to run with fake XFT tracks, this configuration can be used with real XFT tracks as well. What will happen is that every XFT track will be matched by the TF with any 4-point SVX track candidate, so it will take more time, but all good tracks should be fit.
- Assumes coordinate-inverting HFs.
- Wide bins(~500um)
- Large beam spot(5mm) centered at nominal (0,0) position: should be loose enough to be efficient in spite of reasonable misalignments of detector and beam.
Nominal performance (on GEANT simulation):
- Pattern coverage: ~95%
- Actual efficiency will depend on misalignments and beam position, but it is likely to be pretty high.
- SVT execution time should be pretty high.
- This is the choice for first run with XFT included
- Nominal detector geometry, no misalignments. Planes 0,1,2,3.
- Assumes coordinate-inverting HFs.
- Wide bins: ~500um, 5 degrees on XFT to allow for moderate SVX-XFT mismatch.
- Large beam spot(5mm) centered at nominal (0,0) position: should be loose enough to be efficient in spite of reasonable misalignments of detector and beam.
- Barrel-crossers are allowed everywhere.
Nominal performance (on GEANT simulation):
- Pattern coverage: ~95%
- Actual efficiency will depend on misalignments and beam position, but it is likely to be pretty high.
- SVT execution time should be pretty high.
OLDER FILES, used in commissioning run in year 2000
- Uses no real XFT information. It assumes a fake XFT track is injected at every event for the benefit of the TF, but it makes no real use of it.
- Non-coordinate-inverting HFs.
- Nominal detector geometry, no misalignments. Planes 0,1,2,3.
- Wide bins(~500um), large beam spot(2mm): should be loose enough to be efficient in spite
of reasonable misalignments of detector and beam. The whole XFT is mapped into a single strip (it is dummy). Usable at cold startup.
- Barrel-crossers are recognized in the AM, but will produce huge chi-square values in the TF, due to the alternate sign of coordinates between barrels, so they are generally lost.
- TF constants are for nominal geometry, and there is just one set used for all kinds of track candidates,
that is, difference between long and normal clusters are ignored, and all of the 4 SVX layers used are required to be hit, in addition to the (fake) XFT track.
TAGGED RELEASES:
- v0-0: the situation for the runs around 10/14/00. The ss were slightly misaligned here
- v0-9: Fixed above problem, and replaced some invalid addresses with more harmless ones. Those files were produced with code in svt_config/source/svt_ram_gen with same version tag v0-9.
- v1-0: Further fixed version used in shot 10/23/00.
Nominal performance (on GEANT simulation):
- Pattern coverage: ?
- TF efficiency: ?
- Exec time will be slow: not representative of final SVT perfomance
Same as the above nom_wide_fakeXFT, except:
- Use planes 0,1,2,4.
- Even larger beam spot: 5mm
- SS width on layer 4 was chosen to be 650 micron.
- No TF yet.
TAGGED RELEASES:
- v2-0: Created with corresponding release of svtramgen code. The situation for the runs around 10/14/00. Previous versions had bugs in layer placement and range of allowed coordinates.
- v2-0-lc: Branch that allows all long clusters to be used, while in previous versions they were ignored.
Nominal performance:
- For commissioning run: only wedges 2 and 3 are initialized.
- For use with XTFA-M board (modified merger), and non-coordinate-inverting HFs.
- No XT-MAP file is provided, since the coordinate mapping is hardwired into XTF-M.
- Nominal detector geometry, no misalignments. Planes 0,1,2,3.
- Regular bins(~300um), normal beam spot, placed in nominal (0,0) position.
- Barrel-crossers are recognized in the AM, but will produce huge chi-square values in the TF, due to the alternate sign of coordinates between barrels, so they are generally lost.
Nominal performance (on GEANT simulation):
- Pattern coverage: >95%
- TF efficiency: >99%
- Actual efficiency will depend on misalignments, and it is likely to be pretty low.
- SVT data are "similar" to what they will be after final alignment: this is probably the main motivation for this config.
TF is currently being worked out.
- For commissioning run: only wedges 2 and 3 are initialized.
- For use with XTFA-M board (modified merger), and non-coordinate-inverting HFs.
- No XT-MAP file is provided, since the coordinate mapping is hardwired into XTF-M.
- Nominal detector geometry, no misalignments. Planes 0,1,2,3.
- Wide bins(~500um), large beam spot(2mm: should be loose enough to be efficient in spite
of reasonable misalignments of detector and beam. Usable at cold startup.
- Barrel-crossers are recognized in the AM, but will produce huge chi-square values in the TF, due to the alternate sign of coordinates between barrels, so they are generally lost.
Nominal performance (on GEANT simulation):
- Pattern coverage: >99%
- TF efficiency: >99%
- Exec time will be slow: not representative of final SVT perfomance
- TF is currently being worked out.