[Emailed (to B. Roe and C Sougnez) and posted]
Bruce Roe wrote:
> [..Interesting details of optimizing runs under v 1.1/POP5 on the 3700. Deleted
> to save space...]
> Fortuantely, 'knock on wood', all 5 have
> been up and running all week except for one that ran and didn't seem to see
> or collect any signal (eventhough re-running the same plate gave beautiful
> signal on the same instrument after restarting both the 3700 and the associated
> computer). We routinely re-start both the 3700 and computer at least once
> a day just to free the air of any funkey electrons that might have crept in.
> Eventhough ABI says not to do this, I feel better knowing that the memory
> is purged by restarting.
I got an email response from Carrie Sougnez (MIT Whitehead) to an earlier post
I made. I haven't asked for her permission to post that email, so I won't post it
verbatim. But Whitehead's big problem with v 1.1 is the one you describe. They had
gotten a potential fix from PE that they were trying out.
I've had this happen once (or maybe twice)[1] to me. I've put links to my post
about it below[1], but briefly, I speculate that it has something to do with
either "skipping to the next run" and/or "stopping" a run. The run terminates
normally but later run(s?) are effected in strange ways. One way is that (again,
this is speculation that there is cause and effect here) some later run does not
collect data even though it acts like it does. (I could hear the camera shutter
clicking, but nothing was displayed to the array view screen--further I couldn't
find any data anywhere during the run or after. Rerunning the plate yielded normal
results.)
Yet more speculation on what kind of error might be causing this follows. The
3700 data collection software appears to be composed of modules that are
responsible for various aspects of running the machine. These modules appear to
communicate with each other via log files or command files of some sort. I got the
impression that when I hit "skip to the next run" (or maybe it was "stop run", the
data coming off was no longer worth collecting) a command was placed in some log
file to stop the run. Maybe this command file isn't getting completely purged
after it is executed. Then it effects a later run by shutting down one of the
modules (like the one that actually takes data from the machine and saves it to
the database and displays it on the array view window) without telling the other
modules that it has done this.
Now, if I stop a run, I do a complete shut-down (power-down) of the computer
and the 3700. (Actually, I've never used "skip to the next run" since--so I'm not
sure that even the complete shut down is effective.) Since then (about 100 runs) I
have not had this problem. But I've only stopped a run or a batch a couple of
times (like when my buffer ran dry).
I've reported my suspicions to tech support at PE bio and asked them to pass
this on to their programmers. But either it's not getting to the right place, or
I'm just being ignored. I haven't gotten any response from anybody but tech
service at PE bio.
Anyway, I realize these are all "post-hoc" suppositions--so maybe I'm dead
wrong. But if I'm right, this is really the error that is making people frightened
to switch to v 1.1--but it is pretty easy to work around. (Unless you have
software in place that stops runs or skips to the next run when the phred values
for a window of the data slips below a certain threshhold--it was my impression
from Paul McEwan's presentation at the last TIGR meeting that this is the case at
Whitehead.)
The other reason to fear v. 1.1 is that foil piercing may be damaging the
loading robot. Steven Lasky reported this in this newsgroup a while back[2]
(before the official release of v 1.1) It is unclear to me whether PE adjusted the
foil piercing method such that it no longer causes damage to the loading robot--or
not. I notice that the robot is very "cautious" in its foil piercing. Given how
gently it does the piercing, I would like to believe that this problem has been
solved as well. I've certainly been taking advantage of it. It sure is nice not to
have to add different amounts of water to various wells of a 384 well plate to
compensate for evaporation.
> On a related note, last week I updated and posted our latest template
> isolation protocols and they can be found at URL:
>http://www.genome.ou.edu/proto.html
Thanks for providing this resource. Over the past year I've been setting up a
small genomics core facility at Purdue and I would have to say that I've relied on
your site (and some emails from you) more than any other single resource to get
things set up and running.
> [...] We also put
> some Al foil over the plexaglass portion of the door to cut down on any stray
> light that may enter the sample chamber just because I'm slightly paranoid
> about light effects on the dyes.
> [...]
This is eerie because it is exactly what Mary Ann Cushman did when she came
from Oklahoma (Oklahoma State University) to use our machine last year. Is this an
independant event that is indicative of some special relationship you Oklahomans
have with aluminum foil that the rest of us wouldn't understand? (Just joking,
Mary Ann wanted to block out the light, it was me who grabbed the aluminum foil.
Since I'm using foil piercing now, I don't need it anymore...)
Phillip San Miguel
Purdue University Core Facility
[1] See http://bionet.hgmp.mrc.ac.uk/hypermail/autoseq/autoseq.200002/0013.html or
http://www.deja.com/%5bST_rn=ps%5d/getdoc.xp?AN=582351672&fmt=text
[2] See http://www.deja.com/%5bST_rn=ps%5d/getdoc.xp?AN=555863320&fmt=text or
http://bionet.hgmp.mrc.ac.uk/hypermail/autoseq/autoseq.199912/0000.html
---
