SEQanswers

Go Back   SEQanswers > Bioinformatics > Bioinformatics



Similar Threads
Thread Thread Starter Forum Replies Last Post
Bowtie: Ultrafast and memory-efficient alignment of short reads to the human genome Ben Langmead Literature Watch 2 03-04-2013 02:06 AM
The best short read aligner Deutsche Bioinformatics 4 04-14-2011 07:12 PM
Short Read Micro re-Aligner Paper nilshomer Literature Watch 0 10-29-2010 09:59 AM
New Short Read Aligner sparks Bioinformatics 48 08-26-2009 08:01 AM
Very Short Read aligner Rupinder Bioinformatics 1 06-02-2009 07:10 PM

Reply
 
Thread Tools
Old 11-13-2008, 07:56 AM   #21
swbarnes2
Senior Member
 
Location: San Diego

Join Date: May 2008
Posts: 912
Default

Quote:
Originally Posted by Ben Langmead View Post
Hi swbarnes2 - I'm going to add your suggestion to the sourceforge feature request list. You seem invested in SOAP-style alignment, but I would note that Maq-style (the default) accomplishes something like iterative trimming by simply discounting the penalty associated with mismatches at low-quality positions (usually clustered at the 3' end).
Yes, I did notice that, (and I'm running pretty close to default:--best -p 4 -t) but I still see about the same number of aligned reads as I do with SOAP set to no trimming. SOAP iteratively trimming yields a whole lot more. By a test I ran last night, allowing SOAP to iteratively trim every base pair until there were no more than 2 mismatches yielded an extra million reads aligning in one lane compared to bowtie. During the day, I run the faster 'trim 8 bp at a time', but the difference is still substantial.

Quote:
Out of curiosity, do you use SOAP's mode for aligning with indels?
Yes, that's part of the reason. Maq's indel detection is pretty hopeless, or it was when I looked at it last. And I think that it was not handling repeats at all, but maybe I'm misremembering.

I've tried Maq, and I use it as a compliment to SOAP, but I didn't like that the output was all processed for me. I wanted to see qualities and repetitiveness and read IDs and pair distances across the genome, and the pile-up view doesn't show that, and I'm pretty sure that Maqview won't either. But the output of Maq didn't give me the raw alignment info to construct a file with all that info, so I use SOAP, and process that output.
swbarnes2 is offline   Reply With Quote
Old 11-13-2008, 10:31 AM   #22
Chipper
Senior Member
 
Location: Sweden

Join Date: Mar 2008
Posts: 324
Default

Are the extra million reads aligned after truncatinon really correctly placed?
Chipper is offline   Reply With Quote
Old 11-13-2008, 11:24 AM   #23
swbarnes2
Senior Member
 
Location: San Diego

Join Date: May 2008
Posts: 912
Default

They seem to be. But I'm only doing bacteria, and that's easier to align correctly to. Reference genomes are rarely what they are cracked up to be, but when aligning I look across the genome at what aligned where, I see mostly 48-mers, but also 40-mers, 32-mers and occasionally 24-mers, when I trim by 8's. And I know that when I compare the two output files of my test, the reads that show up in SOAP that didn't show up in Bowtie are all ones that SOAP trimmed.
swbarnes2 is offline   Reply With Quote
Old 11-13-2008, 12:07 PM   #24
jyli
Member
 
Location: North Carolina

Join Date: Nov 2008
Posts: 21
Default Memory requirement on a window 32x

I tried to test human index downloaded from recommended site with the command

bowtie -c h_sapiens_asm ATTCAGTAGGTACTATAAATGGCCGAT

then, I got error:

Out of memory allocating ebwt[] in Ebwt::read() at ebwt.h:2811
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

So, my question is about the memory allocation or whether I did anything wrong?

Thank you for your attention.
jyli is offline   Reply With Quote
Old 11-14-2008, 06:00 AM   #25
Ben Langmead
Senior Member
 
Location: Baltimore, MD

Join Date: Sep 2008
Posts: 200
Default

Hi jyli,

The memory footprint of the whole-human index is about 2.2 GB without the -z ("phased") option. With the -z option it's closer to 1.3 GB (last I checked). If your machine has 3 GB of RAM or more and you'd like to align to human, the default mode should be fine. If your machine has 2 gigabytes of RAM and you'd like to align to human, you'll need to use the -z option.

(The unfriendly error message is my fault! - I'm going to fix that for the next release.)

Thanks,
Ben
Ben Langmead is offline   Reply With Quote
Old 11-18-2008, 08:57 AM   #26
myrna
Member
 
Location: Vancouver, Canada

Join Date: Feb 2008
Posts: 44
Default memory issues when creating index file

I am unable to index the human genome on my MacPro (16G RAM). I have the same problem when using the provided Mac binary or compling from source. I have posted the error output below.

Any ideas?

Thanks

./bowtie-build -f ../../genomes/all_human_build_36.fa human_all
Settings:
Output files: "human_all.*.ebwt"
Line rate: 6 (line is 64 bytes)
Lines per side: 1 (side is 64 bytes)
Offset rate: 5 (one in 32)
FTable chars: 10
Max bucket size: default
Max bucket size, sqrt multiplier: default
Max bucket size, len divisor: 4
Difference-cover sample period: 1024
Reference base cutoff: none
Endianness: little
Actual local endianness: little
Sanity checking: disabled
Assertions: disabled
Random seed: 0
Sizeofs: void*:4, int:4, long:4, size_t:4
Input files DNA, FASTA:
../../genomes/all_human_build_36.fa
Reading reference sizes
Choose best chunkRate: 15
Time reading reference sizes: 00:01:09
Calculating joined length
= 2860744704 (5384364 characters of padding)
Writing header
Reserving space for joined string
bowtie-build(6713) malloc: *** mmap(size=2860744704) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
Out of memory creating joined string in Ebwt::initFromVector() at ebwt.h:586
myrna is offline   Reply With Quote
Old 11-18-2008, 10:13 AM   #27
Ben Langmead
Senior Member
 
Location: Baltimore, MD

Join Date: Sep 2008
Posts: 200
Default

Hello myrna,

Yes, sorry, other users have seen that problem too. It seems that even if your machine has plenty of RAM in total, the memory allocator may not be able to dole it out in large enough chunks to satisfy Bowtie (due to memory fragmentation within the allocator). I'm working on a solution for the 0.9.8 release. For now, you can usually work around the problem by using bowtie-build-packed, which uses 2-bit-per-base encoding to save memory.

BTW, a good place to report issues is the sourceforge bug tracker: (https://sourceforge.net/tracker/?fun...7&atid=1101606). It leaves a better paper trail.

Thanks!
Ben
Ben Langmead is offline   Reply With Quote
Old 11-18-2008, 01:57 PM   #28
myrna
Member
 
Location: Vancouver, Canada

Join Date: Feb 2008
Posts: 44
Default memory issues when creating index file

Hi Ben.
Thanks for your prompt reply. This time around I see this error (after quite awhile):

bowtie-build-packed(14780) malloc: *** mmap(size=2860744704) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
Could not allocate a suffix-array block of 2860744708 bytes
Please try using a larger number of blocks by specifying a smaller --bmax or
--bmaxmultsqrt or a larger --bmaxdivn

I will play with bmaxdivn and bmaxmultsqrt to see if I can get a successful build. Any suggestions?

Regards,

Ryan
myrna is offline   Reply With Quote
Old 11-18-2008, 02:02 PM   #29
Ben Langmead
Senior Member
 
Location: Baltimore, MD

Join Date: Sep 2008
Posts: 200
Default

Hello myrna,

As soon as the *next* version of Bowtie comes out, this pain will go away because there will be a "-a/--auto" option that automatically follows the suggestion printed in the error message. As 0.9.7.1 stands, you'll have to do what it says yourself, i.e., just try larger values of --bmaxdivn until it fits in memory. Again - I promise this will be easier in the next version.

Thanks,
Ben
Ben Langmead is offline   Reply With Quote
Old 11-19-2008, 10:55 AM   #30
myrna
Member
 
Location: Vancouver, Canada

Join Date: Feb 2008
Posts: 44
Default Bowtie on a Mac

I found a way to fix the memory issue I mentioned in this thread on a Mac. It seems that the binary was run as a 32-bit intel process, which forces it to use 32-bit memory addressing. This meant that as soon as the process hit the 32-bit memory ceiling, it choked. I edited the Makefile and recompiled, and it runs as a 64-bit process now. I no longer get any complaints about memory, and don't have to tweak any of the runtime parameters.

Makefile modification:
old:
EXTRA_FLAGS =
new:
EXTRA_FLAGS = -arch x86_64

Ryan
myrna is offline   Reply With Quote
Old 11-25-2008, 04:22 PM   #31
Ben Langmead
Senior Member
 
Location: Baltimore, MD

Join Date: Sep 2008
Posts: 200
Default

Hello Ryan,

FYI, I made multiple improvements in Bowtie 0.9.8 that will help prevent such problems for people in the future. First of all, the Mac binary available from sourceforge is now "Universal" for i386 and x86_64, whereas it was previously i386 only, which forced 64-Mac users to start from source. Also, by default bowtie-build will now automatically look for values for the --bmax, --dcv and --packed parameters that fit into the memory of the computer it's running on. This obviates the tedious trial-and-error of trying larger and larger --bmaxdivn. Also, bowtie-build and bowtie-build-packed are now both "in" bowtie-build - they are no longer separate binaries. Packed mode is activated by passing -p/--packed to bowtie-build.

I hope these improvements help you and others.

Thanks,
Ben
Ben Langmead is offline   Reply With Quote
Old 12-10-2008, 11:33 AM   #32
ewingad
Junior Member
 
Location: Philadelphia

Join Date: Aug 2008
Posts: 6
Default

Hi, is there a way to find out how many equally good alignments exist for a given read using bowtie (other than using the -a option and counting them up)? Is this what field #7 ('Reserved') in the bowtie aligner output is?
ewingad is offline   Reply With Quote
Old 12-10-2008, 05:30 PM   #33
Ben Langmead
Senior Member
 
Location: Baltimore, MD

Join Date: Sep 2008
Posts: 200
Default

Hi ewingad,

That's *almost* what field #7 is. What this field really tells you is how many other rows there were in the range of suffix-array rows (equivalently: Burrows-Wheeler matrix rows) from which the alignment was randomly selected and reported. To put it another way, that field tells you how many other alignments there are with the same reference string. To put it yet another way: that field gives an estimate of how many other places the read aligns, but it can be an *underestimate* (in rare cases, it can be a large underestimate). If you want to know exactly how many places it aligns then, yes, giving bowtie the -a option and counting up the alignments is the best thing to do for now.

Everything's a tradeoff! The current Bowtie default maximizes performance but doesn't expend any of the additional effort needed to get a more meaningful result for field #7. Bowtie with the -a options minimizes performance but tells you exactly how many alignments there are and what they are. In the future, it's possible for me to add an option that doesn't necessarily *report* all the alignments, but which expends the effort needed to count them up and reports the right number in field #7. This will be faster than bowtie -a, but probably only a little faster. Is that a useful feature for you, or are the current options sufficient?

Thanks,
Ben
Ben Langmead is offline   Reply With Quote
Old 12-10-2008, 11:02 PM   #34
Chipper
Senior Member
 
Location: Sweden

Join Date: Mar 2008
Posts: 324
Default

Hi Ben,

is column #7 the (minimum) number of equally good hits? Would it be possible to report also the number of hits with an additional mismatch?
Chipper is offline   Reply With Quote
Old 12-11-2008, 02:10 AM   #35
lh3
Senior Member
 
Location: Boston

Join Date: Feb 2008
Posts: 693
Default

To Ben:

First thank you for Bowtie. It is really amazing. I have not read Bowtie codes, but from README, I think all the BWT based aligners (together with SOAP2 and mine) share a lot in common. Some comments:

1. I forget how much time is spent on building BWT index, but my impression is BWT-SW (also used in soap2 and bwa) is much faster and more light-weighted. Maybe it is worth having a look at the publications by Tam's group. Of course, building index is an once-for-all process. Just remind you of a possibly better algorithm.

2. My main concern about bowtie is actually related to the column 7. I think by default (no --best), bowtie just outputs the first group of hits it meets. Users would not know whether it is the best or whether it is a repeat or not. I think (maybe wrong) this behaviour is only useful for screening human contaminations. With "--best", user would know the output is the best hit, but whether it is a repeat is still unknown in some cases. I know the "unknown" cases should be rare, but it would be necessary to convince users that the rare cases would not affect accuracy. Only with "--best -k 2", a user may know whether it is a repeat or not, although he/she would not know the number of occurrences. I think the "--best -k2" is the most desired behaviour and should become the default. Bowtie is fast enough. Slowing it down by a factor 3 will still make most users quite happy (see also below). Also quoting the speed under the default option would be unfair to others.

3. I think it is worth metioning that the speed of soap/bowtie/novoalign is sensitive to error rate, while eland/zoom/rmap not. On bowtie's home page, it is claimed that bowtie is 35X faster than maq and 350X than soap. However, to my experiences, on high quality data, maq and soap is about the same speed. We can only see this big difference when base quality is low. Actually on my small experiment, bowtie is 170X faster than maq (cmd option: -f -v 2; I know using quality may be a bit slower), but I guess the difference would be smaller if the error rate is higher.

4. Comparison of BWT based aligners. So far as I know, there are three BWT based short read aligners: bowtie, soap2 and bwa. Soap2 gives the number of occurences of the best hits and bwa also reports the number of hits with additional mismatches if the best hit is unique (like what chipper is asking for). bwa is the only one that finds short indels at present, although I am sure this is not hard for soap2/bowtie. In addition, soap2 only finds hits with up to 2 mismatches. I think they have to do so according to a brief description of its algorithm. On speed, bowtie-f-v2 is 3X faster than soap2 (bowtie--best-v2-f-k2 is similar to soap2 in speed) and soap2 is 2.5X faster than bwa. On memory, both bwa and bowtie use 2.3GB while soap2 uses 5.3GB.

5. back to how the alignments are reported. I think the bwa behaviour is useful if people do not care too much about speed. Knowing the number of suboptimal hits would help us to decide which alignments are reliable. I know this is important to some (not all) SV detection algorithms. If you think the bwa behaviour is costly (possibly it is), I would recommend the soap2's one. Frequently, we may want to know the exact number of occurences (no need to output the detailed aligments). I am sure having the soap2 behaviour would make bowtie more popular.

[PS: soap2 has binary available; bwa is released under GPL and so source codes are available.]

To swbarnes2:

I do think referees found by Nature thought maq indel caller is rubish. As for the maq output, I wonder whether mapview (not maqview) suits your goal?

To Dmamartin:

I think your benchmark may not be very fair. On one hand, you use chr1 only, but BWT-based method only shines when the reference genome is longer. To this end, the comparison unfair to bowtie and vmatch. On the other hand, ZOOM is only efficient when you feed several million reads in a batch. You will find that the speed on aligning 20k or 40k reads is about the same for ZOOM.

Last edited by lh3; 12-11-2008 at 02:20 AM.
lh3 is offline   Reply With Quote
Old 12-11-2008, 06:24 AM   #36
ewingad
Junior Member
 
Location: Philadelphia

Join Date: Aug 2008
Posts: 6
Default

Thanks for the reply Ben, and thanks for bowtie! I was introduced to it via a talk by Lior Pachter, he speaks highly of you and Cole. In my short experience with it so far it has been extremely fast and accurate when re-mapping reads from the 1000 genomes project.

I agree with lh3 that it may be vital to know whether a given alignment is to a repetitive sequence i.e. if other equally good alignments exist - I suppose that if there are multiple _identical_ alignments they should all be coming from the same BW rows? If this is provable then it is possible to reassure users about lh3's point #2.

I also agree that something like lh3's point #5 is useful - when aligning short reads it is often a useful quality measure to know how many alignments would result from a 1-bp change in the query sequence. So, if for a given read, if I know that even if I changed one base, the reported alignment would not change, I feel more confident about that alignment.

Thanks again!

-Adam
ewingad is offline   Reply With Quote
Old 12-11-2008, 09:12 AM   #37
Ben Langmead
Senior Member
 
Location: Baltimore, MD

Join Date: Sep 2008
Posts: 200
Default

Hey lh3,

This discussion is very helpful - thanks, and thanks for checking out Bowtie.

Quote:
Originally Posted by lh3 View Post
To Ben:

First thank you for Bowtie. It is really amazing. I have not read Bowtie codes, but from README, I think all the BWT based aligners (together with SOAP2 and mine) share a lot in common. Some comments:

1. I forget how much time is spent on building BWT index, but my impression is BWT-SW (also used in soap2 and bwa) is much faster and more light-weighted. Maybe it is worth having a look at the publications by Tam's group. Of course, building index is an once-for-all process. Just remind you of a possibly better algorithm.
I agree; it's entirely possible that there's something faster, e.g., what BWT-SW does. The biggest advantage of the algorithm Bowtie uses as I've implemented it is that it's quite flexible with how much memory it uses. However, I too suspect that something faster could be done. That's on my TODO list (though it's pretty far down, since, as you say, that cost is typically amortized away).

Quote:
2. My main concern about bowtie is actually related to the column 7. I think by default (no --best), bowtie just outputs the first group of hits it meets. Users would not know whether it is the best or whether it is a repeat or not. I think (maybe wrong) this behaviour is only useful for screening human contaminations. With "--best", user would know the output is the best hit, but whether it is a repeat is still unknown in some cases. I know the "unknown" cases should be rare, but it would be necessary to convince users that the rare cases would not affect accuracy. Only with "--best -k 2", a user may know whether it is a repeat or not, although he/she would not know the number of occurrences. I think the "--best -k2" is the most desired behaviour and should become the default. Bowtie is fast enough. Slowing it down by a factor 3 will still make most users quite happy (see also below). Also quoting the speed under the default option would be unfair to others.
Your characterization that Bowtie "outputs the first group of hits it meets" is right - specifically, it will randomly select k distinct alignments from that range of BWT rows. (Of course, if k is greater than the number of alignments in that range, it has to go and search for another range.)

First, let me reemphasize that I think of Bowtie's target application as mammalian resequencing - that's how I characterize it in the manual and that's what we spend our time trying to optimize it for. I also mention in the manual that Bowtie should not be considered a general-purpose alignment tool, because there are definitely alignment scenarios where Bowtie won't give the exact information needed, or may not give it all that much faster than other tools. Given that, I want to argue that the "unknown" cases are not a significant concern, and so I disagree that quoting the speed under the default option is unfair.

First, the "unknown" cases. In resequencing, the result of the alignment step is essentially a multiple alignment across the whole genome with relatively deep coverage. Looking for, e.g., a SNP variant involves walking along the columns of the multiple alignment, looking at the alignments that span that column and combining the relevant evidence from each of the alignments to see if there's a call to be made. As described in the Maq paper (are you familiar with it? ), there's a need to discount evidence from alignments whose placement was ambiguous. That's what field #7 does (or will do, when we've settled on what should actually go there; we've marked it as "reserved" for now). The good news is that we can reasonably assume deep coverage, which means that we don't have to rely on the value in field #7 for just one read to know how reliable its evidence is. We can, for example, take the max of the values for field #7 for all the reads that span the column. That's just an example; probably something smarter than max is needed. In short, I argue that A) the case where field #7 is very wrong is rare, and B) in cases where it is very wrong, it can probably correct it by looking at nearby aligned reads. So I think the problem is manageable.

Quote:
3. I think it is worth metioning that the speed of soap/bowtie/novoalign is sensitive to error rate, while eland/zoom/rmap not. On bowtie's home page, it is claimed that bowtie is 35X faster than maq and 350X than soap. However, to my experiences, on high quality data, maq and soap is about the same speed. We can only see this big difference when base quality is low. Actually on my small experiment, bowtie is 170X faster than maq (cmd option: -f -v 2; I know using quality may be a bit slower), but I guess the difference would be smaller if the error rate is higher.
Those stats are helpful - thank you. I have noticed that the maq/bowtie speed ratio varies substantially based on CPU architecture and whether the input is filtered for poly-As. 35x (rounded down from about 38x) is the most Maq-favorable ratio I obtained in a set of experiments using filtered human read data from 1000 Genomes on a few different machines.

I do mention in the manual that Bowtie is faster for higher-quality input, though I could make that point more prominent.

Quote:
4. Comparison of BWT based aligners. So far as I know, there are three BWT based short read aligners: bowtie, soap2 and bwa. Soap2 gives the number of occurences of the best hits and bwa also reports the number of hits with additional mismatches if the best hit is unique (like what chipper is asking for). bwa is the only one that finds short indels at present, although I am sure this is not hard for soap2/bowtie. In addition, soap2 only finds hits with up to 2 mismatches. I think they have to do so according to a brief description of its algorithm. On speed, bowtie-f-v2 is 3X faster than soap2 (bowtie--best-v2-f-k2 is similar to soap2 in speed) and soap2 is 2.5X faster than bwa. On memory, both bwa and bowtie use 2.3GB while soap2 uses 5.3GB.
Those stats are very good to know. I admit that I haven't had much time to look at soap2 and bwa.

Note that Bowtie uses a bit more than half that amount of member when -z is specified. -z precludes the use of some options, but the default alignment mode works fine.

Quote:
5. back to how the alignments are reported. I think the bwa behaviour is useful if people do not care too much about speed. Knowing the number of suboptimal hits would help us to decide which alignments are reliable. I know this is important to some (not all) SV detection algorithms. If you think the bwa behaviour is costly (possibly it is), I would recommend the soap2's one. Frequently, we may want to know the exact number of occurences (no need to output the detailed aligments). I am sure having the soap2 behaviour would make bowtie more popular.
These are helpful suggestions. The TODO list for Bowtie grows at an alarming rate! In the short run, we're working on supporting paired-end alignment and indels, but we'll spend some time thinking about the best way to accomplish some of these "field #7" improvements too.

Many thanks,
Ben
Ben Langmead is offline   Reply With Quote
Old 12-11-2008, 10:14 AM   #38
lh3
Senior Member
 
Location: Boston

Join Date: Feb 2008
Posts: 693
Default

I have just done a comparison between bowtie and soap2. I am looking at 3.9 million alignments reported by both soap2 and bowtie. Soap2 says that there are 649k reads can be placed more than once, while 171k of them with the 7th col equal to 0 in bowtie. This means bowtie will claim 26% (171/649) of repetitive alignments as unique. This ratio seems a bit high to me. (cmd: soap2, default; bowtie -f -v2) I agree that not all of these wrong alignments may yield wrong SNPs, but SV detection will be affected a lot. Of course we need further evaluation on real data.
lh3 is offline   Reply With Quote
Old 12-11-2008, 11:57 AM   #39
Ben Langmead
Senior Member
 
Location: Baltimore, MD

Join Date: Sep 2008
Posts: 200
Default

That's a good experiment - can I recreate that? Are these public reads that I can access? This will help us think about the issue of what the contents of field #7 should actually be.

Can you explain a little more (or point us somewhere that explains) the SV detection issue? Is there a paper that describes the algorithm you have in mind?

Thanks again,
Ben
Ben Langmead is offline   Reply With Quote
Old 12-11-2008, 12:03 PM   #40
Ben Langmead
Senior Member
 
Location: Baltimore, MD

Join Date: Sep 2008
Posts: 200
Default

Quote:
Originally Posted by ewingad View Post
I agree with lh3 that it may be vital to know whether a given alignment is to a repetitive sequence i.e. if other equally good alignments exist - I suppose that if there are multiple _identical_ alignments they should all be coming from the same BW rows? If this is provable then it is possible to reassure users about lh3's point #2.
Yes, that's true. The alignments included in a single range or rows returned by Bowtie's search routine are "identical" in the sense that the reference characters aligned to are the same. This is provable owing to the properties of the matrix.

Quote:
I also agree that something like lh3's point #5 is useful - when aligning short reads it is often a useful quality measure to know how many alignments would result from a 1-bp change in the query sequence. So, if for a given read, if I know that even if I changed one base, the reported alignment would not change, I feel more confident about that alignment.
That's good to know - thanks; for now, using -a or -k 2 (or whatever other -k you prefer) together with --nostrata should tell you what you need to know.

Thanks,
Ben
Ben Langmead is offline   Reply With Quote
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off




All times are GMT -8. The time now is 10:10 PM.


Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2019, vBulletin Solutions, Inc.
Single Sign On provided by vBSSO