<!-- Title: Day shift. Sun Oct  8, 2000 -->
<!-- Leader: John Yoh -->
<!-- Ace: Alexei Varganov -->
<!-- Co1: DongHee Kim -->
<!-- Co2: Bryan Ward -->
<!-- Co3: &nbsp; -->
<!-- Co4: &nbsp; -->
<!-- Co5: &nbsp; -->
<!-- Notes: -->
<pre>Initial SVX Rad readings -- 0	25.37	.0011	24.34 
 
Job list : 
	Make sure that 2_5 work 
	Make sure that all trigger can have prescale 
		adjested (Greg) 
	</pre>


<!-- Date: Sun Oct 8 10:12:58 2000 -->
<pre>During the Tevatron access, the COT high voltage was ramped up.  
The SL7 problem did not appear, but the ones in SL3 and SL4  
came back.  Best guess at the moment is that we will have to 
disable SL3 quad C, but may be able to live with the SL4 trips.  </pre>
<!-- Author: R. Wagner  -->


<!-- Date: Sun Oct 8 11:28:10 2000 -->
<pre>We are taking a test run with COMM...TABLE_2 5 (40) 
 
We are going to change prescales (by hand) so that we only let  
min_bias trigger to be unprescaled. 
 
During the run we saw several done_timeout error messages related to bunch crossing mismatch. We suspect that this error is due to tevatron tunings.</pre>
<!-- Author: Alexei V -->


<!-- Date: Sun Oct 8 11:28:53 2000 -->
<br><b>Myron Mode: L1 Early checkout</b><br> 
I tried to look at run 100750 to see if the myron mode L1 
early data looked right, with the trigger events in bucket 
one.  What I found was that the data "a-stream" was filtering 
out the myron mode buckets 0,2,3 and keeping only bucket 1. 
We called in Pasha and he confirmed this.  We would like to run 
with L1 early Myron Mode for today's shots.  We called Stephen  
and he and Pasha are working on fixing the data stream so that it 
(hopefully) doesn't split the stream and we accept everything into one place until things are more stable.  Work is in progress.  However, this may indicate that at least the L1 early 
mode is functioning, given that bucket 1 was kept and bucket 0 
filtered (ie- the events were mainly in bucket 1).
<!-- Author: R. Erbacher :: (run 100750) -->


<!-- Date: Sun Oct 8 11:35:46 2000 -->
<table><tr><td><a href=/elog/notebooks/2000/Sun_Oct__8_2000_Day.113521.ps align=top><img src=/elog/gifs/ghost64.gif  width='56' align='top'></td><td>Here are the plots of total CHA energy in Myron Mode buckets 0, 1, 2, and 3.  Notice that *only* bucket 1 exists in the data stream.  Doh!  Pasha/Stephen fixing this now before our beam this afternoon.</a></td></tr></table>
<!-- Author: R. Erbacher -->
<!-- Comment: Sun Oct  8 12;44;21 comment by...R. Erbacher -->
<i>Make that Stefan, and note that Pasha is the one that's working hard on this and we need to test it before using it in beam today.</i>
<!-- Date: Sun Oct 8 12:29:57 2000 -->
<p> 
Starting in run 100763 (11:40 AM) new SCPU code has been loaded to try to reduce the frequency of NoSuchEvent errors from the SCPUs ("Can't find event xxx for sending to L3"). This is a short patch in SCPU 3.20 not in CVS. 
<p>
<!-- Author: Steve Tether :: (run 100763) -->
<!-- Comment: Sun Oct  8 12;47;43 comment by...Steve Tether -->
Link to EVB log entry


<!-- Comment: Sun Oct  8 12;50;07 comment by...Steve -->
That's odd, I didn't get the nice green arrow when I pasted in the log clipboard. Oh, well, if your'e interested see the EVB E-log for Oct 8.
<!-- Comment: Sun Oct  8 14;09;11 comment by...rvidal -->
this may have been my fault, since I seemed to have introduced
a bug in the e-log code at this point - I restored the old code
<!-- Date: Sun Oct 8 12:48:36 2000 -->
<b>Calorimeter trigger rates:</b> 
I was looking at ymon temp plots and Carla's printouts to look 
at how biased we will be with cal triggers on noisy towers. 
Steve and I compared the noisy ones to the masked channels 
in traceDirac.  It looks like there are a few in the plug and 
perhaps elsewhere that might be nice to mask, as they keep triggering much more than others.  We've all decided that 2GeV 
is too low for the sum Et threshold, but also things might be helped if we got rid of only a few noisy channels throughout the 
whole detector.  This is something Rick or I could look into later when we see the rates when we get with beam.  For now I'd like 
to leave it as-is and see how the calorimeter triggers do with beam.
<!-- Author: R. Erbacher -->
<!-- Comment: Sun Oct  8 12;49;25 comment by...rde -->
undo italics </i>



<!-- Date: Sun Oct 8 13:08:38 2000 -->
<pre>Tony 'n Tony reboot CSL server.</pre>
<!-- Author: Alexei V -->


<!-- Date: Sun Oct 8 13:48:34 2000 -->
<pre>CSL status: A RAID controller which started dying last night  
is now completely dead. This controller has been removed  
from the system. There will be a replacement. For now, 
CSL has been restarted using the remaining disks: disk3 
and disk4 (total of 450 GB). 
 
</pre>
<!-- Author: Tony (and Stephan) -->



<!-- Date: Sun Oct 8 14:26:57 2000 -->
<pre>We are starting a run with the COMM...TABLE_2 5 (40) without  
modifying any prescales.  
 
SUM_ET_10   no prescale 
JET_2 no prescale 
 
MIN_BIAS prescaled by 5 
ZERO_BIAS prescaled by 100,000 
 
 No SVX. No COT </pre>
<!-- Author: Alexei V :: (run 100776) -->


<!-- Date: Sun Oct 8 14:57:27 2000 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>Everybody, please, check that free space of  
(disk3+disk4)@b0dau32 >= 50 GB 
 
Don't send the data if  
(disk3+disk4)@b0dau32 <= 5 GB</pre></td></tr></td></table>
<!-- Author: Alexei V -->


<!-- Date: Sun Oct 8 14:58:43 2000 -->
<pre>around 11 am asked L3 group (Farrukh) to link new L3  
executable with all 
the events written into stream A - we do not need stream B  
until it becomes clear what needs to go there. Also need  
to drop 2 CT_HitSets (240 KB/event) from L3 output. 
</pre>
<!-- Author: Pasha -->


<!-- Date: Sun Oct 8 15:55:05 2000 -->
<pre>Pbar test shot was injected at 15:42. They will do another 
test Pbar shot before doing the "keepers". The MCR will 
give us 2 minute warning before injecting the keepers.</pre>
<!-- Author: John Yoh -->


<!-- Date: Sun Oct 8 15:55:06 2000 -->
<pre>We started a new run without SVX COT PCAL_04 WCAL_02,07 and CLC 
We overwrote COMM...TABLE_2 5 (40) so that we use only  
ZERO_BIAS/100,000 and SUM_ET_10 
</pre>
<!-- Author: Alexei V :: (run 100787) -->
<!-- Comment: Sun Oct  8 22;08;28 comment by...R. Erbacher -->
<b>pcal04</b> I asked specifically before I left for a documentation of the problem found in pcal04 and see none.  At
that time it was thought that this might be a VRB problem, and
I requested that all of the error messages be documented carefully surrounding this problem.  All I can figure out now
is that pcal04 is out with <i>no reason given</i>!  
<!-- Date: Sun Oct 8 15:57:09 2000 -->
<font color=red>Shift Summary: </font><pre>Again, kingmaker, but not the king. 
 
Lots of problems--so not much data taken. 
But, we are taking data now, so we are ready for beam ???</pre> 
<br><b>End of Shift Numbers</b>
<table><tr><td width=60% align=left>
<b>CDF Run II <p></b>                       
<pre>
Runs                   
Delivered Luminosity   0  pb-1
Acquired Luminosity    0  pb-1
Efficiency             
   
</td></tr></table></pre>
<!-- Author: John Yoh -->


<!-- Date: Sun Oct 8 16:07:11 2000 -->
<pre>We switched off the Myron mode 
We started a new run without SVX COT PCAL_04 WCAL_02,07 and CLC  
We overwrote COMM...TABLE_2 5 (40) so that we use only   
ZERO_BIAS/100,000 and SUM_ET_50</pre><font color=red><cite>(Entry started on Sun Oct  8 16:07:06 2000)</cite></font>
<!-- Author: Alexei V -->
<!-- Comment: Sun Oct  8 16;08;15 comment by...Alexei V -->
The run is 100789


<!-- Date: Sun Oct 8 16:17:44 2000 -->
After long consideration, I decided three hot towers in the plug where too hot to leave unmasked.  In the process of checking the existing mask, I realized there was no good way of checking the history of previous maskings.  Since the masking may be there either for a calorimeter or a trigger problem, it's very difficult to decide whether one should unmask any tower, other than to take the stand of unmasking everything and then remasking (as Rick and Pedro have been doing). 
<p> 
Editorial mode off.  The towers masked were (in Carla notation): 
<ul> 
<li>phi=22, eta=19 
<li>phi= 2, eta=23 
<li>phi= 3, eta= 2 
</ul><font color=red><cite>(Entry started on Sun Oct  8 16:17:37 2000)</cite></font>
<!-- Author: Steve Hahn -->
<!-- Comment: Mon Oct  9 02;29;00 comment by...R.J. Tesarek -->
I see no reason for the masking of these towers.  Please make notes as to why a tower is masked.  Further, the only people who should be masking towers right now are 1.Tesarek, 2. Amaral, 3. Meyer, 4. Chlebana.  This is to avoid masking towers without proper documentation.

<!-- Comment: Mon Oct  9 17;35;29 comment by...W.Badgett -->
<pre>The history of masking is kept in the hardware database 
on a card-by-card basis.  The constructed (configuration) 
masks are also kept in the run database, but these may not 
necessarily be "hot".

I can add a feature to traceDirac to dump the history of 
a given channel.   Since the mask is stored per card in a 
six-bit mask, this is doable, but not trivial.</pre>