MiSeq stopped run

[yaximik]

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]

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.

[pmiguel]

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

[MoritzF]

I encountered the same problem today...any idea how that error came about?

[yaximik]

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.

[GenoMax]

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.

[MoritzF]

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!

[TonyBrooks]

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).

[MoritzF]

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?

[GenoMax]

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.

[TonyBrooks]

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)

[MoritzF]

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.

[mcnelson.phd]

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.

[yaximik]

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.

[creeves]

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.