<!-- Title: 15:43:32  Tue Feb  4 2003 -->
<!-- Crewchief: SVT group -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
Turn over a new leaf.


<!-- Date: Tue Feb 4 15:44:49 2003 -->
<p> 
At Bill Badgett's behest, I fixed the ID PROM DIP switch 
settings on HF #11 (b0svt07 slot 4) so that the digits are 
"one one" instead of "zero eleven" (where "eleven" of course 
is not a valid binary-coded decimal digit, so it appeared as 
a semicolon). 
<p>
<!-- Author: Bill -->


<!-- Date: Wed Feb 5 07:49:25 2003 -->
I am using SVT test stand to debug new AMS cold start and new microcode. Please avoid using it until further notice, or do so 
at your risk. For the time being I will only talk to the AMS and do not run data, you can freely talk to other boards.
<!-- Author: Stefano -->


<!-- Date: Thu Feb 6 20:41:58 2003 -->
<pre> 
New firmware for smarter GhostBusting algorithm was installed. But, visibly we don't have any 
change at this time since we have 0 chisquare adding map anyway. &lt;BR&gt; 
Coldstart and fakehits mode were succeeded without any problem. In somewhere in next beam time, 
we have test run with meaningful chisquare mapping after that we go to next.  
&lt;BR&gt; 
</pre>
<!-- Author: Taka Maruyama -->


<!-- Date: Fri Feb 7 00:31:20 2003 -->
Though coldstart and fakehits mode test passed successfully, L2 decision error happened in cosmic 
ray run. And run controller complains svt create does not have data. <BR> 
It's really confusing situation. I try to contact Bill Ashmanskas and Marco Rescigno, but in vain 
currently. I wait till next morning and recover this situation.   
<!-- Author: Taka -->
<!-- Comment: Fri Feb  7 07;01;59 comment by...Stefano -->
It is possible that this is beacuse ace did not put all SVT crates in the partition, only 6-7. See entry in shift log


<!-- Date: Fri Feb 7 10:25:07 2003 -->
Thanks to Stefano's grate effort to maintain svtvme, error was  
recovered. It looks like my update command ("svtvme_update_k5") fails by somehow. (Inconsistency RAM address of svtsim_maps.{c,h} happens in online repository. I did "svtsim_update.csh" but something wrong happened.) <p> 
 
It seems that he remaked svtvme library successfully.   
Currently it looks like working well. (coldstart + fakehits + 
L2 Global test)
<!-- Author: Stefano and Taka -->
<!-- Comment: Fri Feb  7 10;35;46 comment by...Stefano -->
<pre>What is "svtsim_update.csh" ?
why is it not part of automatic svtvme_update_k5 ?
I'll be happy to update my instructions page, if I am told
what the procedure is !</pre>


<!-- Comment: Fri Feb 14 09;13;59 comment by...Stefano -->
<pre>My web page has now been updated</pre>
<!-- Date: Fri Feb 7 12:12:25 2003 -->
Yesterday's SVT failure (L2 decision error) in cosmic ray run is guessed to be shift crew's error. 
They only include crate06 so that data is not coming. <BR> 
Greg et al kindly tested if SVT data is OK or not using global L2 system. And we don't have any 
problem. I think installation of new firmware and software has no problem.   
<!-- Author: Taka Maruyama -->


<!-- Date: Fri Feb 7 15:43:12 2003 -->
 Now, we don't have any problem related with new GB algorithm installation (including svtvme part).  
 
<!-- Author: Taka -->


<!-- Date: Fri Feb 7 16:59:11 2003 -->
<pre>OK, faster SVT is a small step away. 
I managed to overcome all problems with cvs, gmake and srt. 
Now offline and online CVS repositories are identical for 
svtsim and all the new AMS code is there, togheter with 
latest GB Chisquare map. 
Taka is going to check this on SVT crates (which require 
nee mapsetm, since AMS crc have changed) then rebuild 
svtvme development and reboot. 
AMS microcode will still be the same as before, i.e. version 1.0. 
The library contains the code to build version 2.0 as well, which 
will be 700nsec faster and should give same output. 
Should disaster strike, the old svtvme development version 
has been saved as a tar file in /cdf/code-common/cdfonline/svtvme. 
The procedure to get back things as of last night is thus: 
 
ksu cdf_svt 
cd /cdf/code-common/cdfonline/svtvme 
mv developmnet BAD 
tar xzf SAVED.tgz 
 
IN order to put in the new AMS code we need: 
1. test it on fakehits with no beam 
2. modify svtsim because with ucode 2.0 roads will be 
 output in strict numerical order, regardless of being 
 5/5 or 4/5 (actually 5/6 and 6/6 are better names). 
I would prefer that Bill does 2, since it is his code, 
and 1. can only be done with Run_COntrol, so has to be 
one of you. I tried r_c from here, but its GUI is 
more slow then one can think of, msut be a problem with 
Java, beacause both emacs and svtgui are OK. </pre>
<!-- Author: Stefano -->


<!-- Date: Fri Feb 7 19:52:02 2003 -->
SVT new software for AMS board is tested and succeeded. SVTVME code written by Stefano 
Berforte looks fine with coldstart and fakehits mode. <p> But, once again, previous conservative 
SVTVME library is now put on as the default code. Since new GhostBuster <BR> 
board is also improved at this time, before mixing up these 2 guys, validation is hopefully needed 
with SPYMON histograms. <p> As soon as after this validation, these code and new mapset will be 
installed.   
<!-- Author: Taka -->


<!-- Date: Fri Feb 7 22:53:29 2003 -->
 
 
Since we can start SVT SPYMON, histograms for checking debug for new software/firmware can 
be looked. These histograms are all fine so far. <BR> 
In particular, ip is not changed using any configuration though beam position is a little bit different 
from fakehits data. <p> Stafano Berforte's new VME code is also tested. And found no problem. 
Therefore, I put these codes in svtvme development package. <BR> 
Currently, svtvme (and related svtsim) is latest greatest ones. (But, we need to put Stefano's 
recommended mapset in near future)   
<!-- Author: Taka -->

<!-- Date: Tue Feb 11 11:37:36 2003 -->
<pre>
 
Merger b0svt07/10: EEreg=0011, FIFOMT=1111, InpEna=1100, Ena&!MT=0000
Merger b0svt07/11: EEreg=1001, FIFOMT=0101, InpEna=0110, Ena&!MT=0010
Merger b0svt00/07: EEreg=0111, FIFOMT=1000, InpEna=1000, Ena&!MT=0000
Merger b0svt00/16: EEreg=0111, FIFOMT=1000, InpEna=1000, Ena&!MT=0000
Merger b0svt01/07: EEreg=0111, FIFOMT=1000, InpEna=1000, Ena&!MT=0000
Merger b0svt01/16: EEreg=0111, FIFOMT=1000, InpEna=1000, Ena&!MT=0000
Merger b0svt02/07: EEreg=0111, FIFOMT=1000, InpEna=1000, Ena&!MT=0000
Merger b0svt02/16: EEreg=0111, FIFOMT=1000, InpEna=1000, Ena&!MT=0000
Merger b0svt03/07: EEreg=0111, FIFOMT=1000, InpEna=1000, Ena&!MT=0000
Merger b0svt03/16: EEreg=0111, FIFOMT=1000, InpEna=1000, Ena&!MT=0000
Merger b0svt04/07: EEreg=0111, FIFOMT=1000, InpEna=1000, Ena&!MT=0000
Merger b0svt04/16: EEreg=0111, FIFOMT=1000, InpEna=1000, Ena&!MT=0000
Merger b0svt05/07: EEreg=0111, FIFOMT=1000, InpEna=1000, Ena&!MT=0000
Merger b0svt05/16: EEreg=0111, FIFOMT=1000, InpEna=1000, 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=1110, FIFOMT=0001, InpEna=0001, Ena&!MT=0000
 
Ena&!MT summary: 040000000000000000
 
</pre>
<!-- Author: svt whodunnit script -->


<!-- Date: Tue Feb 11 18:11:38 2003 -->
<pre>
Date: Tue, 11 Feb 2003 16:53:54 -0600 (CST)
From: Bill Ashmanskas <ashmansk@cdf.uchicago.edu>
To: Greg Feild <feild@fnal.gov>
Cc: Peter Wittich <wittich@fnal.gov>
Subject: SVT timing scan instructions

In case you need to start before I arrive, here are some instructions:

Locate the cable in b0svt07 whose destination is slot 11, input B.  If you
wiggle it, its source should be slot 8, output 2.  Unplug it from its
source and plug it into the bottom connector of slot 12.  (Today, I also
unplugged the grey cable from the next-to-bottom connector of slot 12, but
I am 99% sure that that was superstitious and unnecessary.)

From Run_Control, make sure SvtMode is set to 'hw=bill'.  After cold
start, but before activate, do the following:

  setup -d svtvme
  python ~ashmansk/vst/gb3.py nticks

where nticks is the (decimal integer) number of 33nsec clock cycles by
which to delay the SVT data.  I'm not sure that it works properly with
very small numbers, but today I successfully used values between 100 and
2000. The firmware,

  http://hep.uchicago.edu/cdf/ashmansk/gb/ghostbuster/utility/gb.tdf

indicates that I assigned 12 bits for the delay, so up to 4095 should be
possible.

In the final configuration that we used today (after Peter left), I added
a 310-tick offset to the exponentially-falling distribution of number of
tracks sent into the GhostBuster (only one comes out of the GB, as they
all have the same XFT ID), to reproduce fairly well the timing 
distribution recorded at

  http://www-cdfonline.fnal.gov/cgi-bin/det-system-elog.pl?nb=svt&page=2&anchor=01:54:04

With a small amount of effort, a few cables could be moved around
permanently and a few configuration files could be edited so that this
feature is available permanently and controlled through the usual set of
SVT configurations.  The work to make the changes is tiny, but the time to 
check that there was no collateral damage could be non-neglible.

Please put the cables back when you're done!

-Bill

</pre>
<!-- Author: Bill -->
<!-- Comment: Wed Feb 12 10;23;13 comment by...Bill -->
<table border=0><td><tr><td bgcolor=#e0e030><b>The "superstitious" cable unplug mentioned above is indeed
necessary after all!  I don't understand why.
</b></td></tr></td></table>
<!-- Date: Tue Feb 11 18:11:38 2003 -->
<pre>
Date: Tue, 11 Feb 2003 16:53:54 -0600 (CST)
From: Bill Ashmanskas <ashmansk@cdf.uchicago.edu>
To: Greg Feild <feild@fnal.gov>
Cc: Peter Wittich <wittich@fnal.gov>
Subject: SVT timing scan instructions

In case you need to start before I arrive, here are some instructions:

Locate the cable in b0svt07 whose destination is slot 11, input B.  If you
wiggle it, its source should be slot 8, output 2.  Unplug it from its
source and plug it into the bottom connector of slot 12.  (Today, I also
unplugged the grey cable from the next-to-bottom connector of slot 12, but
I am 99% sure that that was superstitious and unnecessary.)

From Run_Control, make sure SvtMode is set to 'hw=bill'.  After cold
start, but before activate, do the following:

  setup -d svtvme
  python ~ashmansk/vst/gb3.py nticks

where nticks is the (decimal integer) number of 33nsec clock cycles by
which to delay the SVT data.  I'm not sure that it works properly with
very small numbers, but today I successfully used values between 100 and
2000. The firmware,

  http://hep.uchicago.edu/cdf/ashmansk/gb/ghostbuster/utility/gb.tdf

indicates that I assigned 12 bits for the delay, so up to 4095 should be
possible.

In the final configuration that we used today (after Peter left), I added
a 310-tick offset to the exponentially-falling distribution of number of
tracks sent into the GhostBuster (only one comes out of the GB, as they
all have the same XFT ID), to reproduce fairly well the timing 
distribution recorded at

  http://www-cdfonline.fnal.gov/cgi-bin/det-system-elog.pl?nb=svt&page=2&anchor=01:54:04

With a small amount of effort, a few cables could be moved around
permanently and a few configuration files could be edited so that this
feature is available permanently and controlled through the usual set of
SVT configurations.  The work to make the changes is tiny, but the time to 
check that there was no collateral damage could be non-neglible.

Please put the cables back when you're done!

-Bill

</pre>
<!-- Author: Bill -->



<!-- Date: Wed Feb 12 02:13:34 2003 -->
I did the SVT test of Stefano Berforte's AMS new codes using fakehits mode. And it was succeeded. <BR> 
I put his codes as svtvme default area, but any affects should not be happened since his code 
always select default mode of AMS now. This "default" means same configuration as so far. <p>  
 
Timing difference between "default" and "improve" mode looks like 
around 400ns in 4 out of 5 configuration. (from fakehits test mode). <p> 
 
  
<!-- Author: Stefano and Taka -->
<!-- Comment: Fri Feb 14 09;13;09 comment by...Stefano -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>I find the 400nsec different incredible. The difference between the two ASM microcodes (v1.0 and v2.0) is that 18 states are skipped. This is a minumum of 18*clock_period=18*33 nsec. Also one output loop is skipped, and I was expecting a total gain of 22 clock cycles = 22*33=700nsec. I am getting one AMS being moved from Pisa to Trieste to hook a logic state analyser and cross check.</pre></td></tr></td></table>
<!-- Date: Wed Feb 12 19:02:50 2003 -->
I just added a (non-zero) CRC to nosvx.hwset, so that Run_Control 
would not issue a warning message about its absence when the 
shift crew runs with no silicon.  (Bill Badgett wanted to know 
what was the scoop.) 
<p>
<!-- Author: Bill -->




<!-- Date: Fri Feb 14 20:56:02 2003 -->
<table><tr><td><a href=/elog/notebooks/svt/Fri_Feb_14_2003_205538.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-44  align='top'></td><td>This is process time using default AMS microcode (4outof5;  fakehits mode) </a></td></tr></table>
<!-- Author: Taka -->


<!-- Date: Fri Feb 14 20:57:40 2003 -->
<table><tr><td><a href=/elog/notebooks/svt/Fri_Feb_14_2003_205723.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-46  align='top'></td><td>This is process time using improved AMS code (4outof5:  fakehits)</a></td></tr></table>
<!-- Author: Taka -->


<!-- Date: Sat Feb 15 13:01:51 2003 -->
<pre>&lt;table&gt;&lt;tr&gt;&lt;td&gt;&lt;a href=/elog/notebooks/2003/Sat_Feb_15_2003_Day.125936.ps align=top&gt;&lt;img 
src=/cgi/elog/elog.pl?nb=2003&action=view&page=-1027 align='top'&gt;&lt;/td&gt;&lt;td&gt;Current SVT 
efficiency map. I think this is better than before.&lt;/a&gt;&lt;/td&gt;&lt;/tr&gt;&lt;/table&gt;  
</pre>
<!-- Author: Taka -->


<!-- Date: Sat Feb 15 13:02:27 2003 -->
<table><tr><td><a href=/elog/notebooks/2003/Sat_Feb_15_2003_Day.125936.ps align=top><img 
src=/cgi/elog/elog.pl?nb=2003&action=view&page=-1027 align='top'></td><td>Current SVT 
efficiency map. I think this is better than before.</a></td></tr></table>   
<!-- Author: Taka -->


<!-- Date: Sat Feb 15 13:24:42 2003 -->
We have +200um for beam x and -400um for beam y mevement against 
Jan-13 (before shutdown value). <br> 
We need to ask beam division people to stay before value.  
<!-- Author: Taka -->
<!-- Comment: Sat Feb 15 13;34;12 comment by...Taka -->
<pre>For beam y movement, this is wrong information.
+400um is right number. Sorry!</pre>

<!-- Comment: Sat Feb 15 13;37;05 comment by...Taka -->
For x, -2000um (Jan-13) -> -1800um (now)(roughly) <br>
For y, +4000um  (Jan-13) ->  +4400um (now)(roughly)


<!-- Date: Sat Feb 15 15:44:42 2003 -->
Taka called me to find out whether we have an established 
procedure for dealing with repeated Done Timeouts from SVT 
crates, caused by SVT Merger boards detecting a BC mismatch. 
The procedure that I recommend is to identify the SVT wedge 
that is complaining (in this case, wedge 9), then update the 
SVT hwset file to disable the error check for that wedge.  So 
to disable this check for wedge 9, I changed the value for 
spy_w08w09_LostSync_DTO from 2 to 0.  (Normally it is '3' to 
enable DTO for both wedges.  I guess wedge 8 was already 
disabled, and now wedge 9 is disabled, too.)  Since this BC 
check is in principle useful, SVT experts should keep track 
of which wedges have this check masked, determine which 
ladders are responsible, and check with the silicon SPLs 
about their schedule for getting the BC errors fixed. 
<p> 
It looks as if we've disabled the BC check now for SVT 
wedges 0, 1, 2, 3, 6, 8, and 9, i.e. 7/12 of the detector. 
<p>
<!-- Author: Bill -->
<!-- Comment: Sat Feb 15 15;59;54 comment by...Gino -->
<pre>We have the problem in front of our eyes in Feynmann Center.
Still it is not clear how to fix it because it is not repeatable 
in a sistematic way.
Still our understanding so far is that the problem is there only 
on pipe 2 of the FIBs. (this is the L2 ladder of even wedges).
If you guys think the problem is present on other pipes (layers) 
please lt us know. This would be usefull informations for 
debugging the problem at the source.

</pre>

<!-- Comment: Sat Feb 15 16;24;59 comment by...Gino -->
<pre>The fact that you had to mask wedge 9 already answer my question.
Must be the w-e that slows me down.</pre>


<!-- Date: Mon Feb 17 17:51:15 2003 -->
I put latest SVT constant (pattern) made by Roberto Carosi. This will recover B1W5(L0134->L0123) and B4W5(L0123->0124) wedges. <br> 
 
Also, Silicon folks (see Gino and Jason's breif report: 
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2003&action=view&page=144&frame=2&anchor=16:46:43'> 
Si access report </a> ) made great effort to recover Si layers so that it would help SVT coverage by 2 wedges. <br> 
 
Roberto generated this pattern using current beam position. 
This issue will be discussed in tomorrow's SVT meeting.  
 
 
<!-- Author: Roberto and Taka -->


<!-- Date: Mon Feb 17 20:45:34 2003 -->
<table><tr><td><a href=/elog/notebooks/2003/Mon_Feb_17_2003_Eve.203548.ps align=top><img 
src=/cgi/elog/elog.pl?nb=2003&action=view&page=-1211 align='top'></td><td>This is current 
situation of SVT wedge coverage. Due to Silicon folks great effort, dead wedges are reduced to 5. 
Gino expect they can reduce 2 more during tomorrow's access and Bill Ashmanskas will be able to 
reduce 1 more using 3 out of 3. </a></td></tr></table> <BR> 
 
<cite>-- Mon Feb 17 20:41:19 comment by...Taka Maruyama --  </cite>Actually, we lost B4W8 at 
present since we had no time to put 3 out of 3 in this wedge today. Bill will modify pattern so that we 
can use 3 out of 3 configuration in near future again.   
<!-- Author: Taka  -->
<!-- Comment: Mon Feb 17 20;48;55 comment by...Roberto Carosi -->
And of course, new pattern affects better way. It recovered 
one wedge already and will recover one wegde with Silicon folks.

<!-- Date: Tue Feb 18 11:13:48 2003 -->
<pre>
 
Merger b0svt07/10: EEreg=1011, FIFOMT=0111, InpEna=0100, Ena&!MT=0000
Merger b0svt07/11: EEreg=0111, FIFOMT=1001, InpEna=1000, Ena&!MT=0000
Merger b0svt00/07: EEreg=0111, FIFOMT=1000, InpEna=1000, Ena&!MT=0000
Merger b0svt00/16: EEreg=0111, FIFOMT=1000, InpEna=1000, Ena&!MT=0000
Merger b0svt01/07: EEreg=0111, FIFOMT=1000, InpEna=1000, Ena&!MT=0000
Merger b0svt01/16: EEreg=0111, FIFOMT=1000, InpEna=1000, Ena&!MT=0000
Merger b0svt02/07: EEreg=0111, FIFOMT=1000, InpEna=1000, Ena&!MT=0000
Merger b0svt02/16: EEreg=0111, FIFOMT=1000, InpEna=1000, Ena&!MT=0000
Merger b0svt03/07: EEreg=0111, FIFOMT=1000, InpEna=1000, Ena&!MT=0000
Merger b0svt03/16: EEreg=0111, FIFOMT=1000, InpEna=1000, Ena&!MT=0000
Merger b0svt04/07: EEreg=0111, FIFOMT=1000, InpEna=1000, Ena&!MT=0000
Merger b0svt04/16: EEreg=0111, FIFOMT=1000, InpEna=1000, Ena&!MT=0000
Merger b0svt05/07: EEreg=0111, FIFOMT=1000, InpEna=1000, Ena&!MT=0000
Merger b0svt05/16: EEreg=0111, FIFOMT=1000, InpEna=1000, 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: Tue Feb 18 13:02:51 2003 -->
<p> 
Here's the story on 3/3: 
<p> 
XTFA has been programmed to send two wildcards to every  
wedge on every L1A: (layer=0, barrel=0, x=799) and 
(layer=1, barrel=0, x=799).  This is enabled by setting 
xtfWildVersion to 2 in the mapset file.  These should have 
virtually no effect on normal SVT processing, because they 
are outside of the usual physical range. 
<p> 
If xtfWildVersion is 0, then no wildcards are sent.  The 
first plan was for xtfWildVersion to be 1, which was intended 
to send four wildcards: (l=0, b=0, x=799), (l=1, b=0, x=799), 
(l=2, b=0, x=799), (l=3, b=0, x=799), and (l=4, b=0, x=1023). 
(These values are chosen because they are unlikely to overlap 
with physical hits for any part of the detector, given the 
superstrip maps we have used thus far.) 
This didn't work, though, because the current XTFA firmware 
is only able to set the lowest bit of the layer number in its wildcard output.  Simone says that with a trivial modification, 
the bits could be reassigned so that all possible layer numbers 
are covered.  (If that is done, it would make sense also to 
set the "long cluster" bit on the wildcard hit, so that the TF 
and GB can do something smarter with the 3-layer tracks.) 
<p> 
With the current XTFA firmware, we will always need to make 
the "wildcard" layer be AM layer 0 or AM layer 1.  I guess this 
can be made to work, no matter what physical layer is the wildcard, 
by using a perverse layerMap. 
<p> 
The physical layers available in B4W8 are 0,3,4.  The patterns 
generated by Roberto for this wedge use 0,1,3,4.  We want to 
make physical layer 1 a wild card.  So we notice that physical 
layer 1 corresponds to associative memory layer 1 in the current 
layerMap.  The superstrip pitch for AM layer 1 is 4 strips.  So 
the wildcard hit gets mapped to superstrip 199 (this is all 
in decimal). 
<p> 
To change Roberto's patterns for B4W8 into 3/3, we do this: 
(1) strip out all patterns that cross between B4W8 and other 
wedges (maybe not strictly necessary, but keeps things simple); 
(2) replace superstrip for AM layer 1 with "199" for all 
patterns in which the layer 1 superstrip was in barrel 4. 
I wrote a little Python script to do this: it is in 
~ashmansk/python/threeoutof3.py.  It will need to be modified 
if it is to work for other sectors. 
<p> 
The updated pattern file is now in  
~ashmansk/patt_030218_3of3inb4_w08.patt . 
<p> 
Note that a separate part of this process is to make fit 
constants for which the layer 1 resolution is inflated to 
several centimeters.  Jahred and Roberto already did this, 
back in December, and those fit constants are still in place 
for B4W8. 
<p>
<!-- Author: Bill -->
<!-- Comment: Mon Feb 24 03;43;44 comment by...Stefano -->
I wander why the wild card for this B4W8 has to be 199 instead of 799 as previously. A wild card other then 799 in the patterns douls not work unless xftWildVersion (and/or cold start code) is modified. Just a typo ?
<!-- Comment: Wed Mar 19 12;16;34 comment by...Bill -->
799/4 is 199.  The superstrip pitch is 4.
<!-- Date: Wed Feb 19 21:23:36 2003 -->
New SVT mapset to recover B4W8 using 3 out of 3 configuration was installed. <BR> 
(this pattern was rearranged by Bill). <BR> 
According to fakehits mode (SVT internal test), it will recover without problems.   
<!-- Author: Bill, Jahred, Roberto and Taka -->


<!-- Date: Wed Feb 19 21:26:53 2003 -->
SVTSPYMON in the b0svt06 and b0svt07 was stopped by someone. 
(Or, automatically stopped???) <br> 
 
If anyone stopped SPYMON to see printout of crate carefully, 
please start again after your testing. 
 
  
<!-- Author: Taka -->
<!-- Comment: Sun Feb 23 12;51;40 comment by...Bill -->
Oops, I think that was my fault, when I was trying to debug
what had gone wrong between the big b0dau30 shutdown and the
timing tests that Greg, Peter, Jane, and I were doing.
Sorry about that.
<!-- Date: Thu Feb 20 10:08:29 2003 -->
<table><tr><td><a href=/elog/notebooks/2003/Thu_Feb_20_2003_Day.095933.ps align=top><img 
src=/cgi/elog/elog.pl?nb=2003&action=view&page=-1237 align='top'></td><td>Current SVT wedge 
coverage</a></td></tr></table> <BR> 
<cite>-- Thu Feb 20 10:07:18 comment by...Taka Maruyama --  </cite>Beam position has slight 
difference as before. movement is x:-50um, y:-100um. (current beam position is (-1835um, 
4415um))   
<!-- Author: Taka -->
<!-- Comment: Thu Feb 20 10;56;31 comment by...Gino, Jason and Taka -->
Gino said communication between SVX and SVT people is indispensable for improvement for SVT wedge coverage. I totally agree with his opinion. Actually, from December of last year (starting with communication), SVT coverage improves so much. SVT is based on SVX so that this is quite natural thing.


<!-- Date: Fri Feb 21 12:49:11 2003 -->
We succeeded to have SVT special run. (Run#159183-159185). <BR> 
#159183: 4 out of 5  +   AMS improve mode. <br> 
#159184: 4 out of 5  +   GB special chisq table  +  AMS normal mode <br> 
#159185: 4 out of 5  +   GB 0 csq table          +  AMS normal mode <p> 
 
SVT process time of #159183:  31.29us <br> 
SVT process time of #159184:  31.79us <br> 
SVT process time of #159185:  31.98us <br> 
So, it looks process time is reduced as Stefano expected. (~0.7us) <br> All browsable histograms are available from  
SVT web page. <br> 
 
Data quality is not checked yet. All data is now in the look area. Please check them carefully. <br> 
 
  
<!-- Author: Taka -->
<!-- Comment: Fri Feb 21 18;21;45 comment by...Taka -->
Strangely, mapset and hwset of these run for offline are wrong!
These run has database for 1 run before. Please use these carefully.  i.e. For 159183 analysis, use offline mapset and hwset of 159184. <br>
Fortunately, normal run has no problem since we have Si D-mode 
calibration run between SVT special run and normal run. 

<!-- Comment: Fri Feb 21 20;06;11 comment by...Taka -->
I just compare svtsim and board output for run#159184.
(Special run for GB weighted chisquare.) <br>
For ~7400 events, we have no discrepancy between svtsim and 
output. 

<!-- Date: Sat Feb 22 14:30:43 2003 -->
<pre>

---------- Forwarded message ----------
Date: Sat, 22 Feb 2003 12:16:26 -0600 (CST)
From: Bill Ashmanskas
To: Takasumi Maruyama
Subject: Re: mapset and hwset for special run

Hmmm, this is pretty bad.  I guess Run_Control fetched the correct
constants, but the database thinks that the constants were changed after
the "database fetch time" of that run.  Maybe you did the database update
too close to the time the Ace started the run?  I usually do it while the
previous run is running, just before the Ace clicks "end".  It should be
possible to do it any time before the Ace clicks "coldstart", but maybe
there is a small synchronization problem.

Anyway, I fixed it by doing something pretty dangerous.  Only do this if
you really know what you are doing, because you could easily corrupt the
entire database in a way that even I (!) might not know how to recover.  
We would have to beg Bill Badgett for forgiveness and hope that he would
know how to help us.

So here's what I did, to move the database entry date 5 minutes earlier in 
time.  Very dangerous!!!

-Bill

===

(In sqlplus program ...)

select name,to_char(createdate,'YYYY-MM-DD HH24:MI:SS'),type from 
svt_data where name='map@20030221113448';

NAME                                               TO_CHAR(CREATEDATE,
-------------------------------------------------- -------------------
TYPE
--------------------------------------------------------------------------------
map@20030221113448                                 2003-02-21 11:34:54
4outof5_20030221113448.mapset/1958718064


update svt_data set createdate=to_date('2003-02-21 
11:30:00','YYYY-MM-DD HH24:MI:SS') where name='map@20030221113448';

1 row updated.

select name,to_char(createdate,'YYYY-MM-DD HH24:MI:SS'),type from 
svt_data where name='map@20030221113448';

NAME                                               TO_CHAR(CREATEDATE,
-------------------------------------------------- -------------------
TYPE
--------------------------------------------------------------------------------
map@20030221113448                                 2003-02-21 11:30:00
4outof5_20030221113448.mapset/1958718064


commit;

Commit complete.

exit;



On Fri, 21 Feb 2003, Takasumi Maruyama wrote:

I am surprised at offline database (mapset and hwset) being different 
at special run. It seems that offline database is wrong with 1 run before
mapset and hwset of online. (i.e. #159183 has clearly 4 out of 5 in browsable
histograms while run summary web page shows this is 4 out of 4.)

<!-- Author: Bill -->
<!-- Comment: Sat Feb 22 14;32;39 comment by.... -->
</pre>

<!-- Comment: Sat Feb 22 14;33;03 comment by.... -->
testing 1 2 3



<!-- Date: Sun Feb 23 18:31:54 2003 -->
<pre>Wow, the current list of "dead" and "very inefficient" wedges 
is the best I've ever seen: 3 dead, 2 inefficient.  (We may 
need to raise the standard for "efficient"!)  Only  
B1W7 B2W7 B5W4 are dead, and only B0W0 B4W6 are less than 
50% as efficient as their neighbors. 
 
hello world 
 
Processing /cdf/people1/ashmansk/bin/spycheck.C... 
           W0   W1   W2   W3   W4   W5   W6   W7   W8   W9   WA   WB 
davg_B0    -1   -2   -6   -2    2    5   -3    2   -2   -3   -4   -2 
davg_B1     6  -15    3   -1    1   -5   -4    0   -4  -11   -1   -3 
davg_B2    -5    1   -4    1   -2    1    0    0   -6   14   -4    3 
davg_B3   -16    6    2   -8   -4   -1    2    4   -7  -10  -14   -2 
davg_B4   -18    1    9   -8   -0   -6    3   -3    2  -14   -3   -3 
davg_B5   -30   -2   -0   -3    0   -5   -7  -14    7   -6   -2   -1 
dtail_B0   10   10   10    9    8   11   15   10   11   10   11   12 
dtail_B1   17   10    8   13    8   11   10    0    9   10   10   10 
dtail_B2    9    9   11    9    9   13    9    0   18   11   11   11 
dtail_B3   11    9    8    9    8   10   10   12   10    8   11    9 
dtail_B4   11    8    9    8    9   10   10    8   19   10    9   11 
dtail_B5   17   11   10   11    0    9   11    8   10    8   11   11 
chisqw     11   12   11   11   11   14   11   13   10   10   11   12 
rate_B0    37*  91   94   94   85  100   92   81   84   87   83   80  
rate_B1    96  100   88   96   95   97   94    0*  79   97   87   96  
rate_B2    84   94   95   62  100   66   76    0*  89   73   83   90  
rate_B3    75   86   78  100   94   89   80   66   77   76   70   77  
rate_B4    75   76   86  100   96   82   36*  73   78   85   66   75  
rate_B5    75   96   95  100    0*  92   88   79   85   82   83   92  
dead 3 B1W7 B2W7 B5W4 
ineff 2 B0W0 B4W6 
chisq 11.26 
chisqgb 8.06 
proctime 22.59 
davg -2.90 
drms 112.80 
dresol 52.76 
dtail 0.103 
ntrkgb 1.59 
ntrk 2.01 
nxtrp 5.02 
(int)0 
</pre>
<!-- Author: Bill -->


<!-- Date: Sun Feb 23 18:34:11 2003 -->
<pre>Gino's comments from last week: 
 
What is still left to do is to try to deal with the "inefficient wedges". 
Here are my first thoughts about them: 
The inefficient guys are: 
SB0W0: L4 as a dead bit 6. L2 is gone. Is it better 3/3 
SB2W5: L0 has a dead bit 6, is it better to use the L4? 
SB2W7: L1 has a dead bit 1. L4 should be better. 
SB4W6: L3 has a dead bit 3. L2 is gone. Is it better 3/3? 
 
I think we should digest this and come out with the best possible 
configuration. Let me know what you think. 
</pre>
<!-- Author: Bill -->