Differences in depths between artic versions

[DuyenLe2000]

Hello!

I have been using artic v1.2.4 (experimental medaka pipeline) for a long time and wanted to switch to artic v1.6.0. I wanted to compare the consensus sequences generated by the two different versions with artic minion, using the same sample and primer scheme, and noticed that I had more Ns in the consensus sequence generated by artic v1.6.0 compared to the one generated by v1.2.4 in one sample. Looking at the coverage_mask.txt file, two amplicons were masked by v1.6.0 which were not masked by v1.2.4.

In the coverage_mask.txt.2.depths file of v1.6.0 the depths for one of these masked amplicons are the following:

Position	Depth
9540	8
9541	9
9542	11
9543	11
9544	11
9545	11
9546	11

However, in coverage_mask.txt.2.depths of v1.2.4 it looks like this at these positions:

Position	Depth
9540	396
9541	396
9542	396
9543	396
9544	396
9545	396
9546	396

Interestingly, according to the amplicon_depths.tsv file of v1.6.0 the mean_depth for this amplicon is 360. I wanted to ask, why the depths in the coverage_mask.txt.2.depths file are lower in v1.6.0 than in v1.2.4 in the same sample and why they differ from amplicon_depths.tsv. Are there any parameters that I could change to achieve the same depths as in v1.2.4?

Thank you in advance!

[BioWilko]

Can you share your reads fastq file here? And indicate what command you used to run the pipeline for 1.2.4 and 1.6.0 please? :)

I suspect the difference might be related to mapping quality but I can't tell for sure without seeing the data

[DuyenLe2000]

RSV-2023.scheme.bed.txt

RSV-2023.reference.fasta.txt

I have attached the primer scheme and the reference but GitHub won't let me upload the fastq-file :( Is there any other way to provide it to you?

The commands I used are the following:

artic1.2.4:
artic minion --no-longshot --medaka --medaka-model r1041_e82_400bps_sup_variant_v4.3.0 --normalise 100000 --scheme-directory {path_to_primer_scheme} --read-file demultiplexed_barcode08.fastq {scheme_version}/{version} barcode08

artic 1.6.0:
artic minion --model r1041_e82_400bps_sup_v430 --normalise 100000 --bed {path_to_primer_scheme}/{scheme_version}/{version}/{scheme_version}.scheme.bed --ref {path_to_primer_scheme}/{scheme_version}/{version}/{scheme_version}.reference.fasta --read-file demultiplexed_barcode08.fastq barcode08

[BioWilko]

In the data you sent I have much higher depth at those positions than you do with 1.6.0:

cluster_B_2_consensus   2       9540    5811
cluster_B_2_consensus   2       9541    5811
cluster_B_2_consensus   2       9542    5819
cluster_B_2_consensus   2       9543    5819
cluster_B_2_consensus   2       9544    5820
cluster_B_2_consensus   2       9545    5820
cluster_B_2_consensus   2       9546    5820
cluster_B_2_consensus   2       9547    5829
cluster_B_2_consensus   2       9548    5829
cluster_B_2_consensus   2       9549    5829

And the only N runs I have are at the start and end of the genome:

cluster_B_2_consensus   1       193
cluster_B_2_consensus   15007   15276

Is this definitely the same data?

[DuyenLe2000]

That is odd... I will upload the file again as demultiplexed_barcode08_new.fastq in case I uploaded the wrong file. According to $(cat *.fastq|wc -l)/4|bc it should contain 455986 reads.

[BioWilko]

I just got this from the first fastq:

grep -c "^@" field_depth_different.fastq 
1589368

[BioWilko]

Okay thanks for the second set of data, I was able to reproduce the bug, I haven't figured out what the issue is exactly yet but if you rerun with a lower normalisation value it won't occur e.g. --normalise 1000

Generally for amplicon sequencing there is no need to pass so many reads through to variant calling, it just causes the pipeline to run slower without any benefit to consensus quality. If you want a BAM containing all of the reads you can take {prefix}.sorted.bam.

[BioWilko]

Okay, I've temporarily fixed the issue on branch 1.6.1-dev and added catch that blocks --normalise values > 10000, if normalisation isn't desired you can just run --normalise 0 to skip it entirely.

Github actions seem to be having problems at the moment but once that's sorted I'll merge the change

[BioWilko]

Okay that should be sorted, let me know if you run into any other problems.

[DuyenLe2000]

Thank you so much!