Adjusting OLB Firecrest cluster identification

[agagne]

We've noticed with the switch to the v4 chemistry and updated scs software that a number of lanes have started failing completely. These tended to have indexes or large biases at the beginning of the reads.

We resolved this by running firecrest with adjusted cluster identification cycles. Instead of 4 we've used 8, 10 or even 20 cycles for cluster identification using this parameter: --image_flags="--nd=10"

This has greatly increased our ability to generate data. We're able to identify more clusters even in non biased samples. This has helped with high density runs as well.

I was wondering if others have done this as well and if there are any potential drawbacks I should be on the look out for.

[hoisinjl]

I have not heard of the "image_flags" parameter - could you direct me to some documentation about it? The only thing we have found helpful is by re-running Firecrest and cutting out cycles where only 1 base was present - but this method only works if the data from that cycle is not necessary.

[agagne]

There isnt any documentation for this that I know of. I learned of it from troubleshooting and discussing with my FAS and techsupport.

The way to do it in OLB is still with the --image_flags="-nd=n" option where n is the number of cycles to use. Keep in mind that the software now looks for the best cycle in the range given (aka the Golden Cycle) and uses that to determine cluster positions, while in the previous vesions it was averaging the values from the first two cycles, or whatever was specified by this option

.

You can also adjust this in RTA

You can change the cycles used for cluster identification in RTA by
editing the RTA.exe.config

<add key="FirstTemplateCycle" value="1" />
<add key="TemplateCycleCount" value="4" />

This will affect the performance of the instrument so we do not use this, we just recall off of the images.

[kmcarr]

I have done this a couple of time as well for the same kinds of situations you describe, an indexed run with biased base composition and a reduced representation library where the input DNA was restriction digest fragments.

The only drawback is that firecrest requires more time and RAM to generate the template. I would be very careful about making changes like this to RTA. With the increased cluster densities possible with the v4 kits and RTA 1.6 the instrument workstations are pushed to the max (see this thread). If I have to do it I would do it on my cluster with OLB.

[cbrennan]

That is a very cool undocumented option.

We recently had an instrument problem (autofocus bumping objective in early cycles) and I had to trash first 16 cycles because the person I spoke to at tech support didn't know that option. It's exactly what I was looking for, thanks!

[NGSfan]

There isnt any documentation for this that I know of. I learned of it from troubleshooting and discussing with my FAS and techsupport.

The way to do it in OLB is still with the --image_flags="-nd=n" option where n is the number of cycles to use. Keep in mind that the software now looks for the best cycle in the range given (aka the Golden Cycle) and uses that to determine cluster positions, while in the previous vesions it was averaging the values from the first two cycles, or whatever was specified by this option

.

You can also adjust this in RTA

You can change the cycles used for cluster identification in RTA by
editing the RTA.exe.config

<add key="FirstTemplateCycle" value="1" />
<add key="TemplateCycleCount" value="4" />

This will affect the performance of the instrument so we do not use this, we just recall off of the images.

I also got this undocumented feature from Tech Support. Since we have barcodes in the first four bases, we would like to shift the cycles used for cluster id to be:

<add key="FirstTemplateCycle" value="5" />
<add key="TemplateCycleCount" value="8" />

But I am worried we will stretch the limits of the machine. However, since it is still just using 4 cycles, I don't see it being as bad as say, going from 1 to 7, since that would require analyzing 7 cycles of data.

Anybody ever dared try the RTA settings???

[kmcarr]

There isnt any documentation for this that I know of. I learned of it from troubleshooting and discussing with my FAS and techsupport.

The way to do it in OLB is still with the --image_flags="-nd=n" option where n is the number of cycles to use. Keep in mind that the software now looks for the best cycle in the range given (aka the Golden Cycle) and uses that to determine cluster positions, while in the previous vesions it was averaging the values from the first two cycles, or whatever was specified by this option

.

You can also adjust this in RTA


You can change the cycles used for cluster identification in RTA by
editing the RTA.exe.config

<add key="FirstTemplateCycle" value="1" />
<add key="TemplateCycleCount" value="4" />



This will affect the performance of the instrument so we do not use this, we just recall off of the images.

I also got this undocumented feature from Tech Support. Since we have barcodes in the first four bases, we would like to shift the cycles used for cluster id to be:

<add key="FirstTemplateCycle" value="5" />
<add key="TemplateCycleCount" value="8" />

But I am worried we will stretch the limits of the machine. However, since it is still just using 4 cycles, I don't see it being as bad as say, going from 1 to 7, since that would require analyzing 7 cycles of data.

Anybody ever dared try the RTA settings???

I've never changed the RTA settings. I have used the --image_flags="--nd=10" parameter for OLB. I believe (though I have not tested it) that there is another parameter you can pass in the --image_flags which will set which cycle to begin cluster identification at; it is --first-detection-cycle. If you wanted to skip the barcodes in the cluster ID as in NGSfan's example but using OLB you would include the following in your arguments to goat_pipeline.py

--image_flags="--nd=4 --first-detection-cycle=5"

The image_flags are passed to the program analyseImages. You can see all of the parameters that analyseImages accepts by entering the command:

% /PATH-TO-OLB/bin/analyseImages --help

I believe some of the arguments have direct matches in the goat_pipeline.py argument list while others are simple wrapped up in the --image_flags option.

[NGSfan]

Wow! Thanks a lot for sharing those details. I will have a finished paired end run in about 10 days and will try the OLB settings you suggested. I will report back on my results.

[NGSfan]

Does anyone know if in the SCS software, if "Copy images to network folder" and "Delete images locally" are both clicked, then all images from all lanes should be stored to the network folder, even after SCS/RTA analysis right? These are not mutually exclusive options, I hope.

I assume first the images are stored locally, then moved to the network drive. Does the moving of local images to the network folder happen after a complete run? or during the run?

And those operators that don't want the images stored after analysis, would then unclick "Copy images to network folder"? right?

Also, I know where the network path is, but what is the local directory for the images (on the machine running SCS)?


Sorry for the newb questions - but I have looked at the manuals and it's not always clear what the process is. I don't have any hands on experience with the process and am actually monitoring my first run with the operator because we want the images stored for OLB and testing of next_phred.

thanks!

[NGSfan]

Wow! Thanks a lot for sharing those details. I will have a finished paired end run in about 10 days and will try the OLB settings you suggested. I will report back on my results.

I ran the OLB with the new parameters vs the "default" parameters and saw an increase of about 8% only in the number of reads (4 bp barcodes - 4 samples/lane). I had to use a unbarcoded control lane. If no control lane is specified, then things go out of whack.

I will try again with some extra image flag parameters the tech support gave me . Not sure what the flag option is for !

--image_flags=" --minobjpix=3 --flag=3"

I may also try assigning a barcoded lane as a control lane.

Anyone else report experiences?