<!-- Title: 02:48:38  Tue Dec 10 2002 -->
<!-- Crewchief: SVT group -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
New elog


<!-- Date: Tue Dec 10 02:52:21 2002 -->
Broken AMS board (board#10) in teststand will go to University of 
Chicago for a while to be repaired. (Taka brings this). 
<br> Resulting, there is no AMS board in teststand.
<!-- Author: Taka -->


<!-- Date: Tue Dec 10 22:07:34 2002 -->
Cold start of new GB part is tested again. Error which we saw previously is due to board trouble. <br> 
After swapping GB board #004->#003, cold start (Flash RAM writing) is very fine. I don't think #004 is broken since we can store data using another way. <br> 
But there is something strange in that board (#004) at least. Reason will be investigated by Taka.  
<p> 
After cold start passing, I test total performance of new firmware using fakehits mode.  
I think that result is good enough.  
(No error happened, fitted beam position is fine, corrected impact parameter looks fine, etc)  
<br> 
So, we can take data using new GB at the one end of the run, and after validatation, we will be able to install it.  
<!-- Author: Taka and Bill.A. -->


<!-- Date: Tue Dec 10 22:38:58 2002 -->
Board 004 problem is not serious. I brought it to teststand and 
power off/on VME crate, then board 004 is recovered.  
(Correctly, svtvme_gb_cstest() is passed in teststand.) 
<br> 
It seems that that FRAM entered into protected mode somehow by chance (or cannot enter read array mode correctly).  <br> 
  
<!-- Author: Taka -->


<!-- Date: Wed Dec 11 14:56:17 2002 -->
<p> 
Removed spare boards (XTFC and Merger) from slots 20 and 21 of 
b0svt07.  Updated firmware ('utility' program) of spare GB in 
slot 12 of b0svt07: it is now smart enough to replace the 
deaded "XTRP emulator," with the added features that (a) the 
BC offset is VME programmable and (b) the delay from L1A to 
EE output is programmable in 33 nsec increments up to 4K counts 
(about 132 usec).  <b>The XTRP emulator's days are numbered!</b> 
<p> 
Using this feature, Peter Wittich, Greg Feild, and I succeeded  
in sending data from SVT into L2 with fixed, programmable SVT latency, 
even when deadtime is high.  (Using the old method of adjusting 
the delay, with different numbers of tracks flowing through SVT, 
did not give a fixed delay once deadtime became non-negligible, 
because pile-up affects the latency.)  This will be useful in 
estimating trigger deadtime vs rate at rates higher than the 
current 12kHz limit.  (Greg F, Matt W, et al will probably  
measure this soon.) 
<p> 
I'll leave the XTRP emulator plugged in as it was for now,  
because we only have a couple of hours left before possible 
data taking.  Next rainy day, we can remove the XTRP emulator, 
adjust a few cables, and update the relevant .hwset files. 
<p> 
It is possible (but not too likely) that I broke the SVDD 
readout of data from Taka's new GB 'processor' firmware (whose 
output is being sent to a bank for validation).  I'll check  
this in a moment, so that I can fix it if necessary. 
<p>  
<!-- Author: Bill -->
<!-- Comment: Wed Dec 11 14;58;02 comment by...Bill -->
This work on the 'diagnostic/utility' GB functions is in 
parallel with Taka's work on the 'processor' GB functions ...
(CVS is a useful thing.)



<!-- Comment: Wed Dec 11 15;10;28 comment by...Bill -->
OK, I'm pretty sure that I didn't break anything.  I haven't
looked at the SVDD bank contents, but at least it looks as if
the VME readout is occurring.



<!-- Date: Wed Dec 11 23:56:06 2002 -->
I added FRAM reset switch in GB firmware. And I modified svtvme_fer.c for corresponding part. This modification works very  
well in teststand cold start test. Now, it is time to install.   
<p> 
After making sure w/ teststand checking, I swapped GB board #003  
to #004 in the real SVT create (b0svt06 slot#14) 
  
<!-- Author: Taka -->

<!-- Date: Thu Dec 12 10:57:17 2002 -->
<pre>
 
Merger b0svt07/10: EEreg=0011, FIFOMT=1111, InpEna=1100, Ena&!MT=0000
Merger b0svt07/11: EEreg=0111, FIFOMT=1001, InpEna=1000, Ena&!MT=0000
Merger b0svt00/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt00/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt01/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt01/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt02/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt02/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt03/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt03/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt04/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt04/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt05/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt05/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/08: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/18: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/20: EEreg=0001, FIFOMT=1110, InpEna=1110, Ena&!MT=0000
 
Ena&!MT summary: 000000000000000000
 
</pre>
<!-- Author: svt whodunnit script -->


<!-- Date: Thu Dec 12 11:01:26 2002 -->
<pre>
 
Merger b0svt07/10: EEreg=0011, FIFOMT=1111, InpEna=1100, Ena&!MT=0000
Merger b0svt07/11: EEreg=0111, FIFOMT=1001, InpEna=1000, Ena&!MT=0000
Merger b0svt00/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt00/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt01/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt01/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt02/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt02/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt03/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt03/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt04/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt04/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt05/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt05/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/08: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/18: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/20: EEreg=0001, FIFOMT=1110, InpEna=1110, Ena&!MT=0000
 
Ena&!MT summary: 000000000000000000
 
</pre>
<!-- Author: svt whodunnit script -->



<!-- Date: Thu Dec 12 23:38:39 2002 -->
New SVT GhostBuster board firmware was tested in the testrun. (Run#155323). As far as online 
histgrams show, there is no significant problems in this new firmware now. <BR> 
This modification corrects SVT track phi and shorten the SVT processing time (~1us). <p> After 
validation of this data using svtsim, real swapping will be happened in near future. In this time, 
everything returned to previous version so that normal run after test run has nothing special.   
<!-- Author: Taka -->


<!-- Date: Fri Dec 13 05:52:31 2002 -->
I paste here an important tip from Marco on how to test 
GB et al sw/hw modifications w/o data that I got by e-mail and should 
not get lost. 
<pre> 
 
To fully test the beam fitting procedure with no beam here is  
the procedure: 
a) run SVT with fakehits 
b) stop the run 
c) copy the file 
/cdf/code-common/cdfonline/svtdaq/doc/beam/lastbeam.txt  
in some safe place 
d) edit fakethis.hwset and  add the line: 
spy_tf_beamFitEnable                    1   
e) coldstart 
f) wait until a new fit is performed (<~ 5 minutes) 
g) check on the console of b0svt06 that no vme errors appears 
related to writing the GB registers 
h) check that the fitted beam make sense (see for example the SVTSPYMON plots) 
i) stop the run 
j) undo what was done in step c) and d)  
k) cross your fingers! 
l) you have done. 
 
   Marco  
</pre>
<!-- Author: Stefano -->


<!-- Date: Fri Dec 13 21:44:22 2002 -->
New GB was installed from Run#155346. Online histograms dist. 
look fine. <br> 
Bit by bit comparison between board output and svtsim 
will be performed soon after making production data. <br> 
(According to testrun performed yesterday, bit by bit comparison 
shows consistent result with auto SVTmon error rate.  
(6/3730 events) ) 
 
<!-- Author: Taka -->


<!-- Date: Fri Dec 13 22:51:07 2002 -->
Performance of SVT new Ghostbuster is examined using data of Run155346. <br> 
Error rate between bit by bit SVT simulation (svtsim) and new  
board output is consistent with normal daily report from SVTmon. 
(7/3499events; real output while, 0.2% is normal error rate) 
<p> 
It looks like new firmware gets right to take part in SVT boards.  
<!-- Author: Taka -->


<!-- Date: Fri Dec 13 23:07:59 2002 -->
<pre>New set of patterns and mapset file (offline_100030_20021213225348.mapset) 
loaded. 
They include: 
- new layer maps for B0W3,B3W3,B1W5,B2W5,B0W6,B2W6,B0W8,B2W8,B5W9 
as suggested by SVX people; 
- patterns are centered on x=-0.2010 cm, y=0.3917 cm (much 
closer to the real beam position. 
 
After run 155347 B3W3 is switched back to the previous configuration (0123) since the new one did not work.</pre>
<!-- Author: Roberto -->


<!-- Date: Sat Dec 14 10:35:53 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-10&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-10  width='300' align='top'></td><td>Before Roberto's update.</a></td></tr></table>
<!-- Author: Bill -->


<!-- Date: Sat Dec 14 10:36:20 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-11&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-11  width='300' align='top'></td><td>After Roberto's update.</a></td></tr></table>
<!-- Author: Bill -->


<!-- Date: Sat Dec 14 12:47:04 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-12&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-12  width='300' align='top'></td><td>This is phi_SVT-phi_COT_L3 vs phi_SVT after and before the installation of the new ghostbuster.</a></td></tr></table>
<!-- Author: Roberto -->


<!-- Date: Sat Dec 14 21:08:08 2002 -->
svtspymon 
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2002&action=view&page=1043&frame=2&anchor=19:58:19'>update</a>  
by Marco, for beam position old/new 
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2002&action=view&page=1043&frame=2&anchor=21:04:35'>flag</a>.  
<!-- Author: Bill -->
<!-- Comment: Sun Dec 15 02;06;53 comment by...Marco R. -->
Run range affected is [155346,155367]. During this time the status flag in SVDD were always 0 even if a good fit was available. <p>
It should be noted that bit 30 of the status word can now be checked in addition to the usual status flags. In particular the standard status flag are expected to be 0 only when crate reboot or at the start of a new store (or else when the fitter reported an error). Bit 30 instead is expected to be 0 for every new run (coldstart) 'til the first fit is available.


<!-- Date: Mon Dec 16 23:13:43 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-13&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-13  width='300' align='top'></td><td>timing for run 155428</a></td></tr></table>
<!-- Author: Bill -->
<!-- Comment: Mon Dec 16 23;15;03 comment by...Bill -->
In this run, only the wedge 0 merger is in non-deterministic mode.

<!-- Date: Mon Dec 16 23:14:04 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-14&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-14  width='300' align='top'></td><td>timing for run 155429</a></td></tr></table>
<!-- Author: Bill -->
<!-- Comment: Mon Dec 16 23;17;28 comment by...Bill -->
In this run, the wedge 0-11 mergers (all 'wedge' mergers)
are in non-deterministic mode.  Arguably, there is a
1-to-1.5 usec improvement in the peak position.  The
mean improves, too, but since we don't know what causes
the tail (Gino suspects SB0W8L3), I'm not sure I trust
the mean.



<!-- Date: Mon Dec 16 23:46:24 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-15&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-15  width='300' align='top'></td><td>overlay</a></td></tr></table>
<!-- Author: Bill -->


<!-- Date: Mon Dec 16 23:50:12 2002 -->
I left all of the 'wedge' Mergers in non-deterministic mode. 
Gino and I also tried a run in which <b>all</b> Mergers were 
in this mode, and it didn't seem to make much difference.  
<!-- Author: Bill -->


<!-- Date: Tue Dec 17 10:16:31 2002 -->
I am accessing AMS in b0svt00/8 for a little while to test svtgui and look at microcode.
<!-- Author: Stefano -->
<!-- Comment: Tue Dec 17 12;55;57 comment by...Stefano -->
<pre>I am done.</pre>


<!-- Date: Tue Dec 17 15:17:39 2002 -->
UC e-shop group fixed bad AMS chip. <br>  
Now fixed board is inserted in SVT teststand slot#8 again.   
<!-- Author: Taka -->


<!-- Date: Wed Dec 18 21:47:46 2002 -->
<pre>New mapset and patterns downloaded. 
Changed: B2W7,B2W6,B3W8,B4WA,B4W6,B4W8,B1W5,B0W8, 
B1W8,B1WA as recommended by SVX people.</pre>
<!-- Author: Roberto -->


<!-- Date: Wed Dec 18 23:28:01 2002 -->
<p> 
I finally got 4/5 working in svtsim, using the patterns made by 
Roberto in fcdflnx2:~carosi/patt5l.  This required some changes 
to svtsim_maps.[ch] and svtsim_tf.[ch], to generalize to using 
multiple sets of fit constants.  The updated code is committed  
to offline CVS, but the testing is only partly done.   The first 
two of the following steps are done: 
<p> 
 
<li>Check that changes to svtsim do not change behavior of svtsim 
on old data, when using maps from database.  (I checked this on 
10K events from run 152133.) 
<li>Show that 4/5 finds tracks in svtsim.  (See below.) 
<li>Check that calculated RAM images are unchanged when  
initializing from old constants.  (Not yet done.) 
<li>Check that 4/5 works in test stand.  (Not yet done.) 
<li>Take a test run with real SVT.  (Not yet done.) 
<p>  
<!-- Author: Bill -->
<!-- Comment: Wed Dec 18 23;48;04 comment by...Bill -->
On step 3, only the TF coefficient RAMs differ.  Not a bad
start.  I'll track this down tomorrow.

<!-- Comment: Thu Dec 19 14;37;34 comment by...Bill -->
OK, with a trivial patch, all RAM images with new code are now
identical as for old code, when using old maps.

<!-- Comment: Thu Dec 19 22;06;32 comment by...Bill -->
Verified 4/5 in test stand with 10K events from wedge 0 from
run 152133.  Looked OK.  (There is a low rate of mismatch of
some TF status bits, which was also present with old code,
old constants.)
<!-- Comment: Thu Dec 19 22;10;14 comment by...Bill and Taka -->
Took run 155616 (min bias trigger table, parasitically with
Koji's diffractive trigger timing test) with SVT 4/5 constants
loaded.  Checked SVT vs svtsim.  About 1/3 to 1/2 of tracks match
perfectly.  Otherwise, there is a strong resemblance in most
cases between the svtsim and SVT tracks, but something is not
right.  Needs investigation.  So for now, the updated software 
is in the crates, but using the old 4/4 constants, whose RAM
images are identical to those made with the old code.

<!-- Date: Wed Dec 18 23:29:15 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-16&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-16  width='300' align='top'></td><td>Zin vs W for mismatches from run 152133.</a></td></tr></table>
<!-- Author: Bill -->
<!-- Comment: Wed Dec 18 23;31;31 comment by...Bill -->
To establish a baseline, I looked for SVT/svtsim mismatches
in run 152133 (2002-09-27).  This is the same whether the old or the new
svtsim is used.  Fraction of failing tracks is large in 6
wedges: B0W0 (11%), B1W0 (10%), B2W0 (6%), B2W1 (3%), B4W3 (7%),
B0W7 (3%).  Otherwise, rate seems acceptably low.




<!-- Date: Wed Dec 18 23:32:03 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-17&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-17  width='300' align='top'></td><td>chisq</a></td></tr></table>
<!-- Author: Bill -->
<!-- Comment: Wed Dec 18 23;33;09 comment by...Bill -->
Here are chisq distributions for 4/4 and 4/5 tracking for
run 152133.  Since the GB favors tracks with low chisq,
more tracks are found at low chisq when using 4/5.



<!-- Date: Wed Dec 18 23:33:33 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-18&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-18  width='300' align='top'></td><td>phi</a></td></tr></table>
<!-- Author: Bill -->
<!-- Comment: Wed Dec 18 23;35;39 comment by...Bill -->
Here is the phi distribution for 4/4 and 4/5 for run 152133,
for a cut of chisq LT 15.  The rate of chisq LT 15 tracks goes
up by 11% when using 4/5.  This is probably an underestimate of
the true improvement, because about half of the events in this
sample (thus well over half of the tracks) were biased to have
two tracks found by the 4/4 SVT patterns.







<!-- Date: Fri Dec 20 17:29:55 2002 -->
<pre>I have updated the svtspymon documentations which was needed.</pre>
<!-- Author: Subir Sarkar -->


<!-- Date: Sat Dec 21 14:46:42 2002 -->
<pre>Here's what I did today to track down discrepancies between 
svt and svtsim when using 4/5 mode.  I hope that my spelling 
this out explicitly allows other people to use similar 
techniques to track down svt/svtsim mismatches in the future. 
First, I ran offline svtsim on run 155616 (4/5 test run), 
and captured to a disk file the output of mrg_w00 for one 
event in which svt and svtsim disagreed.  The contents of 
that file look like this (except they're gzipped): 
 
zcat /data1/ashmansk/w00.dat.gz 
2004dc 2caff8 2ca1d8 2c9b3a 2c9b18 2cda50 2cda18 2ccb40 2c8a89 2c8a66 2c87b8 2c8798 2c8008 300ad7 300afb 301083 3010a8 301bc8 301be8 30200c 244178 2896a8 289682 28921b 2891f6 28c2f0 2c1666 2c168b 30b7f8 30f2e0 30e3f8 309664 309038 309018 2103a8 2103ca 210766 21078a 214868 259607 259278 2590e3 25907e 258ccd 25cc78 258b2c 258748 25c410 290288 2907ab 2910e6 29111a 2da888 2da858 2d9e0d 31082d 3156f0 31172b 3122c8 312668 3166d8 312a48 316ad0 316b10 312c70 312cc8 316d08 3131b5 3133a8 218f92 218ec8 218e96 218c1d 218bf4 218a0d 2189e2 2183b8 21832d 21c2e8 250008 250048 250088 250118 250183 250240 2502e3 250408 250a58 250a7b 250de8 250e0b 29a39b 29a013 299984 298930 298538 2d07d8 2d4970 2d0ac6 2d1325 2d134c 2d1968 2d2588 2d6bf0 31ae48 31a21d 31dd88 319bd8 319a48 319a1e 318d23 3182c8 2a1b6f 2e8edc 2e8ea3 22ca10 2281c8 2281a8 264218 2aa728 2a9ff8 2a9fd8 2a8b28 2a8478 2a8458 2a81e8 2e03e8 2e2418 2e244a 2e67c0 32947a 329445 1400e0 2e38f3 601047  
 
This was obtained by running svtsim_diag with the cableDataPrint 
flag set to 't' and grepping the output for 'merger00.out', then 
doing a cut -f2 -d':'. 
 
Then on b0dap30 I did this to set up my own development svtvme area: 
 
cd ~ashmansk/svtvme 
source setup_local 
cvs update -d 
 
(I had previously done cvs checkout svtvme from ~ashmansk.)  Then every 
time I made a tentative change e.g. to src/svtsim_maps.c, I did this: 
 
make 
make ppc 
 
on b0dap30 and this: 
 
unld "svtvme_th.o"   
ld &lt; /cdf/people1/ashmansk/svtvme/lib/VxWorks-5.3/ppc/svtvme_th.o 
svtvme_wedge_randomtest(0,"test",0,1)   
 
on tstsvt1.  The stuff on tstsvt1 has the effect of running the 
exact same code as the SVT cold start normally run by Run_Control, 
for the mapset ~cdf_svt/svtconf/test.mapset.  Then I did  
'python ~/vst/mrg2tf.py' on b0dap30 and looked to see the level of  
(dis)agreement between svt and svtsim.  Unless either there is an 
SVT hardware failure or the contents of SIXD or XFLD are wrong, 
it should always be possible to reproduce the failure in this way 
in the test stand. 
 
When I finally converged on a set of changes to svtsim_ams.c and 
svtsim_maps.c, I copied those files back to the workstation I use 
for offline software (nchi03.fnal.gov), committed them back to 
offline svtsim in CVS, and then did this on b0dap30: 
 
make svtsim 
make 
make ppc 
cvs commit 
 
The 'make svtsim' line refreshes the online svtsim files from the 
current contents of the offline CVS repository.  It is important 
never to let the online and offline svtsim code diverge!  The 
offline copy is to be considered the master. 
 
</pre>
<!-- Author: Bill -->
<!-- Comment: Sat Dec 21 14;48;19 comment by...Bill -->
Note that the contents of w00.dat.gz are really one line
per event.  The e-log wrapped the lines.



<!-- Comment: Sat Dec 21 19;32;17 comment by...Bill -->
scratch the "cut -f2 -d':'" because the mrg2tf.py program 
zaps the first column on its own.

<!-- Date: Sat Dec 21 16:14:57 2002 -->
<pre>Further progress on 4/5: 
----------------------- 
 
observations from comparing svt (test stand) with svtsim: 
 
- svt outputs 5-layer roads before 4-layer roads (svtsim goes 
  in strict road-number order). 
- svt and svtsim agree when only 0123 are present; else disagree 
- sim gives same result for 01234 and 0134 (correctly) 
- svt does not give same result for 01234 and 0134 (incorrectly) 
 
=== 
 
steps taken to track down difference: 
 
modify 'whichmap' lookup so that everything uses 0123 constants. 
result: everything agrees. 
 
modify 'whichmap' lookup so that everything uses 0124 constants. 
result: everything is bogus. 
 
set all 'ifitpar' values to 0: still bogus 
 
keep ifitpar==0 but use 0123 for everything: all OK 
 
back to all ifitpar==0, all 0124: bogus (sanity check) 
 
set all intercepts to 0: all OK! 
 
use normal 'whichmap' but all intercepts==0: all OK! 
 
EUREKA!  Found bug in get_tfP0 in svtsim_maps.c: forgot to 
remap layer numbers for SS edge when != 0123 
 
fix this: OK! (but intercepts still 0) 
 
back to normal intercepts: still OK! 
 
=== 
 
checks:  
 
'crcmaps' program gives identical results before/after fix 
for mapset 'offline_100030_20021219215418'.  good. 
 
'crcmaps' CRCs differ before/after fix for mapset 
'4outof5_20021219202053' only for TF intercept memories.  good. 
 
=== 
 
commit changes to svtsim offline; propagate to online; commit 
online; rebuild online svtvme development; reboot test stand; 
try several thousand events from wedge 0, thursday's 4/5 
test run; check svt vs svtsim in test stand (results below) 
</pre>
<!-- Author: Bill -->
<!-- Comment: Sat Dec 21 16;17;38 comment by...Bill -->
Forgot to mention: to fix order of roads (5 layers before 4
layers), I updated svtsim_ams.c.



<!-- Date: Sat Dec 21 16:20:18 2002 -->
<pre>Now two more problems: 
 
(1) the Merger in the test stand seems to calculate the wrong 
parity sometimes (?) 
 
(2) in 2% of the events replayed from run 155616, svtsim and 
the test stand disagree on the road list.  svt outputs roads 
that svtsim does not.  Hmmmmmm. 
</pre>
<!-- Author: Bill -->


<!-- Date: Sat Dec 21 16:52:46 2002 -->
Aha!  I don't know how to make the AMS+AMB force the presence 
of layer 5 (XFT)!  It is accepting roads in which all 5 silicon 
layers have hits, but there is no XFT match!  I've sent an  
urgent plea for help to Belfo ...  
<!-- Author: Bill -->


<!-- Date: Sat Dec 21 17:35:18 2002 -->
Got it!  I need to send the ENABLE opcode to each AMB during 
the cold start to get it to force Layer 5.  4/5 works now 
in the test stand, on 7850 events from wedge 0, run 155616!  And all this while sitting at home in 
my pajamas ....  
<!-- Author: Bill -->



<!-- Date: Sat Dec 21 19:49:01 2002 -->
<pre>There are two tracks in all of these events (for wedge 0) 
in which the TF and svtsim disagree.  Both are missing a 
hit in layer 0.  I don't know whether the TF or the software 
is to blame.  Here is what goes into the AMS for each case: 
 
merger00.out: 25c6f8 298adf 2d8c32 318e4d 148c80 2b18ee 600000 
merger00.out: 248c07 289285 2c9568 30984c 148ec0 2f58c3 600000 
 
Here's what goes into the TF: 
 
05c6f8 098adf 0d8c32 118e4d 148c80 0b18ee 2002b1 05c6f8 098adf 0d8c32 118e4d 148c80 0b18ee 20504e 05c6f8 098adf 0d8c32 118e4d 148c80 0b18ee 205ddf 602100 
 
048c07 089285 0c9568 10984c 148ec0 0f58c3 201a24 048c07 089285 0c9568 10984c 148ec0 0f58c3 2049af 048c07 089285 0c9568 10984c 148ec0 0f58c3 205089 602100 
 
And here's what comes out (real and expected): 
 
svt(1): 137f29* 015666* 00504e  0fe000  08cadf  03924d* 201d1d  
sim(1): 137f2a* 015269* 00504e  0fe000  08cadf  03724d* 201d1d  
 
svt(1): 113fc7  05a241* 0049af  081c00  09a285  004a4c* 200b18  
sim(1): 113fc7  059e44* 0049af  081c00  09a285  00064c* 200b18  
 
This is for ~cdf_svt/svtconf/test.mapset. 
 
I think it's easier to do a test run and get more failing events 
than to try too hard to figure this out. 
</pre>
<!-- Author: Bill -->


<!-- Date: Tue Dec 24 12:44:11 2002 -->
<P> I have moved the Spymon documenation to online. The new address is www-cdfonline.fnal.gov/svt/spymon. Only the main 
Spymon page, the consumer doc and the instructions page were 
placed in the online machines. I have rearranged manuaaly all 
the references including the one in the main SVT page. Please 
let me know about any broken link.<P> 
<!-- Author: Subir -->


<!-- Date: Thu Dec 26 09:45:56 2002 -->
<table border=0><td><tr><td bgcolor=#e0e030><P>svt crates are not sending data for the last half an hour. 
svtspymon histograms were last updated at 9:05 am. I find that status of the SPYMON processes in the crates are 'DELAY'. Can 
somebody check what is happening?</P> 
 </td></tr></td></table>
<!-- Author: Subir -->
<!-- Comment: Thu Dec 26 09;48;51 comment by...subir -->
<pre>svtspymon histograms look ok now.</pre>


<!-- Date: Thu Dec 26 17:47:47 2002 -->
It was possible, without another test run, to track down the 
disagreement between SVT and svtsim for 4/5, by replaying hits 
from wedge 0 for run 152133 (I think) in the test stand, using 
~ashmansk/vst/mrg2tf.py, as described above.  The main source 
of disagreement was an amusing case in which hits are present 
in all SVX layers (0,1,2,3,4), but layer 0 has a long cluster. 
In this case, one should use the fit constants for 1,2,3,4. 
In the rare case in which the track crosses barrels between 
layers 0 and 1, deciding which Zin value to use is tricky.  The 
simulation and the board were not making the same choice (due 
to my error, not Tsuyoshi's or Un-ki's).  I fixed this, and now 
so far the tests in the test stand have been successful.
<!-- Author: Bill -->


<!-- Date: Thu Dec 26 17:49:17 2002 -->
We installed Roberto's latest 4/5 constants between stores, 
and we'll see at the start of the next store whether or not 
this was a good idea!  
<!-- Author: Bill and Taka -->


<!-- Date: Fri Dec 27 01:29:44 2002 -->
<pre>Run 155818 
 
hello world 
 
Processing /cdf/people1/ashmansk/bin/spycheck.C... 
           W0   W1   W2   W3   W4   W5   W6   W7   W8   W9   WA   WB 
chisqw     12   14   12   13   12   14   12   14   13   13   12   12 
rate_B0    29*  49*  83   94  100   97    0*  76   68   80   74   31* 
rate_B1    71  100   90   63    0*   0*  95    0*  79   93   85   99  
rate_B2    79   83   86  100   83   50*  55*  52*  62   80    0*  85  
rate_B3    75   92   61   90  100  100   85   84   80   87   61   84  
rate_B4    61   85   83   98  100   96   30*  83    0*  86   71   83  
rate_B5    82   88   90  100    0*  96   66   84   79   53*  77   86  
dead 7 B0W6 B1W4 B1W5 B1W7 B2WA B4W8 B5W4 
ineff 8 B0W0 B0W1 B0WB B2W5 B2W6 B2W7 B4W6 B5W9 
chisq 12.39 
chisqgb 6.20 
proctime 30.39 
davg -4.97 
drms 131.02 
dresol 53.69 
dtail 0.125 
ntrkgb 2.14 
ntrk 12.48 
nxtrp 5.46 
 
</pre>
<!-- Author: Bill -->


<!-- Date: Fri Dec 27 01:32:23 2002 -->
<pre>Run 155794 
 
 
Processing /cdf/people1/ashmansk/bin/spycheck.C... 
           W0   W1   W2   W3   W4   W5   W6   W7   W8   W9   WA   WB 
chisqw     11   12   11   12   10   13   12   15   11    9   11   12 
rate_B0    37*  24*  91   89   86  100    0*  79   66   86   83   42* 
rate_B1    97  100   74   84    0*   0*  97    0*  80   97   62   99 
rate_B2    78   90   88  100   91   62   70   62   85   69    0*  88 
rate_B3    76   84   73  100   94   90   83   69   78   77   71   65 
rate_B4    77   78   86  100   99   96   38*  75    0*  88   61   78 
rate_B5    76   96   97  100    0*  94   95   83   88   85   88   97 
dead 7 B0W6 B1W4 B1W5 B1W7 B2WA B4W8 B5W4 
ineff 4 B0W0 B0W1 B0WB B4W6 
chisq 11.68 
chisqgb 7.78 
proctime 23.63 
davg -2.31 
drms 114.79 
dresol 54.08 
dtail 0.107 
ntrkgb 1.54 
ntrk 1.97 
nxtrp 5.11 
 
 
</pre>
<!-- Author: Bill -->


<!-- Date: Fri Dec 27 01:40:08 2002 -->
Processing time goes up by about 7usec.  Number of SVT tracks 
per event goes up by about 40%.  Gaussian resolution of SVT 
tracks stays about same.  Mean chisq of SVT tracks (sent to 
L2) decreases from ~7 to ~6.  Fraction of SVT tracks with 
i.p. ge. 120um increases by about 17%.  Interesting!  
<!-- Author: Bill -->


<!-- Date: Fri Dec 27 01:41:12 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-19&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-19  width='300' align='top'></td><td>chisq, after</a></td></tr></table>
<!-- Author: Bill -->


<!-- Date: Fri Dec 27 01:41:42 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-20&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-20  width='300' align='top'></td><td>chisq, before</a></td></tr></table>
<!-- Author: Bill -->


<!-- Date: Fri Dec 27 01:42:30 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-21&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-21  width='300' align='top'></td><td>dvx, after</a></td></tr></table>
<!-- Author: Bill -->


<!-- Date: Fri Dec 27 01:43:10 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-22&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-22  width='300' align='top'></td><td>dvx, before</a></td></tr></table>
<!-- Author: Bill -->


<!-- Date: Fri Dec 27 01:44:03 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-23&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-23  width='300' align='top'></td><td>ntrk (after GB), after</a></td></tr></table>
<!-- Author: Bill -->


<!-- Date: Fri Dec 27 01:44:42 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-24&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-24  width='300' align='top'></td><td>ntrk (after GB), before</a></td></tr></table>
<!-- Author: Bill -->


<!-- Date: Fri Dec 27 01:45:26 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-25&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-25  width='300' align='top'></td><td>ntrk (before GB), after (!!!)</a></td></tr></table>
<!-- Author: Bill -->


<!-- Date: Fri Dec 27 01:46:11 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-26&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-26  width='300' align='top'></td><td>ntrk (before GB), before</a></td></tr></table>
<!-- Author: Bill -->


<!-- Date: Fri Dec 27 01:47:20 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-27&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-27  width='300' align='top'></td><td>phi (after GB), after</a></td></tr></table>
<!-- Author: Bill -->


<!-- Date: Fri Dec 27 01:48:00 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-28&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-28  width='300' align='top'></td><td>phi (after GB), before</a></td></tr></table>
<!-- Author: Bill -->


<!-- Date: Fri Dec 27 01:49:59 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-29&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-29  width='300' align='top'></td><td>phi (before GB), after</a></td></tr></table>
<!-- Author: Bill -->


<!-- Date: Fri Dec 27 01:50:37 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-30&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-30  width='300' align='top'></td><td>phi (before GB), before</a></td></tr></table>
<!-- Author: Bill -->


<!-- Date: Fri Dec 27 01:51:26 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-31&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-31  width='300' align='top'></td><td>SVT timing (1ms scale), after</a></td></tr></table>
<!-- Author: Bill -->


<!-- Date: Fri Dec 27 01:52:04 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-32&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-32  width='300' align='top'></td><td>SVT timing (1ms scale), before</a></td></tr></table>
<!-- Author: Bill -->


<!-- Date: Fri Dec 27 01:53:09 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-33&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-33  width='300' align='top'></td><td>SVT timing, after</a></td></tr></table>
<!-- Author: Bill -->


<!-- Date: Fri Dec 27 01:54:04 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-34&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-34  width='300' align='top'></td><td>SVT timing, before</a></td></tr></table>
<!-- Author: Bill -->
<!-- Comment: Fri Dec 27 01;55;44 comment by...Bill -->
Note how nice and narrow this distribution looked, thanks to Anna Maria's
non-deterministic merging, before we went and moved a whole
bunch of SVT's processing time from hit-moving into track-fitting (where it was originally expected to be).



<!-- Date: Fri Dec 27 01:56:31 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-35&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-35  width='300' align='top'></td><td>Z vs W (for what it's worth), after</a></td></tr></table>
<!-- Author: Bill -->


<!-- Date: Fri Dec 27 01:57:15 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-36&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-36  width='300' align='top'></td><td>Zin vs W, before</a></td></tr></table>
<!-- Author: Bill -->


<!-- Date: Sun Dec 29 08:07:36 2002 -->
As expected, we recover B4W8 wedge wmploying 3/3 layer configuration. This increase about 5% 
SVT efficiency. <BR> 
It looks very fine from online monitor histograms.   
<!-- Author: Jahred, Roberto and Bill (written by Taka -->