SVT FAQ (on 22-Feb-2004)  

If whole wedges are the source, this strongly suggest GB or final MRG is something troublesome.
If one wedge is the source, AMS, AMB, HB, or TF can be wrong.
And specific barrel(s) of one wedge is wrong, we guess HF could be wrong.

(Q2) How to run the svtsim, how to check what board is wrong.
(A2) There are two good instructions in this page. ([svtsim_testconst]) ([svtsim_instruction])
(the former is rather better since it concentrates svtsim only)
If you did "addpkg -h svtsim", you have tclfiles for svtsim running "./svtsim/test/svtsim_data.tcl". Inside this, you might set

module talk svtsim_diag
svtdPrint set f
mismatchPrint set t
debugPrint set f
obspPrint set f
inputDataPrint set f
cableDataPrint set f
svddPrint set f
svddDumpRaw set f
show
exit

Then you get the only mismatched event information.

(Q3) How to look online ROOT files to check.
(A3) See here.
especially EE error bit and road ID information in each ROOT files is to look. This ROOT is very important for the pager carrier since this is the fastest information cpme from online, so that if you want to swap the board, look the distributions here!!

(Q4) How to see SVTSPYMON (or to restart/stop/change the figures)
(A4) SVTSPYMON figures are shown in this page
Especially, plots for the SVT occupancy and processing time are quite important for diagnostic. (made by Italian folks)
Silicon folks usually check the occupancy, but if you are pager, you may need to check this page also at the beginning of the run.

A good tool to view some of the interesting/important histograms from SVTSPYMON ntuples is available on b0dap30:~jahred/print_svt.C. To use it, copy the spymon ntuple you want to examine to a directory with print_svt.C. Start ROOT and compile the script with " .L print_svt.C+ " and then type print_svt(run_numer). Of course, feel free to edit this script to your liking.

(Q5) How to swap the boards. Where is spare boards?
(A5) Spare boards are usually in both teststand and 3rd floor stock room, #3.
Teststand is the farest room from the theater on the second floor.
In swapping board, you may try to validate the board functionality before next run, in particular, AM board case.
Also note that the combination code is 000.
If you are swapping an AM board, make sure that mode of the AM board on the LHS in the crate is set to 0 (you can see this on the outside LED), and that the board in the RHS in the crate is set to 1 (again, on the outside LED). If the board you are swapping is incorrect, you can change the mode by moving the 3 jumpers near to the LED on the front of the board. IF a board is bad, make sure to label it as such before putting it back!

(Q6) After swapping, how to validate of each board functionality
(A6) Each board should have the each validation tool, but I know only GB case.
You can see the all python scripts in
/cdf/people1/cdf_svt/GB/*
After swapping GB, you can run "totaltest.sh" in the directory. (of course after changing slot or crate name)
These are useful any VME crates. and mainly FRAM data erasing and storing, send the dummy track.
Note that you should use this python script after "partition" state in your borrowing run control.
Even in teststand (tstsvt1), we have to temporarily remove the TRACER crate (slot#2) since
if we have L1 accept or so in your FRAM read/write, board should be in funny state and fail to do them.

If you are in hurry, you can check them with SPYMON/TRIGMON/svtsim validation instaed of it.

(Q7) After swapping, how to see SPYMON/TRIGMON/svtsim.
(A7) The fastest information come from SPYMON in any cases.
If you can see occupancy plot is fine, there are few big issues on SVT.
However, 1% level mismatches or small problems cannot be found in the occupancy plot.
So, we need to check the data quality with svtsim in this case.
TrigMon is also useful to check the occupancy, but most important thing using this monitor is to check the beam position.
If you have troubles in "d0 vs phi" or "beam position information" in TrigMon,
you might have wrong beam position (from SVTD readout or GB itself).
We quickly check the variuos thing in such case.

(Q8) How to generate the SVT constants
(A8) Roberto Carosi made excellent web page to instruct this generation. His page is located here

(Q9) How to check generated constants are fine with svtsim.
(A9) Instruction on this is here

(Q10) How to install the SVT constants
(A10) Manual to install these are shown here.

Also, Taka has new instructions for how to update fakehits.mapset after changing SVT constants and/or patters - PLEASE follow them!

(Q11) How to change SVTVME, SVTMON codes
(A11) There is nice instruction for svtvme meaintainance written by Stefano Belforte. [his page].
Most likely, the code which we need to change is the coldstart part of svtvme.
An important thing is to test it before installing very carefuly since
CDF DAQ system may be screwed up. Thus, we should have private
library to test with teststand then commit the code to online CVS repository.

SVTMON (related to svtspymon) is better to have instruction to
change but I am not sure we have. We will have it at near future

(Q12) How to validate the codes svtvme code changing
(a) using teststand (in particular, coldstart test)
According to Stefano's instruction, you get svtvme codes or so from the CVS.
You may want to change and compile the code in the src/ directory.
Then you have compete svtvme packge at b0dap30 like
/cdf/people3/maruyama/work/svtvme/lib/VxWorks-5.3/ppc/svtvme_th.o
This should be overriden in tstsvt1 from dafult svtvme library
Stefano's email (1): coldstart test routine, (2) : about svtvme_th.o described more.
Bill's email also describes this.

(b) using real b0svt** crates
Same trick mentioned above can be used to real crates.
But, in this case, you need to be careful to main DAQ operation and SPYMON's print out.

(c) using fakehits
Fakehits mode is really useful to validate the SVT's functionality after the HF.
Therefore, we can test the most of boards using fakehits.
If you have a new functionality in your board, this test mode is really useful.
The way to use fakehits is described as (A15).

(Q13) How to install these codes to VME library
(A13) For svtvme, Stefano's manual also describes how to do it.
There are 2 basic things to do: (1) CVS commit to changed codes, (2) type update command.
Then you will have updated official svtvme library.

(Q14) How to use the teststand
(A14) I know teststand can be used for variuos things, but here description is limited to coldstart test and python's test. But the former is described as answer of (Q12) and the latter is in (A27).

(Q15) How to use the fakehits
(A15) Followings are very brief explanation at b0dap**:
(1) >setup fer
(2) >rc &
(3) In main run control, choose
"Select run configuration"->DAQTEST"->"SVT"->"DAQ 500Hz".
(4) Fill "svt type" to "hw=fakehits".
(5) Proceed to "partition"->"coldstart"->"run".

(Q16) How to change the fakehits data
(A16) You can find the source of the fakehits data at
/cdf/code-common/cdfonline/svt_config/fakehits/merger*.dat
This was extracted by svtsim and you can see it soon from svtsim test directory.
This dummy data is sent to the OSPY of the HF and going to downstream of the SVT system.
Also, you can see the fakehits structure in the fakehits.hwset.

(Q17) How to install (compile/simulate) the firmware.
For HF, we have a nice instruction here. (written by B.Ashmanskas). note that this includes CVS opearation.
One thing we need to be careful is that we need to use FRAM to install the firmware in the HF case. It is described in latter of the instruction.

For TF, Un-ki Yang describes the how to install it in this page.
Unfortunately, the firmwares are not in the CVS and cannot be gotten right now, but we may have CVS system someday.

For GB, firmware is opened here. Also, you can get it via CVS. (instruction is here. )
How to manage (compile/simulate/) the GB firmware is written here.
Also, how to install the compiled firmware is written here.

(Q18) How to change and commit the svtsim codes
(A18) svtsim is based on the each board functionality, so that it should be perfectly correlated to any board role changing.
Recently, this system is being used to physics group, too, thus
be careful it, also. CVS Commitment can be done by restricted persons.
Alex Cerri proposed update codes should be checked by some careful persons and then doing commitment should be done.
I strongly recommend to send email to discuss any of svtsim codes with him at first.

(Q19) How to check the spydumps and erase if disk space is full
(A19) spydumps are really quite important validation tools for SVT.
The location of spydump data is "$SVTMON_DATA_DIR/spydumps/."
in b0dap30 or so. (Note that you should setup -d svtmon before going to the directory.)
whodunnit script mentioned below smartly does same thing, but you can check the SVT EE word of each
MRG, TF or GB in each crate.
If you have troubles, especially L2 Decision timeout, you may have
mismatched EE in one (some) board(s). If they exist, please concentrate to fix the board. (or wedge).

spysdump is crucially important tool, but sometime it makes quota
full for cdf_svt account. You may have to erase old_spydumps in such a case. There is a script that runs in a cron job every hour 1 minute past the hour on b0dap30 under the cdf_svt account that should archive old spymon files and send them to cdf.uchicago.edu. It archives and send old root files from oldest to newest after they take up more than 200 MB, and deletes log files if they haven't been accessed in over a month. The script is ~cdf_svt/svttest/spymon/spydump_Test.sh, written by Marco and updated by Jahred.

There is also a cron/script on the Chicago machines which runs every hour on the half hour, under Jahred's account. Before it runs, the spymon files can be found at http://hep.uchicago.edu/cdf/svt/spydumps_old/. When the script runs it moves files to fcdfsgi2://cdf/data21/s3/G_03349.0005/old_spydumps/

(Q20) How to run "whodunnit" script
(A20) whodunnnit scripts show the source of L2 decision timeout if it
is happened inside SVT or SVX. You need to login b0dap30 or so,
type "~ashmansk/bin/whodunnit". Results are shown in SVT e-log.
Please be careful that run status should be HALT state in
the main run controller. Otherwise, there is no meaningful result is coming.
Typical result is such like this
In this case, b0svt06 MRG in slot#8 prevent data streaming.
And "Ena&!MT=1000" means that we have a trouble within wedge#0.
To recover the problem is depend on the case, but you can see the source
and it saves your time.

(Q21) How to recover bunch counter mismatch within SVT
(A21) This question is specified in the case SVX has bunch couter mistmach. This page is the real example which we fixed. [SVT e-log].
Now, many wedges are masked to bunch counter mismatch due to SVX, but you may still have it.

(Q22) How to use and read SVDD/SVTD bank
(A22) Very brief explanation is shown here(1) and here(2) .
At present you only need to change the hwset file and cabling of GB board
for read out side. For offline, very good exmaple is already put in the
svtsim. If you use default tcl file, you have SVTD and SVDD data print out.

(Q23) How to check the beam position information. (TrigMon and ACCNET)
Showing the way to see TrigMon and ACCNET is beyond this manuals.
Please go to B0 (control room) and ask the operation peoples.
TrigMon has one slide to show the SVT beam position and show bright
"RED" state if you have a trouble. This is quite useful for the validation
of SVT beam position readout. ACCNET is interesting tool to look the beam position history. AutoSVTMON
also has history, but they help each other.

(Q24) How to check the trigger rate
Trigger rate (a.k.a cross section) is shown both in XMon (consumer) and Scaler monitor.
How to use them is also beyond this manual.
But, if you have a troble in the cross sections related to SVT
(e.g. B->K pi), you may doubt SVT trouble. Especially, we may have trouble
in beam position.

(Q25) How to enter the b0svt** and check the coldstart
(A25)
>setup fer
>vxlogin b0svt**
in b0dap**. You can see the diagnostic print out in cold start time.

(Q26) How to use SPYGUI and SVTGUI
(A26) These are realtively new staff and I never tried yet.
But it is sure that they are good tools.
link for spyGUI and link for SVTGUI .

(Q27) How to syncronize the SPYMON dump time for b0svt06.
(A27) this shows the Marco's e-mail which was realy useful to solve the L2 decision timeout.
Usually, b0svt06 asyncronizes to other SVT VME crates for the timing
of data dumping since b0svt06 needs to fit the beam position quickly.
But, syncronization is better to check the whole of spydump data.

(Q28) How to measure the efficiency and purity
(A28) Efficiency is shown in autoSVTMON (daily) so that you can easily check it.
(note that the denominator of this efficiency is L3 tracks.)
Purity is rather diffcult to measure (or define). You may want to read Roberto's CDF note (#6295).

(Q29) How to use the python programs to validate the whole boards' functionality
(A29) b0dap30:/cdf/people1/cdf_svt/TF/mrg2tf.py (or w00.py)
is the mini-fakehits mode using teststand or real stand.
(Send data to HF memory and data goes through)
One thing which is better than real fakehits is to compare board output to svtsim.
If you need to test the new functionality in the teststand, this helps somehow.

(Q30) How do I edit this document?
(A30) See fozzie.uchicago.edu:/net/newusers/www/cdf/svt/wja/useful.html. E-mail Mary if you don't have permission to edit the file.

Last edited by