LOCS files not found during MiSeq run?

Question

[lubobal]

Hi everyone!

We experienced a problem that our team had not encountered for almost 10 years of working with the MiSeq platform.

We ran a 24-sample VeriSeq PGS library on MiSeq. On the next day when the data was expected to be generated, we noticed that the run had stopped at cycle 30 due to insufficient disk space. This was unexpected, as this is a small 36-cycle single-read experiment that usually generates no more than 25-30 Gb of data. Before starting the run we had around 109 Gb free space (more than the necessary minimum of 100 Gb to start the run).

We tried to free up some space but the Control Software had crashed so we restarted the computer interrupting the run. Looking at the log files we noticed the following error in the RTA log file:

12/7/2021,15:49:31.019,0,0,0,**Compute current state DID NOT find locs file**: D:\Illumina\MiSeqTemp\211207_M01331_0102_000000000-AJJNJ\Processed\L001\s_1_1101.locs,0,0,0
12/7/2021,15:49:31.029,0,0,0,(1,1101) Status extracted 0 base called 0 q scored 0,0,0,0
12/7/2021,15:49:31.029,0,0,0,**Compute current state DID NOT find locs file**: D:\Illumina\MiSeqTemp\211207_M01331_0102_000000000-AJJNJ\Processed\L001\s_1_1102.locs,0,0,0
12/7/2021,15:49:31.029,0,0,0,(1,1102) Status extracted 0 base called 0 q scored 0,0,0,0

...and so on, for all tiles of the flowcell (s_1 1101-1119 and 2101-2119).

In the folder mentioned there are no .locs files but instead when we looked up there were .zlocks files (e.g. s_1_1101.zlocs and so on).

Do you know what the reason for not finding the .locs files could be?

We also noticed that actually the disk space had run out because the software was generating much larger files than usual in the MiSeqTemp...\Images folder. The size of the directory for each cycle (C1.1-C29.1) was the same - 2.38 Gb with 4 images for each nucleotide (s_1_1101_A.tif; s_1_1101_C.tif; s_1_1101_G.tif; s_1_1101_T.tif) and for each lane (s_1 1101-1119 and 2101-2119) - so in total 152 files per cycles. As a result, the sequencer eventually stopped writing data to the disc as there was no space left and the run crashed.

We noticed there is also a difference in the pathway where the files were written. Instead of using the usual address: D:\Illumina\MiSeqTemp\211207_M01331_0102_000000000- AJJNJ\Images\Focus MiSeq had created the L001 folder here: D:\Illumina\MiSeqTemp\211207_M01331_0102_000000000-AJJNJ\Images and had left the Focus folder empty.

Could there have been some problem with the focus?

The thumbnail images in the MiSeqTemp...\Thumbnail_Images folder were created up to cycle 7 (C1.1-C7.1) and looked similar to previous runs.

In addition, we also noticed that no data had been uploaded in BaseSpace and no metrics and charts of the run were available. The %PF and the %Q30 were 0 and there was no yield.

We are now wondering what to do, as there are embryos being tested in this run awaiting transfer.

1. This run is apparently unsuccessful - is there any point in trying to run it again with the same cartridge and flow cell?
2. Should we just repeat the run with another MiSeq Reagent Kit or wait until the reason for this problem is clear?

Any thoughts and ideas on what could have gone wrong would be greatly appreciated.

Kind regards, Lubomir Balabanski

Answer 1

[GenoMax]

You should have Illumina tech support take a look at this sequencer/run remotely. If there is something wrong they will be able to spot the issue by looking at the actual run metric files. Snippets you posted below tell us that the run experienced a problem (perhaps someone changed some settings?). I am not sure if some data can still be recovered and if it would be enough for your purpose.

Once Illumina support gives the sequencer a clean bill of health you will need to repeat run on new kit. You can't re-use a flowcell.

Since we don't use BaseSpace I don't know if the images are written to it directly. Perhaps your sequencer lost its network connection and that caused it to save the images locally causing the disk to fill up. Just thinking out loud.