Has anyone ever encountered an issue where a sampl...
# mag
d
Has anyone ever encountered an issue where a sample produces no reads that pass the contig cutoff, effectively passing a sample with 0 reads to bowtie2 and the entire pipeline crashing? I was hoping to use nf-core/mag 5.2.0 to quickly get a sense of QA/QC on my data (which was failing for the same reason using SqueezeMeta assembly pipeline). It sounds like I don’t have any choice but to manually determine which samples are going to fail and omitting them from the sample sheet, but I was curious if anyone on the channel had insights or how to indicate the pipeline to perhaps omit samples entirely from bowtie2 that don’t meet a threshold. For context, here is my input code, which includes a custom config file to increase resource allocation to different steps
Copy code
nextflow run nf-core/mag -r 5.2.0 -profile apptainer -c mag-wall-time-increase.yaml \
--input 'Long_lake_metagenome_sample_list_1000bp_nf_core.csv' \
--outdir Long_lake_NRCan_MAGs_nf_core \
--min_contig_size 1000 \
--skip_spades \
--refine_bins_dastool \
--postbinning_input refined_bins_only \
--run_checkm2 \
--checkm2_db '/files/home/dgregoire/databases/CheckM2_database/uniref100.KO.1.dmnd' \
--skip_gtdbtk \
--skip_prokka
d
If all the contigs on one of your samples are less than 1000pb, it's a sign of a very poor assembly. And yeah, with 12Mbp I would expect a very low coverage. Is it all the data you have?
In fact, our test data is a bit over 12Mbp and it's a mock community, and barely works (we have been unable to use it with modern binners).
d
Upon inspection of the FASTQC, many, many samples are < 20 Mbp which may be explaining the poor results. That being said, after letting the pipeline hang up, it looks like MEGAHIT still produced assemblies for most files despite that error being thrown. Using the -resume flag doesn’t help move past the error, so I wonder if the move here is looking at what assemblies were output by MEGAHIT, flagging those as samples that can assemble, editing the sample sheet, and re-running everything
d
In general, I would exclude samples with very low coverage from the start, as the results are unlikely to be reliable. If you need to process them anyway, you could try assembling with SPAdes. In my experience it often performs better, though it requires more computational resources. That extra sensitivity might help push some borderline samples above the threshold. Additionally, you can set
errorStrategy = 'ignore'
for the specific process that’s failing. This will prevent the pipeline from stopping and will simply skip any samples that fail, excluding them from downstream steps.