SEQanswers

Go Back   SEQanswers > Sequencing Technologies/Companies > Illumina/Solexa



Similar Threads
Thread Thread Starter Forum Replies Last Post
Demultiplexing MiSeq run - problems kga1978 Bioinformatics 4 07-21-2016 10:48 AM
MiSeq Run Fail - Microsoft Issue? Olivia16 Illumina/Solexa 10 03-09-2015 07:13 AM
Need help debugging a faulty MiSeq run simon_seq Illumina/Solexa 6 08-15-2012 04:18 AM
Worst MiSeq Run ever? pmiguel Illumina/Solexa 0 04-30-2012 04:54 AM
Has Anyone stopped a HiSeq run due to low intensity clusters? ashchin Illumina/Solexa 10 01-25-2011 03:03 PM

Reply
 
Thread Tools
Old 10-20-2012, 01:39 PM   #1
yaximik
Senior Member
 
Location: Oregon

Join Date: Apr 2011
Posts: 205
Default MiSeq stopped run

Hi all,

I set up 2 x 251 paired end run over weekend, which started normally and proceeded almost to the end of the first run. but stopped Saturday morning at cycle 232 with error message "Object reference not set to an instance of an object". Obviously, tech support is closed until Monday; User Guide has no information on this error, so I am asking if anyone have seen that happened? It is upsetting as the run was going beautifully with cluster density >1300, 85% passing filter and a lot of data promised. Can the run be resumed somehow? If not, can the data from the fisrt read be be salvaged at least?
yaximik is offline   Reply With Quote
Old 10-20-2012, 05:55 PM   #2
yaximik
Senior Member
 
Location: Oregon

Join Date: Apr 2011
Posts: 205
Default

Well, I figured out at least how to salvage data. I am posting it here if anyone runs in a similar problem. Although the run is done as nothing I can do at this point with my experience beyond proceeding with a postrun wash. But the problem was how to get usable data, which was about 5 GB out of expected 5.3 (10.6 paired). MiSeq reporter could not start as the run has not been completed, so it was happily idling in background. All I needed was to modify three files in Data/Illumina/MiSeqAnalysis/<RunNAme>/

Adding RTAComplete.txt - I just copied one from the previous successful run and modified date to when this run has stopped

RunInfo.xml - deleted line about read 2 and modified line about read 1 to match the number of completed cycles minus one, that is 231 (232-1)

SampleSheet.csv - deleted line under [Reads] referring to the second set of 251 cycles, modified the line about the first set to match the actual cycles minus one (231)

The latter two can be modified without triggering MiSeq Reporter to run, which immediately engages once the RTAComplete.txt is added. If MSR terminates with error, the job can be requeued after modifications. Voila! I got my fastq files.

Last edited by yaximik; 10-20-2012 at 06:02 PM.
yaximik is offline   Reply With Quote
Old 10-21-2012, 07:15 AM   #3
pmiguel
Senior Member
 
Location: Purdue University, West Lafayette, Indiana

Join Date: Aug 2008
Posts: 2,315
Default

Hi yaximik,
Many thanks for your protocol. May well come in useful in the future.
One pre-run intervention that I always try to do before starting a HiSeq run is a full console computer shutdown, start up. Or at least a reboot. I don't always do it before a MiSeq run but I think I will start doing so. Costs only a few minutes and should give you as close to a clean slate as you can get without reimaging the drive before a run.
--
Phillip
pmiguel is offline   Reply With Quote
Old 11-01-2012, 06:06 AM   #4
MoritzF
Member
 
Location: Europe

Join Date: Sep 2012
Posts: 10
Default

I encountered the same problem today...any idea how that error came about?
MoritzF is offline   Reply With Quote
Old 11-01-2012, 06:55 AM   #5
yaximik
Senior Member
 
Location: Oregon

Join Date: Apr 2011
Posts: 205
Default

Sorry about that. Tech Support said it is likely happened because of too high cluster density (it was >1300) and intensity profile was weird going over maximum with a sharp decline before abort. I have to take that as explanation, but pmiguel doubted this is the reason ( in another thread). I hope that close to the recommended density will prevent that from happening.
yaximik is offline   Reply With Quote
Old 11-01-2012, 07:14 AM   #6
GenoMax
Senior Member
 
Location: East Coast USA

Join Date: Feb 2008
Posts: 6,978
Default

It may still be possible to recover data (albeit partial depending on there the run failed) from such runs.

You will need access to a working install of CASAVA and someone who is familiar with illumina runs since some settings files have to be edited manually.

PS: I did not realize that Yaximilk had provided directions on how to do this on the MiSeq itself in a previous post. I will leave this in as an alternate option.

Last edited by GenoMax; 11-01-2012 at 07:33 AM.
GenoMax is offline   Reply With Quote
Old 11-01-2012, 07:20 AM   #7
MoritzF
Member
 
Location: Europe

Join Date: Sep 2012
Posts: 10
Default

Mine was 1257....I still don't get it though....I could understand if the results were bad when the clusters are too many, but exiting the run with a strange error message doesn't seem like a problem with cluster density to me. I contacted tech support, let's see what they say.

Thanks fors answering anyway. I am just now trying to recoup the reads, following the protocoll you supplied. Thanks!
MoritzF is offline   Reply With Quote
Old 11-01-2012, 07:41 AM   #8
TonyBrooks
Senior Member
 
Location: London

Join Date: Jun 2009
Posts: 298
Default

Cluster density estimation will top out eventually. You may actually have >2000k/mm2, but the MiSeq will still report 1300.

How did the Q scores look? What % of bases did you get >Q30? In my experience, this is usually a better estimate of cluster density. If Illumina are right with the over clustering, then you should have pretty terrible Q's around the time the run crashed.

I saw something similar recently (stopped MiSeq run) where someone attempted to do a 151PE run on an insert of 60bp. R1 began fine, then deteriorated towards the end. The index read was great, but then R2 was horrible. It stopped at cycle 295.
Cluster density was 1260, so I don't know if the problem was the over-read or the higher cluster density.
We used yaximik's fix to ressurect the R1, although using CASAVA with the --use-bases y*,i*,n* should also work (as GenoMax stated).
TonyBrooks is offline   Reply With Quote
Old 11-01-2012, 07:47 AM   #9
MoritzF
Member
 
Location: Europe

Join Date: Sep 2012
Posts: 10
Default

Base quality was excellent until base 80-100, at which point it dropped dramatically.

I also think that maybe the fragments are too small, which is very strange. We used Nextera XT library prep, and the fragments looked too large on the Agilent control chip.

When I checked last night, Quality score was 85% better than Q30 (at which point the machine was still before base 80) and today, before the run stopped, it was 25% better than Q30, which was when the Forward Read was complete and it began reading the reverse reads.

Still, I don't understand how this can cause the machine to stop completely. Bad data, bad reads, I would understand, but stopping with an incomprehensible error message wouldn't have made me think that there was a problem with the library?
MoritzF is offline   Reply With Quote
Old 11-01-2012, 07:48 AM   #10
GenoMax
Senior Member
 
Location: East Coast USA

Join Date: Feb 2008
Posts: 6,978
Default

Quote:
Originally Posted by MoritzF View Post
Mine was 1257....I still don't get it though....I could understand if the results were bad when the clusters are too many, but exiting the run with a strange error message doesn't seem like a problem with cluster density to me. I contacted tech support, let's see what they say.
Is this an upgraded MiSeq or a v.1 machine? With the v.2 hardware upgrade Illumina is putting in a beefier computer (core i7 CPU with 16 GB of RAM). I do not remember if the original MiSeq had a lesser spec computer (e.g. 8 GB of RAM).

Could the error possibly be due to RTA (or some other software component) running out of available memory/disk space? I had noticed with a MiSeq run (where RTA did not start normally) the disk (D drive) filled up rapidly and would probably have run out of space if I had not noticed that and kicked off RTA manually.
GenoMax is offline   Reply With Quote
Old 11-01-2012, 07:59 AM   #11
TonyBrooks
Senior Member
 
Location: London

Join Date: Jun 2009
Posts: 298
Default

I think our RTA ran fine. We had BCL files generated.
I think the problem we had is we ran out of fragments to sequence. We had probably sequenced our insert and right through the adapter. This meant we were still running cycles without being able to incorporate bases. I think this resulted in focus problems (hence terrible Q scores after about 100 bases). When it happened on R2, it go so bad that the run just aborted.

Our error message was as follows;

Best focus is too near edge of range: Autofocus best Z NaN - offset -0.0007 = NaN, which is outside soft limits -0.2950 .. -0.0050 mm: LEDSnapCommand.PrepareCaptureAndGetOffsetFpgaZPosLEDDAC (Illumina.Instrument.Bolt.Logic.SoftLimitsException)
TonyBrooks is offline   Reply With Quote
Old 11-01-2012, 08:08 AM   #12
MoritzF
Member
 
Location: Europe

Join Date: Sep 2012
Posts: 10
Default

Our machines has an i3 CPU, it has not been hardware upgraded. Which is, according to the manual, not required to run 2x251 bp runs. It would be unfortunate if this was the case...

Anyway, the hard drives are pretty empty, so this shouldn't have caused the crash. Whether the RAM was full or not at the time the MiSeq crashed, I can't find out anymore.

The errors in our log file begin with
12-11-01 13:35:14.078 +01 000000031 INF: Y Motor: Position error before settling = -1 encoder counts (0.000 mm)
And then there are more of a similar kind. I hope it is not a hardware problem with a motor inside the machine.
All in all it seemed more like a software problem to me, though.
MoritzF is offline   Reply With Quote
Old 12-03-2012, 01:04 PM   #13
mcnelson.phd
Senior Member
 
Location: Connecticut

Join Date: Jul 2011
Posts: 162
Default

Thanks for putting this out there, now I can get some data from my failed run on Saturday. My FAS was having me try to re-run RTA but that just hung at the last valid base, #502. Would have really sucked if I couldn't get any data considering the run almost completed.

As for the vague-ness of the error. I talked with an Illumina support person and they agreed that it's a pretty useless error message. He had me fully power down and then restart the system and said that a lot of these types of errors also come along with issues that show up when MCS is trying to re-initialize. Fortunately we didn't have any problems there but I'm still not pleased that I don't know what caused this error since this is the second time in a month that it's caused a run failure.

Edit: to get read 2 I had to also edit runParameters.xml and CompletedJobInfo.xml to have read 2 be only as many cycles as listed in the edited sample sheet and RunInfo.xml files.

Last edited by mcnelson.phd; 12-03-2012 at 01:31 PM.
mcnelson.phd is offline   Reply With Quote
Old 12-03-2012, 04:49 PM   #14
yaximik
Senior Member
 
Location: Oregon

Join Date: Apr 2011
Posts: 205
Default

That was the only purpose - if someone ever needs this. I also posted further development in a separate thread - may be someone finds this useful. I certainly did.
http://seqanswers.com/forums/showthread.php?t=25371
For your failed run - could you post BioAnalyzer trace of your libary, cluster density, the full intensity curve and a few tumbnail images at cycles 30, 250 and 500? I am gathering information as to what may be reasons for stopped runs.
yaximik is offline   Reply With Quote
Old 01-06-2013, 08:02 AM   #15
creeves
Member
 
Location: East Bay

Join Date: Jul 2012
Posts: 26
Default MiSeq stopped at start

I have twice had that error message you mention. For me, both times it occurred right at the beginning of the run before cluster generation had even started. When it happened the first time Illumina told me to power off and back on again, which I did, and then restart the run, which required a post-run wash first, since the MiSeq thought it had completed the previous run that never actually started. After the wash (where I switched back to the previous flow cell), the run went smoothly. I am now doing the same thing all over again on Sunday morning when there is no chance of getting help from Illumina. I think it may have something to do with space on the D: drive since I had to delete some image files before starting the first time.
creeves is offline   Reply With Quote
Old 03-08-2013, 06:09 AM   #16
aleferna
Senior Member
 
Location: sweden

Join Date: Sep 2009
Posts: 121
Default

I have the same problem here
aleferna is offline   Reply With Quote
Old 03-09-2013, 05:18 AM   #17
yaximik
Senior Member
 
Location: Oregon

Join Date: Apr 2011
Posts: 205
Default

This may happen if in previous (erroneous) run Z motor hit the bottom of the moving range and cannot recover. Quitting an restarting the software will reinitialize everything including homing Z motor.
yaximik is offline   Reply With Quote
Old 03-18-2013, 03:23 AM   #18
matth431
Member
 
Location: UK

Join Date: Jan 2012
Posts: 36
Default

I just had a similar "Object reference" failure about 185bp into read 1. In our case, cluster density was very low (Nextera XT normalised libraries pooled and diluted as per instructions but according to user, library concentration prior to going into normalisation step sounds low - 1-5ng/ul compared to 20-30ng/ul with libraries I've prepared myself).

Density was only 133K/mm2 which is way lower than our worst run to date (min 700k/mm2). We typically run 900-1300k/mm2.

Thanks for the tip on getting the MiSeq to analyse the data from the failed run, though - user wants to have a look at it although without the index reads I suspect it will be fairly meaningless.
matth431 is offline   Reply With Quote
Old 03-18-2013, 04:32 AM   #19
yaximik
Senior Member
 
Location: Oregon

Join Date: Apr 2011
Posts: 205
Default

Did you try to restart the run using the same cell and reagent set? It worked several times, I just used shorter run times and even got paired read completed. The reads have a lot of Ns and low quality regions, but with aggressive cleaning substantial set of useful data can be recovered. My feeling is sometimes BioAnalyzer traces are misleading in regard to average library size as contamination with shorter fragments can be significant yet not clearly visible. That results in a large portion of clusters being shorter then anticipated and vertical focus unexpectedly fails hitting the floor. That is usually signified by steep declines in the signal intensities on the graphs.
yaximik is offline   Reply With Quote
Old 03-18-2013, 06:40 AM   #20
matth431
Member
 
Location: UK

Join Date: Jan 2012
Posts: 36
Default

Quote:
Originally Posted by yaximik View Post
Did you try to restart the run using the same cell and reagent set? It worked several times, I just used shorter run times and even got paired read completed. The reads have a lot of Ns and low quality regions, but with aggressive cleaning substantial set of useful data can be recovered. My feeling is sometimes BioAnalyzer traces are misleading in regard to average library size as contamination with shorter fragments can be significant yet not clearly visible. That results in a large portion of clusters being shorter then anticipated and vertical focus unexpectedly fails hitting the floor. That is usually signified by steep declines in the signal intensities on the graphs.
I wasn't aware it was possible to restart a failed MiSeq run? Surely it rejects the cartridge and flowcell based on the RFID tags?
matth431 is offline   Reply With Quote
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off




All times are GMT -8. The time now is 07:56 AM.


Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2019, vBulletin Solutions, Inc.
Single Sign On provided by vBSSO