fa8sanger
commented
2 years ago Hi Lisa,
I am sorry it didn’t work for you. Don’t rely on traditional duplicate metrics, with enzymatic digestion most fragments share the mapping coordinates. You have to rely on the barcodes to group reads into duplicate families (read bundles).
How many fmols did you take into the amplification? It seems you sequenced your library to 30x, for that we recommended 0.6 fmol (at present we are recommending 0.4 fmol). However, there are probably slight differences between different quantification methods. Those differences however shouldn’t change from 75-80% duplicate rates to 2.9%. If you have high concentrations of DNA it would be advisable to make dilutions before taking fmols.
Your yields are much lower, I am not sure why. Perhaps they are not the true yields and that’s what made things go wrong?
I hope we can find out what went wrong.
Best wishes, Fede
On 4 May 2022, at 15:34, LisaHagenau @.**@.>> wrote:
Hello,
I am having some trouble with our first NanoSeq results, but I am not sure whether this is a wetlab or bioinformatics problem (though I suspect the former). I processed the data as far necessary to run the efficiency_nanoseq.pl script, which returned an extremely low duplicate rate (0.028). Below are the commmands I ran to create these results:
extract tags
python ~/src/nanoseq/bin/extract-tags.py -a data/raw/fastq/merged/S352_S1_R1.merged.fq -b data/raw/fastq/merged/S352_S1_R2.merged.fq -c data/processed/S352_extrR1.fastq -d data/processed/S352_extrR2.fastq -m 3 -s 4 -l 151
map with bwa, add rb and mb tags
bwa mem -t 12 -C /mnt/genomes/hg/hg38/GCA_000001405.15_GRCh38_no_alt_analysis_set.fna data/processed/S352_extrR1.fastq data/processed/S352_extrR2.fastq > data/processed/S352_mapped.sam
Add rc and mc tags, mark optical duplicates, create read bundle tags
bamsormadup inputformat=sam rcsupport=1 threads=12 < data/processed/S352_mapped.sam > data/processed/S352_mapped_od.bam bammarkduplicatesopt optminpixeldif=2500 threads=12 < data/processed/S352_mapped_od.bam > data/processed/S352_mapped_mdo.bam bamaddreadbundles -I data/processed/S352_mapped_mdo.bam -O data/processed/S352_filtered.bam
run randomreadinbundle to produce a deduplicated (neat) bam
randomreadinbundle -I data/processed/S352_filtered.bam -O data/processed/S352_neat.bam
index bam files
samtools index data/processed/S352_neat.bam samtools index data/processed/S352_filtered.bam
run efficiency.pl
efficiency_nanoseq.pl -d data/processed/S352_neat.bam -x data/processed/S352_filtered.bam -r /mnt/genomes/hg/hg38/GCA_000001405.15_GRCh38_no_alt_analysis_set.fna -o S352
cat S352.tsv
Whole-genome metrics:
NUM_UNIQUE_READS 302800159 NUM_SEQUENCED_READS 311577682 DUPLICATE_RATE 0.0281712186304794
RB metrics are reported for chr/contig chr1 only:
TOTAL_RBS 11799643 TOTAL_READS_IN_RBS 24611888 OK_RBS(2+2) 16452 READS_PER_RB 1.042908 F-EFF 0.008890473 EFFICIENCY 0.00111409575730232 GC_BOTH 0.3772532 GC_SINGLE 0.3769166
What doesn't quite make sense to me is that in the duplex (filtered) bam file, 244 Mio reads are marked as duplicates (out of 311 Mio, using samtools flagstat), while the deduplicated (neat) bam file contains 302 Mio reads and no marked duplicates. Wouldn't that mean that most duplicate reads are in different read bundles?
If the bioinformatic analysis is correct, then I suspect that something went wrong with the library quantification which resulted in a massive underestimation of amplifiable fragments. We used a different kit for the qPCR than described in the methods (NEBNext Library Quant), but checked that the primers that come with the kit are the same as in the KAPA kit and added the NanoqPCR primers to a final concentration of approx 330 nM. We did observe ~10x lower library yields than described in the paper even with high DNA input from freshly prepared HMW DNA from HaCaT cells (see plot). For the sequenced sample (fibroblasts) we tried 3 dilutions (1:50, 1:500 and 1:5000), but only the 1:5000 sample showed a normal amplification curve which we used for calculating the fmol input.
[lib-yield] [user-images.githubusercontent.com]https://urldefense.proofpoint.com/v2/url?u=https-3A__user-2Dimages.githubusercontent.com_13033231_166703955-2D7ff7808a-2D708d-2D49da-2Db5d3-2D2846d8860e07.png&d=DwMCaQ&c=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=v9-R7fUmjpv-9Zaqyk1nlnlOC3qPkTEJz5tyYxg2uec&m=id_OBj0mifdlKNHPlzSmM3dJGs7n4bajPQJhmPoVFNV9JwzlQEp8rJJ2ks-GKWvo&s=ip2fRzqUFxe1cnDcmF551thamLwnP6GPu-t61L9lw0A&e=
Any help would be appreciated.
Thanks, Lisa
— Reply to this email directly, view it on GitHub [github.com]https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_cancerit_NanoSeq_issues_37&d=DwMCaQ&c=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=v9-R7fUmjpv-9Zaqyk1nlnlOC3qPkTEJz5tyYxg2uec&m=id_OBj0mifdlKNHPlzSmM3dJGs7n4bajPQJhmPoVFNV9JwzlQEp8rJJ2ks-GKWvo&s=mQZt_QahGd44NVKg72Ux9WBeGg-6Qs9JMSd6dPcK85g&e=, or unsubscribe [github.com]https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ADNUT3JRCH4CMA5PAEMT35TVIKDIJANCNFSM5VCFVJAQ&d=DwMCaQ&c=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=v9-R7fUmjpv-9Zaqyk1nlnlOC3qPkTEJz5tyYxg2uec&m=id_OBj0mifdlKNHPlzSmM3dJGs7n4bajPQJhmPoVFNV9JwzlQEp8rJJ2ks-GKWvo&s=raI8RFAbP4ZsDFjO5K4hX-JVjjVNil5Xc9xFyDdQWrg&e=. You are receiving this because you are subscribed to this thread.Message ID: @.***>
-- The Wellcome Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.
LisaHagenau
Hello,
I am having some trouble with our first NanoSeq results, but I am not sure whether this is a wetlab or bioinformatics problem (though I suspect the former). I processed the data as far necessary to run the efficiency_nanoseq.pl script, which returned an extremely low duplicate rate (0.028). Below are the commmands I ran to create these results:
What doesn't quite make sense to me is that in the duplex (filtered) bam file, 244 Mio reads are marked as duplicates (out of 311 Mio, using samtools flagstat), while the deduplicated (neat) bam file contains 302 Mio reads and no marked duplicates. Wouldn't that mean that most duplicate reads are in different read bundles?
If the bioinformatic analysis is correct, then I suspect that something went wrong with the library quantification which resulted in a massive underestimation of amplifiable fragments. We used a different kit for the qPCR than described in the methods (NEBNext Library Quant), but checked that the primers that come with the kit are the same as in the KAPA kit and added the NanoqPCR primers to a final concentration of approx 330 nM. We did observe ~10x lower library yields than described in the paper even with high DNA input from freshly prepared HMW DNA from HaCaT cells (see plot). For the sequenced sample (fibroblasts) we tried 3 dilutions (1:50, 1:500 and 1:5000), but only the 1:5000 sample showed a normal amplification curve which we used for calculating the fmol input.
Any help would be appreciated.
Thanks, Lisa