[BLAST_SHIFTS] Shift summary 09/17/2004 B (9-17)

From: Electronic Log Book (elog@blast05.lns.mit.edu)
Date: Fri Sep 17 2004 - 16:50:36 EDT


Operator: ajmasch

not an easy shift. a four-fold set of problems simultaneously arose:

1) noticed that one of the LADs (specifically, LAD LLF0B) wasn't looking right in
      visualscal or in onlineGui. for that matter, the other LADs on the same
      module looked crappy, too (i.e. non-needle-peaked TDCs). called Michael.
      after a long trip to the d-tunnel, he finally ended up moving the module to a
      different slot and reorienting the fan to help cool it better. since then, the
      LADs all look fine. good job, Michael!

2) some ET problems arose that couldn't be fixed by simply resetting CODA.
      called Taylan. somehow, too many attachments were being added to the
      transfer and this was causing problems. he rewrote a little of the CODA
      "setup" script, and the problem went away. you rock, Taylan!

3) apparently, spud6 died last night. called Ernie. he said something to the
      effect of "spud6 will not be a quick recovery". i don't know quite what is
      wrong with it, but, for the present, don't use it. Ernie is working on it, i think.
      right on, Ernie!

4) the autocruncher developed some serious problems. called Tancredi. he
      fixed it up a little. then, because of spud6's problems, it turns out that no
      new runs had started crunching since whenever spud6 died (last night). i
      figured out which runs were missing and added them to the crunch list.
      spud6 has currently been removed from the spud_list.txt entirely, but the
      rest of the spuds all have 2 processors available for crunching. you kick
      ass, Tancredi!

CCR did a little RF cavity tuning at the beginning of the shift. they now have a smooth lifetime rise to about 24 minutes at the beginning of a fill. around 15:00, there was an access so the that Ernie I and others could do a few things before the weekend.

the LADs problem has probably been going on for more than the one run (run 11192) in which it was noticed, so maybe those using the previous 1-10 runs should be wary of this.

the run list has been updated. i'm updating pol.log as much as can be...

Good polarized deuterium runs taken:
11189-11192 11196-11199



This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:31 EST