Dear Brian,
I am using bbmap for mapping and callvariants.sh for variant calling on PE Illumina reads.
I am comparing two mice strains. I am therefore downsampling my .sam files to have the same number of mapped reads going into the alignment.
When I input the original file containing ~680k mapped PE reads I get 2283 variants. When I run the down sampled file containing ~200k mapped PE reads I get 3375 variants.
I would expect to get a lower number of variants when I put in less reads. Could you explain this to me? I am clearly missing something that might be important for my analysis
(I am using the exact same criteria for variant calling and filtering for the two samples)
Seqanswers Leaderboard Ad
Collapse
Announcement
Collapse
No announcement yet.
X
-
Hi Brian,
I'm using trimrname=t from reformat.sh on a sam file. It looks like it trims the ref names correctly on the alignment lines, but not in header lines (the ones that start with @).
Leave a comment:
-
Hi Brian,
Does bbmap callvariants.sh ignore duplicates marked by picard MarkDuplicates by default (or is there an option to ignore duplicates) or do duplicates have to be deleted?
Best,
Gopo
Leave a comment:
-
Originally posted by GenoMax View PostBBMap is one of the aligners that uses the full header present in your fasta file when creating the index and passes it along to alignment file. If there are spaces in the header name they are written to alignment. Some downstream programs have a problem with this.
You can use the option "trd=t" to truncate the fasta header names after the first space in the name. There is an option for reformat.sh that can do this after the fact for aligned data. I can look this up later if you don't find it.
Leave a comment:
-
Dear BBMap programmers/users,
First of all, I want to thank you for your work. This set of tools is very pleasant to use and very well documented. Moreover, the pipeline are very useful and very well explained. This is very easy easy to adapt them.
Nevertheless, as this is the first time I am using BBMap, on a really specific problem, I have few questions (you can find an explanation of my problem here: http://seqanswers.com/forums/showthread.php?t=81997).
I used the variantPipeline.sh pipeline adapted for multiple paired non-covering amplicon data files:
- Does BBMap support IUPAC nucleotide code for building the reference genome index?
- As I will map distant (or polymorph) reads on my reference, I used "k=8" for building the index. is it possible to lower this value and is it useful?
- filterbytile.sh, for trimming the adaptater does not take input file describing my adapters (Nextera...)? Is it normal?
- bbduk.sh, removing the sequencing artifact, take default files (ref=${BBMAPRESSOURCES}/sequencing_artifacts.fa.gz,${BBMAPRESSOURCES}/phix174_ill.ref.fa.gz). Is it commonly found artefacts? Could I use these files or must I create mine? I didn't change k=27, must I change the value due to the poor quality of my reads?
- bbmap.sh, for mapping step, I used "vslow k=8 maxindel=200 minratio=0.1" parameters, as described in the online documentation (https://jgi.doe.gov/data-and-tools/b...e/bbmap-guide/). Is it a good idea with distant reference genome and poor quality data?
- callvariants.sh, for the variants call step, I let the ploidy=1. I'm working on various plants and I don't really know the ploidy. Must I let this parameter to 1? I'm only looking for SNPs, Is it possible to specify it to the scripts?
- Finally, is it really useful to add optional error-correction and recalibration step of my reads, before performing the mapping? Will I lose some important data?
I know some questions are trivial, but I'm still reading the manual and the different scripts documentations...
Thanks in advance for your help.
Denis
Leave a comment:
-
Possible bug with bitflags in SAM alignments with ambig=all option
(Apologies if this shows up more than once, my posts keep disappearing...)
Hello Brian et al.,
The bitflags don't seem to be assigned correctly when the ambig=all option is used. The renaming of read pairs with keepnames=f also appears to be affected.
I am mapping Illumina paired reads with ambig=all to report all ambiguous alignments. From what I understand, the secondary alignments are indicated with the bitflag 0x100. For paired input, the alignments appear to be reported in the following order for each read pair:- read F primary alignment
- read F secondary alignment(s)
- read R primary alignment
- read R secondary alignment(s)
I observed that with keepnames=f, there are two bugs (example below):- Reverse read is renamed to match the forward read only for the primary alignment. The original name (e.g. with the tag 2:N in the example below) is retained in the secondary alignment(s)
- Secondary alignments of the reverse read are erroneously given bitflag 0x40 (first segment in the template, i.e. forward read) instead of 0x80 (last segment of the template, i.e. reverse read)
With keepnames=t, the original names are retained for both forward and reverse reads in both primary and secondary alignments, but the second bug above (misassignment of bitflags 0x40 and 0x80) is still there.
I first noticed the problem with bbmap v37.76 but it still occurs in v37.99.
Maybe I'm overlooking something, but this seems to be a bug. Has anyone else encountered this before? My apologies if this has been posted to this thread before. I didn't find anything relevant with search keywords 'keepnames' and 'ambiguous'.
Thank you!
** Examples **
Alignment columns QNAME and FLAG from SAM file with keepnames=f for a read pair showing the error
Code:HWI-ST863:279:H03F7ADXX:1:1107:5049:39482 1:N:0:AAGGGAAT 99 HWI-ST863:279:H03F7ADXX:1:1107:5049:39482 1:N:0:AAGGGAAT 353 HWI-ST863:279:H03F7ADXX:1:1107:5049:39482 1:N:0:AAGGGAAT 353 HWI-ST863:279:H03F7ADXX:1:1107:5049:39482 1:N:0:AAGGGAAT 353 HWI-ST863:279:H03F7ADXX:1:1107:5049:39482 1:N:0:AAGGGAAT 353 HWI-ST863:279:H03F7ADXX:1:1107:5049:39482 1:N:0:AAGGGAAT 147 HWI-ST863:279:H03F7ADXX:1:1107:5049:39482 2:N:0:AAGGGAAT 337 HWI-ST863:279:H03F7ADXX:1:1107:5049:39482 2:N:0:AAGGGAAT 337 HWI-ST863:279:H03F7ADXX:1:1107:5049:39482 2:N:0:AAGGGAAT 337 HWI-ST863:279:H03F7ADXX:1:1107:5049:39482 2:N:0:AAGGGAAT 337
Code:HWI-ST863:279:H03F7ADXX:1:1107:5049:39482 1:N:0:AAGGGAAT 99 HWI-ST863:279:H03F7ADXX:1:1107:5049:39482 1:N:0:AAGGGAAT 353 HWI-ST863:279:H03F7ADXX:1:1107:5049:39482 1:N:0:AAGGGAAT 353 HWI-ST863:279:H03F7ADXX:1:1107:5049:39482 1:N:0:AAGGGAAT 353 HWI-ST863:279:H03F7ADXX:1:1107:5049:39482 1:N:0:AAGGGAAT 353 HWI-ST863:279:H03F7ADXX:1:1107:5049:39482 2:N:0:AAGGGAAT 147 HWI-ST863:279:H03F7ADXX:1:1107:5049:39482 2:N:0:AAGGGAAT 337 HWI-ST863:279:H03F7ADXX:1:1107:5049:39482 2:N:0:AAGGGAAT 337 HWI-ST863:279:H03F7ADXX:1:1107:5049:39482 2:N:0:AAGGGAAT 337 HWI-ST863:279:H03F7ADXX:1:1107:5049:39482 2:N:0:AAGGGAAT 337
Leave a comment:
-
Originally posted by susanklein View Postah I see, thanks. So they are good alignments, but to multiple sites. I'll have to rethink my strategy because I really should be keeping all alignments.
Thanks,
S.
Leave a comment:
-
Originally posted by Brian Bushnell View PostMAPQ is a measure of the probability (estimate) that the mapping location is correct. This can factor in various things, including the number of mismatches... but, for example, with these very short sequences, even though they are perfect matches, the specificity is low. MAPQ=3 specifically means that there is at most a 50% chance that the mapping is correct, and thus, there's at least one other perfect alignment for each of these.
Thanks,
S.
Leave a comment:
-
We had a discussion about what the x:y coordinates mean on Biostars.
Short take home from poster of that thread was:
Contacted illumina support and they said the information I needed, such as dimension of the tile viewing area or zoom of the microscope, was "considered proprietary," which is frustrating.
Leave a comment:
-
The coordinate system varies across platforms; the physical distance of 1 pixel is much larger on HiSeq 2500 than HiSeq 3000/4000m for example.
NovaSeq has unique problems, though. The distance of 12000 is not really to catch optical duplicates, but rather, clonal colonies that presumably form when a molecule breaks off from a colony and forms a new colony nearby (typically downstream). These have a high degree of positional correlation but are not actually adjacent; they can be fairly distant. They are not even necessarily on the same tile, so Clumpify won't catch all of them when it is restricted to looking for duplicates only within a tile.
And yes, the 12000 comes from empirical testing. That catches most of the duplicates formed by this mechanism. I think I posted the approximate amount somewhere... maybe it was around 85%? You can't get all of them unless you completely disregard position and remove all duplicates.
Leave a comment:
-
optical duplicates
Hi Brian! Hope I'm posting this in the right place.
I've been using clumpify for a while. Great tool! I was totally blown away by how fast it is...
Simple question. I noticed that you make the following recommendations for detection of optical duplicates:
dupedist=40 (dist) Max distance to consider for optical duplicates.
Higher removes more duplicates but is more likely to
remove PCR rather than optical duplicates.
This is platform-specific; recommendations:
NextSeq 40 (and spany=t)
HiSeq 1T 40
HiSeq 2500 40
HiSeq 3k/4k 2500
Novaseq 12000
I was surprised to see that NovaSeq has such a big distance. Is this something you have measured? I have only been able to find the Picard recommendation which groups all the patterned flowcells with the same distance (2500).
Thanks!
Leave a comment:
-
Originally posted by darthsequencer View PostHi Brian - Is there a bbtool that will keep only mapped reads and if the mate doesn't map output the unmapped also from sam/bam files?
Thanks
Code:reformat.sh in=data.sam out=mapped.sam mappedonly reformat.sh in=data.sam out=unmapped_mates_of_mapped_reads.sam requiredbits=4 filterbits=8
Code:reformat.sh in=data.sam out=mapped.sam mappedonly filterbyname.sh in=data.sam names=mapped.sam include=t out=mapped_or_mate_mapped.sam
Leave a comment:
-
Originally posted by susanklein View PostOk I thought this was solved, but see below, still getting sam file alignments with MAPQ=3, even though they actually look like good alignments. Is '3' given because you can't calculate a perfect hit MAPQ? i.e. MAPQ=-10*log10(zero)
@PG ID:BBMap PN:BBMap VN:37.93 CL:java -Djava.library.path=/bin/bbmap/jni/ -ea -Xmx43986m align2.BBMap build=1 overwrite=true fastareadlen=500 ref=genome/genome.fasta ambig=best vslow perfectmode maxsites=10000 nzo=t mappedonly=t outu=test/unmapped/testKT45.unmapped.fasta scafstats=test/mapped/testKT45.map in=testKT45.fastq out=test/mapped/testKT45.sam -idfilter=0.9
700666F:325:CCC50ANXX:6:2211:7729:2233 1:N:0:GTCGAG 0 ctg3849_RHIMB__RM170330.3849 Backbone_3849|arrow|pilon 111580 3 31= * 0 0 GCATTGGTGGTTCAGTGGTAGAATTCTCGCC CCCCCGGGGGGGGGGGGGGGGGGGGGGGGGG XT:A:R NM:i:0 AM:i:3
700666F:325:CCC50ANXX:6:2211:7914:2047 1:N:0:GTAGAG 16 ctg18961_RHIMB__RM170330.18961 Backbone_18961|arrow|pilon 20097 3 31= * 0 0 TCACAATGATAGGAAGAGCCGACATCGAAGG GGGGGGGGGGGGGGGGGGGGGGGGGGCCCCC XT:A:R NM:i:0 AM:i:3
700666F:325:CCC50ANXX:6:2211:7905:2066 1:N:0:GTCGAG 16 ctg18961_RHIMB__RM170330.18961 Backbone_18961|arrow|pilon 34735 3 31= * 0 0 GGTAGGCGCAGAAAGTACCATCGAAAGTTGA GGGGGFGGGGGGGGGGGGGGGGGGGGCCCCC XT:A:R NM:i:0 AM:i:3
700666F:325:CCC50ANXX:6:2211:7970:2099 1:N:0:GTCGAG 0 ctg16585_RHIMB__RM170330.16585 Backbone_16585|arrow|pilon 33974 3 23= * 0 0 GGGAATACCAGGTGCTGTAGGCT CCCCCGEGGGGGGGGGGGGGGGG XT:A:R NM:i:0 AM:i:3
700666F:325:CCC50ANXX:6:2211:7937:2145 1:N:0:GTCGAG 16 ctg13544_RHIMB__RM170330.13544 Backbone_13544|arrow|pilon 7627 3 39= * 0 0 GGTGAGAGCGCCGAATCCTAACCACTAGACCACCAGGGA GGGGGGGGGGGGGGGGGGGGGGGGGFGGGGGGGGCCCCC XT:A:R NM:i:0 AM:i:3
Leave a comment:
-
Hi Brian - Is there a bbtool that will keep only mapped reads and if the mate doesn't map output the unmapped also from sam/bam files?
Thanks
Leave a comment:
-
Ok I thought this was solved, but see below, still getting sam file alignments with MAPQ=3, even though they actually look like good alignments. Is '3' given because you can't calculate a perfect hit MAPQ? i.e. MAPQ=-10*log10(zero)
@PG ID:BBMap PN:BBMap VN:37.93 CL:java -Djava.library.path=/bin/bbmap/jni/ -ea -Xmx43986m align2.BBMap build=1 overwrite=true fastareadlen=500 ref=genome/genome.fasta ambig=best vslow perfectmode maxsites=10000 nzo=t mappedonly=t outu=test/unmapped/testKT45.unmapped.fasta scafstats=test/mapped/testKT45.map in=testKT45.fastq out=test/mapped/testKT45.sam -idfilter=0.9
700666F:325:CCC50ANXX:6:2211:7729:2233 1:N:0:GTCGAG 0 ctg3849_RHIMB__RM170330.3849 Backbone_3849|arrow|pilon 111580 3 31= * 0 0 GCATTGGTGGTTCAGTGGTAGAATTCTCGCC CCCCCGGGGGGGGGGGGGGGGGGGGGGGGGG XT:A:R NM:i:0 AM:i:3
700666F:325:CCC50ANXX:6:2211:7914:2047 1:N:0:GTAGAG 16 ctg18961_RHIMB__RM170330.18961 Backbone_18961|arrow|pilon 20097 3 31= * 0 0 TCACAATGATAGGAAGAGCCGACATCGAAGG GGGGGGGGGGGGGGGGGGGGGGGGGGCCCCC XT:A:R NM:i:0 AM:i:3
700666F:325:CCC50ANXX:6:2211:7905:2066 1:N:0:GTCGAG 16 ctg18961_RHIMB__RM170330.18961 Backbone_18961|arrow|pilon 34735 3 31= * 0 0 GGTAGGCGCAGAAAGTACCATCGAAAGTTGA GGGGGFGGGGGGGGGGGGGGGGGGGGCCCCC XT:A:R NM:i:0 AM:i:3
700666F:325:CCC50ANXX:6:2211:7970:2099 1:N:0:GTCGAG 0 ctg16585_RHIMB__RM170330.16585 Backbone_16585|arrow|pilon 33974 3 23= * 0 0 GGGAATACCAGGTGCTGTAGGCT CCCCCGEGGGGGGGGGGGGGGGG XT:A:R NM:i:0 AM:i:3
700666F:325:CCC50ANXX:6:2211:7937:2145 1:N:0:GTCGAG 16 ctg13544_RHIMB__RM170330.13544 Backbone_13544|arrow|pilon 7627 3 39= * 0 0 GGTGAGAGCGCCGAATCCTAACCACTAGACCACCAGGGA GGGGGGGGGGGGGGGGGGGGGGGGGFGGGGGGGGCCCCC XT:A:R NM:i:0 AM:i:3
Leave a comment:
Latest Articles
Collapse
-
by seqadmin
Proteins are often described as the workhorses of the cell, and identifying their sequences is key to understanding their role in biological processes and disease. Currently, the most common technique used to determine protein sequences is mass spectrometry. While still a valuable tool, mass spectrometry faces several limitations and requires a highly experienced scientist familiar with the equipment to operate it. Additionally, other proteomic methods, like affinity assays, are constrained...-
Channel: Articles
04-04-2024, 04:25 PM -
-
by seqadmin
Despite advancements in sequencing platforms and related sample preparation technologies, certain sample types continue to present significant challenges that can compromise sequencing results. Pedro Echave, Senior Manager of the Global Business Segment at Revvity, explained that the success of a sequencing experiment ultimately depends on the amount and integrity of the nucleic acid template (RNA or DNA) obtained from a sample. “The better the quality of the nucleic acid isolated...-
Channel: Articles
03-22-2024, 06:39 AM -
ad_right_rmr
Collapse
News
Collapse
Topics | Statistics | Last Post | ||
---|---|---|---|---|
Started by seqadmin, 04-11-2024, 12:08 PM
|
0 responses
22 views
0 likes
|
Last Post
by seqadmin
04-11-2024, 12:08 PM
|
||
Started by seqadmin, 04-10-2024, 10:19 PM
|
0 responses
24 views
0 likes
|
Last Post
by seqadmin
04-10-2024, 10:19 PM
|
||
Started by seqadmin, 04-10-2024, 09:21 AM
|
0 responses
19 views
0 likes
|
Last Post
by seqadmin
04-10-2024, 09:21 AM
|
||
Started by seqadmin, 04-04-2024, 09:00 AM
|
0 responses
50 views
0 likes
|
Last Post
by seqadmin
04-04-2024, 09:00 AM
|
Leave a comment: