<!-- Title: 10:52:37  Mon Apr  2 2007 -->
<!-- Crewchief: Oscar (MPC) -->
<!-- Op1: Jose (SPL) -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
The plan is to take data and have fun... setting the preference in the first


<!-- Date: Mon Apr 2 10:59:59 2007 -->
ISL-PCE line is touching it's warning limit (13.3 psi) occasionally. I have an entry in the main log to page me if it is reaching ~13.4 - 13.5 psi, and then I will adjust the flow accordingly. It's only at 1.7lpm, so I'd prefer to wait it out.
<!-- Author: Jennifer :-) -->


<!-- Date: Mon Apr 2 11:05:22 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11029&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11029  width='300' align='top'></a></td><td>ISL PCE (in purple) looks pretty stable, so no adjustments made today (especially with über-access tomorrow)</td></tr></table>
<!-- Author: Jennifer :-) -->


<!-- Date: Mon Apr 2 11:05:59 2007 -->
<h3>...The word on the street</h3> 
 
<p>The word on the street is the big Tuesday access is still on...so the store about to go in will be terminated tomorrow.</p>
<!-- Author: Ankush -->


<!-- Date: Mon Apr 2 11:43:50 2007 -->
<h4>Silicon Integrated Dose Alarm</h4> 
 
<p>Just befor scrapping, we got an integrated dose alarm</p>
<!-- Author: Ankush Mitra (SciCo) -->


<!-- Date: Mon Apr 2 12:12:42 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11030&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11031  width='300' align='top'></a></td><td>New store finally in. Store number 5317 with initial luminosity 240E30. We had an integrated dose alarm right at the beginning of the store (when they declared collisions) but losses are fine after scraping and we put silicon in. SVT plot looks fine, SVXMon has the "lately yellows". I will keep checking, but everything should be fine.</td></tr></table>
<!-- Author: Oscar -->


<!-- Date: Mon Apr 2 12:38:08 2007 -->
<center><a href='/elog/notebooks/silicon/Mon_Apr__2_2007_123725.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11033' ></a><a href='/elog/notebooks/silicon/Mon_Apr__2_2007_123735.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11035' ></a></center>
<!-- Author: Jose, Ignacio and Oscar -->
<!-- Comment: Mon Apr  2 12;43;07 comment by...Jose, Ignacio and Oscar -->
ADCMon distributions for ladder e5a4 (SB5W10L4) during the current run. Left plot are the chips for the phi-side of the ladder. Right plot, the ones in the Z-side. It seems we have lost the Z side that is no longer giving physics.<br>
A jumper failure is the current suggestion, but we will investigate further.

<!-- Date: Mon Apr 2 12:47:22 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W10L4 
<li>problem n: 1985 
<li>Status: needs_work
<li>Type: AVDD
<li>Action: Diagnosis_update
<li>entered by: oscar 
<li>description is: Once we started data-taking ladder was not giving data on the Z-side (run 237972). Candidate to be a jumper failure (phi side seems to be fine). 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W10&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Apr 2 12:47:22 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W10L4 
<li>problem n: 1985 
<li>Status: needs_work
<li>Type: AVDD
<li>Action: Diagnosis_update
<li>entered by: oscar 
<li>description is: Once we started data-taking ladder was not giving data on the Z-side (run 237972). Candidate to be a jumper failure (phi side seems to be fine). 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W10&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Apr 2 12:48:07 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W10L4 
<li>problem n: 1985 
<li>Status: needs_work
<li>Type: AVDD
<li>Action: Diagnosis_update
<li>entered by: oscar 
<li>description is: Once we started data-taking ladder was not giving data on the Z-side (run 237972). Candidate to be a jumper failure (phi side seems to be fine). 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W10&layer=L4">report</a></ul>
<!-- Author: Problem DB -->
<!-- Comment: Mon Apr  2 13;20;33 comment by...Oscar -->
Oops, it seems I did it in triplicate.... forgetting I am not in Spain and its bureaucracy any longer :)<br>
It will not happen again (I will try not to do it again, I mean)

<!-- Date: Mon Apr 2 14:24:32 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: LB0W5L3 
<li>problem n: 1241 
<li>Status: needs_observation
<li>Type: Offline
<li>Action: Monitoring
<li>entered by: ballarin 
<li>description is: I have seen plots related to this ladder: -ADCmon -bias voltage plot -charge collected (landau) plot The ladder seems to be working correctly but will be under further watching.   
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B0W5&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Apr 2 14:28:09 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11036&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11036' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11037&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11037' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11038&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11038' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11039&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11039' width='300'></a></center>
<!-- Author: Ignacio -->
<!-- Comment: Mon Apr  2 14;31;20 comment by...Ignacio -->
SB011L4 is latest loss of the z side we had back in 01/20/07 (after more than a year?). 
We'll see if the bitreporter gives errros for the phi side also.
In that case we should increase the Rdriver as suggested in this 
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=336&frame=2&anchor=18:26:45'>
study</a>. 



<!-- Date: Mon Apr 2 14:44:47 2007 -->
<h4>A word from the Big Cheese</h4> 
 
<p>In Drendel's elog, the Tuesday access is scheduled for 7am.</p> 
 
<p>Everyone should turn in early to get their beauty sleep.</p>
<!-- Author: Ankush  -->


<!-- Date: Mon Apr 2 15:09:40 2007 -->
<h4>Theory on the SVXIICON memory problem</h4> 
 
<p>Yesterday, the COT PC crashed due to a memory problem.  Today it was traced down to a network initiated virus scan which eventaully killed the COT PC.</p> 
 
<p>Now it may be coincidence SVXIICON suffered a memory problem. But could a network initiated virus create the same memory problem with SVXIICON.   Another point to note is both PCs are managed by Mark Knapp, so one may assume the setup of both machines to be similar.</p> 
 
<p>The COT people resolved the problem but not allowing network initiated virus scans. Would the same strategy work for us ?</p>
<!-- Author: Ankush  -->
<!-- Comment: Tue Apr  3 02;35;32 comment by...Ulrich -->
How did the crash look like? If it is the same "memory something in NAM.exe" then it can be solved by a biweekly reboot. This is the first time I hear about a virus scan, but I wouldn't be surprised if CD started such a thing...
<!-- Comment: Wed Apr  4 06;26;00 comment by...Ankush -->
<p>If I remember correctly, the error box reported "failed memory allocation" or something like that.  I thought it was interesting that both SVXIICON and the COT PC both suffered memory problems at the same time. I also remember seeing a Norton Anti-Virus window pop up after rebooting SVXIICON.</p>
<!-- Date: Mon Apr 2 19:07:07 2007 -->
<h3> New GhostBuster settings </h3> 
After the last jumper failure candidate, we have decided to change the number of Ticks in the GB from <b>13</b> → <b>12</b>. We will leave it like this for the momment while this is being investigated.
<!-- Author: Ignacio and Jose -->


<!-- Date: Mon Apr 2 21:37:12 2007 -->
I got paged because there was a jump in bias for SB2W9L0 (<a href="http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2007&action=view&page=276&frame=2&anchor=21:15:21.055">here</a>). It is not pretty large (around 10 muA)so I decided not to come to the Control Room for a detailed look.<br> 
I instructed the shiftcrew to monitor any change in this current and page me if it changes again. I will look at it in the morning (if it is still there... Jose claims it is probably due to a trigger prescale).
<!-- Author: Oscar -->
<!-- Comment: Mon Apr  2 22;41;34 comment by...Ignacio -->
Yes...all the bias currents show  a similar jump. It was the 10 KHz increase in L1A rate.
<!-- Date: Mon Apr 2 22:29:52 2007 -->
<center><a href='/elog/notebooks/silicon/Mon_Apr__2_2007_222830.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11041' ></a><a href='/elog/notebooks/silicon/Mon_Apr__2_2007_222852.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11043' ></a><a href='/elog/notebooks/silicon/Mon_Apr__2_2007_222907.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11045' ></a><a href='/elog/notebooks/silicon/Mon_Apr__2_2007_222921.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11047' ></a></center>
<!-- Author: Ignacio -->
<!-- Comment: Mon Apr  2 22;39;54 comment by...Ignacio -->
For reference before the trigger test.



<!-- Date: Mon Apr 2 23:06:21 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11048&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11048' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11049&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11049' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11050&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11050' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11051&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11051' width='300'></a></center>
<!-- Author: Ignacio -->
<!-- Comment: Mon Apr  2 23;14;49 comment by...Ignacio -->
<pre>I looked at the 13 jumper failures listed above. The first 3 are the ones that look more interesting...e494 has a trip limit at 1700, it is going to trip one of these days..</pre>


<!-- Date: Tue Apr 3 00:02:48 2007 -->
<table><tr><td><a href=/elog/notebooks/silicon/Tue_Apr__3_2007_000242.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11053  align='top'></a></td><td>a</td></tr></table>
<!-- Author: a -->
<!-- Comment: Tue Apr  3 00;04;15 comment by...Ignacio -->
This is the prescale change. The jump in L1A is large, but expected. Since we start at low lumi, we get all the prescales changes at the same time according to David.


<!-- Date: Tue Apr 3 00:07:00 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11054&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11055' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11056&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11057' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11058&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11059' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11060&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11061' ></a></center>
<!-- Author: Ignacio -->
<!-- Comment: Tue Apr  3 00;08;28 comment by...Ignacio -->
This is how the AVDD current of the jumper failures respond to L1A rate. The first step is just starting to run, the second one is the prescale change.  


<!-- Date: Tue Apr 3 00:11:24 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11064&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11065  width='300' align='top'></a></td><td>That's how a normal ladder AVDD looks like. In fact the jumper failure plots above look like DVDD. </td></tr></table>
<!-- Author: Ignacio -->


<!-- Date: Tue Apr 3 00:32:02 2007 -->
<h3>Test is terminated.</h3> 
 
 There were no resonances, nothing particulary strange. My conclusion is that  a jump in L1A looks the same as a resonance from the point of view of the jumper failure ladders,... maybe it also  bahaves as a resonance to get ladder into jumper-failure state, i.e. break the wire. Maybe not. Anyway I think we really need  to get someone/sometime to look at the correlations of currents with L1A rates.
<!-- Author: Ignacio -->
<!-- Comment: Tue Apr  3 00;39;50 comment by...Ignacio -->
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2007&action=view&page=277&frame=2&anchor=00:14:44.491'>
Main e-log test entry. </a>


<!-- Date: Tue Apr 3 02:11:34 2007 -->
I got paged by iFix because of a trip in ISL/L00. Calling RC they told me it was an spontaneous switch off. They were recovering the detector. I told them to call/page me in case of problems.
<!-- Author: Oscar -->
<!-- Comment: Tue Apr  3 06;24;47 comment by...Oscar -->
It seems that it was crate 12 and they had no problems in recovery.
<!-- Date: Tue Apr 3 06:16:04 2007 -->
Another torturing night for ACEs and SciCo. Even after the last changes that Ron Moore made yesterday in TevMon AAGC warning limit, the warning went off like 50 times tonight.
<!-- Author: Jose -->
<!-- Comment: Tue Apr  3 15;07;10 comment by...ronmoore -->
<a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11066&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11066' width='300'></a>
<!-- Comment: Tue Apr  3 15;09;41 comment by...ronmoore -->
The above plot shows that E:SVXWRN starting warning AAGC passed the criterion: (short) RMS > 1 kHz AND (short) average > 5 kHz.
<!-- Date: Tue Apr 3 06:26:57 2007 -->
When outting silicon to Stand-by after finishing data-taking, we have a spontaneous switch-off of Crate PS 1. We leave those wedges off since we plan to switch off everything anyway for the access.
<!-- Author: Jose and Oscar -->


<!-- Date: Tue Apr 3 09:04:20 2007 -->
We switched off the detecor this morning at soon as the store was dropped. AutoHocker to manual. After some change of set points and closing of the valuves the present status: 
<li>ISL e-Valves and SVX portcards closed</li> 
<li>ISL set point 6 C </li> 
<li>SVX set point -3</li> 
<Manual valves in the collsion hall closed> 
<li> Chiller bypass valve is at 0 %</li>
<!-- Author: the idle one in the control room -->
<!-- Comment: Tue Apr  3 09;05;12 comment by...still idle -->
<pre>Now we are going for section II: the drain.</pre>


<!-- Comment: Tue Apr  3 22;24;37 comment by...Jennifer :-) -->
Looks like we're all finished with the cooling fanangling... pleasse see the complete entries below.
<!-- Date: Tue Apr 3 09:06:24 2007 -->
Jen and Saty are going in the collision hall. It is not clear the situation of the arches/muon walls because iFix picture is broken. 
They will check what they can do.
<!-- Author: idle one -->
<!-- Comment: Tue Apr  3 09;13;32 comment by...idle-one -->
We just lost communication with PS 4, so clearly they have reached SW Top Bottom. They are going for ISL IB0W2.

<!-- Comment: Tue Apr  3 10;34;41 comment by...i-o -->
communication to the crate was  back 15 min ago.


<!-- Date: Tue Apr 3 13:09:25 2007 -->
<h3>Current status of the power supply access</h3> 
So far we've obtained 3 of our 4 objectives, although none of our changes has been tested yet since the detector is off.<br><br> 
<b>IB0W2</b><br> 
This supply has problems with drooping DVDD currents on 3 channels.  We swapped in one of the NEW ISL supplies from CAEN.  It loadbox tested fine, so we cabled it up to the wedge.  It still needs to be tested from the PSGui.<br><br> 
<b>LB1W2</b><br> 
The bias scans show that L2 is probably underbiased. From the turn-on IV curve, which is more linear than we expect, it's also possible the bias connectors aren't fully connected.  We checked the connectors; the crowbar was screwed into the cable, so the connections looked fine.  We then bumped the bias trip limits on L0, L1, and L2 up from 90V to 160V.  This supply also still needs to be tested from the PSGui (just to make sure the cables are all connected again).<br><br> 
<b>SB3W9</b><br> 
This supply also showed drooping DVDD on two channels.  We swapped it out and the new supply loadbox tested fine, so we cabled up the wedge.  It <i>also</i> still needs to be tested from the PSGui.<br><br> 
Our fourth and final task for today is to swap out LB0W5, which shows one channel with drooping DVDD.  However, this particular L00 wedge is powered by an SVX supply.  We used our only spare SVX supply on SB3W9.  We could swap in a L00 supply, except we don't have spares of the L00 sense, low voltage, and bias adapter cables.  We'll check over at FCC this afternoon to see if we can have more of these adapters built.  If the answer is yes, then we'll go ahead and swap the supply this afternoon.  If the answer is no, then we'll have to leave it for another day.  Stay tuned...<br>
<!-- Author: Jen and Satyajit -->
<!-- Comment: Tue Apr  3 15;10;24 comment by...Jen & Satyajit -->
<h4>Update on L00 adapters</h4>
We could not find Hank or Vince at FCC.  We checked Hank's teststand, but found only a L00 sense adapter.  That means we have spare sense and bias adapters, but no spare low voltage adapter.  We decided not to go for the L00 swap today, since we'd have to use our only low voltage adapter.  We'll talk to Vince about getting the parts for more adapters.<br>



<!-- Date: Tue Apr 3 23:13:49 2007 -->
<h3>The ISL Cooling Access... though Jennifer's eyes</h3> 
This morning went rather smoothly, all of us following the prepared JHA. Most details are contained in the JHA (step-by-step procedure which was followed relatively closely) so I'll put in my highlights. 
<p><h4>Access Preparation Work:</h4> 
<li>Following the JHA, the night before, I printed out SVX and ISL Cooling, Manifold, and Flow Monitor pages from iFix. This was very helpful when re-establishing flows later on so that we could compare with a "before" picture.</li> 
<li>This morning, along with setting the EV_CHBY valve to "closed", I also recommended that we set the ISL Chiller backup pump to "manual". His job is to automatically turn on when the ISL main pump is tripped off. This was part of our procedure, and we decided that it was a good idea to set it to "manual" from "automatic".</li> 
<li>To begin with, we brought SVX from -10°C to -8°C, and ISL stayed at a balmy +6°C. BH trip temperatures and L00 trip temperatures were set to +6.0°C.</li> 
<li>All necessary alarms were silenced, and then some. We didn't have a nice list, so we just silenced as the access started. Notice, that when changing set points, it's always a good idea to ask your local cryo personnel to silence the chiller evaporator temperature. Note that when you are increasing the temperature, the chiller evaporator temperature will increase outside of his iFix limits.</li> 
<li>We then proceeded with a small experiment: 
<ul><h4>Results of running SVX at -8.0°C while ISL is at +6°C (no glycol in ISL)</h4> 
This scared us, and rightfully so. We could very easily repeat the procedure of freezing the PC cooling lines when the power to SVX is off, but the SVX flow is still enabled while flow and power were dropped to ISL. This was the worst case scenario, and <b>running SVX at the elevated temperature of -8.0°C is not the solution</b>. We did a short experiment to mock the situation in a safe way (since we still had the 10% glycol mixture). While the detector was off, I killed flows to ISL and to the SVX PC lines. Flow to SVX was still established. ISL was at a +6.0°C setpoint and SVX was at the -8.0°C setpoint. This test failed *miserably* as temperatures fell very quickly. PCE lines reported temperatures below -1.0°C with no plateau in sight. We were all pretty nervous, and terminated the experiment, all in agreement that <b>-8.0°C is too cold to run SVX with ISL circulating water without an interlock change. We decide on setting SVX to -6.0°C and changing some temperature trip limits in iFix</b>. Please see the plots below for further explination.</ul></li> 
<li>After we were all ready to go on the prep side, we gave the Ops and cryo the "ok" to begin with valving off the detector by closing the manual supply, and then the manual return valves</li> 
<li>When beginning with circuit isolation for draining, there was one small unexpected problem that we encountered when trying to drain the circuit that includes our ISL back-up pump: there is a valve (stuck in the closed position) that Bill and the alcove crew could  not open. They phoned me and I turned to Andy for some interlock reasoning. It seems that this little valve is set by *one* coil in the ENTIRE interlock code. We found out that this output (telling the valve if it's allowed to open) depends on an operational air separator. Since we were draining the system, needless to say the air separator was a *bit* low. Andy opened up a data window for this variable, and forced it to "open" the valve (i.e. forced the variable "off"). Bill reported over the walkie-talkie that they were able to open the valve and life was good. We "cleared the force" once the circuit was drained.</li> 
<li>The procedure for draining the detector started, and I camped out in multiple locations ensuring that the COT face pressures weren't doing anything screwy while they were isolating different cooling circuits. We did not experience any problems, as Bill Noe and his crew did an excellent job of making sure that they properly isolated the detector. Thanks, guys! :-) More information on the collision hall and alcove work will be in Jose's entry a bit later.</li> 
<li>Jose was gracious enough to allow me to have dinner (yeah, this took all day) and paged me to return to re-establish flows!!! <b>Flows to ISL re-established amazingly well!</b> I was able to re-establish approximately 1.0 lpm through all ISL lines on the first shot, and my cooling lines and I didn't have performance anxiety as all of the big shots looked on, including our spokes, Rob Roser.</li> 
<li>Once we proved that we could re-establish flows (i.e. all valves that needed to be open were open), Rob and the Ops went back into the collision hall to begin to close up.</li> 
<li>With only tripping the West side of ISL *once* (and *NO* trips on the East side, GO ME!) we brought ISL back up better than it was before our access. Most lines have flows near 3.0 lpm on the west side, and the East side is around 2.5 lpm.</li> 
<li>Currently, all sono-alarms and everything that needs to be unsilenced is, and we are in the process of getting rid of IMON pinkies and bringing our silicon up for the next store.</li> 
<p> 
Currently, we have SVX running at -6.0°C with the BH trip limits (and L00 trip limits) at 6.0°C. I have "Set A/W Limits" to assure that a cranky BHE2 doesn't get too warm according to his iFix limits. We are in the green for SVX with some remnant cryo alarms still ignored for ISL (to be altered soon...). All in all, although it took quite a while to get through today, we had a nice access that ended on a high silicon cooling note! 
<p> 
<h3>A BIG "Thank you!!" to all of the help we had today! Thank you to Bill Noe, Warren, KC, Jim, Dean, Del, Rob, Doug, Mike, Peter, Mary, Andy Hocker :-), and ALL of our wonderful Silicon Crew!</h3>
<!-- Author: Jennifer :-) for Jose, Ignacio, Oscar, Ankush & all of the Sillys -->
<!-- Comment: Wed Apr  4 02;22;38 comment by...Jennifer, Jose, Ignacio, Oscar, Ankush for all the crew -->
<h3> More on the cooling drain... </h3>
Before starting with the draining some preparation was needed. The e-valves for ISL and SVX portcards were closed and then also the return and supply valves in the manifold. The detector/manifold was then isolated from the alcove using the bypass valves. The draining plan had 5 circuits:
<ul><li>Circuit 1: From the air separator through the chiller to the UV sterilizer.
<li> Circuit 2: From the air separator through the corrosion test.
<li> Circuit 3: From the air separator to the deionizer through the electro bypass valve.
</ul>
This took less than an hour and we got around 1.5 drums (55 gallons each) of coolant. At that point the alcove part was empty.
<ul>
<li> Circuit 4: From the air separator up to the West manifold and back to the alcove.
<li> Circuit 5: From the air separator up to the East manifold and back to the alcove.
</ul>
Problems started when we tried to drain the circuit 4. After checking that the valves were in the right position we started blowing with nitrogen the circuit (12 psi). But even after waiting a while, almost nothing came out from the circuit. In addition, while trying to drain the circuit a leak was found on the bypass valve in the CH. The draining was stopped and the leak repared (this was a source of air into the system). 

<p>After this the plan was redone and the draining started directly in the collision hall. Using the bypass valves and the nitrogen, the different sections of the circuits 4 and 5 were emptied. ISL West circuit was drained and then flushed with fresh coolant (using one drum). For ISL East the same procedure was followed. Once this was done, still another drain of the system East/West was performed.

<p>When the cooling system was empty, we started the refill using one of the pumps and around 3-4 drums of distilled water (pH around 5). Surprisingly, this was really smooth and we had no problems with the pumps, air in the system... A flow of 30 lpm was stablished in the system (CH part was still isolated). The coolant was kept flowing for around 60 minutes up to the air separator level remained constant. When the air in the system was reduced to a reasonable level, the detector was opened (return 
and supply valves). After that the flows were restablished.

<p>Measurements of the pH were taken during the whole day and more frequently during the last part of the process. <b>The last measurement of the pH (coolant flowing into the detector for more than 4 hours) shows a pH of 2.8</b>. A new measurement will be taken tomorrow morning and more comments added to the e-log.

<p><b>Again many thanks to all the people involved!</b> 

<!-- Date: Tue Apr 3 23:25:42 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W4L4 
<li>problem n: 1987 
<li>Status: needs_access_2hr
<li>Type: DRO_00F3
<li>Action: Incident
<li>entered by: oscar 
<li>description is: No data coming from this ladder. Checked in SVXDAQ and there is no response from the ladder. Looks dead. We keep it in with the readback mask. We suggest a fiber-swap test and (perhaps) check light level. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W4&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Apr 3 23:28:59 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W4L4 
<li>problem n: 1987 
<li>Status: needs_access_2hr
<li>Type: DRO_00F3
<li>Action: Init_RB_mask
<li>entered by: oscar 
<li>description is: We mask the init read back to avoid the fib failing in CONFIG. We keep the ladder in in case it (magically?) comes back. IT MAY HAPPEN WITH A HOCKERIZATION: we have not tried one just because it is 'troublesome' creat 15. If it is hockerized, we should check if this ladder is still dead. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W4&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Apr 3 23:33:07 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W4L4 
<li>problem n: 521 
<li>Status: needs_observation
<li>Type: DVDD
<li>Action: Diagnosis_update
<li>entered by: oscar 
<li>description is: Changed the software-protection limits on this ladder due to  trips. Old values was 600 and it was changed to 700 due to a trip at 650. Note that this ladder is not returning any data right now. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W4&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Apr 3 23:36:37 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11067&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11067  width='300' align='top'></a></td><td><h3>Jennifer's Cooling Experiment</h3> 
To decide if running at -8.0°C is sufficient for ISL not to freeze in the SVX PS trip, ISL flow & PS trip occurance, we did the following experiment: 
<ul><li>Around 06:35, turn off the silicon. This is the first large drop that you see. Note that we have SVX @ -8.0°C and ISL at +6.0°C.</li> 
<li>The small plateau, centered around 07:11 represents flow to both systems, with PS off. Not too bad. The real panic starts when you decide to fill PC flow (see next...)</li> 
<li>The dip that results in a <b>minimum temperature of -1.42°C!!</b> is when I kill the flow to ISL and the PCs. We panic, and immediately re-establish flows to the PCs</li> 
<li> The plot finishes with SVX operating at -3.0°C and ISL at +6.0°C.</li></ul> 
Moral of the story: -8.0°C is *too cold* to run SVX with ISL at water-only without any PLC back-up. 
</td></tr></table>
<!-- Author: Jennifer :-) -->

<!-- Date: Tue Apr 3 23:38:10 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W10L4 
<li>problem n: 1985 
<li>Status: needs_work
<li>Type: Chip_other
<li>Action: Init_RB_mask
<li>entered by: oscar 
<li>description is: We have to mask the init read-back for the chip since it was making the FIB failing CONFIG. Data on the phi-side looks to be fine. Still unclear the lost of the Z-side (needs some investigation). 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W10&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Apr 3 23:41:01 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11068&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11068  width='300' align='top'></a></td><td>East COT face pressure rise when East ISL m,anual return valve was closed/</td></tr></table>
<!-- Author: Jennifer :-) -->


<!-- Date: Tue Apr 3 23:44:31 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11069&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11069  width='300' align='top'></a></td><td>West COT face pressure rise when West ISL manual return valve was closed</td></tr></table>
<!-- Author: Jennifer :-) -->


<!-- Date: Wed Apr 4 00:03:30 2007 -->
I put the Autohocker to AUTO.
<!-- Author: Oscar -->


<!-- Date: Wed Apr 4 00:24:45 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11077&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11078' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11071&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11072' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11073&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11074' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11075&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11076' ></a></center>
<!-- Author: Jose -->
<!-- Comment: Wed Apr  4 01;22;02 comment by...Jose -->
Checkout after the PS and cooling work. All looks quite normal if we do not take into account the problems explained before.



<!-- Date: Wed Apr 4 05:49:14 2007 -->
While waiting for the shot-setup we got a trip from today's bad boy: IB5W4L4 (in DVDD OverCurrent). I tried to recover it alone (just set to stand-by) but it did not hold. I power-cycled the whole wedge and seems to be fine again.
<!-- Author: Oscar -->


<!-- Date: Wed Apr 4 05:51:51 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11079&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11080  width='300' align='top'></a></td><td>This is the current for DVDD for the ladder that tripped in OverCurrent.</td></tr></table>
<!-- Author: Oscar (strikes back) -->



<!-- Date: Wed Apr 4 06:31:26 2007 -->
Since we got a quench at Tevatron during shot-setup, no data expected soon... I did a coldstart to check everything was fine after the quench. No problem observed.<br> 
IB5W4L4 has a DVDD current that steadily grows. Doing the COLDSTART seems to help to lower it (but not to change the trend to increrase). I would recommend someone to check this during the day shift since I would expect some quiet time for a while.<br> 
I guess it is likely to keep tripping in Overcurrent if limits are not changed (?).
<!-- Author: Oscar -->


<!-- Date: Wed Apr 4 09:09:29 2007 -->
<h4>Recovery of IB5W4L4 (f554)</h4> 
 
<p>IB5W4L4 tripped on DVDD.  As an opportuity to train Aart in the art of Si trip recovery, f554 came back.  Again I slightly strecthed my mark as SciCo/ex-Si expert.  But I think this is OK now as I am keeping Ignacio's pager warm.</p>
<!-- Author: Ankush & Aart -->


<!-- Date: Wed Apr 4 09:18:10 2007 -->
<h4>Rob Forrest on a special mission</h4> 
 
<p>Agent Forrest is on a special run to pick up coffee for the Si Coffee Machine!!</p>
<!-- Author: Ankush & Rob -->


<!-- Date: Wed Apr 4 10:06:16 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11082&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11082' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11083&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11083' width='300'></a></center>
<!-- Author: Roberto -->
<!-- Comment: Wed Apr  4 10;09;20 comment by...Roberto -->
<pre>Monitoring of ladder L00-f853
Plots pasted:
1- Bias voltage
2- Landau curve at -5 volts of bias voltage

This ladder seems to have a correct behavior after watching this plots and the ADCmon one as well.</pre>


<!-- Date: Wed Apr 4 10:18:26 2007 -->
<h3>Silicon Nobeam DMode Calibration in progress</h3> 
 
<p>As part of the post-access check out, a no-beam DMode calibtration is taken plce. A couple of thing happened at the start: 
 
<ul> 
<li>SVX L2 & L4 (Micron Ladders) are giving pinkys...I will bump up the IMON limits in a bit</li> 
<li>ISL Ladder IB5W4L4 tripped on DVDD again.  A power cycle of the wedge was necessary to recover the trip.  One may consider taking this ladder out as it is likely to trip durin data taking...but fear not... I will not rush ahead and do this by myself.</li> 
 </ul>
<!-- Author: Ankush  -->

<!-- Date: Wed Apr 4 10:29:16 2007 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 463
Calibration type  : standard
Run period tag    : Apr_2007
DPS-off run       : 238166
DPS-on run        : 238165
Requested by      : rob/aart
Main process id   : 27221
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->


<!-- Date: Wed Apr 4 10:30:37 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W3L2 
<li>problem n: 1280 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>After the access and SVX temperature change, this MICRON ladder went slightly above it's upper IMON limit.  Now adjusting it a bit.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>150.0</td><td>150.0</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>230.0</td><td>240</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W3&layer=L2">report</a></ul>
<!-- Author: Problem DB -->
<!-- Comment: Wed Apr  4 10;57;58 comment by...Ankush -->
<p>This thread will be closed and is an unnecssary PDB entry.  The old limits are to be reloaded when SVX returns to -10°C</p>
<!-- Date: Wed Apr 4 10:33:38 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W8L2 
<li>problem n: 1904 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>After the access and SVX temperature change, this MICRON ladder went slightly above it's upper IMON limit.  Now adjusting it a bit.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>88.0237</td><td>88.0237</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>150.0</td><td>160.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W8&layer=L2">report</a></ul>
<!-- Author: Problem DB -->
<!-- Comment: Wed Apr  4 10;58;17 comment by...Ankush -->
<p>This thread will be closed and is an unnecssary PDB entry.  The old limits are to be reloaded when SVX returns to -10°C</p>
<!-- Date: Wed Apr 4 10:35:15 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W0L4 
<li>problem n: 1988 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>After the access and SVX temperature change, this MICRON ladder went slightly above it's upper IMON limit.  Now adjusting it a bit.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>120.446</td><td>120.446</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>185.0</td><td>200.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W0&layer=L4">report</a></ul>
<!-- Author: Problem DB -->
<!-- Comment: Wed Apr  4 10;58;32 comment by...Ankush  -->
<p>This thread will be closed and is an unnecssary PDB entry.  The old limits are to be reloaded when SVX returns to -10°C</p>
<!-- Date: Wed Apr 4 10:37:50 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W3L2 
<li>problem n: 1989 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>After the access and SVX temperature change, this MICRON ladder went slightly above it's upper IMON limit.  Now adjusting it a bit.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>26.6207</td><td>26.6207</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>100.0</td><td>105.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W3&layer=L2">report</a></ul>
<!-- Author: Problem DB -->
<!-- Comment: Wed Apr  4 10;58;46 comment by...Ankush -->
<p>This thread will be closed and is an unnecssary PDB entry.  The old limits are to be reloaded when SVX returns to -10°C</p>
<!-- Date: Wed Apr 4 10:47:40 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W3L4 
<li>problem n: 1920 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>After the access and SVX temperature change, this MICRON ladder went slightly above it's upper IMON limit.  Now adjusting it a bit.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>143.0</td><td>143.0</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>165.0</td><td>180.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W3&layer=L4">report</a></ul>
<!-- Author: Problem DB -->
<!-- Comment: Wed Apr  4 10;59;04 comment by...Ankush  -->
<p>This thread will be closed and is an unnecssary PDB entry.  The old limits are to be reloaded when SVX returns to -10°C</p>


<!-- Date: Wed Apr 4 11:05:54 2007 -->
<h3> IB5W4L4 out of DB </h3> 
This ladder was tripping on DVDD overcurrent. It tripped four times since we powered up the detector yesterday night. We looked to it into svxdaq and it was giving no data. This could be a problem with temperature (we are running warmer), crate problem (it is in crate 15),... This ladder have a history of DVDD problems, we will check it. By now we will leave it out.
<!-- Author: Jose -->


<!-- Date: Wed Apr 4 11:11:42 2007 -->
<table border=0><td><tr><td bgcolor=#e0e030><h3> IMON Limits </h3> 
We are running SVX warmer than we used to (-6 C instead of -10 C). This made most of the limits on IMON incorrect. I changed yesterday all of them (~200) without documenting it in the DB. This should be a temporary situation, so do NOT document IMON changes in the PDB up to we go back to -10 C. I saved the old limits file on: 
<pre> 
/cdf/onln/home/svxii/imon/lookup_10degrees.txt 
</pre> 
we should be able to go back to the previous situation using this file.</td></tr></td></table>
<!-- Author: Jose -->

<!-- Date: Wed Apr 4 11:13:31 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W4L4 
<li>problem n: 1990 
<li>Status: needs_observation
<li>Type: DVDD
<li>Action: Removed_hdwdb
<li>entered by: jgarcian 
<li>description is: This ladder was tripping on DVDD Overcurrent. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W4&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Apr 4 11:13:31 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W4L4 
<li>problem n: 1990 
<li>Status: needs_observation
<li>Type: DVDD
<li>Action: Removed_hdwdb
<li>entered by: jgarcian 
<li>description is: This ladder was tripping on DVDD Overcurrent. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W4&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Apr 4 13:40:35 2007 -->
<h3>RTServer Glitch</h3> 
 
<p>In the Control Room, there was a RTServer glitch.  This was also seen in SVXInter</p> 
 
<pre> 
svxinter-> WARNING: Lost connection to RTserver: error code = 514. 
Waiting before reconnecting. 
Attempting to reconnect to RTserver. 
Connecting to project <cdf_daq> on <tcp:b0server05> RTserver. 
Using tcp protocol. 
connect: S_errno_ETIMEDOUT 
Could not connect to <tcp:b0server05> RTserver. 
Skipping starting <start_never:tcp:b0server05> RTserver. 
Cannot reconnect to RTserver. 
Attempting to reconnect to RTserver. 
Connecting to project <cdf_daq> on <tcp:b0server05> RTserver. 
Using tcp protocol. 
connect: S_errno_ETIMEDOUT 
Could not connect to <tcp:b0server05> RTserver. 
Skipping starting <start_never:tcp:b0server05> RTserver. 
Cannot reconnect to RTserver. 
Attempting to reconnect to RTserver. 
Connecting to project <cdf_daq> on <tcp:b0server05> RTserver. 
Using tcp protocol. 
Message from RTserver: Connection established.Start subscribing to subject </svxHVHdShk> again. 
Start subscribing to subject </caenInfo/power> again. 
Start subscribing to subject </caenInfo/ilocks> again. 
Start subscribing to subject </_svxinter_14841080> again. 
</pre>
<!-- Author: Ankush -->


<!-- Date: Wed Apr 4 14:53:25 2007 -->
<h3>Pinky and a trip</h3> 
 
<p>I spotted a PINKY in SVX. So I did a COLDSTART to fix it and somehow SB0W5L2 (e052) tripped on DVDD overcurrent.  I tried to recover the ladder to no avail.  I then powercycled the wedge and now everything is OK :-)</p>
<!-- Author: Ankush  -->

<!-- Date: Wed Apr 4 16:30:57 2007 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 463 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 238166
DPS-on run       : 238165
Requested by     : rob/aart
Submitted        : 2007-04-04 10:29:13
Completed        : 2007-04-04 16:30:22
Status           : FAILURE

Last processing stage reported : comparing to the reference calibration
Failure diagnostics :
The calibration failed the following reference comparison criteria:

            Cut Name    Sensor Set   Cut Value   Data Value
--------------------    ----------   ---------   ----------
dps_on_noise rel max    SVX_PHI      0.02        0.020666  
    bad_chan rel max    SVX_Z        0.3         0.3485    

Reference calibration runs are 200286 (DPS off) and 200285 (DPS on)
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->
<!-- Comment: Wed Apr  4 16;40;10 comment by...Jose -->
This is a D-mode calibration without beam.


<!-- Date: Wed Apr 4 21:07:39 2007 -->
So I'm back on Cooling and RadCo pagers, but I have no clue whatsoever...
<!-- Author: Ulrich -->
<!-- Comment: Thu Apr  5 17;34;58 comment by...random e-log reader -->
as if having no clue stopped anyone here
<!-- Date: Wed Apr 4 23:39:43 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11086&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11087  width='300' align='top'></a></td><td>New store 5328 in with an initial luminosity of 198E30. Everything went up fine and so fdar no problems in data taking. Several pinkies in Bias for SVX... I will wait a few minutes before redefining limits just to be sure they are fine.<br> 
They are using the new triggewr table. I will wait until the expert declares it to be fine (probably for some change of prescales) to see the effect for us.</td></tr></table>
<!-- Author: Oscar -->
<!-- Comment: Wed Apr  4 23;54;02 comment by...Oscar (in the Control Room) -->
In fact all the pinkies are in ladders 2 and 4 (the Micron effect). After waiting some minutes, I unmarked them and they seem to be fine now.<br>
We may consider changing the limits for those since it is likely that in every new store we get 20 pinkies.
<br><br>
I have two pinkies now, SB3W3L2 and SB4W7L4 that I change the high-end limits in IMON in 10 units.

<!-- Comment: Thu Apr  5 00;06;41 comment by...Ankush -->
<p>The bias pinkies for the Micron ladders is typical after the detector has been off for some time.  After a week, the bias current will not peak to such a large value.</p>

<p>So just a bit of patience is required....however I understand the need to make things simple, especially for those daft SciCos.</p>


<!-- Date: Thu Apr 5 03:30:10 2007 -->
We have a strange FIB in ISL... Yhey paged me because of a lot of yellow celss in SVXMon. You can find the details 
<a href="http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2007&action=view&page=283&frame=2&anchor=03:22:44.058">here</a><br> 
It looks like a SEU, so I told them to restart the run and page me back if the problem is still there. 
<br> 
They also have lots of pinkies... perhaps due to a trigger prescale change?  
<!-- Author: Oscar -->
<!-- Comment: Thu Apr  5 04;04;27 comment by...Oscar -->
It seems the starting of a new run fixed the FIB upset problem. However, pinkies in Bias are still there. We will have totake a look during the day shift.


<!-- Date: Thu Apr 5 06:35:33 2007 -->
There are currently a lot of bias pinkies and also an AVDD pinkie in SB1W1L4. It seems that is just on the limit. I told the shiftcrew to ignore this one too. We should check why the limit is so close to the value. It seems to have a story on AVDD and chip problems.
<!-- Author: Oscar -->


<!-- Date: Thu Apr 5 09:10:43 2007 -->
<h4>Taking care of <font color="pink">PINKY</font></h4> 
 
<p>There was a bunch of BIAS PINKYS in SVX.  I took care of them by bumping up the limits a litte bit.  You know these SciCos and be <em>so</em> troublesome.</p>
<!-- Author: Ankush -->
<!-- Comment: Thu Apr  5 23;10;03 comment by...The next MPC -->
Hey troublesome SciCo, can you stick around for another week? 
As the next MPC I would love to have a snoopy SciCo around!

<!-- Date: Thu Apr 5 09:34:16 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11088&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11088  width='300' align='top'></a></td><td>AVDD current for the SB1W1L4. It has some excursions towards lower values. I will change slightly the AVDD limits on IMON, but we want to know went this current goes down.</td></tr></table>
<!-- Author: Jose -->


<!-- Date: Thu Apr 5 09:44:38 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11089&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11089  width='300' align='top'></a></td><td>Now we have also PS with dropping VAvdd a lot of more fun for the shutdown...</td></tr></table>
<!-- Author: Jose -->

<!-- Date: Thu Apr 5 10:38:39 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W9L3 
<li>problem n: 1410 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Monitoring
<li>entered by: boveia 
<li>description is: Multiple bits are now low. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W9&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Apr 5 11:44:16 2007 -->
SB3W9L3, the ladder Antonio reports to have several bits low, is giving some Stuck-Cell ID problems in the data-taking. It seems this guy has a long history of bit errors and low bits.
<!-- Author: Oscar -->
<!-- Comment: Thu Apr  5 11;50;48 comment by...Ankush Mitra  -->
<p>I just dumped the raw data...seems to be OK since the HRR.  May be the chip got a little unhappy.</p>


<!-- Comment: Thu Apr  5 18;11;11 comment by...Oscar -->
I forgot to mention that this ladder has some past troubles with low-light level and low bits. Jose and I have the impression that the current problems with Stuck-Cell Id may be due to the warmer state of the SVX now. We will keep the ladder in provided it does not represent a big headache for data-taking.


<!-- Date: Thu Apr 5 21:24:17 2007 -->
I was having dinner when a trigger prescale occurs... with the results of 5 new pinkies (things are improving with the trigger table, they say). You can find the plots <a href="http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2007&action=view&page=285&frame=2&anchor=21:05:12.571">here</a>.  
<br> 
It seems that some of the jumps are of the order of 10 muA (and that the currents were not stable before the prescale change).
<!-- Author: Oscar (at home, this time) -->


<!-- Date: Fri Apr 6 00:28:07 2007 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 464
Calibration type  : standard
Run period tag    : Apr_2007
DPS-off run       : 238344
DPS-on run        : 238343
Requested by      : Barbara&Benedetto
Main process id   : 14980
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->
<!-- Comment: Fri Apr  6 10;35;05 comment by...Jose -->
Calibration people have solved this problem.
<!-- Date: Fri Apr 6 00:28:07 2007 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 464 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 238344
DPS-on run       : 238343
Requested by     : Barbara&Benedetto
Submitted        : 2007-04-06 00:27:23
Completed        : 2007-04-06 00:27:31
Status           : FAILURE

Last processing stage reported : start of the run_calib_analysis.tcl script
Failure diagnostics :
Not enough disk space in the calibration area: only 536960 kB free.
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->



<!-- Date: Fri Apr 6 07:23:02 2007 -->
<b>More pinkies</b>: In this case seems to be unrelated to prescale changes, but they seems just small increases. 
<br> 
As indicated in the main e-log entry (<a href="http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2007&action=view&page=285&frame=2&anchor=22:50:26.548">here</a>),  
they are in IGNORED. I decided to unmark them and wait for the new store to come. After biasing the detector we may decide if a change in the IMON limits has to be done.
<!-- Author: The MPC on the Western Front -->
<!-- Comment: Fri Apr  6 07;30;23 comment by...Oscar -->
I notice that the list of IGNORED channels is not up-to-date... I keep IGNORED those that are in the list until I discuss the issue with the SPL that is still around (I hope).


<!-- Date: Fri Apr 6 09:48:58 2007 -->
We have a DVDD pinkie: B0W3L3. Current went up from 87 to 155. I did a COLDSTART and it came down nicely. Seems to be fine now.
<!-- Author: Oscar -->
<!-- Comment: Fri Apr  6 10;47;41 comment by...Oscar (with Jose) -->
This pinkie is recursively coming up again so we power-cycled the wedge. At the same time, we powercycled the wedge corresponding to SB2W9L3 that was behaving strange yesterday. Seems that they are fine again... I will wait in the Control Room in case the ladder decided to keep giving troubles.


<!-- Date: Fri Apr 6 11:14:47 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11090&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11091  width='300' align='top'></a></td><td>After several tries to recover this ladder, we decided to set it to ignore in IMON. We checked the history plots from the ntuples and it seems it had similar bahviour in the past. </td></tr></table>
<!-- Author: Oscar and Silicon Inc. -->

<!-- Date: Fri Apr 6 19:09:07 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: LB0W5L3 
<li>problem n: 1241 
<li>Status: fixed
<li>Type: Offline
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: This ladder has no digital errors. It also gives data (see <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=347&frame=2&anchor=10:06:16'>here</a> and previous entry). Fixed.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B0W5&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Apr 6 19:18:06 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W9L3 
<li>problem n: 1410 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: This ladder has a low light level on multiple bits. So, it's not a surprise that this shows up in data. What is surprising is that it also seem to have bit7 high (gives unexisting channel numbers: 8x). However, bit7 also has low light level according to previous measurements. So, something weird is going on. It needs quiet time and, possibly, an access to measure light output.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W9&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Apr 6 19:45:01 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W10L4 
<li>problem n: 1985 
<li>Status: needs_work
<li>Type: Chip_other
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: This ladder is currently a jumper suspect. It also has drop DRO and no_First_chip in ~75%, which is similar to what was observed <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=336&frame=2&anchor=18:26:45'>here</a>. But we need to make sure we really lost z-side. According to DS error monitor, z-side is not lost complitely. It gives chip and CAP_ID's , but does not return data. I would naively expect that jumper failure should have resulted in complete loss of z-side. Needs quiet time.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W10&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Apr 6 20:04:04 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W2L3 
<li>problem n: 1979 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: This ladder had another burst of errors during 03/28/07-04/03/07. Now it's running error free again. Keep watching, if errors show up again, then try SVXDAQ.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B1W2&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Apr 6 20:07:38 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W0L2 
<li>problem n: 571 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: Errors persist at ~15% rate. Needs quiet time, will proceed from there. Changing to needs work. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W0&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Apr 6 20:10:52 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W5L2 
<li>problem n: 1972 
<li>Status: needs_work
<li>Type: RX
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: Error rate has increased to ~20%. Needs quiet time. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W5&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Apr 6 20:25:28 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W3L3 
<li>problem n: 752 
<li>Status: needs_observation
<li>Type: Chip_capid
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: CAP_ID errors on chip 85 re-appeared again. Observe for some time to see if errors persist. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W3&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Apr 6 20:27:33 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W2L4 
<li>problem n: 1423 
<li>Status: fixed
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: No errors since last entry in PDB. Fixed for now. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W2&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Apr 6 20:32:41 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W9L2 
<li>problem n: 1991 
<li>Status: needs_work
<li>Type: DropReadOut_nonRX
<li>Action: Incident
<li>entered by: sasha 
<li>description is: c2c2 at ~20% rate since 04/03/07. Needs quiet time. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W9&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Apr 6 23:08:39 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11092&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11093  width='300' align='top'></a></td><td>New store came finally in 14 hours after the time we were told...<br> 
It is store 5337 with an initial luminosity of 211.9E30 (at least we got a lot of pbars).<br> 
Everything looks fine. We have around 15 pinkies which are all in SVX-L2 and SVX-L4. I will change the limits a bit to avoid having them there for every store.</td></tr></table>
<!-- Author: Oscar -->
<!-- Comment: Fri Apr  6 23;20;58 comment by...Oscar -->
I redefined the upper limit for all the pinkies (of course, all were in BIAS). For one ladder I reaised in 15 muA (SB4W9L2). For the rest, just 10 since most of them were close to the previous limit.<br>
Everything looks OK here. I am going to wait for the persistent yellow in SVXMon to disappear. They are using the new trigger table and seem to give reasonably rates (although I am expecting pinkies when prescale changes).


<!-- Comment: Fri Apr  6 23;31;48 comment by...Oscar (again) -->
I checked SB0W3L3 has a DVDD current that is a bit unstable but at the normal level now. It gives good physics data on the phi-side (the z side was lost long time ago). I keep the DVDD display in IMON ignored to avoid being paged for an unfixable guy. I will keep an eye on it during the week-end and if it stays in the normal values, I will unmarked it.


<!-- Date: Sat Apr 7 11:53:37 2007 -->
I came to the Control Room to take a look on the pinkies that have been ignored during the last hours. All in BIAS.  
There are 3 L4 in SVX (SB0W11L4, SB2W9L4 and SB4W2L4) and 4 in BIAS1 for L00: B1, wedges from 0 to 4... strange they are in a row.<br> 
For the first of the SVX ones I just raised the limit. The other two look odd: current are much higher than expected. I will investigate. 
<br> 
The L00 ones look just very small increases and not at the same time, so they should be fine. I just raised the upper limit in IMON by 10 muA to the four of them.
<!-- Author: Oscar -->
<!-- Comment: Sat Apr  7 12;02;47 comment by...the distracted scientist -->
Oops! I just realized the two that look odd are the ones we have ignored for a long time... they have know problems. I guess I am affected by the SMS (Saturday Morning Syndrome).<br> Obviously, I keep them ignored.


<!-- Date: Sat Apr 7 12:09:11 2007 -->
Prevention is better than cure: I raised the limits in ISL for a couple of BIAS currents that are approaching the limit. They look stable and just yellow in IMON.<br> 
I guess I should not make an entry in the PDB since we will overwqrite these values too, although I guess thay may appear in the future.<br> 
Channels are: BIAS0 IB0W2L4 and BIAS0 IB1W5L3. I raised the upper limits by 10 muA.
<!-- Author: Oscar (emulando al Dr. Sanchez Ocana) -->
<!-- Comment: Sat Apr  7 15;15;42 comment by...Oscar -->
I raised in 10 muA the limit for BIAS0 to IB2W1L4 since it was close to the limit.


<!-- Date: Sat Apr 7 22:47:24 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11094&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11095  width='300' align='top'></a></td><td>Store 5338 in. Initial luminosity was 189E30 but proton losses was high (around 2000 Hz). We decided to take silicon off until we understand the situation, and it was a bit bad: they were trying to tune the beam (since in D0 was much worse) and losses went up. We took data without silicon for a while, until beam was stable.<br> 
Now everything looks reasonably well. Losses are not great (1 KHz) but seems to be stable.</td></tr></table>
<!-- Author: Jose and Oscar -->
<!-- Comment: Sat Apr  7 22;58;21 comment by...Jose and Oscar -->
By the way, with the tunning they were doing to lower the losses, the luminosity dropped to 108E30, as you can check in <a href="http://www-bd.fnal.gov/cgi-mcr/elog.pl?nb=2007&action=xe&page=264&time=22:48:26">the MCR elog</a>.


<!-- Date: Sun Apr 8 11:40:03 2007 -->
New day, new ignored cells. All the following in BIAS... I raised the limits by 10 muA: SB0W3L0, SB1W2L1, SB2W9L0, SB3W11L0, SB4W7L1, <br> They all seem to be L0 and L1, probably upset with a PS change (although the shiftcrew claims it was not related...).
<!-- Author: Oscar -->
<!-- Comment: Sun Apr  8 11;44;08 comment by...Oscar -->
I unmarked IB0W4L4 that was ignored in BIAS0. The value seems to be fine now, so no change in limits. In fact the value is well below the limit.

<!-- Comment: Sun Apr  8 11;47;07 comment by...Oscar -->
I also updated the list of knowon ignored cells, since Frank complained about it last night.


<!-- Date: Sun Apr 8 12:18:59 2007 -->
Probably due to the problems they had at the beginning of the store, the AAGC is spiky. It was giving sono-warnings every 5-10 min. I asked the ACE to ignore it in the warning decision to avoid the sono-warnings (still ON in the sono-alarms).
<!-- Author: Jose -->


<!-- Date: Sun Apr 8 16:33:01 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11096&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11097  width='300' align='top'></a></td><td>Interesting pinky: SB1W8L2-BIAS become pinky due to the data taking,,, Current went lower during some inhibit moment and then recover its upset state. 
I raised the upper limit in 10 muA to avoid having it pink everytime rate is high.</td></tr></table>
<!-- Author: Oscar el majo -->


<!-- Date: Sun Apr 8 19:23:31 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11098&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11099  width='300' align='top'></a></td><td>Store 5339 colliding. Initial instanteneous luminosity was 210.7E30. Losses seem to be be fine this time and we have no troubles. Things look great for the silicon.</td></tr></table>
<!-- Author: Oscar (and Jose) -->
<!-- Comment: Sun Apr  8 19;40;39 comment by...Oscar and Jose -->
They lost the store... Coldstart went fine in the Post-quench check-out.


<!-- Date: Mon Apr 9 00:20:33 2007 -->
Late entry. After the quench we did some investigation on the ladders that are misbehaving.  
<ul><li> IB5W4L4 : this ladder is out of the DB. We tried to put it in but it kept tripping on DVDD Overcurrent. Still out of the DB. 
<li> SB5W10L4 : this ladder is another jumper failure candidate. We could not get anything coherent from it. The Z side does not come back but it is not completely dead. Further investigation is needed. 
<li> SB3W9L3: this has clear problem of bit errors. SB3W9L2: is giving problems of Truncate and 00 sequence on chips from 4 to 8. Both ladders show problems probably related with temperature. This should go away (hopefully) when we will go back to -10 C. 
</ul>
<!-- Author: Oscar and Jose -->


<!-- Date: Mon Apr 9 07:56:30 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11100&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11101  width='300' align='top'></a></td><td>Store 5342 colliding with an initial inst. luminosity of 147.36e30. I was not paged (the shiftcrew forgot or so) but I came at the beginning to attend the 8:00 meeting. Everything looks fine.</td></tr></table>
<!-- Author: Oscar -->


<!-- Date: Mon Apr 9 09:01:42 2007 -->
New pinky in BIAS: SB0W3L3. It just went above the limit. I raised it by 10 muA and unmark it.
<!-- Author: Oscar -->


<!-- Date: Mon Apr 9 09:05:38 2007 -->
<h3>Summary of the week</h3> 
 
<b>Monday</b><br> 
<ul> 
<li> Store 5317 with initial luminosity 240E30, with an integrated dose alarm just before scrapping. 
</li> 
<li> SB5W10L4 lost its Z-side. It looks like a jumper failure, although we still get  
something (noise?) from the Z-side so we need further investigation. 
</li> 
<li> Ankush investigated the SVXIICON problem we had during the previous week-end. 
</li> 
<li>The SPLs decided to change the settings of the Ghostbuster until we understand 
the last candidates to be jumper failure. 
</li> 
</ul> 
 
<b>Tuesday</b><br> 
<ul> 
<li> We had a trigger test right before the access. Ignacio was here to check everything was fine. 
The trigger they tested was used during the week. Trigger experts were checking the rates, but we 
were there too. 
</li> 
<li> Spontaneous switch off from Crate 12. No problem to recover. 
</li> 
<li> <b>ACCESS DAY</b> for replacing the acid coolant in the ISL lines and put water 
instead. Apart from that work, Saty and Jen replaced 2 power supplies and changed the limits 
for LB1W2 (to be able to bias L2)... <b>We may need to raise the voltage</b><br> 
Here are the reports for the  
<a href="http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=347&frame=2&anchor=13:09:25">PS-work</a> and 
<a href="http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=347&frame=2&anchor=23:13:49">Colling work</a> 
</li> 
<li> Some check-out after the meeting... everything was fine except for tons of pinkies due to the new 
temperature settings: we are running SVX at -6 C until software is implemented to be safe 
regarding freezing of the cooling lines in case of trips.<br> 
Note that the change in IMON limits are not reported in the PDB because we will undo 
all of them when SVX turns back to -10 C. 
</li> 
</ul> 
<b>Wednesday</b> 
<ul> 
<li> IB5W4L4 (f544) taken out of the data taking becuase it was tripping in DVDD overcurrent. We think 
that it may recover after a hockerization of Crate 15 that we did not take the risk of doing 
ourselves due to the observed problems with this crate. 
</li> 
<li> D-mode calibration taken since noise may have changed with the higher temperature. 
</li> 
<li> Store 5328 with an initial luminosity of 198E30. Too many pinkies. 
</li> 
<li> Strange FIB (SEU) in ISL. Fixed starting a new run. 
</li> 
</ul> 
<b>Thursday</b> 
<ul> 
<li>SB3W9L3 have been giving troubles with several stuck-cell-id forcing an HRR. 
We should keep an eye on it, although it is likely due to the higher temperature. 
</li> 
<li> The BIAS pinky party still goes on... IMON limits changed. Most of the times 
the new pinkies were due to Micron ladders or to trigger PS change. 
</li> 
</ul> 
<b>Friday</b> 
<ul> 
<li> Sasha did some quiet-time studies 
</li> 
<li> Store 5337 with an initial luminosity of 211.9E30 
</li> 
</ul> 
<b>Week-end</b> 
<ul> 
<li> A lot of pinkies that are set to ignored by SciCos in IMON as instructed, until we come and raise the limits. 
</li> 
<li> Store 5338 with initial luminosity 189E30 that dropped to 108E30 after they 
got the proton losses reasonably under control. We started (before that) with no silicon. 
Then silicon was in. Strange store. 
</li> 
<li>A lot of problems at the end of the store with the abort-gap counter. It has been problematicf 
during the whole week at the end of the stores (as in the last weeks), but in this one we went 
into TevMon ALARM because it was a relatively bad store. We decided to override TevMon for once 
since all the other variables were fine... and the value was just briefly and slightly  
above the ALARM limit. Need strategy and investigation about this. 
</li> 
<li> Store 5338 with initial luminosity 210E30. It lasted 15 min due to a Tevatron abort. 
Everything was fine during injection... and during the post-quench check-out. 
</li> 
<li> Some quiet-time studies by Oscar and Jose (mostly Jose). 
</ul> 
<b>Monday and plans</b> 
<ul> 
<li> New store started just before I arrived (they forgot to page silicon MPC). It is 
store 5342 with initial luminosity of 147.36E30. Everything is fine. 
</li> 
<li> They will likely keep the store until the evening. We may request an access 
due to some plug-CAL problems. 
</li> 
<li> Until the calorimeter problem is fixed, data will be marked BAD. Ops manager suggests 
that if TevMon goes to alarm we may safely turn silicon offline since data will not be used. 
A remark is that it would be used in B-physics, but it is true that if situation gets bad, 
it would be better to check if the run will be marked bad for sure, and play safely. 
</li> 
</ul>
<!-- Author: Oscar (the watchman of the week) -->