Hi everyone. I have a question regarding the BLAZE barcode detection step as this step is taking a very long time for me and are causing my jobs to fail due to exceeding the time limit in SLURM. According to the pipeline summary, the BLAZE step is meant to be just for extracting the list of 'present' barcode in the sample, with the barcode extraction and barcode correction done at subsequent steps on the nextflow pipeline. However, the current BLAZE setup involves running the demultiplexing (assign reads to cell) step, which is quite time consuming (my job failed at this part after running for 6.5hrs for this part alone) and also wasteful as I don't believe this demultiplexed FASTQ file is being used in any of the downstream steps? Would it be possible to disable the BLAZE demultiplexing step so that we can make this step runs faster (it will save at least 8+ hours of runtime for my current sample)? I am also happy to submit a pull request to disable BLAZE demultiplexing as well if this step can actually be skipped/disabled.

Hi Andrian, I dont believe theres a way to disable the demux step for BLAZE currently. While we dont use the demultiplexed FASTQ for downstream processing, we do use the final barcode whitelist generated by BLAZE as input for barcode correction later in the pipeline which would need the final barcodes generated by BLAZE. For clarity, what kit are you using and how many threads are you using for BLAZE? You can increase the amount of threads for BLAZE by using something akin to the below in a custom config (you can adjust the number to what your architecture supports)

process
{
    withName: '.*:BLAZE'
    {
        cpus = 30
    }
}

And then add a flag like

-c custom.conf

to the nextflow run command Ill also note do have a PR that includes an alternative barcode calling tool (flexiplex) that would maybe help but its still in review

Hi Austyn, I believe this is actually an option in the latest version of Blaze? https://github.com/shimlab/BLAZE/blob/af8d2cc9f6374caf4d1006d5f8a0e99097211646/blaze/parser.py#L120 I have increased the number of cpu for Blaze step to 30 following the recommendation, but unfortunately that did not help.

@Austyn Trull: last I checked we do have the latest version of Blaze correct? If so, Adrian, you actually can pass custom tool specific parameter via custom config file as well. Do you know how to do this? That being said, we have not tested this specific parameter within blaze, so I would recommend to test the pipeline first with a small test file to ensure everything works fine (we might be able to test it with the test profiles already present to ensure the custom config works). On a side note - just to confirm, what is the raw number of reads for your sample? For something like 130M we have typically seen BLAZE take 2-3 hours with the following config (so I just want to make sure that your input reads are indeed around this size):

process
{
    withName: '.*:.*BLAZE.*'
    {
        cpus = 45
        memory = '55.GB'
    }
}

Hi Lara, would you be able to give me some guidance on how to pass custom tool specific parameter via the custom config file? I've used the custom config file in the documentation, but those only change the CPU and memory. With regards to the raw number of reads, BLAZE reported it to be ~179M reads. It took 12 hours with 30 CPU core to get up to the demultiplexing step, where it managed to process 125M reads in 6h44m. I can certainly try to up the CPU core to see if that would help, but it would be ideal to just skip the demultiplexing step if there is no use for the demultiplexed FASTQ file?

It would be similar to the configuration section that is already present in the pipeline - https://github.com/nf-core/scnanoseq/blob/4a6aade735c742d5c3d9ce73a5dfbc1902fbd0c1/conf/modules.config#L338

--kit-version

for instance is a parameter in BLAZE. We would need to add any additional custom parameters (along with existing ones) to a custom.config. The only thing is that we recommend to test this first on the test data to ensure that the expected outputs are still produced. Let me and @Austyn Trull check this parameter you mentioned in the test data and we can come back to this discussion - hopefully this will make your implementation easier.

Thanks Lara. That would be helpful if you and Austyn can help with the testing as all my samples are promethion runs, so it will take me some time to do the testing with my samples. 😅 With regards to the custom configuration, would I need to do something like this in my custom.config file then?

process {
    withName: '.*:BLAZE' {
        ext.args = {
            [
                "--kit-version ${params.barcode_format.minus('10X_')}",
                "--no-demultiplexing"
            ].join(' ').trim()
        }
    }
}

Yes this is what I am thinking but yeah let's test on some small test data first and then you can add that along with the resources as well.

Correct, though you'll want to also increase the CPUs and memory similar to what Lara mentioned earlier, so the full section would look like this:

process {
    withName: '.*:BLAZE' {
        cpus = 45
        memory = '55.GB'
        ext.args = {
            [
                "--kit-version ${params.barcode_format.minus('10X_')}",
                "--no-demultiplexing"
            ].join(' ').trim()
        }
    }
}

But I agree with Lara, we'll test it with a smaller dataset and report back

@Dr A. Yang - my very quick test (using the small test profile) was successful with the changes above. I fully confirmed that demultiplexing was disabled by checking the BLAZE log, as well as the command executed by Nextflow (as as you said we now do not have the FASTQ file). So the custom change above should work, however as we said, you will need to still pass the appropriate memory and cpus - but if you are correct then hopefully this should be faster. If you do try this and end up seeing a big difference in time, can you let us know? If that parameter is a significant benefit, we could end-up making it a default in future versions (or at least expose it at the pipeline level so that users do no need to write a custom config - but for Nextflow's modularity should do the trick for custom params 🙂 )

I can confirm on my end as well, QC's seem to be the same both with and without the flag for our test dataset. Absolutely let us know how your run goes with the flag enabled

Thanks @Lara Ianov and @Austyn Trull for testing out the BLAZE configuration without demultiplexing! I'm re-running the previously failed BLAZE job now (with the same 30 cpu config as before for consistency) and I will report the run time of that step once it finishes.

Awesome thank your for your feedback! I've added a github ticket here: https://github.com/nf-core/scnanoseq/issues/87

Awesome - thanks for the feedback. This should be an easy change for a next release. In the meantime I will add the custom config file we shared above in the issue Austyn posted so that others can easily implement this change in the meantime. If you catch anything else that can be optimized further, do not hesitate to let us know. Thanks!