Torbjørn RognespersName, Tomáš FlouripersName, Ben NicholspersName, Christopher QuincepersName, Frédéric MahépersName (2016date). “VSEARCH: a versatile open source tool for metagenomics.” PeerJtitle·j.
Object of study — open-source, memory-unrestricted nucleotide sequence processing for metagenomicsterm, genomics, and population genomics
Research question — whether a transparent 64-bit implementation can reproduce and extend USEARCHterm functionality with competitive accuracy, speed, and robustness
Contribution — VSEARCHterm, a multithreaded sequence-analysis suite with heuristic candidate search, optimal alignment, clustering, dereplication, chimeraterm detection, FASTQterm processing, paired-read merging, and subsampling
phenomenon · claim-type · cross-domain-transfer · mechanism · claim-relation · replication-status · limitation — grounded in the full text| phenomenon | accuracy, runtime, memory capacity, interoperability, and algorithmic behavior across nucleotide searching, clustering, dereplication, chimera detection, merging, and subsampling — “The performance of the most important functions of VSEARCH version 2.0.3 (64-bit) was evaluated and compared to the 32-bit versions of USEARCH version 7.0.1090 and 8.1.1861. All datasets used were small enough to fit comfortably in the memory allocated to a 32-bit process. Chimera detection was also compared to UCHIME version 4.2. All tests were run on GNU/Linux CentOS 6.7 compute nodes with 16 physical cores (Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60 GHz) and 64GB RAM. Programs were run with 8 threads, if possible. All times indicated are wall-clock times. All scripts and data necessary to perform the evaluations are available in the GitHub repository at https://github.com/torognes/vsearch-eval/ to enable independent replication.” | |
| claim-type | method — “VSEARCH is an open source and free of charge multithreaded 64-bit tool for processing and preparing metagenomics, genomics and population genomics nucleotide sequence data. It is designed as an alternative to the widely used USEARCH tool ( Edgar, 2010 ) for which the source code is not publicly available, algorithm details are only rudimentarily described, and only a memory-confined 32-bit version is freely available for academic use.” | |
| method — evidence | — “Global pairwise sequence comparison is a core functionality of VSEARCH. Several commands compare a query sequence against a database of sequences: all-vs-all alignment ( allpairs_global ), clustering ( cluster_fast , cluster_size , cluster_smallmem ), chimera detection ( uchime_denovo and uchime_ref ) and searching ( usearch_global ). This comparison function proceeds in two phases: an initial heuristic filtering based on shared words, followed by optimal alignment of the query with the most promising candidates.” | |
| object of study — evidence | — “VSEARCH is an open source and free of charge multithreaded 64-bit tool for processing and preparing metagenomics, genomics and population genomics nucleotide sequence data. It is designed as an alternative to the widely used USEARCH tool ( Edgar, 2010 ) for which the source code is not publicly available, algorithm details are only rudimentarily described, and only a memory-confined 32-bit version is freely available for academic use.” | |
| research question — evidence | — “We believe that the existence of open-source solutions is beneficial for end-users and can invigorate research activities. For this reason, we have undertaken to offer a high quality open-source alternative to USEARCH, freely available to users without any memory limitation. VSEARCH includes most of the USEARCH functions in common use, and further development may add additional features. Here we describe the details of the VSEARCH implementation. To assess its performance in terms of speed and quality of results, we have evaluated some of the most important functions (searching, clustering, chimera detection and subsampling) and compared them to USEARCH. We find that VSEARCH delivers results that are better or on a par with USEARCH results.” | |
| contribution — evidence | — “VSEARCH includes most commands for analysing nucleotide sequences available in USEARCH version 7 and several of those available in USEARCH version 8, including searching (exact or based on global alignment), clustering by similarity (using length pre-sorting, abundance pre-sorting or a user-defined order), chimera detection (reference-based or de novo ), dereplication (full length or prefix), pairwise alignment, reverse complementation, sorting, and subsampling. VSEARCH also includes commands for FASTQ file processing, i.e., format detection, filtering, read quality statistics, and merging of paired reads. Furthermore, VSEARCH extends functionality with several new commands and improvements, including shuffling, rereplication, masking of low-complexity sequences with the well-known DUST algorithm, a choice among different similarity definitions, and FASTQ file format conversion. VSEARCH is here shown to be more accurate than USEARCH when performing searching, clustering, chimera detection and subsampling, while on a par with USEARCH for paired-ends read merging. VSEARCH is slower than USEARCH when performing clustering and chimera detection, but significantly faster when performing paired-end reads merging and dereplication. VSEARCH is available at https://github.com/torognes/vsearch under either the BSD 2-clause license or the GNU General Public License version 3.0.” | |
| mechanism | shared-word filtering K-mer overlap selects a small candidate set without alignment. — “Global pairwise sequence comparison is a core functionality of VSEARCH. Several commands compare a query sequence against a database of sequences: all-vs-all alignment ( allpairs_global ), clustering ( cluster_fast , cluster_size , cluster_smallmem ), chimera detection ( uchime_denovo and uchime_ref ) and searching ( usearch_global ). This comparison function proceeds in two phases: an initial heuristic filtering based on shared words, followed by optimal alignment of the query with the most promising candidates.” | mechanisms[0] |
| mechanism | word index An index of all possible k-mers maps words to database sequences. — “The first phase is presumably quite similar to USEARCH ( Edgar, 2010 ). Heuristics are used to identify a small set of database sequences that have many words in common with the query sequence. Words (or k -mers) consist of a certain number k of consecutive nucleotides of a sequence (8 by default, adjustable with the wordlength option). All overlapping words are included. A sequence of length n then contains at most n − k + 1 unique words. VSEARCH counts the number of shared words between the query and each database sequence. Words that appear multiple times are counted only once. To count the words in the database sequences quickly, VSEARCH creates an index of all the 4 k possible distinct words and stores information about which database sequences they appear in. For extremely frequent words, the set of database sequences is represented by a bitmap; otherwise the set is stored as a list. A finer control of k -mer indexing is described for USEARCH by the pattern (binary string indicating which positions must match) and slots options. USEARCH has such options but seems to ignore them. Currently, VSEARCH ignores these two options too. The minimum number of shared words required may be specified with the minwordmatches option (10 by default), but a lower value is automatically used for short or simple query sequences with less than 10 unique words.” | mechanisms[1] |
| mechanism | full dynamic programming Optimal query-candidate global alignment determines final similarity. — “In the second phase, searching proceeds by considering the database sequences in a specific order, starting with the sequence having the largest number of words in common with the query, and proceeding with a decreasing number of shared words. If two database sequences have the same number of words in common with the query, the shortest sequence is considered first. The query sequence is compared with each database sequence by computing the optimal global alignment. The alignment is performed using a multi-threaded and vectorised full dynamic programming algorithm ( Needleman & Wunsch, 1970 ) adapted from SWIPE ( Rognes, 2011 ). Due to the extreme memory requirements of this method when aligning two long sequences, an alternative algorithm described by Hirschberg (1975) and Myers & Miller (1988) is used when the product of the length of the sequences is greater than 25,000,000, corresponding to aligning two 5,000 bp sequences. This alternative algorithm uses only a linear amount of memory but is considerably slower. This second phase is probably where USEARCH and VSEARCH differ the most, as USEARCH by default presumably performs heuristic seed-and-extend alignment similar to BLAST ( Altschul et al., 1997 ), and only performs optimal alignment when the option fulldp (full dynamic programming) is used. Computing the optimal pairwise alignment in each case gives more accurate results but is also computationally more demanding. The efficient and vectorised full dynamic programming implementation in VSEARCH compensates that extra cost, at least for sequences that are not too long.” | mechanisms[2] |
| mechanism | linear-memory alternative algorithm Long sequence pairs switch to Hirschberg/Myers-Miller alignment to avoid extreme memory use. — “In the second phase, searching proceeds by considering the database sequences in a specific order, starting with the sequence having the largest number of words in common with the query, and proceeding with a decreasing number of shared words. If two database sequences have the same number of words in common with the query, the shortest sequence is considered first. The query sequence is compared with each database sequence by computing the optimal global alignment. The alignment is performed using a multi-threaded and vectorised full dynamic programming algorithm ( Needleman & Wunsch, 1970 ) adapted from SWIPE ( Rognes, 2011 ). Due to the extreme memory requirements of this method when aligning two long sequences, an alternative algorithm described by Hirschberg (1975) and Myers & Miller (1988) is used when the product of the length of the sequences is greater than 25,000,000, corresponding to aligning two 5,000 bp sequences. This alternative algorithm uses only a linear amount of memory but is considerably slower. This second phase is probably where USEARCH and VSEARCH differ the most, as USEARCH by default presumably performs heuristic seed-and-extend alignment similar to BLAST ( Altschul et al., 1997 ), and only performs optimal alignment when the option fulldp (full dynamic programming) is used. Computing the optimal pairwise alignment in each case gives more accurate results but is also computationally more demanding. The efficient and vectorised full dynamic programming implementation in VSEARCH compensates that extra cost, at least for sequences that are not too long.” | mechanisms[3] |
| mechanism | vectorisation and multiple threads Parallel SIMD computation offsets optimal-alignment cost. — “When searching nucleotide sequences, VSEARCH uses a fast heuristic based on words shared by the query and target sequences in order to quickly identify similar sequences, a similar strategy is probably used in USEARCH. VSEARCH then performs optimal global sequence alignment of the query against potential target sequences, using full dynamic programming instead of the seed-and-extend heuristic used by USEARCH. Pairwise alignments are computed in parallel using vectorisation and multiple threads.” | mechanisms[4] |
| mechanism | greedy centroid algorithm Queries join a qualifying centroid or create a new cluster. — “VSEARCH includes commands to perform de novo clustering using a greedy and heuristic centroid-based algorithm with an adjustable sequence similarity threshold specified with the id option (e.g., 0.97). The input sequences are either processed in the user supplied order ( cluster_smallmem ) or pre-sorted based on length ( cluster_fast ) or abundance (the new cluster_size option). Each input sequence is then used as a query in a search against an initially empty database of centroid sequences. The query sequence is clustered with the first centroid sequence found with similarity equal to or above the threshold. The search is performed using the heuristic approach described above which generally finds the most similar sequences first. If no matches are found, the query sequence becomes the centroid of a new cluster and is added to the database. If maxaccepts is higher than 1, several centroids with sufficient sequence similarity may be found and considered. By default, the query is clustered with the centroid presenting the highest sequence similarity (distance-based greedy clustering, DGC), or, if the sizeorder option is turned on, the centroid with the highest abundance (abundance-based greedy clustering, AGC) ( He et al., 2015 ; Westcott & Schloss, 2015 ; Schloss, 2016 ). VSEARCH performs multi-threaded clustering by searching the database of centroid sequences with several query sequences in parallel. If there are any non-matching query sequences giving rise to new centroids, the required internal comparisons between the query sequences are subsequently performed to achieve correct results. For each cluster, VSEARCH can create a simple multiple sequence alignment using the center star method ( Gusfield, 1993 ) with the centroid as the center sequence, and then compute a consensus sequence and a sequence profile.” | mechanisms[5] |
| mechanism | hash table Open addressing and linear probing identify identical full sequences. — “Full-length dereplication ( derep_fulllength ) is performed using a hash table with an open addressing and linear probing strategy based on the Google CityHash hash functions (written by Geoff Pike and Jyrki Alakuijala, and available at https://github.com/google/cityhash ). The hash table is initially empty. For each input sequence, the hash is computed and a lookup in the hash table is performed. If an identical sequence is found, the input sequence is clustered with the matching sequence; otherwise the input sequence is inserted into the hash table.” | mechanisms[6] |
| mechanism | Fowler–Noll–Vo 1a Incremental 64-bit prefix hashing supports prefix dereplication. — “In order to identify matches in the hash table during prefix dereplication, a hash is computed for each full-length input sequence and all its prefixes. The hash function used is the 64-bit Fowler–Noll–Vo 1a hash function ( Fowler, Noll & Vo, 1991 ), which is simple and quick to compute for such a series of sequences by adding one nucleotide at a time.” | mechanisms[7] |
| mechanism | SHA-1 or MD5 Sequence digests provide highly likely unique relabeling. — “The sequences resulting from dereplication and many other commands may be relabeled with a given prefix followed by a sequentially increasing number. VSEARCH exclusively also offers the possibility of relabelling each sequence with the SHA-1 ( Eastlake & Jones, 2001 ) or MD5 ( Rivest, 1992 ) message digest (hash) of the sequence. These are strings that are highly likely to be unique for each sequence. Before the digest is computed, the sequence is normalized by converting U’s to T’s and converting all symbols to upper case. VSEARCH includes public domain code for the MD5 algorithm written by Alexander Peslyak, and for SHA1 by Steve Reid and others.” | mechanisms[8] |
| mechanism | UCHIME algorithm Four sequence segments are compared with candidate parents for chimera scoring. — “Chimeras are detected either de novo ( uchime_denovo command) or with a reference database ( uchime_ref command) using the UCHIME algorithm described by Edgar et al. (2011) . VSEARCH will divide each query sequence into four segments and look for similarity of each segment to sequences in the set of potential parents using the heuristic search function described earlier. It will consider the four best candidates for each segment using maxaccepts 4 and maxrejects 16, and an id threshold of 0.55. VSEARCH optionally outputs borderline sequences, that is, sequences having a high enough score (as specified with the minh option) but with too small a divergence from the closest parent (as specified with the mindiv option). Multi-threading is supported for reference-based chimera detection.” | mechanisms[9] |
| mechanism | Dust algorithm Parallelized masking suppresses simple repeats and low-complexity regions. — “VSEARCH includes a highly optimized and parallelized implementation of the Dust algorithm by Tatusov and Lipman for masking of simple repeats and low-complexity nucleotide sequences. It is considerably faster than the implementation of the same algorithm in USEARCH. Their code available at ftp://ftp.ncbi.nlm.nih.gov/pub/tatusov/dust/version1/src/ is in the public domain. VSEARCH uses this algorithm by default, while USEARCH by default uses an undocumented rapid masking algorithm called fastnucleo . VSEARCH performs soft-masking automatically for the pairwise alignment, search, clustering and chimera detection commands. This behaviour can be controlled with the hardmask option to replace masked symbols with N’s instead of lower-casing them, and the dbmask and qmask options, which selects the masking algorithm (none, dust or soft) used for the database and query sequences, respectively. Masking may also be performed explicitly on an input file using the fastx_mask and maskfasta commands.” | mechanisms[10] |
| mechanism | optimal ungapped alignment Forward and reverse-complemented reads are aligned across their overlap. — “Merging of paired-end reads is supported by VSEARCH using the fastq_mergepairs command. The method used has some similarity to PEAR ( Zhang et al., 2014 ) and recognises options similar to USEARCH. The algorithm computes the optimal ungapped alignment of the overlapping region of the forward sequence and the reverse-complemented reverse sequence. The alignment requires a minimum overlap length (specified with the fastq_minovlen option, default 10), a maximum number of mismatches ( fastq_maxdiffs option, default 5), and a minimum and maximum length of the merged sequence ( fastq_minmergelen option, default 1, and fastq_maxmergelen option, default infinite). Staggered read pairs, i.e., read pairs where the 3′ end of the reverse read has an overhang to the left of the 5′ end of the forward read, are not allowed by default, but may be turned on by the fastq_allowmergestagger option. VSEARCH uses a match score (alpha) of +4 and a mismatch score (beta) of −5 for perfect quality residues. These scores are weighted by the probability that these two residues really match or mismatch, respectively, taking quality scores into account. These probabilities are computed in a way similar to PEAR score method 2 described in ‘Algorithms and implementation’ of the PEAR paper ( Zhang et al., 2014 ), but VSEARCH assumes all nucleotide background frequencies are 0.25. When merging sequences, VSEARCH computes posterior quality scores for the overlapping regions as described by Edgar & Flyvbjerg (2015) . For speed, scores and probabilities are pre-computed for all possible quality scores.” | mechanisms[11] |
| mechanism | quality scores Match and mismatch scores are weighted by residue correctness probabilities. — “Merging of paired-end reads is supported by VSEARCH using the fastq_mergepairs command. The method used has some similarity to PEAR ( Zhang et al., 2014 ) and recognises options similar to USEARCH. The algorithm computes the optimal ungapped alignment of the overlapping region of the forward sequence and the reverse-complemented reverse sequence. The alignment requires a minimum overlap length (specified with the fastq_minovlen option, default 10), a maximum number of mismatches ( fastq_maxdiffs option, default 5), and a minimum and maximum length of the merged sequence ( fastq_minmergelen option, default 1, and fastq_maxmergelen option, default infinite). Staggered read pairs, i.e., read pairs where the 3′ end of the reverse read has an overhang to the left of the 5′ end of the forward read, are not allowed by default, but may be turned on by the fastq_allowmergestagger option. VSEARCH uses a match score (alpha) of +4 and a mismatch score (beta) of −5 for perfect quality residues. These scores are weighted by the probability that these two residues really match or mismatch, respectively, taking quality scores into account. These probabilities are computed in a way similar to PEAR score method 2 described in ‘Algorithms and implementation’ of the PEAR paper ( Zhang et al., 2014 ), but VSEARCH assumes all nucleotide background frequencies are 0.25. When merging sequences, VSEARCH computes posterior quality scores for the overlapping regions as described by Edgar & Flyvbjerg (2015) . For speed, scores and probabilities are pre-computed for all possible quality scores.” | mechanisms[12] |
| mechanism | pseudo random number generator An optional seed makes shuffled FASTA output reproducible. — “VSEARCH can sort FASTA files by decreasing sequence length ( sortbylength ) or abundance ( sortbysize ). VSEARCH can also perform shuffling of FASTA files in random order ( shuffle ). A seed value for the pseudo random number generator may be provided by the randseed option to obtain replicable results.” | mechanisms[13] |
| mechanism | randomly extracting A count or fraction of sequences is sampled, optionally respecting abundance. — “Sequences in FASTA and FASTQ files can be subsampled ( fastx_subsample ) by randomly extracting a certain number ( sample_size ) or percentage ( sample_pct ) of the input sequences. Abundances may be taken into account, giving results as if the input sequences were rereplicated, subsampled and then dereplicated.” | mechanisms[14] |
| contrasts-with | USEARCH — “VSEARCH is an open source and free of charge multithreaded 64-bit tool for processing and preparing metagenomics, genomics and population genomics nucleotide sequence data. It is designed as an alternative to the widely used USEARCH tool ( Edgar, 2010 ) for which the source code is not publicly available, algorithm details are only rudimentarily described, and only a memory-confined 32-bit version is freely available for academic use.” | claim_relations[0] |
| extends | USEARCH version 7 command-line interface — “VSEARCH implements the following commands available in USEARCH version 7: allpairs_global , cluster_fast , cluster_smallmem , derep_fulllength , derep_prefix , fastq_chars , fastq_filter , fastq_mergepairs , fastq_stats , fastx_mask , maskfasta , sortbylength , sortbysize , uchime_denovo , uchime_ref and usearch_global . In addition, the following commands available in USEARCH version 8 have been implemented: fastq_eestats , fastx_revcomp , fastx_subsample and search_exact . VSEARCH additionally includes a few new commands that do not exist in USEARCH: cluster_size , fastq_convert , rereplicate and shuffle .” | claim_relations[1] |
| builds-on | UCHIME chimera detection — “Chimeras are detected either de novo ( uchime_denovo command) or with a reference database ( uchime_ref command) using the UCHIME algorithm described by Edgar et al. (2011) . VSEARCH will divide each query sequence into four segments and look for similarity of each segment to sequences in the set of potential parents using the heuristic search function described earlier. It will consider the four best candidates for each segment using maxaccepts 4 and maxrejects 16, and an id threshold of 0.55. VSEARCH optionally outputs borderline sequences, that is, sequences having a high enough score (as specified with the minh option) but with too small a divergence from the closest parent (as specified with the mindiv option). Multi-threading is supported for reference-based chimera detection.” | claim_relations[2] |
| builds-on | Needleman-Wunsch, SWIPE, Hirschberg, and Myers-Miller alignment methods — “In the second phase, searching proceeds by considering the database sequences in a specific order, starting with the sequence having the largest number of words in common with the query, and proceeding with a decreasing number of shared words. If two database sequences have the same number of words in common with the query, the shortest sequence is considered first. The query sequence is compared with each database sequence by computing the optimal global alignment. The alignment is performed using a multi-threaded and vectorised full dynamic programming algorithm ( Needleman & Wunsch, 1970 ) adapted from SWIPE ( Rognes, 2011 ). Due to the extreme memory requirements of this method when aligning two long sequences, an alternative algorithm described by Hirschberg (1975) and Myers & Miller (1988) is used when the product of the length of the sequences is greater than 25,000,000, corresponding to aligning two 5,000 bp sequences. This alternative algorithm uses only a linear amount of memory but is considerably slower. This second phase is probably where USEARCH and VSEARCH differ the most, as USEARCH by default presumably performs heuristic seed-and-extend alignment similar to BLAST ( Altschul et al., 1997 ), and only performs optimal alignment when the option fulldp (full dynamic programming) is used. Computing the optimal pairwise alignment in each case gives more accurate results but is also computationally more demanding. The efficient and vectorised full dynamic programming implementation in VSEARCH compensates that extra cost, at least for sequences that are not too long.” | claim_relations[3] |
| contrasts-with | seed-and-extend alignment — “When searching nucleotide sequences, VSEARCH uses a fast heuristic based on words shared by the query and target sequences in order to quickly identify similar sequences, a similar strategy is probably used in USEARCH. VSEARCH then performs optimal global sequence alignment of the query against potential target sequences, using full dynamic programming instead of the seed-and-extend heuristic used by USEARCH. Pairwise alignments are computed in parallel using vectorisation and multiple threads.” | claim_relations[4] |
| sense | open source as inspectable unrestricted implementation rather than free academic binary access — “VSEARCH is an open source and free of charge multithreaded 64-bit tool for processing and preparing metagenomics, genomics and population genomics nucleotide sequence data. It is designed as an alternative to the widely used USEARCH tool ( Edgar, 2010 ) for which the source code is not publicly available, algorithm details are only rudimentarily described, and only a memory-confined 32-bit version is freely available for academic use.” | senses[0] |
| sense | search as heuristic candidate filtering followed by exact alignment — “Global pairwise sequence comparison is a core functionality of VSEARCH. Several commands compare a query sequence against a database of sequences: all-vs-all alignment ( allpairs_global ), clustering ( cluster_fast , cluster_size , cluster_smallmem ), chimera detection ( uchime_denovo and uchime_ref ) and searching ( usearch_global ). This comparison function proceeds in two phases: an initial heuristic filtering based on shared words, followed by optimal alignment of the query with the most promising candidates.” | senses[1] |
| sense | word as a unique fixed-length nucleotide substring counted once per sequence — “The first phase is presumably quite similar to USEARCH ( Edgar, 2010 ). Heuristics are used to identify a small set of database sequences that have many words in common with the query sequence. Words (or k -mers) consist of a certain number k of consecutive nucleotides of a sequence (8 by default, adjustable with the wordlength option). All overlapping words are included. A sequence of length n then contains at most n − k + 1 unique words. VSEARCH counts the number of shared words between the query and each database sequence. Words that appear multiple times are counted only once. To count the words in the database sequences quickly, VSEARCH creates an index of all the 4 k possible distinct words and stores information about which database sequences they appear in. For extremely frequent words, the set of database sequences is represented by a bitmap; otherwise the set is stored as a list. A finer control of k -mer indexing is described for USEARCH by the pattern (binary string indicating which positions must match) and slots options. USEARCH has such options but seems to ignore them. Currently, VSEARCH ignores these two options too. The minimum number of shared words required may be specified with the minwordmatches option (10 by default), but a lower value is automatically used for short or simple query sequences with less than 10 unique words.” | senses[2] |
| sense | global alignment as accuracy-oriented full dynamic programming — “In the second phase, searching proceeds by considering the database sequences in a specific order, starting with the sequence having the largest number of words in common with the query, and proceeding with a decreasing number of shared words. If two database sequences have the same number of words in common with the query, the shortest sequence is considered first. The query sequence is compared with each database sequence by computing the optimal global alignment. The alignment is performed using a multi-threaded and vectorised full dynamic programming algorithm ( Needleman & Wunsch, 1970 ) adapted from SWIPE ( Rognes, 2011 ). Due to the extreme memory requirements of this method when aligning two long sequences, an alternative algorithm described by Hirschberg (1975) and Myers & Miller (1988) is used when the product of the length of the sequences is greater than 25,000,000, corresponding to aligning two 5,000 bp sequences. This alternative algorithm uses only a linear amount of memory but is considerably slower. This second phase is probably where USEARCH and VSEARCH differ the most, as USEARCH by default presumably performs heuristic seed-and-extend alignment similar to BLAST ( Altschul et al., 1997 ), and only performs optimal alignment when the option fulldp (full dynamic programming) is used. Computing the optimal pairwise alignment in each case gives more accurate results but is also computationally more demanding. The efficient and vectorised full dynamic programming implementation in VSEARCH compensates that extra cost, at least for sequences that are not too long.” | senses[3] |
| sense | clustering as greedy assignment to a centroid under an identity threshold — “VSEARCH includes commands to perform de novo clustering using a greedy and heuristic centroid-based algorithm with an adjustable sequence similarity threshold specified with the id option (e.g., 0.97). The input sequences are either processed in the user supplied order ( cluster_smallmem ) or pre-sorted based on length ( cluster_fast ) or abundance (the new cluster_size option). Each input sequence is then used as a query in a search against an initially empty database of centroid sequences. The query sequence is clustered with the first centroid sequence found with similarity equal to or above the threshold. The search is performed using the heuristic approach described above which generally finds the most similar sequences first. If no matches are found, the query sequence becomes the centroid of a new cluster and is added to the database. If maxaccepts is higher than 1, several centroids with sufficient sequence similarity may be found and considered. By default, the query is clustered with the centroid presenting the highest sequence similarity (distance-based greedy clustering, DGC), or, if the sizeorder option is turned on, the centroid with the highest abundance (abundance-based greedy clustering, AGC) ( He et al., 2015 ; Westcott & Schloss, 2015 ; Schloss, 2016 ). VSEARCH performs multi-threaded clustering by searching the database of centroid sequences with several query sequences in parallel. If there are any non-matching query sequences giving rise to new centroids, the required internal comparisons between the query sequences are subsequently performed to achieve correct results. For each cluster, VSEARCH can create a simple multiple sequence alignment using the center star method ( Gusfield, 1993 ) with the centroid as the center sequence, and then compute a consensus sequence and a sequence profile.” | senses[4] |
| sense | dereplication as collapsing exact full or prefix-redundant sequences — “Prefix dereplication ( derep_prefix ) is also implemented. As with full-length dereplication, identical sequences are clustered. In addition, sequences that are identical to prefixes of other sequences will also be clustered together. If a sequence is identical to the prefix of multiple sequences, it is generally not defined how prefix clustering should behave. VSEARCH resolves this ambiguity by clustering the sequence with the shortest of the candidate sequences. If they are equally long, priority will be given to the most abundant, the one with the lexicographically smaller identifier or the one with the earliest original position, in that order.” | senses[5] |
| sense | recall as avoidance of splitting one species across OTUs — “We independently evaluated the clustering accuracy of USEARCH and VSEARCH as described for Swarm ( Mahé et al., 2014 ) using two mock datasets, one with an even and one with uneven composition of 57 archaea and bacteria. The datasets were first dereplicated. Then the taxonomy of the unique sequences was assigned by a search against the set of rRNA reference sequences representing the species in the mock datasets, carried out with the usearch_global command of USEARCH. The sequences were shuffled randomly 10 times and clustering was performed at 20 different similarity levels ranging from 80% to 99% in steps of 1%. Clustering was carried out in two ways, first using the cluster_fast command that pre-sorts the sequences by length, and then using the cluster_smallmem command that simply processes the sequences in the user-supplied order (in that case, we supplied sequences ordered by decreasing abundance using the sortbysize command). We then compared the clusters obtained to the assigned species and computed the recall, precision and the adjusted Rand index of the classifications. Recall measures to what extent amplicons assigned to the same species are grouped together in the same OTU (i.e., not over-splitting). Precision measures to what extent amplicons in an OTU are assigned to the same species (i.e., not over-grouping). The adjusted Rand index ( Rand, 1971 ; Hubert & Arabie, 1985 ) summarises both precision and recall using a measure of agreement between two clusterings while adjusting for expected values by chance. The average values over the all shufflings are presented in Figs. 2 and 3 for the even and uneven datasets, respectively. For abundance-sorted sequences, the difference between VSEARCH and USEARCH version 8 is negligible. The difference is larger for length-sorted sequences. When using length sorting, USEARCH 8 (as well as version 7 on the even dataset) shows better precision than VSEARCH for similarity levels below 93%. However, OTU delineation is usually performed at higher similarity values, typically 97%. In the case of our benchmark, overall accuracy as measured by the adjusted Rand index is maximised at 95–97% similarity. This is precisely the region where for length sorting at least VSEARCH outperforms USEARCH.” | senses[6] |
| sense | precision as avoidance of grouping multiple species in one OTU — “We independently evaluated the clustering accuracy of USEARCH and VSEARCH as described for Swarm ( Mahé et al., 2014 ) using two mock datasets, one with an even and one with uneven composition of 57 archaea and bacteria. The datasets were first dereplicated. Then the taxonomy of the unique sequences was assigned by a search against the set of rRNA reference sequences representing the species in the mock datasets, carried out with the usearch_global command of USEARCH. The sequences were shuffled randomly 10 times and clustering was performed at 20 different similarity levels ranging from 80% to 99% in steps of 1%. Clustering was carried out in two ways, first using the cluster_fast command that pre-sorts the sequences by length, and then using the cluster_smallmem command that simply processes the sequences in the user-supplied order (in that case, we supplied sequences ordered by decreasing abundance using the sortbysize command). We then compared the clusters obtained to the assigned species and computed the recall, precision and the adjusted Rand index of the classifications. Recall measures to what extent amplicons assigned to the same species are grouped together in the same OTU (i.e., not over-splitting). Precision measures to what extent amplicons in an OTU are assigned to the same species (i.e., not over-grouping). The adjusted Rand index ( Rand, 1971 ; Hubert & Arabie, 1985 ) summarises both precision and recall using a measure of agreement between two clusterings while adjusting for expected values by chance. The average values over the all shufflings are presented in Figs. 2 and 3 for the even and uneven datasets, respectively. For abundance-sorted sequences, the difference between VSEARCH and USEARCH version 8 is negligible. The difference is larger for length-sorted sequences. When using length sorting, USEARCH 8 (as well as version 7 on the even dataset) shows better precision than VSEARCH for similarity levels below 93%. However, OTU delineation is usually performed at higher similarity values, typically 97%. In the case of our benchmark, overall accuracy as measured by the adjusted Rand index is maximised at 95–97% similarity. This is precisely the region where for length sorting at least VSEARCH outperforms USEARCH.” | senses[7] |
| sense | adjusted Rand index as combined chance-corrected clustering agreement — “We independently evaluated the clustering accuracy of USEARCH and VSEARCH as described for Swarm ( Mahé et al., 2014 ) using two mock datasets, one with an even and one with uneven composition of 57 archaea and bacteria. The datasets were first dereplicated. Then the taxonomy of the unique sequences was assigned by a search against the set of rRNA reference sequences representing the species in the mock datasets, carried out with the usearch_global command of USEARCH. The sequences were shuffled randomly 10 times and clustering was performed at 20 different similarity levels ranging from 80% to 99% in steps of 1%. Clustering was carried out in two ways, first using the cluster_fast command that pre-sorts the sequences by length, and then using the cluster_smallmem command that simply processes the sequences in the user-supplied order (in that case, we supplied sequences ordered by decreasing abundance using the sortbysize command). We then compared the clusters obtained to the assigned species and computed the recall, precision and the adjusted Rand index of the classifications. Recall measures to what extent amplicons assigned to the same species are grouped together in the same OTU (i.e., not over-splitting). Precision measures to what extent amplicons in an OTU are assigned to the same species (i.e., not over-grouping). The adjusted Rand index ( Rand, 1971 ; Hubert & Arabie, 1985 ) summarises both precision and recall using a measure of agreement between two clusterings while adjusting for expected values by chance. The average values over the all shufflings are presented in Figs. 2 and 3 for the even and uneven datasets, respectively. For abundance-sorted sequences, the difference between VSEARCH and USEARCH version 8 is negligible. The difference is larger for length-sorted sequences. When using length sorting, USEARCH 8 (as well as version 7 on the even dataset) shows better precision than VSEARCH for similarity levels below 93%. However, OTU delineation is usually performed at higher similarity values, typically 97%. In the case of our benchmark, overall accuracy as measured by the adjusted Rand index is maximised at 95–97% similarity. This is precisely the region where for length sorting at least VSEARCH outperforms USEARCH.” | senses[8] |
| sense | chimera accuracy as classification of individual reads rather than clusters — “Next, we tested reference-based ( uchime_ref ) and de novo ( uchime_denovo ) chimera detection using sequences from the 2011 version of Greengenes downloaded from http://greengenes.lbl.gov/Download/Sequence_Data/Fasta_data_files/ and from version 106 (May 2011) of the SILVA database downloaded from https://www.arb-silva.de/no_cache/download/archive/release_106/Exports/ . Sequences from the 16S rRNA V4 region was computationally extracted using the 515F (5′-GTGNCAGCMGCCGCGGTAA-3′) and 806R (5′-GGACTACHVGGGTWTCTAAT-3′) primers, and 8,000 reads were randomly selected from each database. PCR was simulated using a new simulation algorithm known as Simera ( Nichols & Quince, 2016 ) (available at https://github.com/bnichols1979/Simera ) that includes amplification and creation of PCR artefacts like chimeras. We sampled 30,000 reads (-s 30,000) and generated 20,000 potential chimeras (-c 20,000). Defaults were used for other options to Simera. The output sequences were then fed into an Illumina MiSeq noise simulator ( Schirmer et al., 2015 ) ending up with 14,966 reads based on Greengenes and 14,952 reads based on SILVA, of which 1,262 and 1,640 reads contain chimeric sequences, respectively. Next, the sequences were either clustered using the cluster_fast command at 97% identity or dereplicated. VSEARCH and USEARCH version 7 and 8 were run using the uchime_denovo command and then using the uchime_ref command with the Gold database downloaded from http://drive5.com/uchime/uchime_download.html as the reference database. To assess the performance, the results were sorted based on the chimera score, and then the ability to classify individual sequences correctly into chimeric and non-chimeric was plotted as ROC curves. The curves reflect the accuracy of classifying individual reads, not clusters, as abundances were taken into account. The plots in Figs. 5 and 6 show that de novo chimera detection performs better than reference-based detection, with the SILVA dataset in particular, but it does of course depend on the reference database used. VSEARCH performs better than both versions of USEARCH for de novo chimera detection. For reference-based detection VSEARCH also performs better for the Greengenes dataset, while none of the programs work well with the SILVA dataset. Clustering at 97% appears to be more appropriate than dereplication. In this test, the USEARCH programs were about twice as fast as VSEARCH for de novo detection, while they were about 10–30% faster than VSEARCH for reference-based detection.” | senses[9] |
| sense | correct merge as perfect alignment to a known reference — “Evaluation of paired-end reads merging performance was carried out in a manner similar to that described for the evaluation of PEAR ( Zhang et al., 2014 ). We used whole genome sequencing data from Staphylococcus aureus subspecies aureus strain USA 300 TCH 1516 sequenced by MacCallum et al. (2009) and retrieved from the GAGE-B repository ( http://ccb.jhu.edu/gage_b/ ). The S.aureus reads were 101 bp long from on average 180 bp long fragments, giving a 45X coverage of the genome. We also used Methylococcus capsulatus strain Bath 16S rRNA V3 region amplicon reads sequenced by Masella et al. (2012) . These reads were 108 bp long and the pairs should have an overlap of exactly 18 bp. Merging options were set to allow a minimum overlap of 10 bp and a maximum of 5 mismatches (USEARCH 7 and 8 have different default values for those), while other options were left at defaults. All programs were run with 8 threads. Merged sequences that could be perfectly aligned to their respective reference sequences (either the entire genome or the specific rRNA region) using BWA MEM ( Li & Durbin, 2009 ) were considered correctly merged. The results are shown in Table 2 . The numbers indicate that USEARCH version 7 merges the most reads for both bacteria, but also has the lowest percentage of correctly merged pairs of those merged. USEARCH version 8 merges the fewest reads, but has the highest percentage of correctly merged reads of those merged. VSEARCH is in the middle by merging more reads than USEARCH 8 with only a small decrease in the percentage of correct merges. VSEARCH is about twice as fast as USEARCH 8 and 4–5 times faster than USEARCH version 7.” | senses[10] |
| sense | subsampling correctness as centering on analytically expected abundance — “We evaluated the subsampling commands of USEARCH version 8 and VSEARCH to check if the results obtained correspond to those expected. We performed 10,000 random subsamplings of 5% of the 9.5 million unique sequences in the TARA V9 dataset ( Karsenti et al., 2011 ). To make this possible with the 32-bit USEARCH, we first downsampled the dataset once to 10% using VSEARCH and then randomly subsampled it again at 50% with either USEARCH or VSEARCH. Plots of the distribution of the abundance of the most abundant sequence in each subsampling are shown in Fig. 7 . The highest amplicon abundance in the original dataset is 15,638,316. After the initial 10% subsampling, the highest abundance was 1,564,267. After the second subsampling, the top abundances should therefore have a distribution centred on a value of 782,133.5. As can be seen from the figure, the USEARCH distribution has a mean that is about 2,000 too small, while the VSEARCH distribution is correctly centred on the expected value. Subsampling experiments were also performed at 2.5%, 1.5% and 0.5% with similar results, although the errors were of decreasing size. USEARCH seems to under-sample abundant amplicons and to over-sample rare amplicons.” | senses[11] |
| control | all performance datasets constrained to fit a 32-bit process — held — “The performance of the most important functions of VSEARCH version 2.0.3 (64-bit) was evaluated and compared to the 32-bit versions of USEARCH version 7.0.1090 and 8.1.1861. All datasets used were small enough to fit comfortably in the memory allocated to a 32-bit process. Chimera detection was also compared to UCHIME version 4.2. All tests were run on GNU/Linux CentOS 6.7 compute nodes with 16 physical cores (Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60 GHz) and 64GB RAM. Programs were run with 8 threads, if possible. All times indicated are wall-clock times. All scripts and data necessary to perform the evaluations are available in the GitHub repository at https://github.com/torognes/vsearch-eval/ to enable independent replication.” — rules out memory failure of USEARCH from ordinary task comparisons — “The performance of the most important functions of VSEARCH version 2.0.3 (64-bit) was evaluated and compared to the 32-bit versions of USEARCH version 7.0.1090 and 8.1.1861. All datasets used were small enough to fit comfortably in the memory allocated to a 32-bit process. Chimera detection was also compared to UCHIME version 4.2. All tests were run on GNU/Linux CentOS 6.7 compute nodes with 16 physical cores (Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60 GHz) and 64GB RAM. Programs were run with 8 threads, if possible. All times indicated are wall-clock times. All scripts and data necessary to perform the evaluations are available in the GitHub repository at https://github.com/torognes/vsearch-eval/ to enable independent replication.” | controls[0] |
| control | same 16-core nodes, 64 GB RAM, and eight threads when possible — held — “The performance of the most important functions of VSEARCH version 2.0.3 (64-bit) was evaluated and compared to the 32-bit versions of USEARCH version 7.0.1090 and 8.1.1861. All datasets used were small enough to fit comfortably in the memory allocated to a 32-bit process. Chimera detection was also compared to UCHIME version 4.2. All tests were run on GNU/Linux CentOS 6.7 compute nodes with 16 physical cores (Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60 GHz) and 64GB RAM. Programs were run with 8 threads, if possible. All times indicated are wall-clock times. All scripts and data necessary to perform the evaluations are available in the GitHub repository at https://github.com/torognes/vsearch-eval/ to enable independent replication.” — rules out hardware and thread-count differences — “The performance of the most important functions of VSEARCH version 2.0.3 (64-bit) was evaluated and compared to the 32-bit versions of USEARCH version 7.0.1090 and 8.1.1861. All datasets used were small enough to fit comfortably in the memory allocated to a 32-bit process. Chimera detection was also compared to UCHIME version 4.2. All tests were run on GNU/Linux CentOS 6.7 compute nodes with 16 physical cores (Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60 GHz) and 64GB RAM. Programs were run with 8 threads, if possible. All times indicated are wall-clock times. All scripts and data necessary to perform the evaluations are available in the GitHub repository at https://github.com/torognes/vsearch-eval/ to enable independent replication.” | controls[1] |
| control | 20 random RFAM shufflings — held — “Evaluation of search accuracy was carried out as described in the USEARCH paper ( Edgar, 2010 ), its supplementary, and on the website ( http://drive5.com/usearch/benchmark_rfam.html ), by assessing the ability of the programs to identify RNA sequences belonging to the same family in RFAM ( Burge et al., 2013 ). The 383,004 sequences in Rfam version 11 were randomly shuffled and then the first sequence from each of the 2,085 (out of 2,208) families that contained at least 2 members was selected as a representative and used as a query against the remaining 380,919 sequences. The programs were run with options id 0.0, minseqlength 1, maxaccepts 1, maxrejects 32, and strand plus. If the matching sequence found belonged to the same family, it was considered a true positive, otherwise it was considered as a false positive. We combined the results from 20 shufflings and plotted the results in the ROC-like curve shown in Fig. 1 . For a false discovery rate between 0.010 and 0.015, VSEARCH is more accurate than USEARCH’s latest version. For lower values, the three programs have similar accuracies. At higher false discovery rates, USEARCH version 8 has an advantage.” — rules out one sequence-order realization driving search accuracy — “Evaluation of search accuracy was carried out as described in the USEARCH paper ( Edgar, 2010 ), its supplementary, and on the website ( http://drive5.com/usearch/benchmark_rfam.html ), by assessing the ability of the programs to identify RNA sequences belonging to the same family in RFAM ( Burge et al., 2013 ). The 383,004 sequences in Rfam version 11 were randomly shuffled and then the first sequence from each of the 2,085 (out of 2,208) families that contained at least 2 members was selected as a representative and used as a query against the remaining 380,919 sequences. The programs were run with options id 0.0, minseqlength 1, maxaccepts 1, maxrejects 32, and strand plus. If the matching sequence found belonged to the same family, it was considered a true positive, otherwise it was considered as a false positive. We combined the results from 20 shufflings and plotted the results in the ROC-like curve shown in Fig. 1 . For a false discovery rate between 0.010 and 0.015, VSEARCH is more accurate than USEARCH’s latest version. For lower values, the three programs have similar accuracies. At higher false discovery rates, USEARCH version 8 has an advantage.” | controls[2] |
| control | 1,000 replicated RFAM datasets — held — “The time to search the Rfam database as described above was measured. To avoid extremely short running times, 1,000 replicates of the datasets were used. USEARCH version 7 required on average 5 min 29 s for the search, USEARCH version 8 took 5 min 57 s, while VSEARCH took 5 min 26 s.” — rules out unstable timing from extremely short searches — “The time to search the Rfam database as described above was measured. To avoid extremely short running times, 1,000 replicates of the datasets were used. USEARCH version 7 required on average 5 min 29 s for the search, USEARCH version 8 took 5 min 57 s, while VSEARCH took 5 min 26 s.” | controls[3] |
| control | even and uneven mock communities, ten shufflings, two orderings, and twenty thresholds — held — “We independently evaluated the clustering accuracy of USEARCH and VSEARCH as described for Swarm ( Mahé et al., 2014 ) using two mock datasets, one with an even and one with uneven composition of 57 archaea and bacteria. The datasets were first dereplicated. Then the taxonomy of the unique sequences was assigned by a search against the set of rRNA reference sequences representing the species in the mock datasets, carried out with the usearch_global command of USEARCH. The sequences were shuffled randomly 10 times and clustering was performed at 20 different similarity levels ranging from 80% to 99% in steps of 1%. Clustering was carried out in two ways, first using the cluster_fast command that pre-sorts the sequences by length, and then using the cluster_smallmem command that simply processes the sequences in the user-supplied order (in that case, we supplied sequences ordered by decreasing abundance using the sortbysize command). We then compared the clusters obtained to the assigned species and computed the recall, precision and the adjusted Rand index of the classifications. Recall measures to what extent amplicons assigned to the same species are grouped together in the same OTU (i.e., not over-splitting). Precision measures to what extent amplicons in an OTU are assigned to the same species (i.e., not over-grouping). The adjusted Rand index ( Rand, 1971 ; Hubert & Arabie, 1985 ) summarises both precision and recall using a measure of agreement between two clusterings while adjusting for expected values by chance. The average values over the all shufflings are presented in Figs. 2 and 3 for the even and uneven datasets, respectively. For abundance-sorted sequences, the difference between VSEARCH and USEARCH version 8 is negligible. The difference is larger for length-sorted sequences. When using length sorting, USEARCH 8 (as well as version 7 on the even dataset) shows better precision than VSEARCH for similarity levels below 93%. However, OTU delineation is usually performed at higher similarity values, typically 97%. In the case of our benchmark, overall accuracy as measured by the adjusted Rand index is maximised at 95–97% similarity. This is precisely the region where for length sorting at least VSEARCH outperforms USEARCH.” — rules out one composition, order, or identity threshold determining clustering conclusions — “We independently evaluated the clustering accuracy of USEARCH and VSEARCH as described for Swarm ( Mahé et al., 2014 ) using two mock datasets, one with an even and one with uneven composition of 57 archaea and bacteria. The datasets were first dereplicated. Then the taxonomy of the unique sequences was assigned by a search against the set of rRNA reference sequences representing the species in the mock datasets, carried out with the usearch_global command of USEARCH. The sequences were shuffled randomly 10 times and clustering was performed at 20 different similarity levels ranging from 80% to 99% in steps of 1%. Clustering was carried out in two ways, first using the cluster_fast command that pre-sorts the sequences by length, and then using the cluster_smallmem command that simply processes the sequences in the user-supplied order (in that case, we supplied sequences ordered by decreasing abundance using the sortbysize command). We then compared the clusters obtained to the assigned species and computed the recall, precision and the adjusted Rand index of the classifications. Recall measures to what extent amplicons assigned to the same species are grouped together in the same OTU (i.e., not over-splitting). Precision measures to what extent amplicons in an OTU are assigned to the same species (i.e., not over-grouping). The adjusted Rand index ( Rand, 1971 ; Hubert & Arabie, 1985 ) summarises both precision and recall using a measure of agreement between two clusterings while adjusting for expected values by chance. The average values over the all shufflings are presented in Figs. 2 and 3 for the even and uneven datasets, respectively. For abundance-sorted sequences, the difference between VSEARCH and USEARCH version 8 is negligible. The difference is larger for length-sorted sequences. When using length sorting, USEARCH 8 (as well as version 7 on the even dataset) shows better precision than VSEARCH for similarity levels below 93%. However, OTU delineation is usually performed at higher similarity values, typically 97%. In the case of our benchmark, overall accuracy as measured by the adjusted Rand index is maximised at 95–97% similarity. This is precisely the region where for length sorting at least VSEARCH outperforms USEARCH.” | controls[4] |
| control | repeated UCHIME SIMM benchmark plus new Greengenes and SILVA simulations — held — “Next, we tested reference-based ( uchime_ref ) and de novo ( uchime_denovo ) chimera detection using sequences from the 2011 version of Greengenes downloaded from http://greengenes.lbl.gov/Download/Sequence_Data/Fasta_data_files/ and from version 106 (May 2011) of the SILVA database downloaded from https://www.arb-silva.de/no_cache/download/archive/release_106/Exports/ . Sequences from the 16S rRNA V4 region was computationally extracted using the 515F (5′-GTGNCAGCMGCCGCGGTAA-3′) and 806R (5′-GGACTACHVGGGTWTCTAAT-3′) primers, and 8,000 reads were randomly selected from each database. PCR was simulated using a new simulation algorithm known as Simera ( Nichols & Quince, 2016 ) (available at https://github.com/bnichols1979/Simera ) that includes amplification and creation of PCR artefacts like chimeras. We sampled 30,000 reads (-s 30,000) and generated 20,000 potential chimeras (-c 20,000). Defaults were used for other options to Simera. The output sequences were then fed into an Illumina MiSeq noise simulator ( Schirmer et al., 2015 ) ending up with 14,966 reads based on Greengenes and 14,952 reads based on SILVA, of which 1,262 and 1,640 reads contain chimeric sequences, respectively. Next, the sequences were either clustered using the cluster_fast command at 97% identity or dereplicated. VSEARCH and USEARCH version 7 and 8 were run using the uchime_denovo command and then using the uchime_ref command with the Gold database downloaded from http://drive5.com/uchime/uchime_download.html as the reference database. To assess the performance, the results were sorted based on the chimera score, and then the ability to classify individual sequences correctly into chimeric and non-chimeric was plotted as ROC curves. The curves reflect the accuracy of classifying individual reads, not clusters, as abundances were taken into account. The plots in Figs. 5 and 6 show that de novo chimera detection performs better than reference-based detection, with the SILVA dataset in particular, but it does of course depend on the reference database used. VSEARCH performs better than both versions of USEARCH for de novo chimera detection. For reference-based detection VSEARCH also performs better for the Greengenes dataset, while none of the programs work well with the SILVA dataset. Clustering at 97% appears to be more appropriate than dereplication. In this test, the USEARCH programs were about twice as fast as VSEARCH for de novo detection, while they were about 10–30% faster than VSEARCH for reference-based detection.” — rules out chimera performance depending on one legacy benchmark — “We evaluated the chimera detection accuracy of VSEARCH and USEARCH in two ways, first using a method similar to that performed for UCHIME, and then using a new chimera simulation procedure based on sequences from Greengenes ( DeSantis et al., 2006 ) and SILVA ( Quast et al., 2013 ) sequences.” | controls[5] |
| control | perfect alignment of merged reads to known references — held — “Evaluation of paired-end reads merging performance was carried out in a manner similar to that described for the evaluation of PEAR ( Zhang et al., 2014 ). We used whole genome sequencing data from Staphylococcus aureus subspecies aureus strain USA 300 TCH 1516 sequenced by MacCallum et al. (2009) and retrieved from the GAGE-B repository ( http://ccb.jhu.edu/gage_b/ ). The S.aureus reads were 101 bp long from on average 180 bp long fragments, giving a 45X coverage of the genome. We also used Methylococcus capsulatus strain Bath 16S rRNA V3 region amplicon reads sequenced by Masella et al. (2012) . These reads were 108 bp long and the pairs should have an overlap of exactly 18 bp. Merging options were set to allow a minimum overlap of 10 bp and a maximum of 5 mismatches (USEARCH 7 and 8 have different default values for those), while other options were left at defaults. All programs were run with 8 threads. Merged sequences that could be perfectly aligned to their respective reference sequences (either the entire genome or the specific rRNA region) using BWA MEM ( Li & Durbin, 2009 ) were considered correctly merged. The results are shown in Table 2 . The numbers indicate that USEARCH version 7 merges the most reads for both bacteria, but also has the lowest percentage of correctly merged pairs of those merged. USEARCH version 8 merges the fewest reads, but has the highest percentage of correctly merged reads of those merged. VSEARCH is in the middle by merging more reads than USEARCH 8 with only a small decrease in the percentage of correct merges. VSEARCH is about twice as fast as USEARCH 8 and 4–5 times faster than USEARCH version 7.” — rules out counting all merged read pairs as correct — “Evaluation of paired-end reads merging performance was carried out in a manner similar to that described for the evaluation of PEAR ( Zhang et al., 2014 ). We used whole genome sequencing data from Staphylococcus aureus subspecies aureus strain USA 300 TCH 1516 sequenced by MacCallum et al. (2009) and retrieved from the GAGE-B repository ( http://ccb.jhu.edu/gage_b/ ). The S.aureus reads were 101 bp long from on average 180 bp long fragments, giving a 45X coverage of the genome. We also used Methylococcus capsulatus strain Bath 16S rRNA V3 region amplicon reads sequenced by Masella et al. (2012) . These reads were 108 bp long and the pairs should have an overlap of exactly 18 bp. Merging options were set to allow a minimum overlap of 10 bp and a maximum of 5 mismatches (USEARCH 7 and 8 have different default values for those), while other options were left at defaults. All programs were run with 8 threads. Merged sequences that could be perfectly aligned to their respective reference sequences (either the entire genome or the specific rRNA region) using BWA MEM ( Li & Durbin, 2009 ) were considered correctly merged. The results are shown in Table 2 . The numbers indicate that USEARCH version 7 merges the most reads for both bacteria, but also has the lowest percentage of correctly merged pairs of those merged. USEARCH version 8 merges the fewest reads, but has the highest percentage of correctly merged reads of those merged. VSEARCH is in the middle by merging more reads than USEARCH 8 with only a small decrease in the percentage of correct merges. VSEARCH is about twice as fast as USEARCH 8 and 4–5 times faster than USEARCH version 7.” | controls[6] |
| control | 10,000 random subsamplings compared with an analytically expected center — held — “We evaluated the subsampling commands of USEARCH version 8 and VSEARCH to check if the results obtained correspond to those expected. We performed 10,000 random subsamplings of 5% of the 9.5 million unique sequences in the TARA V9 dataset ( Karsenti et al., 2011 ). To make this possible with the 32-bit USEARCH, we first downsampled the dataset once to 10% using VSEARCH and then randomly subsampled it again at 50% with either USEARCH or VSEARCH. Plots of the distribution of the abundance of the most abundant sequence in each subsampling are shown in Fig. 7 . The highest amplicon abundance in the original dataset is 15,638,316. After the initial 10% subsampling, the highest abundance was 1,564,267. After the second subsampling, the top abundances should therefore have a distribution centred on a value of 782,133.5. As can be seen from the figure, the USEARCH distribution has a mean that is about 2,000 too small, while the VSEARCH distribution is correctly centred on the expected value. Subsampling experiments were also performed at 2.5%, 1.5% and 0.5% with similar results, although the errors were of decreasing size. USEARCH seems to under-sample abundant amplicons and to over-sample rare amplicons.” — rules out judging subsampling only from apparent randomness — “We evaluated the subsampling commands of USEARCH version 8 and VSEARCH to check if the results obtained correspond to those expected. We performed 10,000 random subsamplings of 5% of the 9.5 million unique sequences in the TARA V9 dataset ( Karsenti et al., 2011 ). To make this possible with the 32-bit USEARCH, we first downsampled the dataset once to 10% using VSEARCH and then randomly subsampled it again at 50% with either USEARCH or VSEARCH. Plots of the distribution of the abundance of the most abundant sequence in each subsampling are shown in Fig. 7 . The highest amplicon abundance in the original dataset is 15,638,316. After the initial 10% subsampling, the highest abundance was 1,564,267. After the second subsampling, the top abundances should therefore have a distribution centred on a value of 782,133.5. As can be seen from the figure, the USEARCH distribution has a mean that is about 2,000 too small, while the VSEARCH distribution is correctly centred on the expected value. Subsampling experiments were also performed at 2.5%, 1.5% and 0.5% with similar results, although the errors were of decreasing size. USEARCH seems to under-sample abundant amplicons and to over-sample rare amplicons.” | controls[7] |
| note | USEARCH — VSEARCH is explicitly designed as an open 64-bit alternative. — “VSEARCH is an open source and free of charge multithreaded 64-bit tool for processing and preparing metagenomics, genomics and population genomics nucleotide sequence data. It is designed as an alternative to the widely used USEARCH tool ( Edgar, 2010 ) for which the source code is not publicly available, algorithm details are only rudimentarily described, and only a memory-confined 32-bit version is freely available for academic use.” | claim_relations[0] |
| weight | USEARCH — 0.95 — “VSEARCH is an open source and free of charge multithreaded 64-bit tool for processing and preparing metagenomics, genomics and population genomics nucleotide sequence data. It is designed as an alternative to the widely used USEARCH tool ( Edgar, 2010 ) for which the source code is not publicly available, algorithm details are only rudimentarily described, and only a memory-confined 32-bit version is freely available for academic use.” | claim_relations[0] |
| note | USEARCH version 7 command-line interface — It retains most commands while adding functions absent from USEARCH. — “VSEARCH implements the following commands available in USEARCH version 7: allpairs_global , cluster_fast , cluster_smallmem , derep_fulllength , derep_prefix , fastq_chars , fastq_filter , fastq_mergepairs , fastq_stats , fastx_mask , maskfasta , sortbylength , sortbysize , uchime_denovo , uchime_ref and usearch_global . In addition, the following commands available in USEARCH version 8 have been implemented: fastq_eestats , fastx_revcomp , fastx_subsample and search_exact . VSEARCH additionally includes a few new commands that do not exist in USEARCH: cluster_size , fastq_convert , rereplicate and shuffle .” | claim_relations[1] |
| weight | USEARCH version 7 command-line interface — 0.95 — “VSEARCH implements the following commands available in USEARCH version 7: allpairs_global , cluster_fast , cluster_smallmem , derep_fulllength , derep_prefix , fastq_chars , fastq_filter , fastq_mergepairs , fastq_stats , fastx_mask , maskfasta , sortbylength , sortbysize , uchime_denovo , uchime_ref and usearch_global . In addition, the following commands available in USEARCH version 8 have been implemented: fastq_eestats , fastx_revcomp , fastx_subsample and search_exact . VSEARCH additionally includes a few new commands that do not exist in USEARCH: cluster_size , fastq_convert , rereplicate and shuffle .” | claim_relations[1] |
| note | UCHIME chimera detection — Both reference and de novo detection implement the published UCHIME algorithm. — “Chimeras are detected either de novo ( uchime_denovo command) or with a reference database ( uchime_ref command) using the UCHIME algorithm described by Edgar et al. (2011) . VSEARCH will divide each query sequence into four segments and look for similarity of each segment to sequences in the set of potential parents using the heuristic search function described earlier. It will consider the four best candidates for each segment using maxaccepts 4 and maxrejects 16, and an id threshold of 0.55. VSEARCH optionally outputs borderline sequences, that is, sequences having a high enough score (as specified with the minh option) but with too small a divergence from the closest parent (as specified with the mindiv option). Multi-threading is supported for reference-based chimera detection.” | claim_relations[2] |
| weight | UCHIME chimera detection — 0.95 — “Chimeras are detected either de novo ( uchime_denovo command) or with a reference database ( uchime_ref command) using the UCHIME algorithm described by Edgar et al. (2011) . VSEARCH will divide each query sequence into four segments and look for similarity of each segment to sequences in the set of potential parents using the heuristic search function described earlier. It will consider the four best candidates for each segment using maxaccepts 4 and maxrejects 16, and an id threshold of 0.55. VSEARCH optionally outputs borderline sequences, that is, sequences having a high enough score (as specified with the minh option) but with too small a divergence from the closest parent (as specified with the mindiv option). Multi-threading is supported for reference-based chimera detection.” | claim_relations[2] |
| note | Needleman-Wunsch, SWIPE, Hirschberg, and Myers-Miller alignment methods — The search phase adapts these established exact-alignment methods. — “In the second phase, searching proceeds by considering the database sequences in a specific order, starting with the sequence having the largest number of words in common with the query, and proceeding with a decreasing number of shared words. If two database sequences have the same number of words in common with the query, the shortest sequence is considered first. The query sequence is compared with each database sequence by computing the optimal global alignment. The alignment is performed using a multi-threaded and vectorised full dynamic programming algorithm ( Needleman & Wunsch, 1970 ) adapted from SWIPE ( Rognes, 2011 ). Due to the extreme memory requirements of this method when aligning two long sequences, an alternative algorithm described by Hirschberg (1975) and Myers & Miller (1988) is used when the product of the length of the sequences is greater than 25,000,000, corresponding to aligning two 5,000 bp sequences. This alternative algorithm uses only a linear amount of memory but is considerably slower. This second phase is probably where USEARCH and VSEARCH differ the most, as USEARCH by default presumably performs heuristic seed-and-extend alignment similar to BLAST ( Altschul et al., 1997 ), and only performs optimal alignment when the option fulldp (full dynamic programming) is used. Computing the optimal pairwise alignment in each case gives more accurate results but is also computationally more demanding. The efficient and vectorised full dynamic programming implementation in VSEARCH compensates that extra cost, at least for sequences that are not too long.” | claim_relations[3] |
| weight | Needleman-Wunsch, SWIPE, Hirschberg, and Myers-Miller alignment methods — 0.95 — “In the second phase, searching proceeds by considering the database sequences in a specific order, starting with the sequence having the largest number of words in common with the query, and proceeding with a decreasing number of shared words. If two database sequences have the same number of words in common with the query, the shortest sequence is considered first. The query sequence is compared with each database sequence by computing the optimal global alignment. The alignment is performed using a multi-threaded and vectorised full dynamic programming algorithm ( Needleman & Wunsch, 1970 ) adapted from SWIPE ( Rognes, 2011 ). Due to the extreme memory requirements of this method when aligning two long sequences, an alternative algorithm described by Hirschberg (1975) and Myers & Miller (1988) is used when the product of the length of the sequences is greater than 25,000,000, corresponding to aligning two 5,000 bp sequences. This alternative algorithm uses only a linear amount of memory but is considerably slower. This second phase is probably where USEARCH and VSEARCH differ the most, as USEARCH by default presumably performs heuristic seed-and-extend alignment similar to BLAST ( Altschul et al., 1997 ), and only performs optimal alignment when the option fulldp (full dynamic programming) is used. Computing the optimal pairwise alignment in each case gives more accurate results but is also computationally more demanding. The efficient and vectorised full dynamic programming implementation in VSEARCH compensates that extra cost, at least for sequences that are not too long.” | claim_relations[3] |
| note | seed-and-extend alignment — VSEARCH uses full dynamic programming where USEARCH is described as heuristic. — “When searching nucleotide sequences, VSEARCH uses a fast heuristic based on words shared by the query and target sequences in order to quickly identify similar sequences, a similar strategy is probably used in USEARCH. VSEARCH then performs optimal global sequence alignment of the query against potential target sequences, using full dynamic programming instead of the seed-and-extend heuristic used by USEARCH. Pairwise alignments are computed in parallel using vectorisation and multiple threads.” | claim_relations[4] |
| weight | seed-and-extend alignment — 0.95 — “When searching nucleotide sequences, VSEARCH uses a fast heuristic based on words shared by the query and target sequences in order to quickly identify similar sequences, a similar strategy is probably used in USEARCH. VSEARCH then performs optimal global sequence alignment of the query against potential target sequences, using full dynamic programming instead of the seed-and-extend heuristic used by USEARCH. Pairwise alignments are computed in parallel using vectorisation and multiple threads.” | claim_relations[4] |
| note | VSEARCH —is-a→ open source and free of charge multithreaded 64-bit tool — Direct categorical statement. — “VSEARCH is an open source and free of charge multithreaded 64-bit tool for processing and preparing metagenomics, genomics and population genomics nucleotide sequence data. It is designed as an alternative to the widely used USEARCH tool ( Edgar, 2010 ) for which the source code is not publicly available, algorithm details are only rudimentarily described, and only a memory-confined 32-bit version is freely available for academic use.” | concept_edges[0] |
| relation | VSEARCH —is-a→ open source and free of charge multithreaded 64-bit tool — VSEARCH is an open source and free of charge multithreaded 64-bit tool. — “VSEARCH is an open source and free of charge multithreaded 64-bit tool for processing and preparing metagenomics, genomics and population genomics nucleotide sequence data. It is designed as an alternative to the widely used USEARCH tool ( Edgar, 2010 ) for which the source code is not publicly available, algorithm details are only rudimentarily described, and only a memory-confined 32-bit version is freely available for academic use.” | concept_edges[0] |
| note | global pairwise sequence comparison —is-a→ core functionality — Direct categorical statement. — “Global pairwise sequence comparison is a core functionality of VSEARCH. Several commands compare a query sequence against a database of sequences: all-vs-all alignment ( allpairs_global ), clustering ( cluster_fast , cluster_size , cluster_smallmem ), chimera detection ( uchime_denovo and uchime_ref ) and searching ( usearch_global ). This comparison function proceeds in two phases: an initial heuristic filtering based on shared words, followed by optimal alignment of the query with the most promising candidates.” | concept_edges[1] |
| relation | global pairwise sequence comparison —is-a→ core functionality — Global pairwise sequence comparison is a core functionality of VSEARCH. — “Global pairwise sequence comparison is a core functionality of VSEARCH. Several commands compare a query sequence against a database of sequences: all-vs-all alignment ( allpairs_global ), clustering ( cluster_fast , cluster_size , cluster_smallmem ), chimera detection ( uchime_denovo and uchime_ref ) and searching ( usearch_global ). This comparison function proceeds in two phases: an initial heuristic filtering based on shared words, followed by optimal alignment of the query with the most promising candidates.” | concept_edges[1] |
| note | VSEARCH —contrasted-with→ USEARCH — Explicit alternative-to contrast. — “VSEARCH is an open source and free of charge multithreaded 64-bit tool for processing and preparing metagenomics, genomics and population genomics nucleotide sequence data. It is designed as an alternative to the widely used USEARCH tool ( Edgar, 2010 ) for which the source code is not publicly available, algorithm details are only rudimentarily described, and only a memory-confined 32-bit version is freely available for academic use.” | concept_edges[2] |
| relation | VSEARCH —contrasted-with→ USEARCH — VSEARCH is designed as an alternative to USEARCH with public source and unrestricted memory. — “VSEARCH is an open source and free of charge multithreaded 64-bit tool for processing and preparing metagenomics, genomics and population genomics nucleotide sequence data. It is designed as an alternative to the widely used USEARCH tool ( Edgar, 2010 ) for which the source code is not publicly available, algorithm details are only rudimentarily described, and only a memory-confined 32-bit version is freely available for academic use.” | concept_edges[2] |
| weight | VSEARCH —contrasted-with→ USEARCH — 0.95 — “VSEARCH is an open source and free of charge multithreaded 64-bit tool for processing and preparing metagenomics, genomics and population genomics nucleotide sequence data. It is designed as an alternative to the widely used USEARCH tool ( Edgar, 2010 ) for which the source code is not publicly available, algorithm details are only rudimentarily described, and only a memory-confined 32-bit version is freely available for academic use.” | concept_edges[2] |
| note | full dynamic programming —contrasted-with→ seed-and-extend heuristic — Explicit instead-of contrast. — “When searching nucleotide sequences, VSEARCH uses a fast heuristic based on words shared by the query and target sequences in order to quickly identify similar sequences, a similar strategy is probably used in USEARCH. VSEARCH then performs optimal global sequence alignment of the query against potential target sequences, using full dynamic programming instead of the seed-and-extend heuristic used by USEARCH. Pairwise alignments are computed in parallel using vectorisation and multiple threads.” | concept_edges[3] |
| relation | full dynamic programming —contrasted-with→ seed-and-extend heuristic — VSEARCH uses full dynamic programming instead of USEARCH's seed-and-extend heuristic. — “When searching nucleotide sequences, VSEARCH uses a fast heuristic based on words shared by the query and target sequences in order to quickly identify similar sequences, a similar strategy is probably used in USEARCH. VSEARCH then performs optimal global sequence alignment of the query against potential target sequences, using full dynamic programming instead of the seed-and-extend heuristic used by USEARCH. Pairwise alignments are computed in parallel using vectorisation and multiple threads.” | concept_edges[3] |
| weight | full dynamic programming —contrasted-with→ seed-and-extend heuristic — 0.95 — “When searching nucleotide sequences, VSEARCH uses a fast heuristic based on words shared by the query and target sequences in order to quickly identify similar sequences, a similar strategy is probably used in USEARCH. VSEARCH then performs optimal global sequence alignment of the query against potential target sequences, using full dynamic programming instead of the seed-and-extend heuristic used by USEARCH. Pairwise alignments are computed in parallel using vectorisation and multiple threads.” | concept_edges[3] |
| note | recall —operationalised-as→ grouped together in the same OTU — Direct measurement definition. — “We independently evaluated the clustering accuracy of USEARCH and VSEARCH as described for Swarm ( Mahé et al., 2014 ) using two mock datasets, one with an even and one with uneven composition of 57 archaea and bacteria. The datasets were first dereplicated. Then the taxonomy of the unique sequences was assigned by a search against the set of rRNA reference sequences representing the species in the mock datasets, carried out with the usearch_global command of USEARCH. The sequences were shuffled randomly 10 times and clustering was performed at 20 different similarity levels ranging from 80% to 99% in steps of 1%. Clustering was carried out in two ways, first using the cluster_fast command that pre-sorts the sequences by length, and then using the cluster_smallmem command that simply processes the sequences in the user-supplied order (in that case, we supplied sequences ordered by decreasing abundance using the sortbysize command). We then compared the clusters obtained to the assigned species and computed the recall, precision and the adjusted Rand index of the classifications. Recall measures to what extent amplicons assigned to the same species are grouped together in the same OTU (i.e., not over-splitting). Precision measures to what extent amplicons in an OTU are assigned to the same species (i.e., not over-grouping). The adjusted Rand index ( Rand, 1971 ; Hubert & Arabie, 1985 ) summarises both precision and recall using a measure of agreement between two clusterings while adjusting for expected values by chance. The average values over the all shufflings are presented in Figs. 2 and 3 for the even and uneven datasets, respectively. For abundance-sorted sequences, the difference between VSEARCH and USEARCH version 8 is negligible. The difference is larger for length-sorted sequences. When using length sorting, USEARCH 8 (as well as version 7 on the even dataset) shows better precision than VSEARCH for similarity levels below 93%. However, OTU delineation is usually performed at higher similarity values, typically 97%. In the case of our benchmark, overall accuracy as measured by the adjusted Rand index is maximised at 95–97% similarity. This is precisely the region where for length sorting at least VSEARCH outperforms USEARCH.” | concept_edges[4] |
| relation | recall —operationalised-as→ grouped together in the same OTU — Recall measures grouping of same-species amplicons without over-splitting. — “We independently evaluated the clustering accuracy of USEARCH and VSEARCH as described for Swarm ( Mahé et al., 2014 ) using two mock datasets, one with an even and one with uneven composition of 57 archaea and bacteria. The datasets were first dereplicated. Then the taxonomy of the unique sequences was assigned by a search against the set of rRNA reference sequences representing the species in the mock datasets, carried out with the usearch_global command of USEARCH. The sequences were shuffled randomly 10 times and clustering was performed at 20 different similarity levels ranging from 80% to 99% in steps of 1%. Clustering was carried out in two ways, first using the cluster_fast command that pre-sorts the sequences by length, and then using the cluster_smallmem command that simply processes the sequences in the user-supplied order (in that case, we supplied sequences ordered by decreasing abundance using the sortbysize command). We then compared the clusters obtained to the assigned species and computed the recall, precision and the adjusted Rand index of the classifications. Recall measures to what extent amplicons assigned to the same species are grouped together in the same OTU (i.e., not over-splitting). Precision measures to what extent amplicons in an OTU are assigned to the same species (i.e., not over-grouping). The adjusted Rand index ( Rand, 1971 ; Hubert & Arabie, 1985 ) summarises both precision and recall using a measure of agreement between two clusterings while adjusting for expected values by chance. The average values over the all shufflings are presented in Figs. 2 and 3 for the even and uneven datasets, respectively. For abundance-sorted sequences, the difference between VSEARCH and USEARCH version 8 is negligible. The difference is larger for length-sorted sequences. When using length sorting, USEARCH 8 (as well as version 7 on the even dataset) shows better precision than VSEARCH for similarity levels below 93%. However, OTU delineation is usually performed at higher similarity values, typically 97%. In the case of our benchmark, overall accuracy as measured by the adjusted Rand index is maximised at 95–97% similarity. This is precisely the region where for length sorting at least VSEARCH outperforms USEARCH.” | concept_edges[4] |
| note | precision —operationalised-as→ assigned to the same species — Direct measurement definition. — “We independently evaluated the clustering accuracy of USEARCH and VSEARCH as described for Swarm ( Mahé et al., 2014 ) using two mock datasets, one with an even and one with uneven composition of 57 archaea and bacteria. The datasets were first dereplicated. Then the taxonomy of the unique sequences was assigned by a search against the set of rRNA reference sequences representing the species in the mock datasets, carried out with the usearch_global command of USEARCH. The sequences were shuffled randomly 10 times and clustering was performed at 20 different similarity levels ranging from 80% to 99% in steps of 1%. Clustering was carried out in two ways, first using the cluster_fast command that pre-sorts the sequences by length, and then using the cluster_smallmem command that simply processes the sequences in the user-supplied order (in that case, we supplied sequences ordered by decreasing abundance using the sortbysize command). We then compared the clusters obtained to the assigned species and computed the recall, precision and the adjusted Rand index of the classifications. Recall measures to what extent amplicons assigned to the same species are grouped together in the same OTU (i.e., not over-splitting). Precision measures to what extent amplicons in an OTU are assigned to the same species (i.e., not over-grouping). The adjusted Rand index ( Rand, 1971 ; Hubert & Arabie, 1985 ) summarises both precision and recall using a measure of agreement between two clusterings while adjusting for expected values by chance. The average values over the all shufflings are presented in Figs. 2 and 3 for the even and uneven datasets, respectively. For abundance-sorted sequences, the difference between VSEARCH and USEARCH version 8 is negligible. The difference is larger for length-sorted sequences. When using length sorting, USEARCH 8 (as well as version 7 on the even dataset) shows better precision than VSEARCH for similarity levels below 93%. However, OTU delineation is usually performed at higher similarity values, typically 97%. In the case of our benchmark, overall accuracy as measured by the adjusted Rand index is maximised at 95–97% similarity. This is precisely the region where for length sorting at least VSEARCH outperforms USEARCH.” | concept_edges[5] |
| relation | precision —operationalised-as→ assigned to the same species — Precision measures keeping each OTU to one species without over-grouping. — “We independently evaluated the clustering accuracy of USEARCH and VSEARCH as described for Swarm ( Mahé et al., 2014 ) using two mock datasets, one with an even and one with uneven composition of 57 archaea and bacteria. The datasets were first dereplicated. Then the taxonomy of the unique sequences was assigned by a search against the set of rRNA reference sequences representing the species in the mock datasets, carried out with the usearch_global command of USEARCH. The sequences were shuffled randomly 10 times and clustering was performed at 20 different similarity levels ranging from 80% to 99% in steps of 1%. Clustering was carried out in two ways, first using the cluster_fast command that pre-sorts the sequences by length, and then using the cluster_smallmem command that simply processes the sequences in the user-supplied order (in that case, we supplied sequences ordered by decreasing abundance using the sortbysize command). We then compared the clusters obtained to the assigned species and computed the recall, precision and the adjusted Rand index of the classifications. Recall measures to what extent amplicons assigned to the same species are grouped together in the same OTU (i.e., not over-splitting). Precision measures to what extent amplicons in an OTU are assigned to the same species (i.e., not over-grouping). The adjusted Rand index ( Rand, 1971 ; Hubert & Arabie, 1985 ) summarises both precision and recall using a measure of agreement between two clusterings while adjusting for expected values by chance. The average values over the all shufflings are presented in Figs. 2 and 3 for the even and uneven datasets, respectively. For abundance-sorted sequences, the difference between VSEARCH and USEARCH version 8 is negligible. The difference is larger for length-sorted sequences. When using length sorting, USEARCH 8 (as well as version 7 on the even dataset) shows better precision than VSEARCH for similarity levels below 93%. However, OTU delineation is usually performed at higher similarity values, typically 97%. In the case of our benchmark, overall accuracy as measured by the adjusted Rand index is maximised at 95–97% similarity. This is precisely the region where for length sorting at least VSEARCH outperforms USEARCH.” | concept_edges[5] |
| note | de novo chimera detection —contrasted-with→ reference-based detection — Direct comparative result. — “Next, we tested reference-based ( uchime_ref ) and de novo ( uchime_denovo ) chimera detection using sequences from the 2011 version of Greengenes downloaded from http://greengenes.lbl.gov/Download/Sequence_Data/Fasta_data_files/ and from version 106 (May 2011) of the SILVA database downloaded from https://www.arb-silva.de/no_cache/download/archive/release_106/Exports/ . Sequences from the 16S rRNA V4 region was computationally extracted using the 515F (5′-GTGNCAGCMGCCGCGGTAA-3′) and 806R (5′-GGACTACHVGGGTWTCTAAT-3′) primers, and 8,000 reads were randomly selected from each database. PCR was simulated using a new simulation algorithm known as Simera ( Nichols & Quince, 2016 ) (available at https://github.com/bnichols1979/Simera ) that includes amplification and creation of PCR artefacts like chimeras. We sampled 30,000 reads (-s 30,000) and generated 20,000 potential chimeras (-c 20,000). Defaults were used for other options to Simera. The output sequences were then fed into an Illumina MiSeq noise simulator ( Schirmer et al., 2015 ) ending up with 14,966 reads based on Greengenes and 14,952 reads based on SILVA, of which 1,262 and 1,640 reads contain chimeric sequences, respectively. Next, the sequences were either clustered using the cluster_fast command at 97% identity or dereplicated. VSEARCH and USEARCH version 7 and 8 were run using the uchime_denovo command and then using the uchime_ref command with the Gold database downloaded from http://drive5.com/uchime/uchime_download.html as the reference database. To assess the performance, the results were sorted based on the chimera score, and then the ability to classify individual sequences correctly into chimeric and non-chimeric was plotted as ROC curves. The curves reflect the accuracy of classifying individual reads, not clusters, as abundances were taken into account. The plots in Figs. 5 and 6 show that de novo chimera detection performs better than reference-based detection, with the SILVA dataset in particular, but it does of course depend on the reference database used. VSEARCH performs better than both versions of USEARCH for de novo chimera detection. For reference-based detection VSEARCH also performs better for the Greengenes dataset, while none of the programs work well with the SILVA dataset. Clustering at 97% appears to be more appropriate than dereplication. In this test, the USEARCH programs were about twice as fast as VSEARCH for de novo detection, while they were about 10–30% faster than VSEARCH for reference-based detection.” | concept_edges[6] |
| relation | de novo chimera detection —contrasted-with→ reference-based detection — De novo chimera detection performs better than reference-based detection in these simulations. — “Next, we tested reference-based ( uchime_ref ) and de novo ( uchime_denovo ) chimera detection using sequences from the 2011 version of Greengenes downloaded from http://greengenes.lbl.gov/Download/Sequence_Data/Fasta_data_files/ and from version 106 (May 2011) of the SILVA database downloaded from https://www.arb-silva.de/no_cache/download/archive/release_106/Exports/ . Sequences from the 16S rRNA V4 region was computationally extracted using the 515F (5′-GTGNCAGCMGCCGCGGTAA-3′) and 806R (5′-GGACTACHVGGGTWTCTAAT-3′) primers, and 8,000 reads were randomly selected from each database. PCR was simulated using a new simulation algorithm known as Simera ( Nichols & Quince, 2016 ) (available at https://github.com/bnichols1979/Simera ) that includes amplification and creation of PCR artefacts like chimeras. We sampled 30,000 reads (-s 30,000) and generated 20,000 potential chimeras (-c 20,000). Defaults were used for other options to Simera. The output sequences were then fed into an Illumina MiSeq noise simulator ( Schirmer et al., 2015 ) ending up with 14,966 reads based on Greengenes and 14,952 reads based on SILVA, of which 1,262 and 1,640 reads contain chimeric sequences, respectively. Next, the sequences were either clustered using the cluster_fast command at 97% identity or dereplicated. VSEARCH and USEARCH version 7 and 8 were run using the uchime_denovo command and then using the uchime_ref command with the Gold database downloaded from http://drive5.com/uchime/uchime_download.html as the reference database. To assess the performance, the results were sorted based on the chimera score, and then the ability to classify individual sequences correctly into chimeric and non-chimeric was plotted as ROC curves. The curves reflect the accuracy of classifying individual reads, not clusters, as abundances were taken into account. The plots in Figs. 5 and 6 show that de novo chimera detection performs better than reference-based detection, with the SILVA dataset in particular, but it does of course depend on the reference database used. VSEARCH performs better than both versions of USEARCH for de novo chimera detection. For reference-based detection VSEARCH also performs better for the Greengenes dataset, while none of the programs work well with the SILVA dataset. Clustering at 97% appears to be more appropriate than dereplication. In this test, the USEARCH programs were about twice as fast as VSEARCH for de novo detection, while they were about 10–30% faster than VSEARCH for reference-based detection.” | concept_edges[6] |
| weight | de novo chimera detection —contrasted-with→ reference-based detection — 0.95 — “Next, we tested reference-based ( uchime_ref ) and de novo ( uchime_denovo ) chimera detection using sequences from the 2011 version of Greengenes downloaded from http://greengenes.lbl.gov/Download/Sequence_Data/Fasta_data_files/ and from version 106 (May 2011) of the SILVA database downloaded from https://www.arb-silva.de/no_cache/download/archive/release_106/Exports/ . Sequences from the 16S rRNA V4 region was computationally extracted using the 515F (5′-GTGNCAGCMGCCGCGGTAA-3′) and 806R (5′-GGACTACHVGGGTWTCTAAT-3′) primers, and 8,000 reads were randomly selected from each database. PCR was simulated using a new simulation algorithm known as Simera ( Nichols & Quince, 2016 ) (available at https://github.com/bnichols1979/Simera ) that includes amplification and creation of PCR artefacts like chimeras. We sampled 30,000 reads (-s 30,000) and generated 20,000 potential chimeras (-c 20,000). Defaults were used for other options to Simera. The output sequences were then fed into an Illumina MiSeq noise simulator ( Schirmer et al., 2015 ) ending up with 14,966 reads based on Greengenes and 14,952 reads based on SILVA, of which 1,262 and 1,640 reads contain chimeric sequences, respectively. Next, the sequences were either clustered using the cluster_fast command at 97% identity or dereplicated. VSEARCH and USEARCH version 7 and 8 were run using the uchime_denovo command and then using the uchime_ref command with the Gold database downloaded from http://drive5.com/uchime/uchime_download.html as the reference database. To assess the performance, the results were sorted based on the chimera score, and then the ability to classify individual sequences correctly into chimeric and non-chimeric was plotted as ROC curves. The curves reflect the accuracy of classifying individual reads, not clusters, as abundances were taken into account. The plots in Figs. 5 and 6 show that de novo chimera detection performs better than reference-based detection, with the SILVA dataset in particular, but it does of course depend on the reference database used. VSEARCH performs better than both versions of USEARCH for de novo chimera detection. For reference-based detection VSEARCH also performs better for the Greengenes dataset, while none of the programs work well with the SILVA dataset. Clustering at 97% appears to be more appropriate than dereplication. In this test, the USEARCH programs were about twice as fast as VSEARCH for de novo detection, while they were about 10–30% faster than VSEARCH for reference-based detection.” | concept_edges[6] |
| outcome | control — held — “The performance of the most important functions of VSEARCH version 2.0.3 (64-bit) was evaluated and compared to the 32-bit versions of USEARCH version 7.0.1090 and 8.1.1861. All datasets used were small enough to fit comfortably in the memory allocated to a 32-bit process. Chimera detection was also compared to UCHIME version 4.2. All tests were run on GNU/Linux CentOS 6.7 compute nodes with 16 physical cores (Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60 GHz) and 64GB RAM. Programs were run with 8 threads, if possible. All times indicated are wall-clock times. All scripts and data necessary to perform the evaluations are available in the GitHub repository at https://github.com/torognes/vsearch-eval/ to enable independent replication.” | controls[0] |
| outcome | control — held — “The performance of the most important functions of VSEARCH version 2.0.3 (64-bit) was evaluated and compared to the 32-bit versions of USEARCH version 7.0.1090 and 8.1.1861. All datasets used were small enough to fit comfortably in the memory allocated to a 32-bit process. Chimera detection was also compared to UCHIME version 4.2. All tests were run on GNU/Linux CentOS 6.7 compute nodes with 16 physical cores (Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60 GHz) and 64GB RAM. Programs were run with 8 threads, if possible. All times indicated are wall-clock times. All scripts and data necessary to perform the evaluations are available in the GitHub repository at https://github.com/torognes/vsearch-eval/ to enable independent replication.” | controls[1] |
| outcome | control — held — “Evaluation of search accuracy was carried out as described in the USEARCH paper ( Edgar, 2010 ), its supplementary, and on the website ( http://drive5.com/usearch/benchmark_rfam.html ), by assessing the ability of the programs to identify RNA sequences belonging to the same family in RFAM ( Burge et al., 2013 ). The 383,004 sequences in Rfam version 11 were randomly shuffled and then the first sequence from each of the 2,085 (out of 2,208) families that contained at least 2 members was selected as a representative and used as a query against the remaining 380,919 sequences. The programs were run with options id 0.0, minseqlength 1, maxaccepts 1, maxrejects 32, and strand plus. If the matching sequence found belonged to the same family, it was considered a true positive, otherwise it was considered as a false positive. We combined the results from 20 shufflings and plotted the results in the ROC-like curve shown in Fig. 1 . For a false discovery rate between 0.010 and 0.015, VSEARCH is more accurate than USEARCH’s latest version. For lower values, the three programs have similar accuracies. At higher false discovery rates, USEARCH version 8 has an advantage.” | controls[2] |
| outcome | control — held — “The time to search the Rfam database as described above was measured. To avoid extremely short running times, 1,000 replicates of the datasets were used. USEARCH version 7 required on average 5 min 29 s for the search, USEARCH version 8 took 5 min 57 s, while VSEARCH took 5 min 26 s.” | controls[3] |
| outcome | control — held — “We independently evaluated the clustering accuracy of USEARCH and VSEARCH as described for Swarm ( Mahé et al., 2014 ) using two mock datasets, one with an even and one with uneven composition of 57 archaea and bacteria. The datasets were first dereplicated. Then the taxonomy of the unique sequences was assigned by a search against the set of rRNA reference sequences representing the species in the mock datasets, carried out with the usearch_global command of USEARCH. The sequences were shuffled randomly 10 times and clustering was performed at 20 different similarity levels ranging from 80% to 99% in steps of 1%. Clustering was carried out in two ways, first using the cluster_fast command that pre-sorts the sequences by length, and then using the cluster_smallmem command that simply processes the sequences in the user-supplied order (in that case, we supplied sequences ordered by decreasing abundance using the sortbysize command). We then compared the clusters obtained to the assigned species and computed the recall, precision and the adjusted Rand index of the classifications. Recall measures to what extent amplicons assigned to the same species are grouped together in the same OTU (i.e., not over-splitting). Precision measures to what extent amplicons in an OTU are assigned to the same species (i.e., not over-grouping). The adjusted Rand index ( Rand, 1971 ; Hubert & Arabie, 1985 ) summarises both precision and recall using a measure of agreement between two clusterings while adjusting for expected values by chance. The average values over the all shufflings are presented in Figs. 2 and 3 for the even and uneven datasets, respectively. For abundance-sorted sequences, the difference between VSEARCH and USEARCH version 8 is negligible. The difference is larger for length-sorted sequences. When using length sorting, USEARCH 8 (as well as version 7 on the even dataset) shows better precision than VSEARCH for similarity levels below 93%. However, OTU delineation is usually performed at higher similarity values, typically 97%. In the case of our benchmark, overall accuracy as measured by the adjusted Rand index is maximised at 95–97% similarity. This is precisely the region where for length sorting at least VSEARCH outperforms USEARCH.” | controls[4] |
| outcome | control — held — “We evaluated the chimera detection accuracy of VSEARCH and USEARCH in two ways, first using a method similar to that performed for UCHIME, and then using a new chimera simulation procedure based on sequences from Greengenes ( DeSantis et al., 2006 ) and SILVA ( Quast et al., 2013 ) sequences.” — “Next, we tested reference-based ( uchime_ref ) and de novo ( uchime_denovo ) chimera detection using sequences from the 2011 version of Greengenes downloaded from http://greengenes.lbl.gov/Download/Sequence_Data/Fasta_data_files/ and from version 106 (May 2011) of the SILVA database downloaded from https://www.arb-silva.de/no_cache/download/archive/release_106/Exports/ . Sequences from the 16S rRNA V4 region was computationally extracted using the 515F (5′-GTGNCAGCMGCCGCGGTAA-3′) and 806R (5′-GGACTACHVGGGTWTCTAAT-3′) primers, and 8,000 reads were randomly selected from each database. PCR was simulated using a new simulation algorithm known as Simera ( Nichols & Quince, 2016 ) (available at https://github.com/bnichols1979/Simera ) that includes amplification and creation of PCR artefacts like chimeras. We sampled 30,000 reads (-s 30,000) and generated 20,000 potential chimeras (-c 20,000). Defaults were used for other options to Simera. The output sequences were then fed into an Illumina MiSeq noise simulator ( Schirmer et al., 2015 ) ending up with 14,966 reads based on Greengenes and 14,952 reads based on SILVA, of which 1,262 and 1,640 reads contain chimeric sequences, respectively. Next, the sequences were either clustered using the cluster_fast command at 97% identity or dereplicated. VSEARCH and USEARCH version 7 and 8 were run using the uchime_denovo command and then using the uchime_ref command with the Gold database downloaded from http://drive5.com/uchime/uchime_download.html as the reference database. To assess the performance, the results were sorted based on the chimera score, and then the ability to classify individual sequences correctly into chimeric and non-chimeric was plotted as ROC curves. The curves reflect the accuracy of classifying individual reads, not clusters, as abundances were taken into account. The plots in Figs. 5 and 6 show that de novo chimera detection performs better than reference-based detection, with the SILVA dataset in particular, but it does of course depend on the reference database used. VSEARCH performs better than both versions of USEARCH for de novo chimera detection. For reference-based detection VSEARCH also performs better for the Greengenes dataset, while none of the programs work well with the SILVA dataset. Clustering at 97% appears to be more appropriate than dereplication. In this test, the USEARCH programs were about twice as fast as VSEARCH for de novo detection, while they were about 10–30% faster than VSEARCH for reference-based detection.” | controls[5] |
| outcome | control — held — “Evaluation of paired-end reads merging performance was carried out in a manner similar to that described for the evaluation of PEAR ( Zhang et al., 2014 ). We used whole genome sequencing data from Staphylococcus aureus subspecies aureus strain USA 300 TCH 1516 sequenced by MacCallum et al. (2009) and retrieved from the GAGE-B repository ( http://ccb.jhu.edu/gage_b/ ). The S.aureus reads were 101 bp long from on average 180 bp long fragments, giving a 45X coverage of the genome. We also used Methylococcus capsulatus strain Bath 16S rRNA V3 region amplicon reads sequenced by Masella et al. (2012) . These reads were 108 bp long and the pairs should have an overlap of exactly 18 bp. Merging options were set to allow a minimum overlap of 10 bp and a maximum of 5 mismatches (USEARCH 7 and 8 have different default values for those), while other options were left at defaults. All programs were run with 8 threads. Merged sequences that could be perfectly aligned to their respective reference sequences (either the entire genome or the specific rRNA region) using BWA MEM ( Li & Durbin, 2009 ) were considered correctly merged. The results are shown in Table 2 . The numbers indicate that USEARCH version 7 merges the most reads for both bacteria, but also has the lowest percentage of correctly merged pairs of those merged. USEARCH version 8 merges the fewest reads, but has the highest percentage of correctly merged reads of those merged. VSEARCH is in the middle by merging more reads than USEARCH 8 with only a small decrease in the percentage of correct merges. VSEARCH is about twice as fast as USEARCH 8 and 4–5 times faster than USEARCH version 7.” | controls[6] |
| outcome | control — held — “We evaluated the subsampling commands of USEARCH version 8 and VSEARCH to check if the results obtained correspond to those expected. We performed 10,000 random subsamplings of 5% of the 9.5 million unique sequences in the TARA V9 dataset ( Karsenti et al., 2011 ). To make this possible with the 32-bit USEARCH, we first downsampled the dataset once to 10% using VSEARCH and then randomly subsampled it again at 50% with either USEARCH or VSEARCH. Plots of the distribution of the abundance of the most abundant sequence in each subsampling are shown in Fig. 7 . The highest amplicon abundance in the original dataset is 15,638,316. After the initial 10% subsampling, the highest abundance was 1,564,267. After the second subsampling, the top abundances should therefore have a distribution centred on a value of 782,133.5. As can be seen from the figure, the USEARCH distribution has a mean that is about 2,000 too small, while the VSEARCH distribution is correctly centred on the expected value. Subsampling experiments were also performed at 2.5%, 1.5% and 0.5% with similar results, although the errors were of decreasing size. USEARCH seems to under-sample abundant amplicons and to over-sample rare amplicons.” | controls[7] |
| relation | database sequence → similarity equal to or greater than the value specified with the id option — A database sequence is accepted when similarity meets or exceeds the id threshold. — “If the resulting alignment indicates a similarity equal to or greater than the value specified with the id option, the database sequence is accepted. If the similarity is too low, it is rejected. Several other options may also be used to determine how similarity is computed ( iddef , as USEARCH used to offer up to version 6), and which sequences should be accepted and rejected, either before (e.g., self , minqsize ) or after alignment (e.g., maxgaps , maxsubs ). The search is terminated when either a certain number of sequences have been accepted (1 by default, adjustable with the maxaccepts option), or a certain number of sequences have been rejected (32 by default, adjustable with the maxrejects option). The accepted sequences are sorted by sequence similarity and presented as the search results.” | unhoused_relations[0] |
| relation | shared words → database sequence — Shared-word counts identify promising database candidates before alignment. — “The first phase is presumably quite similar to USEARCH ( Edgar, 2010 ). Heuristics are used to identify a small set of database sequences that have many words in common with the query sequence. Words (or k -mers) consist of a certain number k of consecutive nucleotides of a sequence (8 by default, adjustable with the wordlength option). All overlapping words are included. A sequence of length n then contains at most n − k + 1 unique words. VSEARCH counts the number of shared words between the query and each database sequence. Words that appear multiple times are counted only once. To count the words in the database sequences quickly, VSEARCH creates an index of all the 4 k possible distinct words and stores information about which database sequences they appear in. For extremely frequent words, the set of database sequences is represented by a bitmap; otherwise the set is stored as a list. A finer control of k -mer indexing is described for USEARCH by the pattern (binary string indicating which positions must match) and slots options. USEARCH has such options but seems to ignore them. Currently, VSEARCH ignores these two options too. The minimum number of shared words required may be specified with the minwordmatches option (10 by default), but a lower value is automatically used for short or simple query sequences with less than 10 unique words.” | unhoused_relations[1] |
| weight | shared words → database sequence — 0.95 — “The first phase is presumably quite similar to USEARCH ( Edgar, 2010 ). Heuristics are used to identify a small set of database sequences that have many words in common with the query sequence. Words (or k -mers) consist of a certain number k of consecutive nucleotides of a sequence (8 by default, adjustable with the wordlength option). All overlapping words are included. A sequence of length n then contains at most n − k + 1 unique words. VSEARCH counts the number of shared words between the query and each database sequence. Words that appear multiple times are counted only once. To count the words in the database sequences quickly, VSEARCH creates an index of all the 4 k possible distinct words and stores information about which database sequences they appear in. For extremely frequent words, the set of database sequences is represented by a bitmap; otherwise the set is stored as a list. A finer control of k -mer indexing is described for USEARCH by the pattern (binary string indicating which positions must match) and slots options. USEARCH has such options but seems to ignore them. Currently, VSEARCH ignores these two options too. The minimum number of shared words required may be specified with the minwordmatches option (10 by default), but a lower value is automatically used for short or simple query sequences with less than 10 unique words.” | unhoused_relations[1] |
| relation | full dynamic programming → optimal global alignment — Full dynamic programming computes optimal pairwise alignments. — “In the second phase, searching proceeds by considering the database sequences in a specific order, starting with the sequence having the largest number of words in common with the query, and proceeding with a decreasing number of shared words. If two database sequences have the same number of words in common with the query, the shortest sequence is considered first. The query sequence is compared with each database sequence by computing the optimal global alignment. The alignment is performed using a multi-threaded and vectorised full dynamic programming algorithm ( Needleman & Wunsch, 1970 ) adapted from SWIPE ( Rognes, 2011 ). Due to the extreme memory requirements of this method when aligning two long sequences, an alternative algorithm described by Hirschberg (1975) and Myers & Miller (1988) is used when the product of the length of the sequences is greater than 25,000,000, corresponding to aligning two 5,000 bp sequences. This alternative algorithm uses only a linear amount of memory but is considerably slower. This second phase is probably where USEARCH and VSEARCH differ the most, as USEARCH by default presumably performs heuristic seed-and-extend alignment similar to BLAST ( Altschul et al., 1997 ), and only performs optimal alignment when the option fulldp (full dynamic programming) is used. Computing the optimal pairwise alignment in each case gives more accurate results but is also computationally more demanding. The efficient and vectorised full dynamic programming implementation in VSEARCH compensates that extra cost, at least for sequences that are not too long.” | unhoused_relations[2] |
| relation | full dynamic programming → memory — Exact alignment of long sequences can require extreme memory. — “In the second phase, searching proceeds by considering the database sequences in a specific order, starting with the sequence having the largest number of words in common with the query, and proceeding with a decreasing number of shared words. If two database sequences have the same number of words in common with the query, the shortest sequence is considered first. The query sequence is compared with each database sequence by computing the optimal global alignment. The alignment is performed using a multi-threaded and vectorised full dynamic programming algorithm ( Needleman & Wunsch, 1970 ) adapted from SWIPE ( Rognes, 2011 ). Due to the extreme memory requirements of this method when aligning two long sequences, an alternative algorithm described by Hirschberg (1975) and Myers & Miller (1988) is used when the product of the length of the sequences is greater than 25,000,000, corresponding to aligning two 5,000 bp sequences. This alternative algorithm uses only a linear amount of memory but is considerably slower. This second phase is probably where USEARCH and VSEARCH differ the most, as USEARCH by default presumably performs heuristic seed-and-extend alignment similar to BLAST ( Altschul et al., 1997 ), and only performs optimal alignment when the option fulldp (full dynamic programming) is used. Computing the optimal pairwise alignment in each case gives more accurate results but is also computationally more demanding. The efficient and vectorised full dynamic programming implementation in VSEARCH compensates that extra cost, at least for sequences that are not too long.” | unhoused_relations[3] |
| weight | full dynamic programming → memory — 0.95 — “In the second phase, searching proceeds by considering the database sequences in a specific order, starting with the sequence having the largest number of words in common with the query, and proceeding with a decreasing number of shared words. If two database sequences have the same number of words in common with the query, the shortest sequence is considered first. The query sequence is compared with each database sequence by computing the optimal global alignment. The alignment is performed using a multi-threaded and vectorised full dynamic programming algorithm ( Needleman & Wunsch, 1970 ) adapted from SWIPE ( Rognes, 2011 ). Due to the extreme memory requirements of this method when aligning two long sequences, an alternative algorithm described by Hirschberg (1975) and Myers & Miller (1988) is used when the product of the length of the sequences is greater than 25,000,000, corresponding to aligning two 5,000 bp sequences. This alternative algorithm uses only a linear amount of memory but is considerably slower. This second phase is probably where USEARCH and VSEARCH differ the most, as USEARCH by default presumably performs heuristic seed-and-extend alignment similar to BLAST ( Altschul et al., 1997 ), and only performs optimal alignment when the option fulldp (full dynamic programming) is used. Computing the optimal pairwise alignment in each case gives more accurate results but is also computationally more demanding. The efficient and vectorised full dynamic programming implementation in VSEARCH compensates that extra cost, at least for sequences that are not too long.” | unhoused_relations[3] |
| relation | vectorisation → full dynamic programming — Vectorisation compensates part of exact alignment's computational cost. — “In the second phase, searching proceeds by considering the database sequences in a specific order, starting with the sequence having the largest number of words in common with the query, and proceeding with a decreasing number of shared words. If two database sequences have the same number of words in common with the query, the shortest sequence is considered first. The query sequence is compared with each database sequence by computing the optimal global alignment. The alignment is performed using a multi-threaded and vectorised full dynamic programming algorithm ( Needleman & Wunsch, 1970 ) adapted from SWIPE ( Rognes, 2011 ). Due to the extreme memory requirements of this method when aligning two long sequences, an alternative algorithm described by Hirschberg (1975) and Myers & Miller (1988) is used when the product of the length of the sequences is greater than 25,000,000, corresponding to aligning two 5,000 bp sequences. This alternative algorithm uses only a linear amount of memory but is considerably slower. This second phase is probably where USEARCH and VSEARCH differ the most, as USEARCH by default presumably performs heuristic seed-and-extend alignment similar to BLAST ( Altschul et al., 1997 ), and only performs optimal alignment when the option fulldp (full dynamic programming) is used. Computing the optimal pairwise alignment in each case gives more accurate results but is also computationally more demanding. The efficient and vectorised full dynamic programming implementation in VSEARCH compensates that extra cost, at least for sequences that are not too long.” | unhoused_relations[4] |
| weight | vectorisation → full dynamic programming — 0.95 — “In the second phase, searching proceeds by considering the database sequences in a specific order, starting with the sequence having the largest number of words in common with the query, and proceeding with a decreasing number of shared words. If two database sequences have the same number of words in common with the query, the shortest sequence is considered first. The query sequence is compared with each database sequence by computing the optimal global alignment. The alignment is performed using a multi-threaded and vectorised full dynamic programming algorithm ( Needleman & Wunsch, 1970 ) adapted from SWIPE ( Rognes, 2011 ). Due to the extreme memory requirements of this method when aligning two long sequences, an alternative algorithm described by Hirschberg (1975) and Myers & Miller (1988) is used when the product of the length of the sequences is greater than 25,000,000, corresponding to aligning two 5,000 bp sequences. This alternative algorithm uses only a linear amount of memory but is considerably slower. This second phase is probably where USEARCH and VSEARCH differ the most, as USEARCH by default presumably performs heuristic seed-and-extend alignment similar to BLAST ( Altschul et al., 1997 ), and only performs optimal alignment when the option fulldp (full dynamic programming) is used. Computing the optimal pairwise alignment in each case gives more accurate results but is also computationally more demanding. The efficient and vectorised full dynamic programming implementation in VSEARCH compensates that extra cost, at least for sequences that are not too long.” | unhoused_relations[4] |
| relation | sequence similarity threshold → centroid-based algorithm — The threshold determines whether a query joins a centroid or creates a new cluster. — “VSEARCH includes commands to perform de novo clustering using a greedy and heuristic centroid-based algorithm with an adjustable sequence similarity threshold specified with the id option (e.g., 0.97). The input sequences are either processed in the user supplied order ( cluster_smallmem ) or pre-sorted based on length ( cluster_fast ) or abundance (the new cluster_size option). Each input sequence is then used as a query in a search against an initially empty database of centroid sequences. The query sequence is clustered with the first centroid sequence found with similarity equal to or above the threshold. The search is performed using the heuristic approach described above which generally finds the most similar sequences first. If no matches are found, the query sequence becomes the centroid of a new cluster and is added to the database. If maxaccepts is higher than 1, several centroids with sufficient sequence similarity may be found and considered. By default, the query is clustered with the centroid presenting the highest sequence similarity (distance-based greedy clustering, DGC), or, if the sizeorder option is turned on, the centroid with the highest abundance (abundance-based greedy clustering, AGC) ( He et al., 2015 ; Westcott & Schloss, 2015 ; Schloss, 2016 ). VSEARCH performs multi-threaded clustering by searching the database of centroid sequences with several query sequences in parallel. If there are any non-matching query sequences giving rise to new centroids, the required internal comparisons between the query sequences are subsequently performed to achieve correct results. For each cluster, VSEARCH can create a simple multiple sequence alignment using the center star method ( Gusfield, 1993 ) with the centroid as the center sequence, and then compute a consensus sequence and a sequence profile.” | unhoused_relations[5] |
| weight | sequence similarity threshold → centroid-based algorithm — 0.95 — “VSEARCH includes commands to perform de novo clustering using a greedy and heuristic centroid-based algorithm with an adjustable sequence similarity threshold specified with the id option (e.g., 0.97). The input sequences are either processed in the user supplied order ( cluster_smallmem ) or pre-sorted based on length ( cluster_fast ) or abundance (the new cluster_size option). Each input sequence is then used as a query in a search against an initially empty database of centroid sequences. The query sequence is clustered with the first centroid sequence found with similarity equal to or above the threshold. The search is performed using the heuristic approach described above which generally finds the most similar sequences first. If no matches are found, the query sequence becomes the centroid of a new cluster and is added to the database. If maxaccepts is higher than 1, several centroids with sufficient sequence similarity may be found and considered. By default, the query is clustered with the centroid presenting the highest sequence similarity (distance-based greedy clustering, DGC), or, if the sizeorder option is turned on, the centroid with the highest abundance (abundance-based greedy clustering, AGC) ( He et al., 2015 ; Westcott & Schloss, 2015 ; Schloss, 2016 ). VSEARCH performs multi-threaded clustering by searching the database of centroid sequences with several query sequences in parallel. If there are any non-matching query sequences giving rise to new centroids, the required internal comparisons between the query sequences are subsequently performed to achieve correct results. For each cluster, VSEARCH can create a simple multiple sequence alignment using the center star method ( Gusfield, 1993 ) with the centroid as the center sequence, and then compute a consensus sequence and a sequence profile.” | unhoused_relations[5] |
| relation | Dust algorithm → low-complexity nucleotide sequences — DUST masks low-complexity sequence regions before comparison. — “VSEARCH includes a highly optimized and parallelized implementation of the Dust algorithm by Tatusov and Lipman for masking of simple repeats and low-complexity nucleotide sequences. It is considerably faster than the implementation of the same algorithm in USEARCH. Their code available at ftp://ftp.ncbi.nlm.nih.gov/pub/tatusov/dust/version1/src/ is in the public domain. VSEARCH uses this algorithm by default, while USEARCH by default uses an undocumented rapid masking algorithm called fastnucleo . VSEARCH performs soft-masking automatically for the pairwise alignment, search, clustering and chimera detection commands. This behaviour can be controlled with the hardmask option to replace masked symbols with N’s instead of lower-casing them, and the dbmask and qmask options, which selects the masking algorithm (none, dust or soft) used for the database and query sequences, respectively. Masking may also be performed explicitly on an input file using the fastx_mask and maskfasta commands.” | unhoused_relations[6] |
| weight | Dust algorithm → low-complexity nucleotide sequences — 0.95 — “VSEARCH includes a highly optimized and parallelized implementation of the Dust algorithm by Tatusov and Lipman for masking of simple repeats and low-complexity nucleotide sequences. It is considerably faster than the implementation of the same algorithm in USEARCH. Their code available at ftp://ftp.ncbi.nlm.nih.gov/pub/tatusov/dust/version1/src/ is in the public domain. VSEARCH uses this algorithm by default, while USEARCH by default uses an undocumented rapid masking algorithm called fastnucleo . VSEARCH performs soft-masking automatically for the pairwise alignment, search, clustering and chimera detection commands. This behaviour can be controlled with the hardmask option to replace masked symbols with N’s instead of lower-casing them, and the dbmask and qmask options, which selects the masking algorithm (none, dust or soft) used for the database and query sequences, respectively. Masking may also be performed explicitly on an input file using the fastx_mask and maskfasta commands.” | unhoused_relations[6] |
| relation | USEARCH → memory — The free 32-bit USEARCH build limits memory to under 4 GB. — “VSEARCH is a 64-bit program and allows very large datasets to be processed, essentially limited only by the amount of memory available. The free USEARCH versions are 32-bit programs that limit the available memory to somewhere less than 4GB, often seriously hampering the analysis of realistic datasets.” | unhoused_relations[7] |
| weight | USEARCH → memory — 0.95 — “VSEARCH is a 64-bit program and allows very large datasets to be processed, essentially limited only by the amount of memory available. The free USEARCH versions are 32-bit programs that limit the available memory to somewhere less than 4GB, often seriously hampering the analysis of realistic datasets.” | unhoused_relations[7] |
| relation | clustering threshold → time used — Clustering runtime depends on dataset, algorithm, and threshold. — “The time used for clustering is shown in Fig. 4 . The time used depended on the dataset, algorithm and clustering threshold. The USEARCH programs were in general 2–3 times faster than VSEARCH. In general the difference in speed was smaller for higher thresholds, especially at 99% similarity. Clustering with USEARCH using the fulldp option is an order of magnitude slower than VSEARCH, but contrary to our expectations it does not seem to improve accuracy.” | unhoused_relations[8] |
| weight | clustering threshold → time used — 0.95 — “The time used for clustering is shown in Fig. 4 . The time used depended on the dataset, algorithm and clustering threshold. The USEARCH programs were in general 2–3 times faster than VSEARCH. In general the difference in speed was smaller for higher thresholds, especially at 99% similarity. Clustering with USEARCH using the fulldp option is an order of magnitude slower than VSEARCH, but contrary to our expectations it does not seem to improve accuracy.” | unhoused_relations[8] |
| relation | reference-based detection → SILVA — Reference-based chimera detection performs poorly on the SILVA simulation. — “Next, we tested reference-based ( uchime_ref ) and de novo ( uchime_denovo ) chimera detection using sequences from the 2011 version of Greengenes downloaded from http://greengenes.lbl.gov/Download/Sequence_Data/Fasta_data_files/ and from version 106 (May 2011) of the SILVA database downloaded from https://www.arb-silva.de/no_cache/download/archive/release_106/Exports/ . Sequences from the 16S rRNA V4 region was computationally extracted using the 515F (5′-GTGNCAGCMGCCGCGGTAA-3′) and 806R (5′-GGACTACHVGGGTWTCTAAT-3′) primers, and 8,000 reads were randomly selected from each database. PCR was simulated using a new simulation algorithm known as Simera ( Nichols & Quince, 2016 ) (available at https://github.com/bnichols1979/Simera ) that includes amplification and creation of PCR artefacts like chimeras. We sampled 30,000 reads (-s 30,000) and generated 20,000 potential chimeras (-c 20,000). Defaults were used for other options to Simera. The output sequences were then fed into an Illumina MiSeq noise simulator ( Schirmer et al., 2015 ) ending up with 14,966 reads based on Greengenes and 14,952 reads based on SILVA, of which 1,262 and 1,640 reads contain chimeric sequences, respectively. Next, the sequences were either clustered using the cluster_fast command at 97% identity or dereplicated. VSEARCH and USEARCH version 7 and 8 were run using the uchime_denovo command and then using the uchime_ref command with the Gold database downloaded from http://drive5.com/uchime/uchime_download.html as the reference database. To assess the performance, the results were sorted based on the chimera score, and then the ability to classify individual sequences correctly into chimeric and non-chimeric was plotted as ROC curves. The curves reflect the accuracy of classifying individual reads, not clusters, as abundances were taken into account. The plots in Figs. 5 and 6 show that de novo chimera detection performs better than reference-based detection, with the SILVA dataset in particular, but it does of course depend on the reference database used. VSEARCH performs better than both versions of USEARCH for de novo chimera detection. For reference-based detection VSEARCH also performs better for the Greengenes dataset, while none of the programs work well with the SILVA dataset. Clustering at 97% appears to be more appropriate than dereplication. In this test, the USEARCH programs were about twice as fast as VSEARCH for de novo detection, while they were about 10–30% faster than VSEARCH for reference-based detection.” | unhoused_relations[9] |
| weight | reference-based detection → SILVA — 0.95 — “Next, we tested reference-based ( uchime_ref ) and de novo ( uchime_denovo ) chimera detection using sequences from the 2011 version of Greengenes downloaded from http://greengenes.lbl.gov/Download/Sequence_Data/Fasta_data_files/ and from version 106 (May 2011) of the SILVA database downloaded from https://www.arb-silva.de/no_cache/download/archive/release_106/Exports/ . Sequences from the 16S rRNA V4 region was computationally extracted using the 515F (5′-GTGNCAGCMGCCGCGGTAA-3′) and 806R (5′-GGACTACHVGGGTWTCTAAT-3′) primers, and 8,000 reads were randomly selected from each database. PCR was simulated using a new simulation algorithm known as Simera ( Nichols & Quince, 2016 ) (available at https://github.com/bnichols1979/Simera ) that includes amplification and creation of PCR artefacts like chimeras. We sampled 30,000 reads (-s 30,000) and generated 20,000 potential chimeras (-c 20,000). Defaults were used for other options to Simera. The output sequences were then fed into an Illumina MiSeq noise simulator ( Schirmer et al., 2015 ) ending up with 14,966 reads based on Greengenes and 14,952 reads based on SILVA, of which 1,262 and 1,640 reads contain chimeric sequences, respectively. Next, the sequences were either clustered using the cluster_fast command at 97% identity or dereplicated. VSEARCH and USEARCH version 7 and 8 were run using the uchime_denovo command and then using the uchime_ref command with the Gold database downloaded from http://drive5.com/uchime/uchime_download.html as the reference database. To assess the performance, the results were sorted based on the chimera score, and then the ability to classify individual sequences correctly into chimeric and non-chimeric was plotted as ROC curves. The curves reflect the accuracy of classifying individual reads, not clusters, as abundances were taken into account. The plots in Figs. 5 and 6 show that de novo chimera detection performs better than reference-based detection, with the SILVA dataset in particular, but it does of course depend on the reference database used. VSEARCH performs better than both versions of USEARCH for de novo chimera detection. For reference-based detection VSEARCH also performs better for the Greengenes dataset, while none of the programs work well with the SILVA dataset. Clustering at 97% appears to be more appropriate than dereplication. In this test, the USEARCH programs were about twice as fast as VSEARCH for de novo detection, while they were about 10–30% faster than VSEARCH for reference-based detection.” | unhoused_relations[9] |
| relation | VSEARCH → abundant amplicons — VSEARCH subsampling preserves the expected abundance center. — “We evaluated the subsampling commands of USEARCH version 8 and VSEARCH to check if the results obtained correspond to those expected. We performed 10,000 random subsamplings of 5% of the 9.5 million unique sequences in the TARA V9 dataset ( Karsenti et al., 2011 ). To make this possible with the 32-bit USEARCH, we first downsampled the dataset once to 10% using VSEARCH and then randomly subsampled it again at 50% with either USEARCH or VSEARCH. Plots of the distribution of the abundance of the most abundant sequence in each subsampling are shown in Fig. 7 . The highest amplicon abundance in the original dataset is 15,638,316. After the initial 10% subsampling, the highest abundance was 1,564,267. After the second subsampling, the top abundances should therefore have a distribution centred on a value of 782,133.5. As can be seen from the figure, the USEARCH distribution has a mean that is about 2,000 too small, while the VSEARCH distribution is correctly centred on the expected value. Subsampling experiments were also performed at 2.5%, 1.5% and 0.5% with similar results, although the errors were of decreasing size. USEARCH seems to under-sample abundant amplicons and to over-sample rare amplicons.” | unhoused_relations[10] |
| weight | VSEARCH → abundant amplicons — 0.95 — “We evaluated the subsampling commands of USEARCH version 8 and VSEARCH to check if the results obtained correspond to those expected. We performed 10,000 random subsamplings of 5% of the 9.5 million unique sequences in the TARA V9 dataset ( Karsenti et al., 2011 ). To make this possible with the 32-bit USEARCH, we first downsampled the dataset once to 10% using VSEARCH and then randomly subsampled it again at 50% with either USEARCH or VSEARCH. Plots of the distribution of the abundance of the most abundant sequence in each subsampling are shown in Fig. 7 . The highest amplicon abundance in the original dataset is 15,638,316. After the initial 10% subsampling, the highest abundance was 1,564,267. After the second subsampling, the top abundances should therefore have a distribution centred on a value of 782,133.5. As can be seen from the figure, the USEARCH distribution has a mean that is about 2,000 too small, while the VSEARCH distribution is correctly centred on the expected value. Subsampling experiments were also performed at 2.5%, 1.5% and 0.5% with similar results, although the errors were of decreasing size. USEARCH seems to under-sample abundant amplicons and to over-sample rare amplicons.” | unhoused_relations[10] |
| relation | USEARCH → abundant amplicons — USEARCH appears to under-sample abundant amplicons. — “We evaluated the subsampling commands of USEARCH version 8 and VSEARCH to check if the results obtained correspond to those expected. We performed 10,000 random subsamplings of 5% of the 9.5 million unique sequences in the TARA V9 dataset ( Karsenti et al., 2011 ). To make this possible with the 32-bit USEARCH, we first downsampled the dataset once to 10% using VSEARCH and then randomly subsampled it again at 50% with either USEARCH or VSEARCH. Plots of the distribution of the abundance of the most abundant sequence in each subsampling are shown in Fig. 7 . The highest amplicon abundance in the original dataset is 15,638,316. After the initial 10% subsampling, the highest abundance was 1,564,267. After the second subsampling, the top abundances should therefore have a distribution centred on a value of 782,133.5. As can be seen from the figure, the USEARCH distribution has a mean that is about 2,000 too small, while the VSEARCH distribution is correctly centred on the expected value. Subsampling experiments were also performed at 2.5%, 1.5% and 0.5% with similar results, although the errors were of decreasing size. USEARCH seems to under-sample abundant amplicons and to over-sample rare amplicons.” | unhoused_relations[11] |
| weight | USEARCH → abundant amplicons — 0.95 — “We evaluated the subsampling commands of USEARCH version 8 and VSEARCH to check if the results obtained correspond to those expected. We performed 10,000 random subsamplings of 5% of the 9.5 million unique sequences in the TARA V9 dataset ( Karsenti et al., 2011 ). To make this possible with the 32-bit USEARCH, we first downsampled the dataset once to 10% using VSEARCH and then randomly subsampled it again at 50% with either USEARCH or VSEARCH. Plots of the distribution of the abundance of the most abundant sequence in each subsampling are shown in Fig. 7 . The highest amplicon abundance in the original dataset is 15,638,316. After the initial 10% subsampling, the highest abundance was 1,564,267. After the second subsampling, the top abundances should therefore have a distribution centred on a value of 782,133.5. As can be seen from the figure, the USEARCH distribution has a mean that is about 2,000 too small, while the VSEARCH distribution is correctly centred on the expected value. Subsampling experiments were also performed at 2.5%, 1.5% and 0.5% with similar results, although the errors were of decreasing size. USEARCH seems to under-sample abundant amplicons and to over-sample rare amplicons.” | unhoused_relations[11] |
| relation | USEARCH → rare amplicons — USEARCH appears to over-sample rare amplicons. — “We evaluated the subsampling commands of USEARCH version 8 and VSEARCH to check if the results obtained correspond to those expected. We performed 10,000 random subsamplings of 5% of the 9.5 million unique sequences in the TARA V9 dataset ( Karsenti et al., 2011 ). To make this possible with the 32-bit USEARCH, we first downsampled the dataset once to 10% using VSEARCH and then randomly subsampled it again at 50% with either USEARCH or VSEARCH. Plots of the distribution of the abundance of the most abundant sequence in each subsampling are shown in Fig. 7 . The highest amplicon abundance in the original dataset is 15,638,316. After the initial 10% subsampling, the highest abundance was 1,564,267. After the second subsampling, the top abundances should therefore have a distribution centred on a value of 782,133.5. As can be seen from the figure, the USEARCH distribution has a mean that is about 2,000 too small, while the VSEARCH distribution is correctly centred on the expected value. Subsampling experiments were also performed at 2.5%, 1.5% and 0.5% with similar results, although the errors were of decreasing size. USEARCH seems to under-sample abundant amplicons and to over-sample rare amplicons.” | unhoused_relations[12] |
| weight | USEARCH → rare amplicons — 0.95 — “We evaluated the subsampling commands of USEARCH version 8 and VSEARCH to check if the results obtained correspond to those expected. We performed 10,000 random subsamplings of 5% of the 9.5 million unique sequences in the TARA V9 dataset ( Karsenti et al., 2011 ). To make this possible with the 32-bit USEARCH, we first downsampled the dataset once to 10% using VSEARCH and then randomly subsampled it again at 50% with either USEARCH or VSEARCH. Plots of the distribution of the abundance of the most abundant sequence in each subsampling are shown in Fig. 7 . The highest amplicon abundance in the original dataset is 15,638,316. After the initial 10% subsampling, the highest abundance was 1,564,267. After the second subsampling, the top abundances should therefore have a distribution centred on a value of 782,133.5. As can be seen from the figure, the USEARCH distribution has a mean that is about 2,000 too small, while the VSEARCH distribution is correctly centred on the expected value. Subsampling experiments were also performed at 2.5%, 1.5% and 0.5% with similar results, although the errors were of decreasing size. USEARCH seems to under-sample abundant amplicons and to over-sample rare amplicons.” | unhoused_relations[12] |
| no type for this | database sequence → similarity equal to or greater than the value specified with the id option — A database sequence is accepted when similarity meets or exceeds the id threshold. — “If the resulting alignment indicates a similarity equal to or greater than the value specified with the id option, the database sequence is accepted. If the similarity is too low, it is rejected. Several other options may also be used to determine how similarity is computed ( iddef , as USEARCH used to offer up to version 6), and which sequences should be accepted and rejected, either before (e.g., self , minqsize ) or after alignment (e.g., maxgaps , maxsubs ). The search is terminated when either a certain number of sequences have been accepted (1 by default, adjustable with the maxaccepts option), or a certain number of sequences have been rejected (32 by default, adjustable with the maxrejects option). The accepted sequences are sorted by sequence similarity and presented as the search results.” | unhoused_relations[0] |
| no type for this | shared words → database sequence — Shared-word counts identify promising database candidates before alignment. — “The first phase is presumably quite similar to USEARCH ( Edgar, 2010 ). Heuristics are used to identify a small set of database sequences that have many words in common with the query sequence. Words (or k -mers) consist of a certain number k of consecutive nucleotides of a sequence (8 by default, adjustable with the wordlength option). All overlapping words are included. A sequence of length n then contains at most n − k + 1 unique words. VSEARCH counts the number of shared words between the query and each database sequence. Words that appear multiple times are counted only once. To count the words in the database sequences quickly, VSEARCH creates an index of all the 4 k possible distinct words and stores information about which database sequences they appear in. For extremely frequent words, the set of database sequences is represented by a bitmap; otherwise the set is stored as a list. A finer control of k -mer indexing is described for USEARCH by the pattern (binary string indicating which positions must match) and slots options. USEARCH has such options but seems to ignore them. Currently, VSEARCH ignores these two options too. The minimum number of shared words required may be specified with the minwordmatches option (10 by default), but a lower value is automatically used for short or simple query sequences with less than 10 unique words.” | unhoused_relations[1] |
| no type for this | full dynamic programming → optimal global alignment — Full dynamic programming computes optimal pairwise alignments. — “In the second phase, searching proceeds by considering the database sequences in a specific order, starting with the sequence having the largest number of words in common with the query, and proceeding with a decreasing number of shared words. If two database sequences have the same number of words in common with the query, the shortest sequence is considered first. The query sequence is compared with each database sequence by computing the optimal global alignment. The alignment is performed using a multi-threaded and vectorised full dynamic programming algorithm ( Needleman & Wunsch, 1970 ) adapted from SWIPE ( Rognes, 2011 ). Due to the extreme memory requirements of this method when aligning two long sequences, an alternative algorithm described by Hirschberg (1975) and Myers & Miller (1988) is used when the product of the length of the sequences is greater than 25,000,000, corresponding to aligning two 5,000 bp sequences. This alternative algorithm uses only a linear amount of memory but is considerably slower. This second phase is probably where USEARCH and VSEARCH differ the most, as USEARCH by default presumably performs heuristic seed-and-extend alignment similar to BLAST ( Altschul et al., 1997 ), and only performs optimal alignment when the option fulldp (full dynamic programming) is used. Computing the optimal pairwise alignment in each case gives more accurate results but is also computationally more demanding. The efficient and vectorised full dynamic programming implementation in VSEARCH compensates that extra cost, at least for sequences that are not too long.” | unhoused_relations[2] |
| no type for this | full dynamic programming → memory — Exact alignment of long sequences can require extreme memory. — “In the second phase, searching proceeds by considering the database sequences in a specific order, starting with the sequence having the largest number of words in common with the query, and proceeding with a decreasing number of shared words. If two database sequences have the same number of words in common with the query, the shortest sequence is considered first. The query sequence is compared with each database sequence by computing the optimal global alignment. The alignment is performed using a multi-threaded and vectorised full dynamic programming algorithm ( Needleman & Wunsch, 1970 ) adapted from SWIPE ( Rognes, 2011 ). Due to the extreme memory requirements of this method when aligning two long sequences, an alternative algorithm described by Hirschberg (1975) and Myers & Miller (1988) is used when the product of the length of the sequences is greater than 25,000,000, corresponding to aligning two 5,000 bp sequences. This alternative algorithm uses only a linear amount of memory but is considerably slower. This second phase is probably where USEARCH and VSEARCH differ the most, as USEARCH by default presumably performs heuristic seed-and-extend alignment similar to BLAST ( Altschul et al., 1997 ), and only performs optimal alignment when the option fulldp (full dynamic programming) is used. Computing the optimal pairwise alignment in each case gives more accurate results but is also computationally more demanding. The efficient and vectorised full dynamic programming implementation in VSEARCH compensates that extra cost, at least for sequences that are not too long.” | unhoused_relations[3] |
| no type for this | vectorisation → full dynamic programming — Vectorisation compensates part of exact alignment's computational cost. — “In the second phase, searching proceeds by considering the database sequences in a specific order, starting with the sequence having the largest number of words in common with the query, and proceeding with a decreasing number of shared words. If two database sequences have the same number of words in common with the query, the shortest sequence is considered first. The query sequence is compared with each database sequence by computing the optimal global alignment. The alignment is performed using a multi-threaded and vectorised full dynamic programming algorithm ( Needleman & Wunsch, 1970 ) adapted from SWIPE ( Rognes, 2011 ). Due to the extreme memory requirements of this method when aligning two long sequences, an alternative algorithm described by Hirschberg (1975) and Myers & Miller (1988) is used when the product of the length of the sequences is greater than 25,000,000, corresponding to aligning two 5,000 bp sequences. This alternative algorithm uses only a linear amount of memory but is considerably slower. This second phase is probably where USEARCH and VSEARCH differ the most, as USEARCH by default presumably performs heuristic seed-and-extend alignment similar to BLAST ( Altschul et al., 1997 ), and only performs optimal alignment when the option fulldp (full dynamic programming) is used. Computing the optimal pairwise alignment in each case gives more accurate results but is also computationally more demanding. The efficient and vectorised full dynamic programming implementation in VSEARCH compensates that extra cost, at least for sequences that are not too long.” | unhoused_relations[4] |
| no type for this | sequence similarity threshold → centroid-based algorithm — The threshold determines whether a query joins a centroid or creates a new cluster. — “VSEARCH includes commands to perform de novo clustering using a greedy and heuristic centroid-based algorithm with an adjustable sequence similarity threshold specified with the id option (e.g., 0.97). The input sequences are either processed in the user supplied order ( cluster_smallmem ) or pre-sorted based on length ( cluster_fast ) or abundance (the new cluster_size option). Each input sequence is then used as a query in a search against an initially empty database of centroid sequences. The query sequence is clustered with the first centroid sequence found with similarity equal to or above the threshold. The search is performed using the heuristic approach described above which generally finds the most similar sequences first. If no matches are found, the query sequence becomes the centroid of a new cluster and is added to the database. If maxaccepts is higher than 1, several centroids with sufficient sequence similarity may be found and considered. By default, the query is clustered with the centroid presenting the highest sequence similarity (distance-based greedy clustering, DGC), or, if the sizeorder option is turned on, the centroid with the highest abundance (abundance-based greedy clustering, AGC) ( He et al., 2015 ; Westcott & Schloss, 2015 ; Schloss, 2016 ). VSEARCH performs multi-threaded clustering by searching the database of centroid sequences with several query sequences in parallel. If there are any non-matching query sequences giving rise to new centroids, the required internal comparisons between the query sequences are subsequently performed to achieve correct results. For each cluster, VSEARCH can create a simple multiple sequence alignment using the center star method ( Gusfield, 1993 ) with the centroid as the center sequence, and then compute a consensus sequence and a sequence profile.” | unhoused_relations[5] |
| no type for this | Dust algorithm → low-complexity nucleotide sequences — DUST masks low-complexity sequence regions before comparison. — “VSEARCH includes a highly optimized and parallelized implementation of the Dust algorithm by Tatusov and Lipman for masking of simple repeats and low-complexity nucleotide sequences. It is considerably faster than the implementation of the same algorithm in USEARCH. Their code available at ftp://ftp.ncbi.nlm.nih.gov/pub/tatusov/dust/version1/src/ is in the public domain. VSEARCH uses this algorithm by default, while USEARCH by default uses an undocumented rapid masking algorithm called fastnucleo . VSEARCH performs soft-masking automatically for the pairwise alignment, search, clustering and chimera detection commands. This behaviour can be controlled with the hardmask option to replace masked symbols with N’s instead of lower-casing them, and the dbmask and qmask options, which selects the masking algorithm (none, dust or soft) used for the database and query sequences, respectively. Masking may also be performed explicitly on an input file using the fastx_mask and maskfasta commands.” | unhoused_relations[6] |
| no type for this | USEARCH → memory — The free 32-bit USEARCH build limits memory to under 4 GB. — “VSEARCH is a 64-bit program and allows very large datasets to be processed, essentially limited only by the amount of memory available. The free USEARCH versions are 32-bit programs that limit the available memory to somewhere less than 4GB, often seriously hampering the analysis of realistic datasets.” | unhoused_relations[7] |
| no type for this | clustering threshold → time used — Clustering runtime depends on dataset, algorithm, and threshold. — “The time used for clustering is shown in Fig. 4 . The time used depended on the dataset, algorithm and clustering threshold. The USEARCH programs were in general 2–3 times faster than VSEARCH. In general the difference in speed was smaller for higher thresholds, especially at 99% similarity. Clustering with USEARCH using the fulldp option is an order of magnitude slower than VSEARCH, but contrary to our expectations it does not seem to improve accuracy.” | unhoused_relations[8] |
| no type for this | reference-based detection → SILVA — Reference-based chimera detection performs poorly on the SILVA simulation. — “Next, we tested reference-based ( uchime_ref ) and de novo ( uchime_denovo ) chimera detection using sequences from the 2011 version of Greengenes downloaded from http://greengenes.lbl.gov/Download/Sequence_Data/Fasta_data_files/ and from version 106 (May 2011) of the SILVA database downloaded from https://www.arb-silva.de/no_cache/download/archive/release_106/Exports/ . Sequences from the 16S rRNA V4 region was computationally extracted using the 515F (5′-GTGNCAGCMGCCGCGGTAA-3′) and 806R (5′-GGACTACHVGGGTWTCTAAT-3′) primers, and 8,000 reads were randomly selected from each database. PCR was simulated using a new simulation algorithm known as Simera ( Nichols & Quince, 2016 ) (available at https://github.com/bnichols1979/Simera ) that includes amplification and creation of PCR artefacts like chimeras. We sampled 30,000 reads (-s 30,000) and generated 20,000 potential chimeras (-c 20,000). Defaults were used for other options to Simera. The output sequences were then fed into an Illumina MiSeq noise simulator ( Schirmer et al., 2015 ) ending up with 14,966 reads based on Greengenes and 14,952 reads based on SILVA, of which 1,262 and 1,640 reads contain chimeric sequences, respectively. Next, the sequences were either clustered using the cluster_fast command at 97% identity or dereplicated. VSEARCH and USEARCH version 7 and 8 were run using the uchime_denovo command and then using the uchime_ref command with the Gold database downloaded from http://drive5.com/uchime/uchime_download.html as the reference database. To assess the performance, the results were sorted based on the chimera score, and then the ability to classify individual sequences correctly into chimeric and non-chimeric was plotted as ROC curves. The curves reflect the accuracy of classifying individual reads, not clusters, as abundances were taken into account. The plots in Figs. 5 and 6 show that de novo chimera detection performs better than reference-based detection, with the SILVA dataset in particular, but it does of course depend on the reference database used. VSEARCH performs better than both versions of USEARCH for de novo chimera detection. For reference-based detection VSEARCH also performs better for the Greengenes dataset, while none of the programs work well with the SILVA dataset. Clustering at 97% appears to be more appropriate than dereplication. In this test, the USEARCH programs were about twice as fast as VSEARCH for de novo detection, while they were about 10–30% faster than VSEARCH for reference-based detection.” | unhoused_relations[9] |
| no type for this | VSEARCH → abundant amplicons — VSEARCH subsampling preserves the expected abundance center. — “We evaluated the subsampling commands of USEARCH version 8 and VSEARCH to check if the results obtained correspond to those expected. We performed 10,000 random subsamplings of 5% of the 9.5 million unique sequences in the TARA V9 dataset ( Karsenti et al., 2011 ). To make this possible with the 32-bit USEARCH, we first downsampled the dataset once to 10% using VSEARCH and then randomly subsampled it again at 50% with either USEARCH or VSEARCH. Plots of the distribution of the abundance of the most abundant sequence in each subsampling are shown in Fig. 7 . The highest amplicon abundance in the original dataset is 15,638,316. After the initial 10% subsampling, the highest abundance was 1,564,267. After the second subsampling, the top abundances should therefore have a distribution centred on a value of 782,133.5. As can be seen from the figure, the USEARCH distribution has a mean that is about 2,000 too small, while the VSEARCH distribution is correctly centred on the expected value. Subsampling experiments were also performed at 2.5%, 1.5% and 0.5% with similar results, although the errors were of decreasing size. USEARCH seems to under-sample abundant amplicons and to over-sample rare amplicons.” | unhoused_relations[10] |
| no type for this | USEARCH → abundant amplicons — USEARCH appears to under-sample abundant amplicons. — “We evaluated the subsampling commands of USEARCH version 8 and VSEARCH to check if the results obtained correspond to those expected. We performed 10,000 random subsamplings of 5% of the 9.5 million unique sequences in the TARA V9 dataset ( Karsenti et al., 2011 ). To make this possible with the 32-bit USEARCH, we first downsampled the dataset once to 10% using VSEARCH and then randomly subsampled it again at 50% with either USEARCH or VSEARCH. Plots of the distribution of the abundance of the most abundant sequence in each subsampling are shown in Fig. 7 . The highest amplicon abundance in the original dataset is 15,638,316. After the initial 10% subsampling, the highest abundance was 1,564,267. After the second subsampling, the top abundances should therefore have a distribution centred on a value of 782,133.5. As can be seen from the figure, the USEARCH distribution has a mean that is about 2,000 too small, while the VSEARCH distribution is correctly centred on the expected value. Subsampling experiments were also performed at 2.5%, 1.5% and 0.5% with similar results, although the errors were of decreasing size. USEARCH seems to under-sample abundant amplicons and to over-sample rare amplicons.” | unhoused_relations[11] |
| no type for this | USEARCH → rare amplicons — USEARCH appears to over-sample rare amplicons. — “We evaluated the subsampling commands of USEARCH version 8 and VSEARCH to check if the results obtained correspond to those expected. We performed 10,000 random subsamplings of 5% of the 9.5 million unique sequences in the TARA V9 dataset ( Karsenti et al., 2011 ). To make this possible with the 32-bit USEARCH, we first downsampled the dataset once to 10% using VSEARCH and then randomly subsampled it again at 50% with either USEARCH or VSEARCH. Plots of the distribution of the abundance of the most abundant sequence in each subsampling are shown in Fig. 7 . The highest amplicon abundance in the original dataset is 15,638,316. After the initial 10% subsampling, the highest abundance was 1,564,267. After the second subsampling, the top abundances should therefore have a distribution centred on a value of 782,133.5. As can be seen from the figure, the USEARCH distribution has a mean that is about 2,000 too small, while the VSEARCH distribution is correctly centred on the expected value. Subsampling experiments were also performed at 2.5%, 1.5% and 0.5% with similar results, although the errors were of decreasing size. USEARCH seems to under-sample abundant amplicons and to over-sample rare amplicons.” | unhoused_relations[12] |
| limitation | VSEARCH optimal alignment is more computationally demanding than seed-and-extend search. — “In the second phase, searching proceeds by considering the database sequences in a specific order, starting with the sequence having the largest number of words in common with the query, and proceeding with a decreasing number of shared words. If two database sequences have the same number of words in common with the query, the shortest sequence is considered first. The query sequence is compared with each database sequence by computing the optimal global alignment. The alignment is performed using a multi-threaded and vectorised full dynamic programming algorithm ( Needleman & Wunsch, 1970 ) adapted from SWIPE ( Rognes, 2011 ). Due to the extreme memory requirements of this method when aligning two long sequences, an alternative algorithm described by Hirschberg (1975) and Myers & Miller (1988) is used when the product of the length of the sequences is greater than 25,000,000, corresponding to aligning two 5,000 bp sequences. This alternative algorithm uses only a linear amount of memory but is considerably slower. This second phase is probably where USEARCH and VSEARCH differ the most, as USEARCH by default presumably performs heuristic seed-and-extend alignment similar to BLAST ( Altschul et al., 1997 ), and only performs optimal alignment when the option fulldp (full dynamic programming) is used. Computing the optimal pairwise alignment in each case gives more accurate results but is also computationally more demanding. The efficient and vectorised full dynamic programming implementation in VSEARCH compensates that extra cost, at least for sequences that are not too long.” | limitations[0] |
| limitation | The linear-memory fallback for long sequences is considerably slower. — “In the second phase, searching proceeds by considering the database sequences in a specific order, starting with the sequence having the largest number of words in common with the query, and proceeding with a decreasing number of shared words. If two database sequences have the same number of words in common with the query, the shortest sequence is considered first. The query sequence is compared with each database sequence by computing the optimal global alignment. The alignment is performed using a multi-threaded and vectorised full dynamic programming algorithm ( Needleman & Wunsch, 1970 ) adapted from SWIPE ( Rognes, 2011 ). Due to the extreme memory requirements of this method when aligning two long sequences, an alternative algorithm described by Hirschberg (1975) and Myers & Miller (1988) is used when the product of the length of the sequences is greater than 25,000,000, corresponding to aligning two 5,000 bp sequences. This alternative algorithm uses only a linear amount of memory but is considerably slower. This second phase is probably where USEARCH and VSEARCH differ the most, as USEARCH by default presumably performs heuristic seed-and-extend alignment similar to BLAST ( Altschul et al., 1997 ), and only performs optimal alignment when the option fulldp (full dynamic programming) is used. Computing the optimal pairwise alignment in each case gives more accurate results but is also computationally more demanding. The efficient and vectorised full dynamic programming implementation in VSEARCH compensates that extra cost, at least for sequences that are not too long.” | limitations[1] |
| limitation | VSEARCH and USEARCH both ignore some advanced k-mer-index options. — “The first phase is presumably quite similar to USEARCH ( Edgar, 2010 ). Heuristics are used to identify a small set of database sequences that have many words in common with the query sequence. Words (or k -mers) consist of a certain number k of consecutive nucleotides of a sequence (8 by default, adjustable with the wordlength option). All overlapping words are included. A sequence of length n then contains at most n − k + 1 unique words. VSEARCH counts the number of shared words between the query and each database sequence. Words that appear multiple times are counted only once. To count the words in the database sequences quickly, VSEARCH creates an index of all the 4 k possible distinct words and stores information about which database sequences they appear in. For extremely frequent words, the set of database sequences is represented by a bitmap; otherwise the set is stored as a list. A finer control of k -mer indexing is described for USEARCH by the pattern (binary string indicating which positions must match) and slots options. USEARCH has such options but seems to ignore them. Currently, VSEARCH ignores these two options too. The minimum number of shared words required may be specified with the minwordmatches option (10 by default), but a lower value is automatically used for short or simple query sequences with less than 10 unique words.” | limitations[2] |
| limitation | Original labels cannot be reconstructed after rereplication. — “VSEARCH also includes a new command ( rereplicate ) to perform rereplication that can be used to recreate datasets as they were before full-length dereplication, but of course original labels cannot be recreated.” | limitations[3] |
| limitation | Some USEARCH functions for amino acids, local alignment, UDB databases, and UPARSE were not implemented. — “Some USEARCH version 7 commands have not yet been implemented in VSEARCH. We have not prioritized commands related to amino acid sequences ( findorfs ), local alignment ( allpairs_local , pairs_local , search_local , ublast ), brute-force search ( search_global , pairs_global ), UDB databases ( makeudb_ublast , makeudb_usearch , udb2fasta , udbinfo , udbstats ), and the UPARSE pipeline ( cluster_otus , uparse_ref ).” | limitations[4] |
| limitation | The evaluation used small datasets that fit a 32-bit process, so it did not benchmark the main large-memory advantage. — “The performance of the most important functions of VSEARCH version 2.0.3 (64-bit) was evaluated and compared to the 32-bit versions of USEARCH version 7.0.1090 and 8.1.1861. All datasets used were small enough to fit comfortably in the memory allocated to a 32-bit process. Chimera detection was also compared to UCHIME version 4.2. All tests were run on GNU/Linux CentOS 6.7 compute nodes with 16 physical cores (Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60 GHz) and 64GB RAM. Programs were run with 8 threads, if possible. All times indicated are wall-clock times. All scripts and data necessary to perform the evaluations are available in the GitHub repository at https://github.com/torognes/vsearch-eval/ to enable independent replication.” | limitations[5] |
| limitation | Clustering and chimera detection were slower than USEARCH despite generally higher accuracy. — “VSEARCH supports almost all of the commands and options for nucleotide sequence analysis in USEARCH version 7 as well as several new features. It has a 64-bit design and handles large datasets virtually only limited by the amount of available memory. We have demonstrated that VSEARCH is in general more accurate than USEARCH when performing searching, clustering, chimera detection and subsampling. The accuracy is on a par with USEARCH for paired-end reads merging. VSEARCH is faster than USEARCH when performing dereplication and merging of paired-end reads, but slower for clustering and chimera detection. We will continue to improve the accuracy, speed and robustness of VSEARCH in the future, as well as adding new features.” | limitations[6] |
| limitation | Clustering performance depends on input order, algorithm, identity threshold, and dataset composition. — “We independently evaluated the clustering accuracy of USEARCH and VSEARCH as described for Swarm ( Mahé et al., 2014 ) using two mock datasets, one with an even and one with uneven composition of 57 archaea and bacteria. The datasets were first dereplicated. Then the taxonomy of the unique sequences was assigned by a search against the set of rRNA reference sequences representing the species in the mock datasets, carried out with the usearch_global command of USEARCH. The sequences were shuffled randomly 10 times and clustering was performed at 20 different similarity levels ranging from 80% to 99% in steps of 1%. Clustering was carried out in two ways, first using the cluster_fast command that pre-sorts the sequences by length, and then using the cluster_smallmem command that simply processes the sequences in the user-supplied order (in that case, we supplied sequences ordered by decreasing abundance using the sortbysize command). We then compared the clusters obtained to the assigned species and computed the recall, precision and the adjusted Rand index of the classifications. Recall measures to what extent amplicons assigned to the same species are grouped together in the same OTU (i.e., not over-splitting). Precision measures to what extent amplicons in an OTU are assigned to the same species (i.e., not over-grouping). The adjusted Rand index ( Rand, 1971 ; Hubert & Arabie, 1985 ) summarises both precision and recall using a measure of agreement between two clusterings while adjusting for expected values by chance. The average values over the all shufflings are presented in Figs. 2 and 3 for the even and uneven datasets, respectively. For abundance-sorted sequences, the difference between VSEARCH and USEARCH version 8 is negligible. The difference is larger for length-sorted sequences. When using length sorting, USEARCH 8 (as well as version 7 on the even dataset) shows better precision than VSEARCH for similarity levels below 93%. However, OTU delineation is usually performed at higher similarity values, typically 97%. In the case of our benchmark, overall accuracy as measured by the adjusted Rand index is maximised at 95–97% similarity. This is precisely the region where for length sorting at least VSEARCH outperforms USEARCH.” | limitations[7] |
| limitation | Reference-based chimera detection depends strongly on the reference database and all tools failed on one SILVA condition. — “Next, we tested reference-based ( uchime_ref ) and de novo ( uchime_denovo ) chimera detection using sequences from the 2011 version of Greengenes downloaded from http://greengenes.lbl.gov/Download/Sequence_Data/Fasta_data_files/ and from version 106 (May 2011) of the SILVA database downloaded from https://www.arb-silva.de/no_cache/download/archive/release_106/Exports/ . Sequences from the 16S rRNA V4 region was computationally extracted using the 515F (5′-GTGNCAGCMGCCGCGGTAA-3′) and 806R (5′-GGACTACHVGGGTWTCTAAT-3′) primers, and 8,000 reads were randomly selected from each database. PCR was simulated using a new simulation algorithm known as Simera ( Nichols & Quince, 2016 ) (available at https://github.com/bnichols1979/Simera ) that includes amplification and creation of PCR artefacts like chimeras. We sampled 30,000 reads (-s 30,000) and generated 20,000 potential chimeras (-c 20,000). Defaults were used for other options to Simera. The output sequences were then fed into an Illumina MiSeq noise simulator ( Schirmer et al., 2015 ) ending up with 14,966 reads based on Greengenes and 14,952 reads based on SILVA, of which 1,262 and 1,640 reads contain chimeric sequences, respectively. Next, the sequences were either clustered using the cluster_fast command at 97% identity or dereplicated. VSEARCH and USEARCH version 7 and 8 were run using the uchime_denovo command and then using the uchime_ref command with the Gold database downloaded from http://drive5.com/uchime/uchime_download.html as the reference database. To assess the performance, the results were sorted based on the chimera score, and then the ability to classify individual sequences correctly into chimeric and non-chimeric was plotted as ROC curves. The curves reflect the accuracy of classifying individual reads, not clusters, as abundances were taken into account. The plots in Figs. 5 and 6 show that de novo chimera detection performs better than reference-based detection, with the SILVA dataset in particular, but it does of course depend on the reference database used. VSEARCH performs better than both versions of USEARCH for de novo chimera detection. For reference-based detection VSEARCH also performs better for the Greengenes dataset, while none of the programs work well with the SILVA dataset. Clustering at 97% appears to be more appropriate than dereplication. In this test, the USEARCH programs were about twice as fast as VSEARCH for de novo detection, while they were about 10–30% faster than VSEARCH for reference-based detection.” | limitations[8] |
| limitation | VSEARCH paired-read merging trades slightly fewer correct percentages than USEARCH 8 for greater merge yield. — “Evaluation of paired-end reads merging performance was carried out in a manner similar to that described for the evaluation of PEAR ( Zhang et al., 2014 ). We used whole genome sequencing data from Staphylococcus aureus subspecies aureus strain USA 300 TCH 1516 sequenced by MacCallum et al. (2009) and retrieved from the GAGE-B repository ( http://ccb.jhu.edu/gage_b/ ). The S.aureus reads were 101 bp long from on average 180 bp long fragments, giving a 45X coverage of the genome. We also used Methylococcus capsulatus strain Bath 16S rRNA V3 region amplicon reads sequenced by Masella et al. (2012) . These reads were 108 bp long and the pairs should have an overlap of exactly 18 bp. Merging options were set to allow a minimum overlap of 10 bp and a maximum of 5 mismatches (USEARCH 7 and 8 have different default values for those), while other options were left at defaults. All programs were run with 8 threads. Merged sequences that could be perfectly aligned to their respective reference sequences (either the entire genome or the specific rRNA region) using BWA MEM ( Li & Durbin, 2009 ) were considered correctly merged. The results are shown in Table 2 . The numbers indicate that USEARCH version 7 merges the most reads for both bacteria, but also has the lowest percentage of correctly merged pairs of those merged. USEARCH version 8 merges the fewest reads, but has the highest percentage of correctly merged reads of those merged. VSEARCH is in the middle by merging more reads than USEARCH 8 with only a small decrease in the percentage of correct merges. VSEARCH is about twice as fast as USEARCH 8 and 4–5 times faster than USEARCH version 7.” | limitations[9] |
| limitation | The free USEARCH comparator is a 32-bit build, making feature parity and large-data comparison structurally asymmetric. — “VSEARCH is an open source and free of charge multithreaded 64-bit tool for processing and preparing metagenomics, genomics and population genomics nucleotide sequence data. It is designed as an alternative to the widely used USEARCH tool ( Edgar, 2010 ) for which the source code is not publicly available, algorithm details are only rudimentarily described, and only a memory-confined 32-bit version is freely available for academic use.” | limitations[10] |
finding · quantity · variable · definition · key-term — grounded in the full text| finding | VSEARCH provides a free open-source 64-bit alternative to memory-limited closed-source USEARCH. — “VSEARCH is an open source and free of charge multithreaded 64-bit tool for processing and preparing metagenomics, genomics and population genomics nucleotide sequence data. It is designed as an alternative to the widely used USEARCH tool ( Edgar, 2010 ) for which the source code is not publicly available, algorithm details are only rudimentarily described, and only a memory-confined 32-bit version is freely available for academic use.” | content_tags.findings[0] |
| finding | Shared-word filtering narrows candidate sequences before optimal global alignment. — “When searching nucleotide sequences, VSEARCH uses a fast heuristic based on words shared by the query and target sequences in order to quickly identify similar sequences, a similar strategy is probably used in USEARCH. VSEARCH then performs optimal global sequence alignment of the query against potential target sequences, using full dynamic programming instead of the seed-and-extend heuristic used by USEARCH. Pairwise alignments are computed in parallel using vectorisation and multiple threads.” | content_tags.findings[1] |
| finding | Vectorisation and multithreading parallelize pairwise full-dynamic-programming alignments. — “When searching nucleotide sequences, VSEARCH uses a fast heuristic based on words shared by the query and target sequences in order to quickly identify similar sequences, a similar strategy is probably used in USEARCH. VSEARCH then performs optimal global sequence alignment of the query against potential target sequences, using full dynamic programming instead of the seed-and-extend heuristic used by USEARCH. Pairwise alignments are computed in parallel using vectorisation and multiple threads.” | content_tags.findings[2] |
| finding | Across evaluated tasks VSEARCH was more accurate for searching, clustering, chimera detection, and subsampling and comparable for paired-read merging. — “VSEARCH includes most commands for analysing nucleotide sequences available in USEARCH version 7 and several of those available in USEARCH version 8, including searching (exact or based on global alignment), clustering by similarity (using length pre-sorting, abundance pre-sorting or a user-defined order), chimera detection (reference-based or de novo ), dereplication (full length or prefix), pairwise alignment, reverse complementation, sorting, and subsampling. VSEARCH also includes commands for FASTQ file processing, i.e., format detection, filtering, read quality statistics, and merging of paired reads. Furthermore, VSEARCH extends functionality with several new commands and improvements, including shuffling, rereplication, masking of low-complexity sequences with the well-known DUST algorithm, a choice among different similarity definitions, and FASTQ file format conversion. VSEARCH is here shown to be more accurate than USEARCH when performing searching, clustering, chimera detection and subsampling, while on a par with USEARCH for paired-ends read merging. VSEARCH is slower than USEARCH when performing clustering and chimera detection, but significantly faster when performing paired-end reads merging and dereplication. VSEARCH is available at https://github.com/torognes/vsearch under either the BSD 2-clause license or the GNU General Public License version 3.0.” | content_tags.findings[3] |
| finding | VSEARCH was slower for clustering and chimera detection but faster for merging and dereplication. — “VSEARCH includes most commands for analysing nucleotide sequences available in USEARCH version 7 and several of those available in USEARCH version 8, including searching (exact or based on global alignment), clustering by similarity (using length pre-sorting, abundance pre-sorting or a user-defined order), chimera detection (reference-based or de novo ), dereplication (full length or prefix), pairwise alignment, reverse complementation, sorting, and subsampling. VSEARCH also includes commands for FASTQ file processing, i.e., format detection, filtering, read quality statistics, and merging of paired reads. Furthermore, VSEARCH extends functionality with several new commands and improvements, including shuffling, rereplication, masking of low-complexity sequences with the well-known DUST algorithm, a choice among different similarity definitions, and FASTQ file format conversion. VSEARCH is here shown to be more accurate than USEARCH when performing searching, clustering, chimera detection and subsampling, while on a par with USEARCH for paired-ends read merging. VSEARCH is slower than USEARCH when performing clustering and chimera detection, but significantly faster when performing paired-end reads merging and dereplication. VSEARCH is available at https://github.com/torognes/vsearch under either the BSD 2-clause license or the GNU General Public License version 3.0.” | content_tags.findings[4] |
| finding | The 64-bit design removes the under-4-GB address-space restriction of freely available USEARCH builds. — “VSEARCH is a 64-bit program and allows very large datasets to be processed, essentially limited only by the amount of memory available. The free USEARCH versions are 32-bit programs that limit the available memory to somewhere less than 4GB, often seriously hampering the analysis of realistic datasets.” | content_tags.findings[5] |
| finding | VSEARCH handles compressed FASTA and FASTQ automatically and supports pipe-based workflows without slow disk writes. — “Most VSEARCH commands read files in FASTA or FASTQ format. The parser for FASTQ files in VSEARCH is compliant with the standard as described by Cock et al. (2010) and correctly parses all their tests files. FASTA and FASTQ files are automatically detected and many commands accept both as input. Files compressed with gzip or bzip2 are automatically detected and decompressed using the zlib library by Gailly & Adler (2016) or the bzip2 library by Seward (2016) , respectively. Data may also be piped into or out of VSEARCH, allowing for instance many separate FASTA files to be piped into VSEARCH for simultaneous dereplication, or allowing the creation of complex pipelines without ever having to write on slow disks.” | content_tags.findings[6] |
| finding | Full dynamic programming improves alignment accuracy at greater computational cost, partly offset by vectorisation. — “In the second phase, searching proceeds by considering the database sequences in a specific order, starting with the sequence having the largest number of words in common with the query, and proceeding with a decreasing number of shared words. If two database sequences have the same number of words in common with the query, the shortest sequence is considered first. The query sequence is compared with each database sequence by computing the optimal global alignment. The alignment is performed using a multi-threaded and vectorised full dynamic programming algorithm ( Needleman & Wunsch, 1970 ) adapted from SWIPE ( Rognes, 2011 ). Due to the extreme memory requirements of this method when aligning two long sequences, an alternative algorithm described by Hirschberg (1975) and Myers & Miller (1988) is used when the product of the length of the sequences is greater than 25,000,000, corresponding to aligning two 5,000 bp sequences. This alternative algorithm uses only a linear amount of memory but is considerably slower. This second phase is probably where USEARCH and VSEARCH differ the most, as USEARCH by default presumably performs heuristic seed-and-extend alignment similar to BLAST ( Altschul et al., 1997 ), and only performs optimal alignment when the option fulldp (full dynamic programming) is used. Computing the optimal pairwise alignment in each case gives more accurate results but is also computationally more demanding. The efficient and vectorised full dynamic programming implementation in VSEARCH compensates that extra cost, at least for sequences that are not too long.” | content_tags.findings[7] |
| finding | A linear-memory alternative is used for sequence-length products above 25 million. — “In the second phase, searching proceeds by considering the database sequences in a specific order, starting with the sequence having the largest number of words in common with the query, and proceeding with a decreasing number of shared words. If two database sequences have the same number of words in common with the query, the shortest sequence is considered first. The query sequence is compared with each database sequence by computing the optimal global alignment. The alignment is performed using a multi-threaded and vectorised full dynamic programming algorithm ( Needleman & Wunsch, 1970 ) adapted from SWIPE ( Rognes, 2011 ). Due to the extreme memory requirements of this method when aligning two long sequences, an alternative algorithm described by Hirschberg (1975) and Myers & Miller (1988) is used when the product of the length of the sequences is greater than 25,000,000, corresponding to aligning two 5,000 bp sequences. This alternative algorithm uses only a linear amount of memory but is considerably slower. This second phase is probably where USEARCH and VSEARCH differ the most, as USEARCH by default presumably performs heuristic seed-and-extend alignment similar to BLAST ( Altschul et al., 1997 ), and only performs optimal alignment when the option fulldp (full dynamic programming) is used. Computing the optimal pairwise alignment in each case gives more accurate results but is also computationally more demanding. The efficient and vectorised full dynamic programming implementation in VSEARCH compensates that extra cost, at least for sequences that are not too long.” | content_tags.findings[8] |
| finding | Centroid clustering supports input, length, or abundance ordering and configurable similarity thresholds. — “VSEARCH includes commands to perform de novo clustering using a greedy and heuristic centroid-based algorithm with an adjustable sequence similarity threshold specified with the id option (e.g., 0.97). The input sequences are either processed in the user supplied order ( cluster_smallmem ) or pre-sorted based on length ( cluster_fast ) or abundance (the new cluster_size option). Each input sequence is then used as a query in a search against an initially empty database of centroid sequences. The query sequence is clustered with the first centroid sequence found with similarity equal to or above the threshold. The search is performed using the heuristic approach described above which generally finds the most similar sequences first. If no matches are found, the query sequence becomes the centroid of a new cluster and is added to the database. If maxaccepts is higher than 1, several centroids with sufficient sequence similarity may be found and considered. By default, the query is clustered with the centroid presenting the highest sequence similarity (distance-based greedy clustering, DGC), or, if the sizeorder option is turned on, the centroid with the highest abundance (abundance-based greedy clustering, AGC) ( He et al., 2015 ; Westcott & Schloss, 2015 ; Schloss, 2016 ). VSEARCH performs multi-threaded clustering by searching the database of centroid sequences with several query sequences in parallel. If there are any non-matching query sequences giving rise to new centroids, the required internal comparisons between the query sequences are subsequently performed to achieve correct results. For each cluster, VSEARCH can create a simple multiple sequence alignment using the center star method ( Gusfield, 1993 ) with the centroid as the center sequence, and then compute a consensus sequence and a sequence profile.” | content_tags.findings[9] |
| finding | Prefix dereplication resolves ambiguous prefix matches using length, abundance, identifier, and original-order priorities. — “Prefix dereplication ( derep_prefix ) is also implemented. As with full-length dereplication, identical sequences are clustered. In addition, sequences that are identical to prefixes of other sequences will also be clustered together. If a sequence is identical to the prefix of multiple sequences, it is generally not defined how prefix clustering should behave. VSEARCH resolves this ambiguity by clustering the sequence with the shortest of the candidate sequences. If they are equally long, priority will be given to the most abundant, the one with the lexicographically smaller identifier or the one with the earliest original position, in that order.” | content_tags.findings[10] |
| finding | VSEARCH implements reference-based and de novo UCHIME chimera detection and parallelizes the reference mode. — “Chimeras are detected either de novo ( uchime_denovo command) or with a reference database ( uchime_ref command) using the UCHIME algorithm described by Edgar et al. (2011) . VSEARCH will divide each query sequence into four segments and look for similarity of each segment to sequences in the set of potential parents using the heuristic search function described earlier. It will consider the four best candidates for each segment using maxaccepts 4 and maxrejects 16, and an id threshold of 0.55. VSEARCH optionally outputs borderline sequences, that is, sequences having a high enough score (as specified with the minh option) but with too small a divergence from the closest parent (as specified with the mindiv option). Multi-threading is supported for reference-based chimera detection.” | content_tags.findings[11] |
| finding | Its optimized DUST implementation is considerably faster than the corresponding USEARCH implementation. — “VSEARCH includes a highly optimized and parallelized implementation of the Dust algorithm by Tatusov and Lipman for masking of simple repeats and low-complexity nucleotide sequences. It is considerably faster than the implementation of the same algorithm in USEARCH. Their code available at ftp://ftp.ncbi.nlm.nih.gov/pub/tatusov/dust/version1/src/ is in the public domain. VSEARCH uses this algorithm by default, while USEARCH by default uses an undocumented rapid masking algorithm called fastnucleo . VSEARCH performs soft-masking automatically for the pairwise alignment, search, clustering and chimera detection commands. This behaviour can be controlled with the hardmask option to replace masked symbols with N’s instead of lower-casing them, and the dbmask and qmask options, which selects the masking algorithm (none, dust or soft) used for the database and query sequences, respectively. Masking may also be performed explicitly on an input file using the fastx_mask and maskfasta commands.” | content_tags.findings[12] |
| finding | Nearly all USEARCH 7 command and option names are retained, allowing many QIIME commands to use VSEARCH through an alias. — “The same command and option names as in USEARCH version 7 have generally been used in order to make VSEARCH an almost drop-in replacement. In fact, in QIIME many commands will run fine if an alias or link from usearch to vsearch is made. Detailed documentation of VSEARCH is available as a man page. We will consider adding further commands and options to VSEARCH in the future.” | content_tags.findings[13] |
| finding | In RFAM searching VSEARCH was most accurate at false discovery rates between 0.010 and 0.015 and had similar runtime. — “Evaluation of search accuracy was carried out as described in the USEARCH paper ( Edgar, 2010 ), its supplementary, and on the website ( http://drive5.com/usearch/benchmark_rfam.html ), by assessing the ability of the programs to identify RNA sequences belonging to the same family in RFAM ( Burge et al., 2013 ). The 383,004 sequences in Rfam version 11 were randomly shuffled and then the first sequence from each of the 2,085 (out of 2,208) families that contained at least 2 members was selected as a representative and used as a query against the remaining 380,919 sequences. The programs were run with options id 0.0, minseqlength 1, maxaccepts 1, maxrejects 32, and strand plus. If the matching sequence found belonged to the same family, it was considered a true positive, otherwise it was considered as a false positive. We combined the results from 20 shufflings and plotted the results in the ROC-like curve shown in Fig. 1 . For a false discovery rate between 0.010 and 0.015, VSEARCH is more accurate than USEARCH’s latest version. For lower values, the three programs have similar accuracies. At higher false discovery rates, USEARCH version 8 has an advantage.” | content_tags.findings[14] |
| finding | Abundance-sorted clustering differences were negligible, while VSEARCH led near the 95 to 97 percent identity region under length sorting. — “We independently evaluated the clustering accuracy of USEARCH and VSEARCH as described for Swarm ( Mahé et al., 2014 ) using two mock datasets, one with an even and one with uneven composition of 57 archaea and bacteria. The datasets were first dereplicated. Then the taxonomy of the unique sequences was assigned by a search against the set of rRNA reference sequences representing the species in the mock datasets, carried out with the usearch_global command of USEARCH. The sequences were shuffled randomly 10 times and clustering was performed at 20 different similarity levels ranging from 80% to 99% in steps of 1%. Clustering was carried out in two ways, first using the cluster_fast command that pre-sorts the sequences by length, and then using the cluster_smallmem command that simply processes the sequences in the user-supplied order (in that case, we supplied sequences ordered by decreasing abundance using the sortbysize command). We then compared the clusters obtained to the assigned species and computed the recall, precision and the adjusted Rand index of the classifications. Recall measures to what extent amplicons assigned to the same species are grouped together in the same OTU (i.e., not over-splitting). Precision measures to what extent amplicons in an OTU are assigned to the same species (i.e., not over-grouping). The adjusted Rand index ( Rand, 1971 ; Hubert & Arabie, 1985 ) summarises both precision and recall using a measure of agreement between two clusterings while adjusting for expected values by chance. The average values over the all shufflings are presented in Figs. 2 and 3 for the even and uneven datasets, respectively. For abundance-sorted sequences, the difference between VSEARCH and USEARCH version 8 is negligible. The difference is larger for length-sorted sequences. When using length sorting, USEARCH 8 (as well as version 7 on the even dataset) shows better precision than VSEARCH for similarity levels below 93%. However, OTU delineation is usually performed at higher similarity values, typically 97%. In the case of our benchmark, overall accuracy as measured by the adjusted Rand index is maximised at 95–97% similarity. This is precisely the region where for length sorting at least VSEARCH outperforms USEARCH.” | content_tags.findings[15] |
| finding | USEARCH clustering was generally two to three times faster, but full-dynamic-programming USEARCH was much slower without improving accuracy. — “The time used for clustering is shown in Fig. 4 . The time used depended on the dataset, algorithm and clustering threshold. The USEARCH programs were in general 2–3 times faster than VSEARCH. In general the difference in speed was smaller for higher thresholds, especially at 99% similarity. Clustering with USEARCH using the fulldp option is an order of magnitude slower than VSEARCH, but contrary to our expectations it does not seem to improve accuracy.” | content_tags.findings[16] |
| finding | VSEARCH full-length dereplication was 40 to 70 percent faster across the tested datasets. — “Measurements of dereplication speed were performed on the even and uneven datasets described earlier as well as on the BioMarKs dataset ( Logares et al., 2014 ). For full-length dereplication ( derep_fulllength ) VSEARCH was about 40–50% faster than USEARCH version 7 and 50–70% faster than version 8 on all three datasets. All programs were approximately equally fast on prefix dereplication ( derep_prefix ) of the even and uneven datasets. However, prefix dereplication of the BioMarKs dataset was extremely slow with USEARCH. USEARCH version 7 used more than 4 min and version 8 more than 27 min, while VSEARCH used less than 4 s. The prefix dereplication algorithm used in USEARCH appears ineffective when dealing with short sequences. Removing the 811 sequences shorter than 200 bp out of the 312,503 sequences of the BioMarKs dataset reduces the running time of USEARCH version 7 and 8 down to just 5 and 6 s, respectively.” | content_tags.findings[17] |
| finding | VSEARCH prefix dereplicated BioMarKs in under four seconds where USEARCH took minutes. — “Measurements of dereplication speed were performed on the even and uneven datasets described earlier as well as on the BioMarKs dataset ( Logares et al., 2014 ). For full-length dereplication ( derep_fulllength ) VSEARCH was about 40–50% faster than USEARCH version 7 and 50–70% faster than version 8 on all three datasets. All programs were approximately equally fast on prefix dereplication ( derep_prefix ) of the even and uneven datasets. However, prefix dereplication of the BioMarKs dataset was extremely slow with USEARCH. USEARCH version 7 used more than 4 min and version 8 more than 27 min, while VSEARCH used less than 4 s. The prefix dereplication algorithm used in USEARCH appears ineffective when dealing with short sequences. Removing the 811 sequences shorter than 200 bp out of the 312,503 sequences of the BioMarKs dataset reduces the running time of USEARCH version 7 and 8 down to just 5 and 6 s, respectively.” | content_tags.findings[18] |
| finding | On SIMM chimeras VSEARCH was superior in almost all cases and USEARCH won only four of 99 cases. — “First we repeated the evaluation of the uchime_ref command described in the UCHIME paper ( Edgar et al., 2011 ) using the SIMM dataset downloaded from http://drive5.com/uchime/uchime_download.html . The dataset consists of 900 simulated chimeras that are approximately 250 bp long. The chimeras were generated from 2, 3 or 4 segments selected randomly from 86 original sequences and have similarities in the ranges 90–95%, 95–97% and 97–99% to the original sequences. They were either used unmodified or with 1–5% indels or 1–5% substitutions. We assessed the performance of (i) the original open-source UCHIME version 4.2 program, (ii) USEARCH version 7, (iii) USEARCH version 8, and (iv) VSEARCH. The results are shown in Table 1 and indicate that VSEARCH is superior to the other tools in almost all cases, and in particular when indels were added. The original UCHIME program was found to be quite, but also considerably slower than all the other tools. USEARCH was better than VSEARCH in only 4 out of 99 cases.” | content_tags.findings[19] |
| finding | De novo chimera detection outperformed reference-based detection in the simulated microbial tests and depended on the reference database. — “Next, we tested reference-based ( uchime_ref ) and de novo ( uchime_denovo ) chimera detection using sequences from the 2011 version of Greengenes downloaded from http://greengenes.lbl.gov/Download/Sequence_Data/Fasta_data_files/ and from version 106 (May 2011) of the SILVA database downloaded from https://www.arb-silva.de/no_cache/download/archive/release_106/Exports/ . Sequences from the 16S rRNA V4 region was computationally extracted using the 515F (5′-GTGNCAGCMGCCGCGGTAA-3′) and 806R (5′-GGACTACHVGGGTWTCTAAT-3′) primers, and 8,000 reads were randomly selected from each database. PCR was simulated using a new simulation algorithm known as Simera ( Nichols & Quince, 2016 ) (available at https://github.com/bnichols1979/Simera ) that includes amplification and creation of PCR artefacts like chimeras. We sampled 30,000 reads (-s 30,000) and generated 20,000 potential chimeras (-c 20,000). Defaults were used for other options to Simera. The output sequences were then fed into an Illumina MiSeq noise simulator ( Schirmer et al., 2015 ) ending up with 14,966 reads based on Greengenes and 14,952 reads based on SILVA, of which 1,262 and 1,640 reads contain chimeric sequences, respectively. Next, the sequences were either clustered using the cluster_fast command at 97% identity or dereplicated. VSEARCH and USEARCH version 7 and 8 were run using the uchime_denovo command and then using the uchime_ref command with the Gold database downloaded from http://drive5.com/uchime/uchime_download.html as the reference database. To assess the performance, the results were sorted based on the chimera score, and then the ability to classify individual sequences correctly into chimeric and non-chimeric was plotted as ROC curves. The curves reflect the accuracy of classifying individual reads, not clusters, as abundances were taken into account. The plots in Figs. 5 and 6 show that de novo chimera detection performs better than reference-based detection, with the SILVA dataset in particular, but it does of course depend on the reference database used. VSEARCH performs better than both versions of USEARCH for de novo chimera detection. For reference-based detection VSEARCH also performs better for the Greengenes dataset, while none of the programs work well with the SILVA dataset. Clustering at 97% appears to be more appropriate than dereplication. In this test, the USEARCH programs were about twice as fast as VSEARCH for de novo detection, while they were about 10–30% faster than VSEARCH for reference-based detection.” | content_tags.findings[20] |
| finding | VSEARCH paired-read merging balanced the number and correctness of merges and ran two to five times faster than USEARCH. — “Evaluation of paired-end reads merging performance was carried out in a manner similar to that described for the evaluation of PEAR ( Zhang et al., 2014 ). We used whole genome sequencing data from Staphylococcus aureus subspecies aureus strain USA 300 TCH 1516 sequenced by MacCallum et al. (2009) and retrieved from the GAGE-B repository ( http://ccb.jhu.edu/gage_b/ ). The S.aureus reads were 101 bp long from on average 180 bp long fragments, giving a 45X coverage of the genome. We also used Methylococcus capsulatus strain Bath 16S rRNA V3 region amplicon reads sequenced by Masella et al. (2012) . These reads were 108 bp long and the pairs should have an overlap of exactly 18 bp. Merging options were set to allow a minimum overlap of 10 bp and a maximum of 5 mismatches (USEARCH 7 and 8 have different default values for those), while other options were left at defaults. All programs were run with 8 threads. Merged sequences that could be perfectly aligned to their respective reference sequences (either the entire genome or the specific rRNA region) using BWA MEM ( Li & Durbin, 2009 ) were considered correctly merged. The results are shown in Table 2 . The numbers indicate that USEARCH version 7 merges the most reads for both bacteria, but also has the lowest percentage of correctly merged pairs of those merged. USEARCH version 8 merges the fewest reads, but has the highest percentage of correctly merged reads of those merged. VSEARCH is in the middle by merging more reads than USEARCH 8 with only a small decrease in the percentage of correct merges. VSEARCH is about twice as fast as USEARCH 8 and 4–5 times faster than USEARCH version 7.” | content_tags.findings[21] |
| finding | VSEARCH subsampling centered abundant amplicons on the expected value while USEARCH under-sampled abundant and over-sampled rare amplicons. — “We evaluated the subsampling commands of USEARCH version 8 and VSEARCH to check if the results obtained correspond to those expected. We performed 10,000 random subsamplings of 5% of the 9.5 million unique sequences in the TARA V9 dataset ( Karsenti et al., 2011 ). To make this possible with the 32-bit USEARCH, we first downsampled the dataset once to 10% using VSEARCH and then randomly subsampled it again at 50% with either USEARCH or VSEARCH. Plots of the distribution of the abundance of the most abundant sequence in each subsampling are shown in Fig. 7 . The highest amplicon abundance in the original dataset is 15,638,316. After the initial 10% subsampling, the highest abundance was 1,564,267. After the second subsampling, the top abundances should therefore have a distribution centred on a value of 782,133.5. As can be seen from the figure, the USEARCH distribution has a mean that is about 2,000 too small, while the VSEARCH distribution is correctly centred on the expected value. Subsampling experiments were also performed at 2.5%, 1.5% and 0.5% with similar results, although the errors were of decreasing size. USEARCH seems to under-sample abundant amplicons and to over-sample rare amplicons.” | content_tags.findings[22] |
| quantity | 64-bit — VSEARCH process and data-addressing design — “VSEARCH is an open source and free of charge multithreaded 64-bit tool for processing and preparing metagenomics, genomics and population genomics nucleotide sequence data. It is designed as an alternative to the widely used USEARCH tool ( Edgar, 2010 ) for which the source code is not publicly available, algorithm details are only rudimentarily described, and only a memory-confined 32-bit version is freely available for academic use.” | content_tags.quantities[0] |
| quantity | less than 4GB — memory ceiling of free 32-bit USEARCH versions — “VSEARCH is a 64-bit program and allows very large datasets to be processed, essentially limited only by the amount of memory available. The free USEARCH versions are 32-bit programs that limit the available memory to somewhere less than 4GB, often seriously hampering the analysis of realistic datasets.” | content_tags.quantities[1] |
| quantity | 8 — default shared-word length — “The first phase is presumably quite similar to USEARCH ( Edgar, 2010 ). Heuristics are used to identify a small set of database sequences that have many words in common with the query sequence. Words (or k -mers) consist of a certain number k of consecutive nucleotides of a sequence (8 by default, adjustable with the wordlength option). All overlapping words are included. A sequence of length n then contains at most n − k + 1 unique words. VSEARCH counts the number of shared words between the query and each database sequence. Words that appear multiple times are counted only once. To count the words in the database sequences quickly, VSEARCH creates an index of all the 4 k possible distinct words and stores information about which database sequences they appear in. For extremely frequent words, the set of database sequences is represented by a bitmap; otherwise the set is stored as a list. A finer control of k -mer indexing is described for USEARCH by the pattern (binary string indicating which positions must match) and slots options. USEARCH has such options but seems to ignore them. Currently, VSEARCH ignores these two options too. The minimum number of shared words required may be specified with the minwordmatches option (10 by default), but a lower value is automatically used for short or simple query sequences with less than 10 unique words.” | content_tags.quantities[2] |
| quantity | 10 — default minimum shared-word matches — “The first phase is presumably quite similar to USEARCH ( Edgar, 2010 ). Heuristics are used to identify a small set of database sequences that have many words in common with the query sequence. Words (or k -mers) consist of a certain number k of consecutive nucleotides of a sequence (8 by default, adjustable with the wordlength option). All overlapping words are included. A sequence of length n then contains at most n − k + 1 unique words. VSEARCH counts the number of shared words between the query and each database sequence. Words that appear multiple times are counted only once. To count the words in the database sequences quickly, VSEARCH creates an index of all the 4 k possible distinct words and stores information about which database sequences they appear in. For extremely frequent words, the set of database sequences is represented by a bitmap; otherwise the set is stored as a list. A finer control of k -mer indexing is described for USEARCH by the pattern (binary string indicating which positions must match) and slots options. USEARCH has such options but seems to ignore them. Currently, VSEARCH ignores these two options too. The minimum number of shared words required may be specified with the minwordmatches option (10 by default), but a lower value is automatically used for short or simple query sequences with less than 10 unique words.” | content_tags.quantities[3] |
| quantity | 25,000,000 — sequence-length product triggering linear-memory alignment — “In the second phase, searching proceeds by considering the database sequences in a specific order, starting with the sequence having the largest number of words in common with the query, and proceeding with a decreasing number of shared words. If two database sequences have the same number of words in common with the query, the shortest sequence is considered first. The query sequence is compared with each database sequence by computing the optimal global alignment. The alignment is performed using a multi-threaded and vectorised full dynamic programming algorithm ( Needleman & Wunsch, 1970 ) adapted from SWIPE ( Rognes, 2011 ). Due to the extreme memory requirements of this method when aligning two long sequences, an alternative algorithm described by Hirschberg (1975) and Myers & Miller (1988) is used when the product of the length of the sequences is greater than 25,000,000, corresponding to aligning two 5,000 bp sequences. This alternative algorithm uses only a linear amount of memory but is considerably slower. This second phase is probably where USEARCH and VSEARCH differ the most, as USEARCH by default presumably performs heuristic seed-and-extend alignment similar to BLAST ( Altschul et al., 1997 ), and only performs optimal alignment when the option fulldp (full dynamic programming) is used. Computing the optimal pairwise alignment in each case gives more accurate results but is also computationally more demanding. The efficient and vectorised full dynamic programming implementation in VSEARCH compensates that extra cost, at least for sequences that are not too long.” | content_tags.quantities[4] |
| quantity | 0.97 — example sequence-similarity threshold for clustering — “VSEARCH includes commands to perform de novo clustering using a greedy and heuristic centroid-based algorithm with an adjustable sequence similarity threshold specified with the id option (e.g., 0.97). The input sequences are either processed in the user supplied order ( cluster_smallmem ) or pre-sorted based on length ( cluster_fast ) or abundance (the new cluster_size option). Each input sequence is then used as a query in a search against an initially empty database of centroid sequences. The query sequence is clustered with the first centroid sequence found with similarity equal to or above the threshold. The search is performed using the heuristic approach described above which generally finds the most similar sequences first. If no matches are found, the query sequence becomes the centroid of a new cluster and is added to the database. If maxaccepts is higher than 1, several centroids with sufficient sequence similarity may be found and considered. By default, the query is clustered with the centroid presenting the highest sequence similarity (distance-based greedy clustering, DGC), or, if the sizeorder option is turned on, the centroid with the highest abundance (abundance-based greedy clustering, AGC) ( He et al., 2015 ; Westcott & Schloss, 2015 ; Schloss, 2016 ). VSEARCH performs multi-threaded clustering by searching the database of centroid sequences with several query sequences in parallel. If there are any non-matching query sequences giving rise to new centroids, the required internal comparisons between the query sequences are subsequently performed to achieve correct results. For each cluster, VSEARCH can create a simple multiple sequence alignment using the center star method ( Gusfield, 1993 ) with the centroid as the center sequence, and then compute a consensus sequence and a sequence profile.” | content_tags.quantities[5] |
| quantity | 1 — default maximum accepted search hits — “If the resulting alignment indicates a similarity equal to or greater than the value specified with the id option, the database sequence is accepted. If the similarity is too low, it is rejected. Several other options may also be used to determine how similarity is computed ( iddef , as USEARCH used to offer up to version 6), and which sequences should be accepted and rejected, either before (e.g., self , minqsize ) or after alignment (e.g., maxgaps , maxsubs ). The search is terminated when either a certain number of sequences have been accepted (1 by default, adjustable with the maxaccepts option), or a certain number of sequences have been rejected (32 by default, adjustable with the maxrejects option). The accepted sequences are sorted by sequence similarity and presented as the search results.” | content_tags.quantities[6] |
| quantity | 32 — default maximum rejected search candidates — “If the resulting alignment indicates a similarity equal to or greater than the value specified with the id option, the database sequence is accepted. If the similarity is too low, it is rejected. Several other options may also be used to determine how similarity is computed ( iddef , as USEARCH used to offer up to version 6), and which sequences should be accepted and rejected, either before (e.g., self , minqsize ) or after alignment (e.g., maxgaps , maxsubs ). The search is terminated when either a certain number of sequences have been accepted (1 by default, adjustable with the maxaccepts option), or a certain number of sequences have been rejected (32 by default, adjustable with the maxrejects option). The accepted sequences are sorted by sequence similarity and presented as the search results.” | content_tags.quantities[7] |
| quantity | 383,004 — RFAM v11 sequences in search evaluation — “Evaluation of search accuracy was carried out as described in the USEARCH paper ( Edgar, 2010 ), its supplementary, and on the website ( http://drive5.com/usearch/benchmark_rfam.html ), by assessing the ability of the programs to identify RNA sequences belonging to the same family in RFAM ( Burge et al., 2013 ). The 383,004 sequences in Rfam version 11 were randomly shuffled and then the first sequence from each of the 2,085 (out of 2,208) families that contained at least 2 members was selected as a representative and used as a query against the remaining 380,919 sequences. The programs were run with options id 0.0, minseqlength 1, maxaccepts 1, maxrejects 32, and strand plus. If the matching sequence found belonged to the same family, it was considered a true positive, otherwise it was considered as a false positive. We combined the results from 20 shufflings and plotted the results in the ROC-like curve shown in Fig. 1 . For a false discovery rate between 0.010 and 0.015, VSEARCH is more accurate than USEARCH’s latest version. For lower values, the three programs have similar accuracies. At higher false discovery rates, USEARCH version 8 has an advantage.” | content_tags.quantities[8] |
| quantity | 20 shufflings — search evaluation repetitions combined — “Evaluation of search accuracy was carried out as described in the USEARCH paper ( Edgar, 2010 ), its supplementary, and on the website ( http://drive5.com/usearch/benchmark_rfam.html ), by assessing the ability of the programs to identify RNA sequences belonging to the same family in RFAM ( Burge et al., 2013 ). The 383,004 sequences in Rfam version 11 were randomly shuffled and then the first sequence from each of the 2,085 (out of 2,208) families that contained at least 2 members was selected as a representative and used as a query against the remaining 380,919 sequences. The programs were run with options id 0.0, minseqlength 1, maxaccepts 1, maxrejects 32, and strand plus. If the matching sequence found belonged to the same family, it was considered a true positive, otherwise it was considered as a false positive. We combined the results from 20 shufflings and plotted the results in the ROC-like curve shown in Fig. 1 . For a false discovery rate between 0.010 and 0.015, VSEARCH is more accurate than USEARCH’s latest version. For lower values, the three programs have similar accuracies. At higher false discovery rates, USEARCH version 8 has an advantage.” | content_tags.quantities[9] |
| quantity | 5 min 26 s — VSEARCH RFAM search time across 1,000 replicate datasets — “The time to search the Rfam database as described above was measured. To avoid extremely short running times, 1,000 replicates of the datasets were used. USEARCH version 7 required on average 5 min 29 s for the search, USEARCH version 8 took 5 min 57 s, while VSEARCH took 5 min 26 s.” | content_tags.quantities[10] |
| quantity | 80% to 99% — similarity-threshold range in clustering evaluation — “We independently evaluated the clustering accuracy of USEARCH and VSEARCH as described for Swarm ( Mahé et al., 2014 ) using two mock datasets, one with an even and one with uneven composition of 57 archaea and bacteria. The datasets were first dereplicated. Then the taxonomy of the unique sequences was assigned by a search against the set of rRNA reference sequences representing the species in the mock datasets, carried out with the usearch_global command of USEARCH. The sequences were shuffled randomly 10 times and clustering was performed at 20 different similarity levels ranging from 80% to 99% in steps of 1%. Clustering was carried out in two ways, first using the cluster_fast command that pre-sorts the sequences by length, and then using the cluster_smallmem command that simply processes the sequences in the user-supplied order (in that case, we supplied sequences ordered by decreasing abundance using the sortbysize command). We then compared the clusters obtained to the assigned species and computed the recall, precision and the adjusted Rand index of the classifications. Recall measures to what extent amplicons assigned to the same species are grouped together in the same OTU (i.e., not over-splitting). Precision measures to what extent amplicons in an OTU are assigned to the same species (i.e., not over-grouping). The adjusted Rand index ( Rand, 1971 ; Hubert & Arabie, 1985 ) summarises both precision and recall using a measure of agreement between two clusterings while adjusting for expected values by chance. The average values over the all shufflings are presented in Figs. 2 and 3 for the even and uneven datasets, respectively. For abundance-sorted sequences, the difference between VSEARCH and USEARCH version 8 is negligible. The difference is larger for length-sorted sequences. When using length sorting, USEARCH 8 (as well as version 7 on the even dataset) shows better precision than VSEARCH for similarity levels below 93%. However, OTU delineation is usually performed at higher similarity values, typically 97%. In the case of our benchmark, overall accuracy as measured by the adjusted Rand index is maximised at 95–97% similarity. This is precisely the region where for length sorting at least VSEARCH outperforms USEARCH.” | content_tags.quantities[11] |
| quantity | 40–70% faster — range of VSEARCH full-length dereplication advantage across USEARCH versions — “Measurements of dereplication speed were performed on the even and uneven datasets described earlier as well as on the BioMarKs dataset ( Logares et al., 2014 ). For full-length dereplication ( derep_fulllength ) VSEARCH was about 40–50% faster than USEARCH version 7 and 50–70% faster than version 8 on all three datasets. All programs were approximately equally fast on prefix dereplication ( derep_prefix ) of the even and uneven datasets. However, prefix dereplication of the BioMarKs dataset was extremely slow with USEARCH. USEARCH version 7 used more than 4 min and version 8 more than 27 min, while VSEARCH used less than 4 s. The prefix dereplication algorithm used in USEARCH appears ineffective when dealing with short sequences. Removing the 811 sequences shorter than 200 bp out of the 312,503 sequences of the BioMarKs dataset reduces the running time of USEARCH version 7 and 8 down to just 5 and 6 s, respectively.” | content_tags.quantities[12] |
| quantity | 900 — simulated chimeras in the repeated UCHIME evaluation — “First we repeated the evaluation of the uchime_ref command described in the UCHIME paper ( Edgar et al., 2011 ) using the SIMM dataset downloaded from http://drive5.com/uchime/uchime_download.html . The dataset consists of 900 simulated chimeras that are approximately 250 bp long. The chimeras were generated from 2, 3 or 4 segments selected randomly from 86 original sequences and have similarities in the ranges 90–95%, 95–97% and 97–99% to the original sequences. They were either used unmodified or with 1–5% indels or 1–5% substitutions. We assessed the performance of (i) the original open-source UCHIME version 4.2 program, (ii) USEARCH version 7, (iii) USEARCH version 8, and (iv) VSEARCH. The results are shown in Table 1 and indicate that VSEARCH is superior to the other tools in almost all cases, and in particular when indels were added. The original UCHIME program was found to be quite, but also considerably slower than all the other tools. USEARCH was better than VSEARCH in only 4 out of 99 cases.” | content_tags.quantities[13] |
| quantity | 10,000 — random subsampling repetitions — “We evaluated the subsampling commands of USEARCH version 8 and VSEARCH to check if the results obtained correspond to those expected. We performed 10,000 random subsamplings of 5% of the 9.5 million unique sequences in the TARA V9 dataset ( Karsenti et al., 2011 ). To make this possible with the 32-bit USEARCH, we first downsampled the dataset once to 10% using VSEARCH and then randomly subsampled it again at 50% with either USEARCH or VSEARCH. Plots of the distribution of the abundance of the most abundant sequence in each subsampling are shown in Fig. 7 . The highest amplicon abundance in the original dataset is 15,638,316. After the initial 10% subsampling, the highest abundance was 1,564,267. After the second subsampling, the top abundances should therefore have a distribution centred on a value of 782,133.5. As can be seen from the figure, the USEARCH distribution has a mean that is about 2,000 too small, while the VSEARCH distribution is correctly centred on the expected value. Subsampling experiments were also performed at 2.5%, 1.5% and 0.5% with similar results, although the errors were of decreasing size. USEARCH seems to under-sample abundant amplicons and to over-sample rare amplicons.” | content_tags.quantities[14] |
| quantity | 782,133.5 — expected center of maximum abundance after two-stage 5-percent subsampling — “We evaluated the subsampling commands of USEARCH version 8 and VSEARCH to check if the results obtained correspond to those expected. We performed 10,000 random subsamplings of 5% of the 9.5 million unique sequences in the TARA V9 dataset ( Karsenti et al., 2011 ). To make this possible with the 32-bit USEARCH, we first downsampled the dataset once to 10% using VSEARCH and then randomly subsampled it again at 50% with either USEARCH or VSEARCH. Plots of the distribution of the abundance of the most abundant sequence in each subsampling are shown in Fig. 7 . The highest amplicon abundance in the original dataset is 15,638,316. After the initial 10% subsampling, the highest abundance was 1,564,267. After the second subsampling, the top abundances should therefore have a distribution centred on a value of 782,133.5. As can be seen from the figure, the USEARCH distribution has a mean that is about 2,000 too small, while the VSEARCH distribution is correctly centred on the expected value. Subsampling experiments were also performed at 2.5%, 1.5% and 0.5% with similar results, although the errors were of decreasing size. USEARCH seems to under-sample abundant amplicons and to over-sample rare amplicons.” | content_tags.quantities[15] |
| variable | shared words (candidate-filtering similarity proxy) — “The first phase is presumably quite similar to USEARCH ( Edgar, 2010 ). Heuristics are used to identify a small set of database sequences that have many words in common with the query sequence. Words (or k -mers) consist of a certain number k of consecutive nucleotides of a sequence (8 by default, adjustable with the wordlength option). All overlapping words are included. A sequence of length n then contains at most n − k + 1 unique words. VSEARCH counts the number of shared words between the query and each database sequence. Words that appear multiple times are counted only once. To count the words in the database sequences quickly, VSEARCH creates an index of all the 4 k possible distinct words and stores information about which database sequences they appear in. For extremely frequent words, the set of database sequences is represented by a bitmap; otherwise the set is stored as a list. A finer control of k -mer indexing is described for USEARCH by the pattern (binary string indicating which positions must match) and slots options. USEARCH has such options but seems to ignore them. Currently, VSEARCH ignores these two options too. The minimum number of shared words required may be specified with the minwordmatches option (10 by default), but a lower value is automatically used for short or simple query sequences with less than 10 unique words.” | content_tags.variables[0] |
| variable | sequence similarity (acceptance and clustering threshold quantity) — “If the resulting alignment indicates a similarity equal to or greater than the value specified with the id option, the database sequence is accepted. If the similarity is too low, it is rejected. Several other options may also be used to determine how similarity is computed ( iddef , as USEARCH used to offer up to version 6), and which sequences should be accepted and rejected, either before (e.g., self , minqsize ) or after alignment (e.g., maxgaps , maxsubs ). The search is terminated when either a certain number of sequences have been accepted (1 by default, adjustable with the maxaccepts option), or a certain number of sequences have been rejected (32 by default, adjustable with the maxrejects option). The accepted sequences are sorted by sequence similarity and presented as the search results.” | content_tags.variables[1] |
| variable | wordlength (search-index granularity) — “The first phase is presumably quite similar to USEARCH ( Edgar, 2010 ). Heuristics are used to identify a small set of database sequences that have many words in common with the query sequence. Words (or k -mers) consist of a certain number k of consecutive nucleotides of a sequence (8 by default, adjustable with the wordlength option). All overlapping words are included. A sequence of length n then contains at most n − k + 1 unique words. VSEARCH counts the number of shared words between the query and each database sequence. Words that appear multiple times are counted only once. To count the words in the database sequences quickly, VSEARCH creates an index of all the 4 k possible distinct words and stores information about which database sequences they appear in. For extremely frequent words, the set of database sequences is represented by a bitmap; otherwise the set is stored as a list. A finer control of k -mer indexing is described for USEARCH by the pattern (binary string indicating which positions must match) and slots options. USEARCH has such options but seems to ignore them. Currently, VSEARCH ignores these two options too. The minimum number of shared words required may be specified with the minwordmatches option (10 by default), but a lower value is automatically used for short or simple query sequences with less than 10 unique words.” | content_tags.variables[2] |
| variable | sequence length (alignment-memory fallback determinant) — “In the second phase, searching proceeds by considering the database sequences in a specific order, starting with the sequence having the largest number of words in common with the query, and proceeding with a decreasing number of shared words. If two database sequences have the same number of words in common with the query, the shortest sequence is considered first. The query sequence is compared with each database sequence by computing the optimal global alignment. The alignment is performed using a multi-threaded and vectorised full dynamic programming algorithm ( Needleman & Wunsch, 1970 ) adapted from SWIPE ( Rognes, 2011 ). Due to the extreme memory requirements of this method when aligning two long sequences, an alternative algorithm described by Hirschberg (1975) and Myers & Miller (1988) is used when the product of the length of the sequences is greater than 25,000,000, corresponding to aligning two 5,000 bp sequences. This alternative algorithm uses only a linear amount of memory but is considerably slower. This second phase is probably where USEARCH and VSEARCH differ the most, as USEARCH by default presumably performs heuristic seed-and-extend alignment similar to BLAST ( Altschul et al., 1997 ), and only performs optimal alignment when the option fulldp (full dynamic programming) is used. Computing the optimal pairwise alignment in each case gives more accurate results but is also computationally more demanding. The efficient and vectorised full dynamic programming implementation in VSEARCH compensates that extra cost, at least for sequences that are not too long.” | content_tags.variables[3] |
| variable | clustering threshold (accuracy and runtime condition) — “The time used for clustering is shown in Fig. 4 . The time used depended on the dataset, algorithm and clustering threshold. The USEARCH programs were in general 2–3 times faster than VSEARCH. In general the difference in speed was smaller for higher thresholds, especially at 99% similarity. Clustering with USEARCH using the fulldp option is an order of magnitude slower than VSEARCH, but contrary to our expectations it does not seem to improve accuracy.” | content_tags.variables[4] |
| variable | false discovery rate (search-accuracy operating point) — “Evaluation of search accuracy was carried out as described in the USEARCH paper ( Edgar, 2010 ), its supplementary, and on the website ( http://drive5.com/usearch/benchmark_rfam.html ), by assessing the ability of the programs to identify RNA sequences belonging to the same family in RFAM ( Burge et al., 2013 ). The 383,004 sequences in Rfam version 11 were randomly shuffled and then the first sequence from each of the 2,085 (out of 2,208) families that contained at least 2 members was selected as a representative and used as a query against the remaining 380,919 sequences. The programs were run with options id 0.0, minseqlength 1, maxaccepts 1, maxrejects 32, and strand plus. If the matching sequence found belonged to the same family, it was considered a true positive, otherwise it was considered as a false positive. We combined the results from 20 shufflings and plotted the results in the ROC-like curve shown in Fig. 1 . For a false discovery rate between 0.010 and 0.015, VSEARCH is more accurate than USEARCH’s latest version. For lower values, the three programs have similar accuracies. At higher false discovery rates, USEARCH version 8 has an advantage.” | content_tags.variables[6] |
| variable | recall (clustering completeness outcome) — “We independently evaluated the clustering accuracy of USEARCH and VSEARCH as described for Swarm ( Mahé et al., 2014 ) using two mock datasets, one with an even and one with uneven composition of 57 archaea and bacteria. The datasets were first dereplicated. Then the taxonomy of the unique sequences was assigned by a search against the set of rRNA reference sequences representing the species in the mock datasets, carried out with the usearch_global command of USEARCH. The sequences were shuffled randomly 10 times and clustering was performed at 20 different similarity levels ranging from 80% to 99% in steps of 1%. Clustering was carried out in two ways, first using the cluster_fast command that pre-sorts the sequences by length, and then using the cluster_smallmem command that simply processes the sequences in the user-supplied order (in that case, we supplied sequences ordered by decreasing abundance using the sortbysize command). We then compared the clusters obtained to the assigned species and computed the recall, precision and the adjusted Rand index of the classifications. Recall measures to what extent amplicons assigned to the same species are grouped together in the same OTU (i.e., not over-splitting). Precision measures to what extent amplicons in an OTU are assigned to the same species (i.e., not over-grouping). The adjusted Rand index ( Rand, 1971 ; Hubert & Arabie, 1985 ) summarises both precision and recall using a measure of agreement between two clusterings while adjusting for expected values by chance. The average values over the all shufflings are presented in Figs. 2 and 3 for the even and uneven datasets, respectively. For abundance-sorted sequences, the difference between VSEARCH and USEARCH version 8 is negligible. The difference is larger for length-sorted sequences. When using length sorting, USEARCH 8 (as well as version 7 on the even dataset) shows better precision than VSEARCH for similarity levels below 93%. However, OTU delineation is usually performed at higher similarity values, typically 97%. In the case of our benchmark, overall accuracy as measured by the adjusted Rand index is maximised at 95–97% similarity. This is precisely the region where for length sorting at least VSEARCH outperforms USEARCH.” | content_tags.variables[7] |
| variable | precision (clustering purity outcome) — “We independently evaluated the clustering accuracy of USEARCH and VSEARCH as described for Swarm ( Mahé et al., 2014 ) using two mock datasets, one with an even and one with uneven composition of 57 archaea and bacteria. The datasets were first dereplicated. Then the taxonomy of the unique sequences was assigned by a search against the set of rRNA reference sequences representing the species in the mock datasets, carried out with the usearch_global command of USEARCH. The sequences were shuffled randomly 10 times and clustering was performed at 20 different similarity levels ranging from 80% to 99% in steps of 1%. Clustering was carried out in two ways, first using the cluster_fast command that pre-sorts the sequences by length, and then using the cluster_smallmem command that simply processes the sequences in the user-supplied order (in that case, we supplied sequences ordered by decreasing abundance using the sortbysize command). We then compared the clusters obtained to the assigned species and computed the recall, precision and the adjusted Rand index of the classifications. Recall measures to what extent amplicons assigned to the same species are grouped together in the same OTU (i.e., not over-splitting). Precision measures to what extent amplicons in an OTU are assigned to the same species (i.e., not over-grouping). The adjusted Rand index ( Rand, 1971 ; Hubert & Arabie, 1985 ) summarises both precision and recall using a measure of agreement between two clusterings while adjusting for expected values by chance. The average values over the all shufflings are presented in Figs. 2 and 3 for the even and uneven datasets, respectively. For abundance-sorted sequences, the difference between VSEARCH and USEARCH version 8 is negligible. The difference is larger for length-sorted sequences. When using length sorting, USEARCH 8 (as well as version 7 on the even dataset) shows better precision than VSEARCH for similarity levels below 93%. However, OTU delineation is usually performed at higher similarity values, typically 97%. In the case of our benchmark, overall accuracy as measured by the adjusted Rand index is maximised at 95–97% similarity. This is precisely the region where for length sorting at least VSEARCH outperforms USEARCH.” | content_tags.variables[8] |
| variable | adjusted Rand index (chance-adjusted overall clustering outcome) — “We independently evaluated the clustering accuracy of USEARCH and VSEARCH as described for Swarm ( Mahé et al., 2014 ) using two mock datasets, one with an even and one with uneven composition of 57 archaea and bacteria. The datasets were first dereplicated. Then the taxonomy of the unique sequences was assigned by a search against the set of rRNA reference sequences representing the species in the mock datasets, carried out with the usearch_global command of USEARCH. The sequences were shuffled randomly 10 times and clustering was performed at 20 different similarity levels ranging from 80% to 99% in steps of 1%. Clustering was carried out in two ways, first using the cluster_fast command that pre-sorts the sequences by length, and then using the cluster_smallmem command that simply processes the sequences in the user-supplied order (in that case, we supplied sequences ordered by decreasing abundance using the sortbysize command). We then compared the clusters obtained to the assigned species and computed the recall, precision and the adjusted Rand index of the classifications. Recall measures to what extent amplicons assigned to the same species are grouped together in the same OTU (i.e., not over-splitting). Precision measures to what extent amplicons in an OTU are assigned to the same species (i.e., not over-grouping). The adjusted Rand index ( Rand, 1971 ; Hubert & Arabie, 1985 ) summarises both precision and recall using a measure of agreement between two clusterings while adjusting for expected values by chance. The average values over the all shufflings are presented in Figs. 2 and 3 for the even and uneven datasets, respectively. For abundance-sorted sequences, the difference between VSEARCH and USEARCH version 8 is negligible. The difference is larger for length-sorted sequences. When using length sorting, USEARCH 8 (as well as version 7 on the even dataset) shows better precision than VSEARCH for similarity levels below 93%. However, OTU delineation is usually performed at higher similarity values, typically 97%. In the case of our benchmark, overall accuracy as measured by the adjusted Rand index is maximised at 95–97% similarity. This is precisely the region where for length sorting at least VSEARCH outperforms USEARCH.” | content_tags.variables[9] |
| variable | chimera score (ROC ranking variable) — “Next, we tested reference-based ( uchime_ref ) and de novo ( uchime_denovo ) chimera detection using sequences from the 2011 version of Greengenes downloaded from http://greengenes.lbl.gov/Download/Sequence_Data/Fasta_data_files/ and from version 106 (May 2011) of the SILVA database downloaded from https://www.arb-silva.de/no_cache/download/archive/release_106/Exports/ . Sequences from the 16S rRNA V4 region was computationally extracted using the 515F (5′-GTGNCAGCMGCCGCGGTAA-3′) and 806R (5′-GGACTACHVGGGTWTCTAAT-3′) primers, and 8,000 reads were randomly selected from each database. PCR was simulated using a new simulation algorithm known as Simera ( Nichols & Quince, 2016 ) (available at https://github.com/bnichols1979/Simera ) that includes amplification and creation of PCR artefacts like chimeras. We sampled 30,000 reads (-s 30,000) and generated 20,000 potential chimeras (-c 20,000). Defaults were used for other options to Simera. The output sequences were then fed into an Illumina MiSeq noise simulator ( Schirmer et al., 2015 ) ending up with 14,966 reads based on Greengenes and 14,952 reads based on SILVA, of which 1,262 and 1,640 reads contain chimeric sequences, respectively. Next, the sequences were either clustered using the cluster_fast command at 97% identity or dereplicated. VSEARCH and USEARCH version 7 and 8 were run using the uchime_denovo command and then using the uchime_ref command with the Gold database downloaded from http://drive5.com/uchime/uchime_download.html as the reference database. To assess the performance, the results were sorted based on the chimera score, and then the ability to classify individual sequences correctly into chimeric and non-chimeric was plotted as ROC curves. The curves reflect the accuracy of classifying individual reads, not clusters, as abundances were taken into account. The plots in Figs. 5 and 6 show that de novo chimera detection performs better than reference-based detection, with the SILVA dataset in particular, but it does of course depend on the reference database used. VSEARCH performs better than both versions of USEARCH for de novo chimera detection. For reference-based detection VSEARCH also performs better for the Greengenes dataset, while none of the programs work well with the SILVA dataset. Clustering at 97% appears to be more appropriate than dereplication. In this test, the USEARCH programs were about twice as fast as VSEARCH for de novo detection, while they were about 10–30% faster than VSEARCH for reference-based detection.” | content_tags.variables[10] |
| variable | merged pairs (paired-read yield outcome) — “Evaluation of paired-end reads merging performance was carried out in a manner similar to that described for the evaluation of PEAR ( Zhang et al., 2014 ). We used whole genome sequencing data from Staphylococcus aureus subspecies aureus strain USA 300 TCH 1516 sequenced by MacCallum et al. (2009) and retrieved from the GAGE-B repository ( http://ccb.jhu.edu/gage_b/ ). The S.aureus reads were 101 bp long from on average 180 bp long fragments, giving a 45X coverage of the genome. We also used Methylococcus capsulatus strain Bath 16S rRNA V3 region amplicon reads sequenced by Masella et al. (2012) . These reads were 108 bp long and the pairs should have an overlap of exactly 18 bp. Merging options were set to allow a minimum overlap of 10 bp and a maximum of 5 mismatches (USEARCH 7 and 8 have different default values for those), while other options were left at defaults. All programs were run with 8 threads. Merged sequences that could be perfectly aligned to their respective reference sequences (either the entire genome or the specific rRNA region) using BWA MEM ( Li & Durbin, 2009 ) were considered correctly merged. The results are shown in Table 2 . The numbers indicate that USEARCH version 7 merges the most reads for both bacteria, but also has the lowest percentage of correctly merged pairs of those merged. USEARCH version 8 merges the fewest reads, but has the highest percentage of correctly merged reads of those merged. VSEARCH is in the middle by merging more reads than USEARCH 8 with only a small decrease in the percentage of correct merges. VSEARCH is about twice as fast as USEARCH 8 and 4–5 times faster than USEARCH version 7.” | content_tags.variables[11] |
| variable | correct merges (paired-read accuracy outcome) — “Evaluation of paired-end reads merging performance was carried out in a manner similar to that described for the evaluation of PEAR ( Zhang et al., 2014 ). We used whole genome sequencing data from Staphylococcus aureus subspecies aureus strain USA 300 TCH 1516 sequenced by MacCallum et al. (2009) and retrieved from the GAGE-B repository ( http://ccb.jhu.edu/gage_b/ ). The S.aureus reads were 101 bp long from on average 180 bp long fragments, giving a 45X coverage of the genome. We also used Methylococcus capsulatus strain Bath 16S rRNA V3 region amplicon reads sequenced by Masella et al. (2012) . These reads were 108 bp long and the pairs should have an overlap of exactly 18 bp. Merging options were set to allow a minimum overlap of 10 bp and a maximum of 5 mismatches (USEARCH 7 and 8 have different default values for those), while other options were left at defaults. All programs were run with 8 threads. Merged sequences that could be perfectly aligned to their respective reference sequences (either the entire genome or the specific rRNA region) using BWA MEM ( Li & Durbin, 2009 ) were considered correctly merged. The results are shown in Table 2 . The numbers indicate that USEARCH version 7 merges the most reads for both bacteria, but also has the lowest percentage of correctly merged pairs of those merged. USEARCH version 8 merges the fewest reads, but has the highest percentage of correctly merged reads of those merged. VSEARCH is in the middle by merging more reads than USEARCH 8 with only a small decrease in the percentage of correct merges. VSEARCH is about twice as fast as USEARCH 8 and 4–5 times faster than USEARCH version 7.” | content_tags.variables[12] |
| definition | global pairwise sequence comparison — “Global pairwise sequence comparison is a core functionality of VSEARCH. Several commands compare a query sequence against a database of sequences: all-vs-all alignment ( allpairs_global ), clustering ( cluster_fast , cluster_size , cluster_smallmem ), chimera detection ( uchime_denovo and uchime_ref ) and searching ( usearch_global ). This comparison function proceeds in two phases: an initial heuristic filtering based on shared words, followed by optimal alignment of the query with the most promising candidates.” | content_tags.definitions[1] |
| definition | distance-based greedy clustering — “VSEARCH includes commands to perform de novo clustering using a greedy and heuristic centroid-based algorithm with an adjustable sequence similarity threshold specified with the id option (e.g., 0.97). The input sequences are either processed in the user supplied order ( cluster_smallmem ) or pre-sorted based on length ( cluster_fast ) or abundance (the new cluster_size option). Each input sequence is then used as a query in a search against an initially empty database of centroid sequences. The query sequence is clustered with the first centroid sequence found with similarity equal to or above the threshold. The search is performed using the heuristic approach described above which generally finds the most similar sequences first. If no matches are found, the query sequence becomes the centroid of a new cluster and is added to the database. If maxaccepts is higher than 1, several centroids with sufficient sequence similarity may be found and considered. By default, the query is clustered with the centroid presenting the highest sequence similarity (distance-based greedy clustering, DGC), or, if the sizeorder option is turned on, the centroid with the highest abundance (abundance-based greedy clustering, AGC) ( He et al., 2015 ; Westcott & Schloss, 2015 ; Schloss, 2016 ). VSEARCH performs multi-threaded clustering by searching the database of centroid sequences with several query sequences in parallel. If there are any non-matching query sequences giving rise to new centroids, the required internal comparisons between the query sequences are subsequently performed to achieve correct results. For each cluster, VSEARCH can create a simple multiple sequence alignment using the center star method ( Gusfield, 1993 ) with the centroid as the center sequence, and then compute a consensus sequence and a sequence profile.” | content_tags.definitions[2] |
| definition | abundance-based greedy clustering — “VSEARCH includes commands to perform de novo clustering using a greedy and heuristic centroid-based algorithm with an adjustable sequence similarity threshold specified with the id option (e.g., 0.97). The input sequences are either processed in the user supplied order ( cluster_smallmem ) or pre-sorted based on length ( cluster_fast ) or abundance (the new cluster_size option). Each input sequence is then used as a query in a search against an initially empty database of centroid sequences. The query sequence is clustered with the first centroid sequence found with similarity equal to or above the threshold. The search is performed using the heuristic approach described above which generally finds the most similar sequences first. If no matches are found, the query sequence becomes the centroid of a new cluster and is added to the database. If maxaccepts is higher than 1, several centroids with sufficient sequence similarity may be found and considered. By default, the query is clustered with the centroid presenting the highest sequence similarity (distance-based greedy clustering, DGC), or, if the sizeorder option is turned on, the centroid with the highest abundance (abundance-based greedy clustering, AGC) ( He et al., 2015 ; Westcott & Schloss, 2015 ; Schloss, 2016 ). VSEARCH performs multi-threaded clustering by searching the database of centroid sequences with several query sequences in parallel. If there are any non-matching query sequences giving rise to new centroids, the required internal comparisons between the query sequences are subsequently performed to achieve correct results. For each cluster, VSEARCH can create a simple multiple sequence alignment using the center star method ( Gusfield, 1993 ) with the centroid as the center sequence, and then compute a consensus sequence and a sequence profile.” | content_tags.definitions[3] |
| definition | full-length dereplication — “Full-length dereplication ( derep_fulllength ) is performed using a hash table with an open addressing and linear probing strategy based on the Google CityHash hash functions (written by Geoff Pike and Jyrki Alakuijala, and available at https://github.com/google/cityhash ). The hash table is initially empty. For each input sequence, the hash is computed and a lookup in the hash table is performed. If an identical sequence is found, the input sequence is clustered with the matching sequence; otherwise the input sequence is inserted into the hash table.” | content_tags.definitions[4] |
| definition | prefix dereplication — “Prefix dereplication ( derep_prefix ) is also implemented. As with full-length dereplication, identical sequences are clustered. In addition, sequences that are identical to prefixes of other sequences will also be clustered together. If a sequence is identical to the prefix of multiple sequences, it is generally not defined how prefix clustering should behave. VSEARCH resolves this ambiguity by clustering the sequence with the shortest of the candidate sequences. If they are equally long, priority will be given to the most abundant, the one with the lexicographically smaller identifier or the one with the earliest original position, in that order.” | content_tags.definitions[5] |
| definition | recall — “We independently evaluated the clustering accuracy of USEARCH and VSEARCH as described for Swarm ( Mahé et al., 2014 ) using two mock datasets, one with an even and one with uneven composition of 57 archaea and bacteria. The datasets were first dereplicated. Then the taxonomy of the unique sequences was assigned by a search against the set of rRNA reference sequences representing the species in the mock datasets, carried out with the usearch_global command of USEARCH. The sequences were shuffled randomly 10 times and clustering was performed at 20 different similarity levels ranging from 80% to 99% in steps of 1%. Clustering was carried out in two ways, first using the cluster_fast command that pre-sorts the sequences by length, and then using the cluster_smallmem command that simply processes the sequences in the user-supplied order (in that case, we supplied sequences ordered by decreasing abundance using the sortbysize command). We then compared the clusters obtained to the assigned species and computed the recall, precision and the adjusted Rand index of the classifications. Recall measures to what extent amplicons assigned to the same species are grouped together in the same OTU (i.e., not over-splitting). Precision measures to what extent amplicons in an OTU are assigned to the same species (i.e., not over-grouping). The adjusted Rand index ( Rand, 1971 ; Hubert & Arabie, 1985 ) summarises both precision and recall using a measure of agreement between two clusterings while adjusting for expected values by chance. The average values over the all shufflings are presented in Figs. 2 and 3 for the even and uneven datasets, respectively. For abundance-sorted sequences, the difference between VSEARCH and USEARCH version 8 is negligible. The difference is larger for length-sorted sequences. When using length sorting, USEARCH 8 (as well as version 7 on the even dataset) shows better precision than VSEARCH for similarity levels below 93%. However, OTU delineation is usually performed at higher similarity values, typically 97%. In the case of our benchmark, overall accuracy as measured by the adjusted Rand index is maximised at 95–97% similarity. This is precisely the region where for length sorting at least VSEARCH outperforms USEARCH.” | content_tags.definitions[6] |
| definition | precision — “We independently evaluated the clustering accuracy of USEARCH and VSEARCH as described for Swarm ( Mahé et al., 2014 ) using two mock datasets, one with an even and one with uneven composition of 57 archaea and bacteria. The datasets were first dereplicated. Then the taxonomy of the unique sequences was assigned by a search against the set of rRNA reference sequences representing the species in the mock datasets, carried out with the usearch_global command of USEARCH. The sequences were shuffled randomly 10 times and clustering was performed at 20 different similarity levels ranging from 80% to 99% in steps of 1%. Clustering was carried out in two ways, first using the cluster_fast command that pre-sorts the sequences by length, and then using the cluster_smallmem command that simply processes the sequences in the user-supplied order (in that case, we supplied sequences ordered by decreasing abundance using the sortbysize command). We then compared the clusters obtained to the assigned species and computed the recall, precision and the adjusted Rand index of the classifications. Recall measures to what extent amplicons assigned to the same species are grouped together in the same OTU (i.e., not over-splitting). Precision measures to what extent amplicons in an OTU are assigned to the same species (i.e., not over-grouping). The adjusted Rand index ( Rand, 1971 ; Hubert & Arabie, 1985 ) summarises both precision and recall using a measure of agreement between two clusterings while adjusting for expected values by chance. The average values over the all shufflings are presented in Figs. 2 and 3 for the even and uneven datasets, respectively. For abundance-sorted sequences, the difference between VSEARCH and USEARCH version 8 is negligible. The difference is larger for length-sorted sequences. When using length sorting, USEARCH 8 (as well as version 7 on the even dataset) shows better precision than VSEARCH for similarity levels below 93%. However, OTU delineation is usually performed at higher similarity values, typically 97%. In the case of our benchmark, overall accuracy as measured by the adjusted Rand index is maximised at 95–97% similarity. This is precisely the region where for length sorting at least VSEARCH outperforms USEARCH.” | content_tags.definitions[7] |
| definition | adjusted Rand index — “We independently evaluated the clustering accuracy of USEARCH and VSEARCH as described for Swarm ( Mahé et al., 2014 ) using two mock datasets, one with an even and one with uneven composition of 57 archaea and bacteria. The datasets were first dereplicated. Then the taxonomy of the unique sequences was assigned by a search against the set of rRNA reference sequences representing the species in the mock datasets, carried out with the usearch_global command of USEARCH. The sequences were shuffled randomly 10 times and clustering was performed at 20 different similarity levels ranging from 80% to 99% in steps of 1%. Clustering was carried out in two ways, first using the cluster_fast command that pre-sorts the sequences by length, and then using the cluster_smallmem command that simply processes the sequences in the user-supplied order (in that case, we supplied sequences ordered by decreasing abundance using the sortbysize command). We then compared the clusters obtained to the assigned species and computed the recall, precision and the adjusted Rand index of the classifications. Recall measures to what extent amplicons assigned to the same species are grouped together in the same OTU (i.e., not over-splitting). Precision measures to what extent amplicons in an OTU are assigned to the same species (i.e., not over-grouping). The adjusted Rand index ( Rand, 1971 ; Hubert & Arabie, 1985 ) summarises both precision and recall using a measure of agreement between two clusterings while adjusting for expected values by chance. The average values over the all shufflings are presented in Figs. 2 and 3 for the even and uneven datasets, respectively. For abundance-sorted sequences, the difference between VSEARCH and USEARCH version 8 is negligible. The difference is larger for length-sorted sequences. When using length sorting, USEARCH 8 (as well as version 7 on the even dataset) shows better precision than VSEARCH for similarity levels below 93%. However, OTU delineation is usually performed at higher similarity values, typically 97%. In the case of our benchmark, overall accuracy as measured by the adjusted Rand index is maximised at 95–97% similarity. This is precisely the region where for length sorting at least VSEARCH outperforms USEARCH.” | content_tags.definitions[8] |
| definition | correctly merged — “Evaluation of paired-end reads merging performance was carried out in a manner similar to that described for the evaluation of PEAR ( Zhang et al., 2014 ). We used whole genome sequencing data from Staphylococcus aureus subspecies aureus strain USA 300 TCH 1516 sequenced by MacCallum et al. (2009) and retrieved from the GAGE-B repository ( http://ccb.jhu.edu/gage_b/ ). The S.aureus reads were 101 bp long from on average 180 bp long fragments, giving a 45X coverage of the genome. We also used Methylococcus capsulatus strain Bath 16S rRNA V3 region amplicon reads sequenced by Masella et al. (2012) . These reads were 108 bp long and the pairs should have an overlap of exactly 18 bp. Merging options were set to allow a minimum overlap of 10 bp and a maximum of 5 mismatches (USEARCH 7 and 8 have different default values for those), while other options were left at defaults. All programs were run with 8 threads. Merged sequences that could be perfectly aligned to their respective reference sequences (either the entire genome or the specific rRNA region) using BWA MEM ( Li & Durbin, 2009 ) were considered correctly merged. The results are shown in Table 2 . The numbers indicate that USEARCH version 7 merges the most reads for both bacteria, but also has the lowest percentage of correctly merged pairs of those merged. USEARCH version 8 merges the fewest reads, but has the highest percentage of correctly merged reads of those merged. VSEARCH is in the middle by merging more reads than USEARCH 8 with only a small decrease in the percentage of correct merges. VSEARCH is about twice as fast as USEARCH 8 and 4–5 times faster than USEARCH version 7.” | content_tags.definitions[9] |
| concept | VSEARCH — not defined in this paper's own words; open multithreaded nucleotide processing suite — “VSEARCH is an open source and free of charge multithreaded 64-bit tool for processing and preparing metagenomics, genomics and population genomics nucleotide sequence data. It is designed as an alternative to the widely used USEARCH tool ( Edgar, 2010 ) for which the source code is not publicly available, algorithm details are only rudimentarily described, and only a memory-confined 32-bit version is freely available for academic use.” | concepts[0] |
| concept | open source and free of charge multithreaded 64-bit tool — not defined in this paper's own words; licensing and architecture class of VSEARCH — “VSEARCH is an open source and free of charge multithreaded 64-bit tool for processing and preparing metagenomics, genomics and population genomics nucleotide sequence data. It is designed as an alternative to the widely used USEARCH tool ( Edgar, 2010 ) for which the source code is not publicly available, algorithm details are only rudimentarily described, and only a memory-confined 32-bit version is freely available for academic use.” | concepts[1] |
| concept | metagenomics — not defined in this paper's own words; microbial-community nucleotide analysis domain — “VSEARCH is an open source and free of charge multithreaded 64-bit tool for processing and preparing metagenomics, genomics and population genomics nucleotide sequence data. It is designed as an alternative to the widely used USEARCH tool ( Edgar, 2010 ) for which the source code is not publicly available, algorithm details are only rudimentarily described, and only a memory-confined 32-bit version is freely available for academic use.” | concepts[2] |
| concept | nucleotide sequence data — not defined in this paper's own words; FASTA/FASTQ sequence inputs — “VSEARCH is an open source and free of charge multithreaded 64-bit tool for processing and preparing metagenomics, genomics and population genomics nucleotide sequence data. It is designed as an alternative to the widely used USEARCH tool ( Edgar, 2010 ) for which the source code is not publicly available, algorithm details are only rudimentarily described, and only a memory-confined 32-bit version is freely available for academic use.” | concepts[3] |
| concept | USEARCH — not defined in this paper's own words; closed-source sequence-analysis comparator — “VSEARCH is an open source and free of charge multithreaded 64-bit tool for processing and preparing metagenomics, genomics and population genomics nucleotide sequence data. It is designed as an alternative to the widely used USEARCH tool ( Edgar, 2010 ) for which the source code is not publicly available, algorithm details are only rudimentarily described, and only a memory-confined 32-bit version is freely available for academic use.” | concepts[4] |
| concept | words shared by the query and target sequences — not defined in this paper's own words; heuristic candidate similarity signal — “When searching nucleotide sequences, VSEARCH uses a fast heuristic based on words shared by the query and target sequences in order to quickly identify similar sequences, a similar strategy is probably used in USEARCH. VSEARCH then performs optimal global sequence alignment of the query against potential target sequences, using full dynamic programming instead of the seed-and-extend heuristic used by USEARCH. Pairwise alignments are computed in parallel using vectorisation and multiple threads.” | concepts[5] |
| concept | optimal global sequence alignment — not defined in this paper's own words; exact final query-target comparison — “When searching nucleotide sequences, VSEARCH uses a fast heuristic based on words shared by the query and target sequences in order to quickly identify similar sequences, a similar strategy is probably used in USEARCH. VSEARCH then performs optimal global sequence alignment of the query against potential target sequences, using full dynamic programming instead of the seed-and-extend heuristic used by USEARCH. Pairwise alignments are computed in parallel using vectorisation and multiple threads.” | concepts[6] |
| concept | full dynamic programming — not defined in this paper's own words; optimal alignment implementation — “When searching nucleotide sequences, VSEARCH uses a fast heuristic based on words shared by the query and target sequences in order to quickly identify similar sequences, a similar strategy is probably used in USEARCH. VSEARCH then performs optimal global sequence alignment of the query against potential target sequences, using full dynamic programming instead of the seed-and-extend heuristic used by USEARCH. Pairwise alignments are computed in parallel using vectorisation and multiple threads.” | concepts[7] |
| concept | seed-and-extend heuristic — not defined in this paper's own words; USEARCH alignment strategy comparator — “When searching nucleotide sequences, VSEARCH uses a fast heuristic based on words shared by the query and target sequences in order to quickly identify similar sequences, a similar strategy is probably used in USEARCH. VSEARCH then performs optimal global sequence alignment of the query against potential target sequences, using full dynamic programming instead of the seed-and-extend heuristic used by USEARCH. Pairwise alignments are computed in parallel using vectorisation and multiple threads.” | concepts[8] |
| concept | vectorisation — not defined in this paper's own words; parallel low-level alignment computation — “When searching nucleotide sequences, VSEARCH uses a fast heuristic based on words shared by the query and target sequences in order to quickly identify similar sequences, a similar strategy is probably used in USEARCH. VSEARCH then performs optimal global sequence alignment of the query against potential target sequences, using full dynamic programming instead of the seed-and-extend heuristic used by USEARCH. Pairwise alignments are computed in parallel using vectorisation and multiple threads.” | concepts[9] |
| concept | multiple threads — not defined in this paper's own words; parallel CPU execution — “When searching nucleotide sequences, VSEARCH uses a fast heuristic based on words shared by the query and target sequences in order to quickly identify similar sequences, a similar strategy is probably used in USEARCH. VSEARCH then performs optimal global sequence alignment of the query against potential target sequences, using full dynamic programming instead of the seed-and-extend heuristic used by USEARCH. Pairwise alignments are computed in parallel using vectorisation and multiple threads.” | concepts[10] |
| concept | global pairwise sequence comparison — not defined in this paper's own words; two-phase filter and alignment search — “Global pairwise sequence comparison is a core functionality of VSEARCH. Several commands compare a query sequence against a database of sequences: all-vs-all alignment ( allpairs_global ), clustering ( cluster_fast , cluster_size , cluster_smallmem ), chimera detection ( uchime_denovo and uchime_ref ) and searching ( usearch_global ). This comparison function proceeds in two phases: an initial heuristic filtering based on shared words, followed by optimal alignment of the query with the most promising candidates.” | concepts[11] |
| concept | core functionality — not defined in this paper's own words; central VSEARCH capability — “Global pairwise sequence comparison is a core functionality of VSEARCH. Several commands compare a query sequence against a database of sequences: all-vs-all alignment ( allpairs_global ), clustering ( cluster_fast , cluster_size , cluster_smallmem ), chimera detection ( uchime_denovo and uchime_ref ) and searching ( usearch_global ). This comparison function proceeds in two phases: an initial heuristic filtering based on shared words, followed by optimal alignment of the query with the most promising candidates.” | concepts[12] |
| concept | shared words — not defined in this paper's own words; overlapping k-mer candidate evidence — “The first phase is presumably quite similar to USEARCH ( Edgar, 2010 ). Heuristics are used to identify a small set of database sequences that have many words in common with the query sequence. Words (or k -mers) consist of a certain number k of consecutive nucleotides of a sequence (8 by default, adjustable with the wordlength option). All overlapping words are included. A sequence of length n then contains at most n − k + 1 unique words. VSEARCH counts the number of shared words between the query and each database sequence. Words that appear multiple times are counted only once. To count the words in the database sequences quickly, VSEARCH creates an index of all the 4 k possible distinct words and stores information about which database sequences they appear in. For extremely frequent words, the set of database sequences is represented by a bitmap; otherwise the set is stored as a list. A finer control of k -mer indexing is described for USEARCH by the pattern (binary string indicating which positions must match) and slots options. USEARCH has such options but seems to ignore them. Currently, VSEARCH ignores these two options too. The minimum number of shared words required may be specified with the minwordmatches option (10 by default), but a lower value is automatically used for short or simple query sequences with less than 10 unique words.” | concepts[13] |
| concept | Words — not defined in this paper's own words; fixed-length consecutive nucleotide substrings — “The first phase is presumably quite similar to USEARCH ( Edgar, 2010 ). Heuristics are used to identify a small set of database sequences that have many words in common with the query sequence. Words (or k -mers) consist of a certain number k of consecutive nucleotides of a sequence (8 by default, adjustable with the wordlength option). All overlapping words are included. A sequence of length n then contains at most n − k + 1 unique words. VSEARCH counts the number of shared words between the query and each database sequence. Words that appear multiple times are counted only once. To count the words in the database sequences quickly, VSEARCH creates an index of all the 4 k possible distinct words and stores information about which database sequences they appear in. For extremely frequent words, the set of database sequences is represented by a bitmap; otherwise the set is stored as a list. A finer control of k -mer indexing is described for USEARCH by the pattern (binary string indicating which positions must match) and slots options. USEARCH has such options but seems to ignore them. Currently, VSEARCH ignores these two options too. The minimum number of shared words required may be specified with the minwordmatches option (10 by default), but a lower value is automatically used for short or simple query sequences with less than 10 unique words.” | concepts[14] |
| concept | bitmap — not defined in this paper's own words; compact representation for frequent-word sequence sets — “The first phase is presumably quite similar to USEARCH ( Edgar, 2010 ). Heuristics are used to identify a small set of database sequences that have many words in common with the query sequence. Words (or k -mers) consist of a certain number k of consecutive nucleotides of a sequence (8 by default, adjustable with the wordlength option). All overlapping words are included. A sequence of length n then contains at most n − k + 1 unique words. VSEARCH counts the number of shared words between the query and each database sequence. Words that appear multiple times are counted only once. To count the words in the database sequences quickly, VSEARCH creates an index of all the 4 k possible distinct words and stores information about which database sequences they appear in. For extremely frequent words, the set of database sequences is represented by a bitmap; otherwise the set is stored as a list. A finer control of k -mer indexing is described for USEARCH by the pattern (binary string indicating which positions must match) and slots options. USEARCH has such options but seems to ignore them. Currently, VSEARCH ignores these two options too. The minimum number of shared words required may be specified with the minwordmatches option (10 by default), but a lower value is automatically used for short or simple query sequences with less than 10 unique words.” | concepts[15] |
| concept | optimal global alignment — not defined in this paper's own words; exact second-phase sequence comparison — “In the second phase, searching proceeds by considering the database sequences in a specific order, starting with the sequence having the largest number of words in common with the query, and proceeding with a decreasing number of shared words. If two database sequences have the same number of words in common with the query, the shortest sequence is considered first. The query sequence is compared with each database sequence by computing the optimal global alignment. The alignment is performed using a multi-threaded and vectorised full dynamic programming algorithm ( Needleman & Wunsch, 1970 ) adapted from SWIPE ( Rognes, 2011 ). Due to the extreme memory requirements of this method when aligning two long sequences, an alternative algorithm described by Hirschberg (1975) and Myers & Miller (1988) is used when the product of the length of the sequences is greater than 25,000,000, corresponding to aligning two 5,000 bp sequences. This alternative algorithm uses only a linear amount of memory but is considerably slower. This second phase is probably where USEARCH and VSEARCH differ the most, as USEARCH by default presumably performs heuristic seed-and-extend alignment similar to BLAST ( Altschul et al., 1997 ), and only performs optimal alignment when the option fulldp (full dynamic programming) is used. Computing the optimal pairwise alignment in each case gives more accurate results but is also computationally more demanding. The efficient and vectorised full dynamic programming implementation in VSEARCH compensates that extra cost, at least for sequences that are not too long.” | concepts[16] |
| concept | alternative algorithm — not defined in this paper's own words; linear-memory long-sequence alignment — “In the second phase, searching proceeds by considering the database sequences in a specific order, starting with the sequence having the largest number of words in common with the query, and proceeding with a decreasing number of shared words. If two database sequences have the same number of words in common with the query, the shortest sequence is considered first. The query sequence is compared with each database sequence by computing the optimal global alignment. The alignment is performed using a multi-threaded and vectorised full dynamic programming algorithm ( Needleman & Wunsch, 1970 ) adapted from SWIPE ( Rognes, 2011 ). Due to the extreme memory requirements of this method when aligning two long sequences, an alternative algorithm described by Hirschberg (1975) and Myers & Miller (1988) is used when the product of the length of the sequences is greater than 25,000,000, corresponding to aligning two 5,000 bp sequences. This alternative algorithm uses only a linear amount of memory but is considerably slower. This second phase is probably where USEARCH and VSEARCH differ the most, as USEARCH by default presumably performs heuristic seed-and-extend alignment similar to BLAST ( Altschul et al., 1997 ), and only performs optimal alignment when the option fulldp (full dynamic programming) is used. Computing the optimal pairwise alignment in each case gives more accurate results but is also computationally more demanding. The efficient and vectorised full dynamic programming implementation in VSEARCH compensates that extra cost, at least for sequences that are not too long.” | concepts[17] |
| concept | database sequence — not defined in this paper's own words; candidate search target — “If the resulting alignment indicates a similarity equal to or greater than the value specified with the id option, the database sequence is accepted. If the similarity is too low, it is rejected. Several other options may also be used to determine how similarity is computed ( iddef , as USEARCH used to offer up to version 6), and which sequences should be accepted and rejected, either before (e.g., self , minqsize ) or after alignment (e.g., maxgaps , maxsubs ). The search is terminated when either a certain number of sequences have been accepted (1 by default, adjustable with the maxaccepts option), or a certain number of sequences have been rejected (32 by default, adjustable with the maxrejects option). The accepted sequences are sorted by sequence similarity and presented as the search results.” | concepts[18] |
| concept | similarity equal to or greater than the value specified with the id option — not defined in this paper's own words; search acceptance criterion — “If the resulting alignment indicates a similarity equal to or greater than the value specified with the id option, the database sequence is accepted. If the similarity is too low, it is rejected. Several other options may also be used to determine how similarity is computed ( iddef , as USEARCH used to offer up to version 6), and which sequences should be accepted and rejected, either before (e.g., self , minqsize ) or after alignment (e.g., maxgaps , maxsubs ). The search is terminated when either a certain number of sequences have been accepted (1 by default, adjustable with the maxaccepts option), or a certain number of sequences have been rejected (32 by default, adjustable with the maxrejects option). The accepted sequences are sorted by sequence similarity and presented as the search results.” | concepts[19] |
| concept | centroid-based algorithm — not defined in this paper's own words; greedy clustering around representative sequences — “VSEARCH includes commands to perform de novo clustering using a greedy and heuristic centroid-based algorithm with an adjustable sequence similarity threshold specified with the id option (e.g., 0.97). The input sequences are either processed in the user supplied order ( cluster_smallmem ) or pre-sorted based on length ( cluster_fast ) or abundance (the new cluster_size option). Each input sequence is then used as a query in a search against an initially empty database of centroid sequences. The query sequence is clustered with the first centroid sequence found with similarity equal to or above the threshold. The search is performed using the heuristic approach described above which generally finds the most similar sequences first. If no matches are found, the query sequence becomes the centroid of a new cluster and is added to the database. If maxaccepts is higher than 1, several centroids with sufficient sequence similarity may be found and considered. By default, the query is clustered with the centroid presenting the highest sequence similarity (distance-based greedy clustering, DGC), or, if the sizeorder option is turned on, the centroid with the highest abundance (abundance-based greedy clustering, AGC) ( He et al., 2015 ; Westcott & Schloss, 2015 ; Schloss, 2016 ). VSEARCH performs multi-threaded clustering by searching the database of centroid sequences with several query sequences in parallel. If there are any non-matching query sequences giving rise to new centroids, the required internal comparisons between the query sequences are subsequently performed to achieve correct results. For each cluster, VSEARCH can create a simple multiple sequence alignment using the center star method ( Gusfield, 1993 ) with the centroid as the center sequence, and then compute a consensus sequence and a sequence profile.” | concepts[20] |
| concept | sequence similarity threshold — not defined in this paper's own words; cluster membership cutoff — “VSEARCH includes commands to perform de novo clustering using a greedy and heuristic centroid-based algorithm with an adjustable sequence similarity threshold specified with the id option (e.g., 0.97). The input sequences are either processed in the user supplied order ( cluster_smallmem ) or pre-sorted based on length ( cluster_fast ) or abundance (the new cluster_size option). Each input sequence is then used as a query in a search against an initially empty database of centroid sequences. The query sequence is clustered with the first centroid sequence found with similarity equal to or above the threshold. The search is performed using the heuristic approach described above which generally finds the most similar sequences first. If no matches are found, the query sequence becomes the centroid of a new cluster and is added to the database. If maxaccepts is higher than 1, several centroids with sufficient sequence similarity may be found and considered. By default, the query is clustered with the centroid presenting the highest sequence similarity (distance-based greedy clustering, DGC), or, if the sizeorder option is turned on, the centroid with the highest abundance (abundance-based greedy clustering, AGC) ( He et al., 2015 ; Westcott & Schloss, 2015 ; Schloss, 2016 ). VSEARCH performs multi-threaded clustering by searching the database of centroid sequences with several query sequences in parallel. If there are any non-matching query sequences giving rise to new centroids, the required internal comparisons between the query sequences are subsequently performed to achieve correct results. For each cluster, VSEARCH can create a simple multiple sequence alignment using the center star method ( Gusfield, 1993 ) with the centroid as the center sequence, and then compute a consensus sequence and a sequence profile.” | concepts[21] |
| concept | distance-based greedy clustering — not defined in this paper's own words; highest-similarity centroid assignment — “VSEARCH includes commands to perform de novo clustering using a greedy and heuristic centroid-based algorithm with an adjustable sequence similarity threshold specified with the id option (e.g., 0.97). The input sequences are either processed in the user supplied order ( cluster_smallmem ) or pre-sorted based on length ( cluster_fast ) or abundance (the new cluster_size option). Each input sequence is then used as a query in a search against an initially empty database of centroid sequences. The query sequence is clustered with the first centroid sequence found with similarity equal to or above the threshold. The search is performed using the heuristic approach described above which generally finds the most similar sequences first. If no matches are found, the query sequence becomes the centroid of a new cluster and is added to the database. If maxaccepts is higher than 1, several centroids with sufficient sequence similarity may be found and considered. By default, the query is clustered with the centroid presenting the highest sequence similarity (distance-based greedy clustering, DGC), or, if the sizeorder option is turned on, the centroid with the highest abundance (abundance-based greedy clustering, AGC) ( He et al., 2015 ; Westcott & Schloss, 2015 ; Schloss, 2016 ). VSEARCH performs multi-threaded clustering by searching the database of centroid sequences with several query sequences in parallel. If there are any non-matching query sequences giving rise to new centroids, the required internal comparisons between the query sequences are subsequently performed to achieve correct results. For each cluster, VSEARCH can create a simple multiple sequence alignment using the center star method ( Gusfield, 1993 ) with the centroid as the center sequence, and then compute a consensus sequence and a sequence profile.” | concepts[22] |
| concept | abundance-based greedy clustering — not defined in this paper's own words; highest-abundance centroid assignment — “VSEARCH includes commands to perform de novo clustering using a greedy and heuristic centroid-based algorithm with an adjustable sequence similarity threshold specified with the id option (e.g., 0.97). The input sequences are either processed in the user supplied order ( cluster_smallmem ) or pre-sorted based on length ( cluster_fast ) or abundance (the new cluster_size option). Each input sequence is then used as a query in a search against an initially empty database of centroid sequences. The query sequence is clustered with the first centroid sequence found with similarity equal to or above the threshold. The search is performed using the heuristic approach described above which generally finds the most similar sequences first. If no matches are found, the query sequence becomes the centroid of a new cluster and is added to the database. If maxaccepts is higher than 1, several centroids with sufficient sequence similarity may be found and considered. By default, the query is clustered with the centroid presenting the highest sequence similarity (distance-based greedy clustering, DGC), or, if the sizeorder option is turned on, the centroid with the highest abundance (abundance-based greedy clustering, AGC) ( He et al., 2015 ; Westcott & Schloss, 2015 ; Schloss, 2016 ). VSEARCH performs multi-threaded clustering by searching the database of centroid sequences with several query sequences in parallel. If there are any non-matching query sequences giving rise to new centroids, the required internal comparisons between the query sequences are subsequently performed to achieve correct results. For each cluster, VSEARCH can create a simple multiple sequence alignment using the center star method ( Gusfield, 1993 ) with the centroid as the center sequence, and then compute a consensus sequence and a sequence profile.” | concepts[23] |
| concept | Full-length dereplication — not defined in this paper's own words; hash grouping of identical complete sequences — “Full-length dereplication ( derep_fulllength ) is performed using a hash table with an open addressing and linear probing strategy based on the Google CityHash hash functions (written by Geoff Pike and Jyrki Alakuijala, and available at https://github.com/google/cityhash ). The hash table is initially empty. For each input sequence, the hash is computed and a lookup in the hash table is performed. If an identical sequence is found, the input sequence is clustered with the matching sequence; otherwise the input sequence is inserted into the hash table.” | concepts[24] |
| concept | hash table — not defined in this paper's own words; lookup structure for exact sequence identity — “Full-length dereplication ( derep_fulllength ) is performed using a hash table with an open addressing and linear probing strategy based on the Google CityHash hash functions (written by Geoff Pike and Jyrki Alakuijala, and available at https://github.com/google/cityhash ). The hash table is initially empty. For each input sequence, the hash is computed and a lookup in the hash table is performed. If an identical sequence is found, the input sequence is clustered with the matching sequence; otherwise the input sequence is inserted into the hash table.” | concepts[25] |
| concept | Prefix dereplication — not defined in this paper's own words; hash grouping by full or prefix identity — “Prefix dereplication ( derep_prefix ) is also implemented. As with full-length dereplication, identical sequences are clustered. In addition, sequences that are identical to prefixes of other sequences will also be clustered together. If a sequence is identical to the prefix of multiple sequences, it is generally not defined how prefix clustering should behave. VSEARCH resolves this ambiguity by clustering the sequence with the shortest of the candidate sequences. If they are equally long, priority will be given to the most abundant, the one with the lexicographically smaller identifier or the one with the earliest original position, in that order.” | concepts[26] |
| concept | Fowler–Noll–Vo 1a hash function — not defined in this paper's own words; incremental prefix hash — “In order to identify matches in the hash table during prefix dereplication, a hash is computed for each full-length input sequence and all its prefixes. The hash function used is the 64-bit Fowler–Noll–Vo 1a hash function ( Fowler, Noll & Vo, 1991 ), which is simple and quick to compute for such a series of sequences by adding one nucleotide at a time.” | concepts[27] |
| concept | SHA-1 — not defined in this paper's own words; sequence digest relabeling option — “The sequences resulting from dereplication and many other commands may be relabeled with a given prefix followed by a sequentially increasing number. VSEARCH exclusively also offers the possibility of relabelling each sequence with the SHA-1 ( Eastlake & Jones, 2001 ) or MD5 ( Rivest, 1992 ) message digest (hash) of the sequence. These are strings that are highly likely to be unique for each sequence. Before the digest is computed, the sequence is normalized by converting U’s to T’s and converting all symbols to upper case. VSEARCH includes public domain code for the MD5 algorithm written by Alexander Peslyak, and for SHA1 by Steve Reid and others.” | concepts[28] |
| concept | MD5 — not defined in this paper's own words; sequence digest relabeling option — “The sequences resulting from dereplication and many other commands may be relabeled with a given prefix followed by a sequentially increasing number. VSEARCH exclusively also offers the possibility of relabelling each sequence with the SHA-1 ( Eastlake & Jones, 2001 ) or MD5 ( Rivest, 1992 ) message digest (hash) of the sequence. These are strings that are highly likely to be unique for each sequence. Before the digest is computed, the sequence is normalized by converting U’s to T’s and converting all symbols to upper case. VSEARCH includes public domain code for the MD5 algorithm written by Alexander Peslyak, and for SHA1 by Steve Reid and others.” | concepts[29] |
| concept | rereplication — not defined in this paper's own words; reconstruction of multiplicities after dereplication — “VSEARCH also includes a new command ( rereplicate ) to perform rereplication that can be used to recreate datasets as they were before full-length dereplication, but of course original labels cannot be recreated.” | concepts[30] |
| concept | Chimeras — not defined in this paper's own words; artefactual hybrid sequences — “Chimeras are detected either de novo ( uchime_denovo command) or with a reference database ( uchime_ref command) using the UCHIME algorithm described by Edgar et al. (2011) . VSEARCH will divide each query sequence into four segments and look for similarity of each segment to sequences in the set of potential parents using the heuristic search function described earlier. It will consider the four best candidates for each segment using maxaccepts 4 and maxrejects 16, and an id threshold of 0.55. VSEARCH optionally outputs borderline sequences, that is, sequences having a high enough score (as specified with the minh option) but with too small a divergence from the closest parent (as specified with the mindiv option). Multi-threading is supported for reference-based chimera detection.” | concepts[31] |
| concept | UCHIME algorithm — not defined in this paper's own words; reference or de novo chimera scoring — “Chimeras are detected either de novo ( uchime_denovo command) or with a reference database ( uchime_ref command) using the UCHIME algorithm described by Edgar et al. (2011) . VSEARCH will divide each query sequence into four segments and look for similarity of each segment to sequences in the set of potential parents using the heuristic search function described earlier. It will consider the four best candidates for each segment using maxaccepts 4 and maxrejects 16, and an id threshold of 0.55. VSEARCH optionally outputs borderline sequences, that is, sequences having a high enough score (as specified with the minh option) but with too small a divergence from the closest parent (as specified with the mindiv option). Multi-threading is supported for reference-based chimera detection.” | concepts[32] |
| concept | Dust algorithm — not defined in this paper's own words; simple-repeat and low-complexity masking — “VSEARCH includes a highly optimized and parallelized implementation of the Dust algorithm by Tatusov and Lipman for masking of simple repeats and low-complexity nucleotide sequences. It is considerably faster than the implementation of the same algorithm in USEARCH. Their code available at ftp://ftp.ncbi.nlm.nih.gov/pub/tatusov/dust/version1/src/ is in the public domain. VSEARCH uses this algorithm by default, while USEARCH by default uses an undocumented rapid masking algorithm called fastnucleo . VSEARCH performs soft-masking automatically for the pairwise alignment, search, clustering and chimera detection commands. This behaviour can be controlled with the hardmask option to replace masked symbols with N’s instead of lower-casing them, and the dbmask and qmask options, which selects the masking algorithm (none, dust or soft) used for the database and query sequences, respectively. Masking may also be performed explicitly on an input file using the fastx_mask and maskfasta commands.” | concepts[33] |
| concept | soft-masking — not defined in this paper's own words; lowercase masking before analysis — “VSEARCH includes a highly optimized and parallelized implementation of the Dust algorithm by Tatusov and Lipman for masking of simple repeats and low-complexity nucleotide sequences. It is considerably faster than the implementation of the same algorithm in USEARCH. Their code available at ftp://ftp.ncbi.nlm.nih.gov/pub/tatusov/dust/version1/src/ is in the public domain. VSEARCH uses this algorithm by default, while USEARCH by default uses an undocumented rapid masking algorithm called fastnucleo . VSEARCH performs soft-masking automatically for the pairwise alignment, search, clustering and chimera detection commands. This behaviour can be controlled with the hardmask option to replace masked symbols with N’s instead of lower-casing them, and the dbmask and qmask options, which selects the masking algorithm (none, dust or soft) used for the database and query sequences, respectively. Masking may also be performed explicitly on an input file using the fastx_mask and maskfasta commands.” | concepts[34] |
| concept | FASTQ — not defined in this paper's own words; sequence and quality-score file format — “VSEARCH includes commands to detect the FASTQ file version and the range of quality scores used ( fastq_chars ), as well as two commands for computing sequence quality statistics ( fastq_stats and fastq_eestats ). It can also truncate and filter sequences in FASTQ files based on various criteria ( fastq_filter ). A new command is added to convert between different FASTQ file versions and quality encodings ( fastq_convert ), e.g., from the old Phred+64 encoded Illumina FASTQ files to the newer Phred+33 format.” | concepts[35] |
| concept | paired-end reads — not defined in this paper's own words; forward/reverse sequence pairs to merge — “Merging of paired-end reads is supported by VSEARCH using the fastq_mergepairs command. The method used has some similarity to PEAR ( Zhang et al., 2014 ) and recognises options similar to USEARCH. The algorithm computes the optimal ungapped alignment of the overlapping region of the forward sequence and the reverse-complemented reverse sequence. The alignment requires a minimum overlap length (specified with the fastq_minovlen option, default 10), a maximum number of mismatches ( fastq_maxdiffs option, default 5), and a minimum and maximum length of the merged sequence ( fastq_minmergelen option, default 1, and fastq_maxmergelen option, default infinite). Staggered read pairs, i.e., read pairs where the 3′ end of the reverse read has an overhang to the left of the 5′ end of the forward read, are not allowed by default, but may be turned on by the fastq_allowmergestagger option. VSEARCH uses a match score (alpha) of +4 and a mismatch score (beta) of −5 for perfect quality residues. These scores are weighted by the probability that these two residues really match or mismatch, respectively, taking quality scores into account. These probabilities are computed in a way similar to PEAR score method 2 described in ‘Algorithms and implementation’ of the PEAR paper ( Zhang et al., 2014 ), but VSEARCH assumes all nucleotide background frequencies are 0.25. When merging sequences, VSEARCH computes posterior quality scores for the overlapping regions as described by Edgar & Flyvbjerg (2015) . For speed, scores and probabilities are pre-computed for all possible quality scores.” | concepts[36] |
| concept | optimal ungapped alignment — not defined in this paper's own words; overlap computation for read merging — “Merging of paired-end reads is supported by VSEARCH using the fastq_mergepairs command. The method used has some similarity to PEAR ( Zhang et al., 2014 ) and recognises options similar to USEARCH. The algorithm computes the optimal ungapped alignment of the overlapping region of the forward sequence and the reverse-complemented reverse sequence. The alignment requires a minimum overlap length (specified with the fastq_minovlen option, default 10), a maximum number of mismatches ( fastq_maxdiffs option, default 5), and a minimum and maximum length of the merged sequence ( fastq_minmergelen option, default 1, and fastq_maxmergelen option, default infinite). Staggered read pairs, i.e., read pairs where the 3′ end of the reverse read has an overhang to the left of the 5′ end of the forward read, are not allowed by default, but may be turned on by the fastq_allowmergestagger option. VSEARCH uses a match score (alpha) of +4 and a mismatch score (beta) of −5 for perfect quality residues. These scores are weighted by the probability that these two residues really match or mismatch, respectively, taking quality scores into account. These probabilities are computed in a way similar to PEAR score method 2 described in ‘Algorithms and implementation’ of the PEAR paper ( Zhang et al., 2014 ), but VSEARCH assumes all nucleotide background frequencies are 0.25. When merging sequences, VSEARCH computes posterior quality scores for the overlapping regions as described by Edgar & Flyvbjerg (2015) . For speed, scores and probabilities are pre-computed for all possible quality scores.” | concepts[37] |
| concept | posterior quality scores — not defined in this paper's own words; merged-overlap confidence estimates — “Merging of paired-end reads is supported by VSEARCH using the fastq_mergepairs command. The method used has some similarity to PEAR ( Zhang et al., 2014 ) and recognises options similar to USEARCH. The algorithm computes the optimal ungapped alignment of the overlapping region of the forward sequence and the reverse-complemented reverse sequence. The alignment requires a minimum overlap length (specified with the fastq_minovlen option, default 10), a maximum number of mismatches ( fastq_maxdiffs option, default 5), and a minimum and maximum length of the merged sequence ( fastq_minmergelen option, default 1, and fastq_maxmergelen option, default infinite). Staggered read pairs, i.e., read pairs where the 3′ end of the reverse read has an overhang to the left of the 5′ end of the forward read, are not allowed by default, but may be turned on by the fastq_allowmergestagger option. VSEARCH uses a match score (alpha) of +4 and a mismatch score (beta) of −5 for perfect quality residues. These scores are weighted by the probability that these two residues really match or mismatch, respectively, taking quality scores into account. These probabilities are computed in a way similar to PEAR score method 2 described in ‘Algorithms and implementation’ of the PEAR paper ( Zhang et al., 2014 ), but VSEARCH assumes all nucleotide background frequencies are 0.25. When merging sequences, VSEARCH computes posterior quality scores for the overlapping regions as described by Edgar & Flyvbjerg (2015) . For speed, scores and probabilities are pre-computed for all possible quality scores.” | concepts[38] |
| concept | pseudo random number generator — not defined in this paper's own words; seedable shuffle engine — “VSEARCH can sort FASTA files by decreasing sequence length ( sortbylength ) or abundance ( sortbysize ). VSEARCH can also perform shuffling of FASTA files in random order ( shuffle ). A seed value for the pseudo random number generator may be provided by the randseed option to obtain replicable results.” | concepts[39] |
| concept | subsampled — not defined in this paper's own words; random selection of input sequence count or percentage — “Sequences in FASTA and FASTQ files can be subsampled ( fastx_subsample ) by randomly extracting a certain number ( sample_size ) or percentage ( sample_pct ) of the input sequences. Abundances may be taken into account, giving results as if the input sequences were rereplicated, subsampled and then dereplicated.” | concepts[40] |
| concept | drop-in replacement — not defined in this paper's own words; command-compatible substitute — “The same command and option names as in USEARCH version 7 have generally been used in order to make VSEARCH an almost drop-in replacement. In fact, in QIIME many commands will run fine if an alias or link from usearch to vsearch is made. Detailed documentation of VSEARCH is available as a man page. We will consider adding further commands and options to VSEARCH in the future.” | concepts[41] |
| concept | RFAM — not defined in this paper's own words; RNA-family search benchmark — “Evaluation of search accuracy was carried out as described in the USEARCH paper ( Edgar, 2010 ), its supplementary, and on the website ( http://drive5.com/usearch/benchmark_rfam.html ), by assessing the ability of the programs to identify RNA sequences belonging to the same family in RFAM ( Burge et al., 2013 ). The 383,004 sequences in Rfam version 11 were randomly shuffled and then the first sequence from each of the 2,085 (out of 2,208) families that contained at least 2 members was selected as a representative and used as a query against the remaining 380,919 sequences. The programs were run with options id 0.0, minseqlength 1, maxaccepts 1, maxrejects 32, and strand plus. If the matching sequence found belonged to the same family, it was considered a true positive, otherwise it was considered as a false positive. We combined the results from 20 shufflings and plotted the results in the ROC-like curve shown in Fig. 1 . For a false discovery rate between 0.010 and 0.015, VSEARCH is more accurate than USEARCH’s latest version. For lower values, the three programs have similar accuracies. At higher false discovery rates, USEARCH version 8 has an advantage.” | concepts[42] |
| concept | false discovery rate — not defined in this paper's own words; search accuracy operating point — “Evaluation of search accuracy was carried out as described in the USEARCH paper ( Edgar, 2010 ), its supplementary, and on the website ( http://drive5.com/usearch/benchmark_rfam.html ), by assessing the ability of the programs to identify RNA sequences belonging to the same family in RFAM ( Burge et al., 2013 ). The 383,004 sequences in Rfam version 11 were randomly shuffled and then the first sequence from each of the 2,085 (out of 2,208) families that contained at least 2 members was selected as a representative and used as a query against the remaining 380,919 sequences. The programs were run with options id 0.0, minseqlength 1, maxaccepts 1, maxrejects 32, and strand plus. If the matching sequence found belonged to the same family, it was considered a true positive, otherwise it was considered as a false positive. We combined the results from 20 shufflings and plotted the results in the ROC-like curve shown in Fig. 1 . For a false discovery rate between 0.010 and 0.015, VSEARCH is more accurate than USEARCH’s latest version. For lower values, the three programs have similar accuracies. At higher false discovery rates, USEARCH version 8 has an advantage.” | concepts[43] |
| concept | recall — not defined in this paper's own words; avoidance of OTU over-splitting — “We independently evaluated the clustering accuracy of USEARCH and VSEARCH as described for Swarm ( Mahé et al., 2014 ) using two mock datasets, one with an even and one with uneven composition of 57 archaea and bacteria. The datasets were first dereplicated. Then the taxonomy of the unique sequences was assigned by a search against the set of rRNA reference sequences representing the species in the mock datasets, carried out with the usearch_global command of USEARCH. The sequences were shuffled randomly 10 times and clustering was performed at 20 different similarity levels ranging from 80% to 99% in steps of 1%. Clustering was carried out in two ways, first using the cluster_fast command that pre-sorts the sequences by length, and then using the cluster_smallmem command that simply processes the sequences in the user-supplied order (in that case, we supplied sequences ordered by decreasing abundance using the sortbysize command). We then compared the clusters obtained to the assigned species and computed the recall, precision and the adjusted Rand index of the classifications. Recall measures to what extent amplicons assigned to the same species are grouped together in the same OTU (i.e., not over-splitting). Precision measures to what extent amplicons in an OTU are assigned to the same species (i.e., not over-grouping). The adjusted Rand index ( Rand, 1971 ; Hubert & Arabie, 1985 ) summarises both precision and recall using a measure of agreement between two clusterings while adjusting for expected values by chance. The average values over the all shufflings are presented in Figs. 2 and 3 for the even and uneven datasets, respectively. For abundance-sorted sequences, the difference between VSEARCH and USEARCH version 8 is negligible. The difference is larger for length-sorted sequences. When using length sorting, USEARCH 8 (as well as version 7 on the even dataset) shows better precision than VSEARCH for similarity levels below 93%. However, OTU delineation is usually performed at higher similarity values, typically 97%. In the case of our benchmark, overall accuracy as measured by the adjusted Rand index is maximised at 95–97% similarity. This is precisely the region where for length sorting at least VSEARCH outperforms USEARCH.” | concepts[44] |
| concept | precision — not defined in this paper's own words; avoidance of OTU over-grouping — “We independently evaluated the clustering accuracy of USEARCH and VSEARCH as described for Swarm ( Mahé et al., 2014 ) using two mock datasets, one with an even and one with uneven composition of 57 archaea and bacteria. The datasets were first dereplicated. Then the taxonomy of the unique sequences was assigned by a search against the set of rRNA reference sequences representing the species in the mock datasets, carried out with the usearch_global command of USEARCH. The sequences were shuffled randomly 10 times and clustering was performed at 20 different similarity levels ranging from 80% to 99% in steps of 1%. Clustering was carried out in two ways, first using the cluster_fast command that pre-sorts the sequences by length, and then using the cluster_smallmem command that simply processes the sequences in the user-supplied order (in that case, we supplied sequences ordered by decreasing abundance using the sortbysize command). We then compared the clusters obtained to the assigned species and computed the recall, precision and the adjusted Rand index of the classifications. Recall measures to what extent amplicons assigned to the same species are grouped together in the same OTU (i.e., not over-splitting). Precision measures to what extent amplicons in an OTU are assigned to the same species (i.e., not over-grouping). The adjusted Rand index ( Rand, 1971 ; Hubert & Arabie, 1985 ) summarises both precision and recall using a measure of agreement between two clusterings while adjusting for expected values by chance. The average values over the all shufflings are presented in Figs. 2 and 3 for the even and uneven datasets, respectively. For abundance-sorted sequences, the difference between VSEARCH and USEARCH version 8 is negligible. The difference is larger for length-sorted sequences. When using length sorting, USEARCH 8 (as well as version 7 on the even dataset) shows better precision than VSEARCH for similarity levels below 93%. However, OTU delineation is usually performed at higher similarity values, typically 97%. In the case of our benchmark, overall accuracy as measured by the adjusted Rand index is maximised at 95–97% similarity. This is precisely the region where for length sorting at least VSEARCH outperforms USEARCH.” | concepts[45] |
| concept | adjusted Rand index — not defined in this paper's own words; chance-adjusted clustering agreement — “We independently evaluated the clustering accuracy of USEARCH and VSEARCH as described for Swarm ( Mahé et al., 2014 ) using two mock datasets, one with an even and one with uneven composition of 57 archaea and bacteria. The datasets were first dereplicated. Then the taxonomy of the unique sequences was assigned by a search against the set of rRNA reference sequences representing the species in the mock datasets, carried out with the usearch_global command of USEARCH. The sequences were shuffled randomly 10 times and clustering was performed at 20 different similarity levels ranging from 80% to 99% in steps of 1%. Clustering was carried out in two ways, first using the cluster_fast command that pre-sorts the sequences by length, and then using the cluster_smallmem command that simply processes the sequences in the user-supplied order (in that case, we supplied sequences ordered by decreasing abundance using the sortbysize command). We then compared the clusters obtained to the assigned species and computed the recall, precision and the adjusted Rand index of the classifications. Recall measures to what extent amplicons assigned to the same species are grouped together in the same OTU (i.e., not over-splitting). Precision measures to what extent amplicons in an OTU are assigned to the same species (i.e., not over-grouping). The adjusted Rand index ( Rand, 1971 ; Hubert & Arabie, 1985 ) summarises both precision and recall using a measure of agreement between two clusterings while adjusting for expected values by chance. The average values over the all shufflings are presented in Figs. 2 and 3 for the even and uneven datasets, respectively. For abundance-sorted sequences, the difference between VSEARCH and USEARCH version 8 is negligible. The difference is larger for length-sorted sequences. When using length sorting, USEARCH 8 (as well as version 7 on the even dataset) shows better precision than VSEARCH for similarity levels below 93%. However, OTU delineation is usually performed at higher similarity values, typically 97%. In the case of our benchmark, overall accuracy as measured by the adjusted Rand index is maximised at 95–97% similarity. This is precisely the region where for length sorting at least VSEARCH outperforms USEARCH.” | concepts[46] |
| concept | SIMM dataset — not defined in this paper's own words; legacy simulated-chimera benchmark — “First we repeated the evaluation of the uchime_ref command described in the UCHIME paper ( Edgar et al., 2011 ) using the SIMM dataset downloaded from http://drive5.com/uchime/uchime_download.html . The dataset consists of 900 simulated chimeras that are approximately 250 bp long. The chimeras were generated from 2, 3 or 4 segments selected randomly from 86 original sequences and have similarities in the ranges 90–95%, 95–97% and 97–99% to the original sequences. They were either used unmodified or with 1–5% indels or 1–5% substitutions. We assessed the performance of (i) the original open-source UCHIME version 4.2 program, (ii) USEARCH version 7, (iii) USEARCH version 8, and (iv) VSEARCH. The results are shown in Table 1 and indicate that VSEARCH is superior to the other tools in almost all cases, and in particular when indels were added. The original UCHIME program was found to be quite, but also considerably slower than all the other tools. USEARCH was better than VSEARCH in only 4 out of 99 cases.” | concepts[47] |
| concept | Greengenes — not defined in this paper's own words; 16S source for simulated chimera test — “Next, we tested reference-based ( uchime_ref ) and de novo ( uchime_denovo ) chimera detection using sequences from the 2011 version of Greengenes downloaded from http://greengenes.lbl.gov/Download/Sequence_Data/Fasta_data_files/ and from version 106 (May 2011) of the SILVA database downloaded from https://www.arb-silva.de/no_cache/download/archive/release_106/Exports/ . Sequences from the 16S rRNA V4 region was computationally extracted using the 515F (5′-GTGNCAGCMGCCGCGGTAA-3′) and 806R (5′-GGACTACHVGGGTWTCTAAT-3′) primers, and 8,000 reads were randomly selected from each database. PCR was simulated using a new simulation algorithm known as Simera ( Nichols & Quince, 2016 ) (available at https://github.com/bnichols1979/Simera ) that includes amplification and creation of PCR artefacts like chimeras. We sampled 30,000 reads (-s 30,000) and generated 20,000 potential chimeras (-c 20,000). Defaults were used for other options to Simera. The output sequences were then fed into an Illumina MiSeq noise simulator ( Schirmer et al., 2015 ) ending up with 14,966 reads based on Greengenes and 14,952 reads based on SILVA, of which 1,262 and 1,640 reads contain chimeric sequences, respectively. Next, the sequences were either clustered using the cluster_fast command at 97% identity or dereplicated. VSEARCH and USEARCH version 7 and 8 were run using the uchime_denovo command and then using the uchime_ref command with the Gold database downloaded from http://drive5.com/uchime/uchime_download.html as the reference database. To assess the performance, the results were sorted based on the chimera score, and then the ability to classify individual sequences correctly into chimeric and non-chimeric was plotted as ROC curves. The curves reflect the accuracy of classifying individual reads, not clusters, as abundances were taken into account. The plots in Figs. 5 and 6 show that de novo chimera detection performs better than reference-based detection, with the SILVA dataset in particular, but it does of course depend on the reference database used. VSEARCH performs better than both versions of USEARCH for de novo chimera detection. For reference-based detection VSEARCH also performs better for the Greengenes dataset, while none of the programs work well with the SILVA dataset. Clustering at 97% appears to be more appropriate than dereplication. In this test, the USEARCH programs were about twice as fast as VSEARCH for de novo detection, while they were about 10–30% faster than VSEARCH for reference-based detection.” | concepts[48] |
| concept | SILVA — not defined in this paper's own words; 16S source for simulated chimera test — “Next, we tested reference-based ( uchime_ref ) and de novo ( uchime_denovo ) chimera detection using sequences from the 2011 version of Greengenes downloaded from http://greengenes.lbl.gov/Download/Sequence_Data/Fasta_data_files/ and from version 106 (May 2011) of the SILVA database downloaded from https://www.arb-silva.de/no_cache/download/archive/release_106/Exports/ . Sequences from the 16S rRNA V4 region was computationally extracted using the 515F (5′-GTGNCAGCMGCCGCGGTAA-3′) and 806R (5′-GGACTACHVGGGTWTCTAAT-3′) primers, and 8,000 reads were randomly selected from each database. PCR was simulated using a new simulation algorithm known as Simera ( Nichols & Quince, 2016 ) (available at https://github.com/bnichols1979/Simera ) that includes amplification and creation of PCR artefacts like chimeras. We sampled 30,000 reads (-s 30,000) and generated 20,000 potential chimeras (-c 20,000). Defaults were used for other options to Simera. The output sequences were then fed into an Illumina MiSeq noise simulator ( Schirmer et al., 2015 ) ending up with 14,966 reads based on Greengenes and 14,952 reads based on SILVA, of which 1,262 and 1,640 reads contain chimeric sequences, respectively. Next, the sequences were either clustered using the cluster_fast command at 97% identity or dereplicated. VSEARCH and USEARCH version 7 and 8 were run using the uchime_denovo command and then using the uchime_ref command with the Gold database downloaded from http://drive5.com/uchime/uchime_download.html as the reference database. To assess the performance, the results were sorted based on the chimera score, and then the ability to classify individual sequences correctly into chimeric and non-chimeric was plotted as ROC curves. The curves reflect the accuracy of classifying individual reads, not clusters, as abundances were taken into account. The plots in Figs. 5 and 6 show that de novo chimera detection performs better than reference-based detection, with the SILVA dataset in particular, but it does of course depend on the reference database used. VSEARCH performs better than both versions of USEARCH for de novo chimera detection. For reference-based detection VSEARCH also performs better for the Greengenes dataset, while none of the programs work well with the SILVA dataset. Clustering at 97% appears to be more appropriate than dereplication. In this test, the USEARCH programs were about twice as fast as VSEARCH for de novo detection, while they were about 10–30% faster than VSEARCH for reference-based detection.” | concepts[49] |
| concept | reference-based detection — not defined in this paper's own words; chimera detection against Gold database — “Next, we tested reference-based ( uchime_ref ) and de novo ( uchime_denovo ) chimera detection using sequences from the 2011 version of Greengenes downloaded from http://greengenes.lbl.gov/Download/Sequence_Data/Fasta_data_files/ and from version 106 (May 2011) of the SILVA database downloaded from https://www.arb-silva.de/no_cache/download/archive/release_106/Exports/ . Sequences from the 16S rRNA V4 region was computationally extracted using the 515F (5′-GTGNCAGCMGCCGCGGTAA-3′) and 806R (5′-GGACTACHVGGGTWTCTAAT-3′) primers, and 8,000 reads were randomly selected from each database. PCR was simulated using a new simulation algorithm known as Simera ( Nichols & Quince, 2016 ) (available at https://github.com/bnichols1979/Simera ) that includes amplification and creation of PCR artefacts like chimeras. We sampled 30,000 reads (-s 30,000) and generated 20,000 potential chimeras (-c 20,000). Defaults were used for other options to Simera. The output sequences were then fed into an Illumina MiSeq noise simulator ( Schirmer et al., 2015 ) ending up with 14,966 reads based on Greengenes and 14,952 reads based on SILVA, of which 1,262 and 1,640 reads contain chimeric sequences, respectively. Next, the sequences were either clustered using the cluster_fast command at 97% identity or dereplicated. VSEARCH and USEARCH version 7 and 8 were run using the uchime_denovo command and then using the uchime_ref command with the Gold database downloaded from http://drive5.com/uchime/uchime_download.html as the reference database. To assess the performance, the results were sorted based on the chimera score, and then the ability to classify individual sequences correctly into chimeric and non-chimeric was plotted as ROC curves. The curves reflect the accuracy of classifying individual reads, not clusters, as abundances were taken into account. The plots in Figs. 5 and 6 show that de novo chimera detection performs better than reference-based detection, with the SILVA dataset in particular, but it does of course depend on the reference database used. VSEARCH performs better than both versions of USEARCH for de novo chimera detection. For reference-based detection VSEARCH also performs better for the Greengenes dataset, while none of the programs work well with the SILVA dataset. Clustering at 97% appears to be more appropriate than dereplication. In this test, the USEARCH programs were about twice as fast as VSEARCH for de novo detection, while they were about 10–30% faster than VSEARCH for reference-based detection.” | concepts[50] |
| concept | de novo chimera detection — not defined in this paper's own words; abundance-based detection without reference — “Next, we tested reference-based ( uchime_ref ) and de novo ( uchime_denovo ) chimera detection using sequences from the 2011 version of Greengenes downloaded from http://greengenes.lbl.gov/Download/Sequence_Data/Fasta_data_files/ and from version 106 (May 2011) of the SILVA database downloaded from https://www.arb-silva.de/no_cache/download/archive/release_106/Exports/ . Sequences from the 16S rRNA V4 region was computationally extracted using the 515F (5′-GTGNCAGCMGCCGCGGTAA-3′) and 806R (5′-GGACTACHVGGGTWTCTAAT-3′) primers, and 8,000 reads were randomly selected from each database. PCR was simulated using a new simulation algorithm known as Simera ( Nichols & Quince, 2016 ) (available at https://github.com/bnichols1979/Simera ) that includes amplification and creation of PCR artefacts like chimeras. We sampled 30,000 reads (-s 30,000) and generated 20,000 potential chimeras (-c 20,000). Defaults were used for other options to Simera. The output sequences were then fed into an Illumina MiSeq noise simulator ( Schirmer et al., 2015 ) ending up with 14,966 reads based on Greengenes and 14,952 reads based on SILVA, of which 1,262 and 1,640 reads contain chimeric sequences, respectively. Next, the sequences were either clustered using the cluster_fast command at 97% identity or dereplicated. VSEARCH and USEARCH version 7 and 8 were run using the uchime_denovo command and then using the uchime_ref command with the Gold database downloaded from http://drive5.com/uchime/uchime_download.html as the reference database. To assess the performance, the results were sorted based on the chimera score, and then the ability to classify individual sequences correctly into chimeric and non-chimeric was plotted as ROC curves. The curves reflect the accuracy of classifying individual reads, not clusters, as abundances were taken into account. The plots in Figs. 5 and 6 show that de novo chimera detection performs better than reference-based detection, with the SILVA dataset in particular, but it does of course depend on the reference database used. VSEARCH performs better than both versions of USEARCH for de novo chimera detection. For reference-based detection VSEARCH also performs better for the Greengenes dataset, while none of the programs work well with the SILVA dataset. Clustering at 97% appears to be more appropriate than dereplication. In this test, the USEARCH programs were about twice as fast as VSEARCH for de novo detection, while they were about 10–30% faster than VSEARCH for reference-based detection.” | concepts[51] |
| concept | correctly merged — not defined in this paper's own words; perfect reference-alignment criterion — “Evaluation of paired-end reads merging performance was carried out in a manner similar to that described for the evaluation of PEAR ( Zhang et al., 2014 ). We used whole genome sequencing data from Staphylococcus aureus subspecies aureus strain USA 300 TCH 1516 sequenced by MacCallum et al. (2009) and retrieved from the GAGE-B repository ( http://ccb.jhu.edu/gage_b/ ). The S.aureus reads were 101 bp long from on average 180 bp long fragments, giving a 45X coverage of the genome. We also used Methylococcus capsulatus strain Bath 16S rRNA V3 region amplicon reads sequenced by Masella et al. (2012) . These reads were 108 bp long and the pairs should have an overlap of exactly 18 bp. Merging options were set to allow a minimum overlap of 10 bp and a maximum of 5 mismatches (USEARCH 7 and 8 have different default values for those), while other options were left at defaults. All programs were run with 8 threads. Merged sequences that could be perfectly aligned to their respective reference sequences (either the entire genome or the specific rRNA region) using BWA MEM ( Li & Durbin, 2009 ) were considered correctly merged. The results are shown in Table 2 . The numbers indicate that USEARCH version 7 merges the most reads for both bacteria, but also has the lowest percentage of correctly merged pairs of those merged. USEARCH version 8 merges the fewest reads, but has the highest percentage of correctly merged reads of those merged. VSEARCH is in the middle by merging more reads than USEARCH 8 with only a small decrease in the percentage of correct merges. VSEARCH is about twice as fast as USEARCH 8 and 4–5 times faster than USEARCH version 7.” | concepts[52] |
| concept | expected value — not defined in this paper's own words; theoretical subsampling distribution center — “We evaluated the subsampling commands of USEARCH version 8 and VSEARCH to check if the results obtained correspond to those expected. We performed 10,000 random subsamplings of 5% of the 9.5 million unique sequences in the TARA V9 dataset ( Karsenti et al., 2011 ). To make this possible with the 32-bit USEARCH, we first downsampled the dataset once to 10% using VSEARCH and then randomly subsampled it again at 50% with either USEARCH or VSEARCH. Plots of the distribution of the abundance of the most abundant sequence in each subsampling are shown in Fig. 7 . The highest amplicon abundance in the original dataset is 15,638,316. After the initial 10% subsampling, the highest abundance was 1,564,267. After the second subsampling, the top abundances should therefore have a distribution centred on a value of 782,133.5. As can be seen from the figure, the USEARCH distribution has a mean that is about 2,000 too small, while the VSEARCH distribution is correctly centred on the expected value. Subsampling experiments were also performed at 2.5%, 1.5% and 0.5% with similar results, although the errors were of decreasing size. USEARCH seems to under-sample abundant amplicons and to over-sample rare amplicons.” | concepts[53] |
| concept | abundant amplicons — not defined in this paper's own words; high-count sequence variants in subsampling — “We evaluated the subsampling commands of USEARCH version 8 and VSEARCH to check if the results obtained correspond to those expected. We performed 10,000 random subsamplings of 5% of the 9.5 million unique sequences in the TARA V9 dataset ( Karsenti et al., 2011 ). To make this possible with the 32-bit USEARCH, we first downsampled the dataset once to 10% using VSEARCH and then randomly subsampled it again at 50% with either USEARCH or VSEARCH. Plots of the distribution of the abundance of the most abundant sequence in each subsampling are shown in Fig. 7 . The highest amplicon abundance in the original dataset is 15,638,316. After the initial 10% subsampling, the highest abundance was 1,564,267. After the second subsampling, the top abundances should therefore have a distribution centred on a value of 782,133.5. As can be seen from the figure, the USEARCH distribution has a mean that is about 2,000 too small, while the VSEARCH distribution is correctly centred on the expected value. Subsampling experiments were also performed at 2.5%, 1.5% and 0.5% with similar results, although the errors were of decreasing size. USEARCH seems to under-sample abundant amplicons and to over-sample rare amplicons.” | concepts[54] |
| concept | rare amplicons — not defined in this paper's own words; low-count sequence variants in subsampling — “We evaluated the subsampling commands of USEARCH version 8 and VSEARCH to check if the results obtained correspond to those expected. We performed 10,000 random subsamplings of 5% of the 9.5 million unique sequences in the TARA V9 dataset ( Karsenti et al., 2011 ). To make this possible with the 32-bit USEARCH, we first downsampled the dataset once to 10% using VSEARCH and then randomly subsampled it again at 50% with either USEARCH or VSEARCH. Plots of the distribution of the abundance of the most abundant sequence in each subsampling are shown in Fig. 7 . The highest amplicon abundance in the original dataset is 15,638,316. After the initial 10% subsampling, the highest abundance was 1,564,267. After the second subsampling, the top abundances should therefore have a distribution centred on a value of 782,133.5. As can be seen from the figure, the USEARCH distribution has a mean that is about 2,000 too small, while the VSEARCH distribution is correctly centred on the expected value. Subsampling experiments were also performed at 2.5%, 1.5% and 0.5% with similar results, although the errors were of decreasing size. USEARCH seems to under-sample abundant amplicons and to over-sample rare amplicons.” | concepts[55] |
| concept | memory — not defined in this paper's own words; available address space for sequence processing — “VSEARCH is a 64-bit program and allows very large datasets to be processed, essentially limited only by the amount of memory available. The free USEARCH versions are 32-bit programs that limit the available memory to somewhere less than 4GB, often seriously hampering the analysis of realistic datasets.” | concepts[56] |
| concept | low-complexity nucleotide sequences — not defined in this paper's own words; repeat-rich sequence regions subject to masking — “VSEARCH includes a highly optimized and parallelized implementation of the Dust algorithm by Tatusov and Lipman for masking of simple repeats and low-complexity nucleotide sequences. It is considerably faster than the implementation of the same algorithm in USEARCH. Their code available at ftp://ftp.ncbi.nlm.nih.gov/pub/tatusov/dust/version1/src/ is in the public domain. VSEARCH uses this algorithm by default, while USEARCH by default uses an undocumented rapid masking algorithm called fastnucleo . VSEARCH performs soft-masking automatically for the pairwise alignment, search, clustering and chimera detection commands. This behaviour can be controlled with the hardmask option to replace masked symbols with N’s instead of lower-casing them, and the dbmask and qmask options, which selects the masking algorithm (none, dust or soft) used for the database and query sequences, respectively. Masking may also be performed explicitly on an input file using the fastx_mask and maskfasta commands.” | concepts[57] |
| concept | clustering threshold — not defined in this paper's own words; identity cutoff affecting runtime and assignments — “The time used for clustering is shown in Fig. 4 . The time used depended on the dataset, algorithm and clustering threshold. The USEARCH programs were in general 2–3 times faster than VSEARCH. In general the difference in speed was smaller for higher thresholds, especially at 99% similarity. Clustering with USEARCH using the fulldp option is an order of magnitude slower than VSEARCH, but contrary to our expectations it does not seem to improve accuracy.” | concepts[58] |
| concept | time used — not defined in this paper's own words; wall-clock clustering performance — “The time used for clustering is shown in Fig. 4 . The time used depended on the dataset, algorithm and clustering threshold. The USEARCH programs were in general 2–3 times faster than VSEARCH. In general the difference in speed was smaller for higher thresholds, especially at 99% similarity. Clustering with USEARCH using the fulldp option is an order of magnitude slower than VSEARCH, but contrary to our expectations it does not seem to improve accuracy.” | concepts[59] |
| concept | grouped together in the same OTU — not defined in this paper's own words; recall-side avoidance of over-splitting — “We independently evaluated the clustering accuracy of USEARCH and VSEARCH as described for Swarm ( Mahé et al., 2014 ) using two mock datasets, one with an even and one with uneven composition of 57 archaea and bacteria. The datasets were first dereplicated. Then the taxonomy of the unique sequences was assigned by a search against the set of rRNA reference sequences representing the species in the mock datasets, carried out with the usearch_global command of USEARCH. The sequences were shuffled randomly 10 times and clustering was performed at 20 different similarity levels ranging from 80% to 99% in steps of 1%. Clustering was carried out in two ways, first using the cluster_fast command that pre-sorts the sequences by length, and then using the cluster_smallmem command that simply processes the sequences in the user-supplied order (in that case, we supplied sequences ordered by decreasing abundance using the sortbysize command). We then compared the clusters obtained to the assigned species and computed the recall, precision and the adjusted Rand index of the classifications. Recall measures to what extent amplicons assigned to the same species are grouped together in the same OTU (i.e., not over-splitting). Precision measures to what extent amplicons in an OTU are assigned to the same species (i.e., not over-grouping). The adjusted Rand index ( Rand, 1971 ; Hubert & Arabie, 1985 ) summarises both precision and recall using a measure of agreement between two clusterings while adjusting for expected values by chance. The average values over the all shufflings are presented in Figs. 2 and 3 for the even and uneven datasets, respectively. For abundance-sorted sequences, the difference between VSEARCH and USEARCH version 8 is negligible. The difference is larger for length-sorted sequences. When using length sorting, USEARCH 8 (as well as version 7 on the even dataset) shows better precision than VSEARCH for similarity levels below 93%. However, OTU delineation is usually performed at higher similarity values, typically 97%. In the case of our benchmark, overall accuracy as measured by the adjusted Rand index is maximised at 95–97% similarity. This is precisely the region where for length sorting at least VSEARCH outperforms USEARCH.” | concepts[60] |
| concept | assigned to the same species — not defined in this paper's own words; precision-side avoidance of over-grouping — “We independently evaluated the clustering accuracy of USEARCH and VSEARCH as described for Swarm ( Mahé et al., 2014 ) using two mock datasets, one with an even and one with uneven composition of 57 archaea and bacteria. The datasets were first dereplicated. Then the taxonomy of the unique sequences was assigned by a search against the set of rRNA reference sequences representing the species in the mock datasets, carried out with the usearch_global command of USEARCH. The sequences were shuffled randomly 10 times and clustering was performed at 20 different similarity levels ranging from 80% to 99% in steps of 1%. Clustering was carried out in two ways, first using the cluster_fast command that pre-sorts the sequences by length, and then using the cluster_smallmem command that simply processes the sequences in the user-supplied order (in that case, we supplied sequences ordered by decreasing abundance using the sortbysize command). We then compared the clusters obtained to the assigned species and computed the recall, precision and the adjusted Rand index of the classifications. Recall measures to what extent amplicons assigned to the same species are grouped together in the same OTU (i.e., not over-splitting). Precision measures to what extent amplicons in an OTU are assigned to the same species (i.e., not over-grouping). The adjusted Rand index ( Rand, 1971 ; Hubert & Arabie, 1985 ) summarises both precision and recall using a measure of agreement between two clusterings while adjusting for expected values by chance. The average values over the all shufflings are presented in Figs. 2 and 3 for the even and uneven datasets, respectively. For abundance-sorted sequences, the difference between VSEARCH and USEARCH version 8 is negligible. The difference is larger for length-sorted sequences. When using length sorting, USEARCH 8 (as well as version 7 on the even dataset) shows better precision than VSEARCH for similarity levels below 93%. However, OTU delineation is usually performed at higher similarity values, typically 97%. In the case of our benchmark, overall accuracy as measured by the adjusted Rand index is maximised at 95–97% similarity. This is precisely the region where for length sorting at least VSEARCH outperforms USEARCH.” | concepts[61] |
Full text — tagged
The reference list is not part of the text we hold for this paper. Our copy was extracted from the publisher's page and the bibliography did not survive that extraction, so the article below ends before its references. Nothing has been removed by us.
VSEARCHterm: a versatile open source tool for metagenomicsterm Abstract VSEARCHterm is an open source and free of charge multithreaded 64-bit toolterm for processing and preparing metagenomicsterm, genomics and population genomics nucleotide sequence dataterm. It is designed as an alternative to the widely used USEARCHterm tool ( Edgar, 2010 ) for which the source code is not publicly available, algorithm details are only rudimentarily described, and only a memory-confined 32-bit version is freely available for academic use.
When searching nucleotide sequences, VSEARCHterm uses a fast heuristic based on words shared by the query and target sequencesterm in order to quickly identify similar sequences, a similar strategy is probably used in USEARCHterm. VSEARCHterm then performs optimal global sequence alignmentterm of the query against potential target sequences, using full dynamic programmingterm instead of the seed-and-extend heuristicterm used by USEARCHterm. Pairwise alignments are computed in parallel using vectorisationterm and multiple threadsterm.
VSEARCHterm includes most commands for analysing nucleotide sequences available in USEARCHterm version 7 and several of those available in USEARCHterm version 8, including searching (exact or based on global alignment), clustering by similarity (using length pre-sorting, abundance pre-sorting or a user-defined order), chimeraterm detection (reference-based or de novo ), dereplication (full length or prefix), pairwise alignment, reverse complementation, sorting, and subsampling. VSEARCHterm also includes commands for FASTQterm file processing, i.e., format detection, filtering, read quality statistics, and merging of paired reads. Furthermore, VSEARCHterm extends functionality with several new commands and improvements, including shuffling, rereplicationterm, masking of low-complexity sequences with the well-known DUST algorithmterm, a choice among different similarity definitions, and FASTQterm file format conversion. VSEARCHterm is here shown to be more accurate than USEARCHterm when performing searching, clustering, chimeraterm detection and subsampling, while on a par with USEARCHterm for paired-ends read merging. VSEARCHterm is slower than USEARCHterm when performing clustering and chimeraterm detection, but significantly faster when performing paired-end readsterm merging and dereplication. VSEARCHterm is available at https://github.com/torognes/vsearchterm under either the BSD 2-clause license or the GNU General Public License version 3.0.
VSEARCHterm has been shown to be a fast, accurate and full-fledged alternative to USEARCHterm. A free and open-source versatile tool for sequence analysis is now available to the metagenomicsterm community.
Introduction Rockström et al. (2009) and Steffen et al. (2015) presented biodiversity loss as a major threat for the short-term survival of humanity. Recent progress in sequencing technologies have made possible large scale studies of environmental genetic diversity, from deep sea hydrothermal vents to Antarctic lakes ( Karsenti et al., 2011 ), and from tropical forests to Siberian steppes ( Gilbert, Jansson & Knight, 2014 ). Recent clinical studies have shown the importance of the microbiomes of our bodies and daily environments for human health ( Human Microbiome Project Consortium, 2012 ). Usually focusing on universal markers (e.g., 16S rRNA, ITS, COI), these targeted metagenomicsterm studies produce many millions of sequences, and require open-source, fast and memoryterm efficient tools to facilitate their ecological interpretation.
Several pipelines have been developed for microbiome analysis, among which mothur ( Schloss et al., 2009 ), QIIME ( Caporaso et al., 2010 ), and UPARSE ( Edgar, 2013 ) are the most popular. QIIME and UPARSE are both based on USEARCHterm ( Edgar, 2010 ), a set of tools designed and implemented by Robert C. Edgar, and available at http://drive5.com/usearchterm/ . USEARCHterm offers a great number of commands and options to manipulate and analyse FASTQterm and FASTA files. However, the source code of USEARCHterm is not publicly available, algorithm details are only rudimentarily described, and only a memory-confined 32-bit version is freely available for academic use.
We believe that the existence of open-source solutions is beneficial for end-users and can invigorate research activities. For this reason, we have undertaken to offer a high quality open-source alternative to USEARCHterm, freely available to users without any memoryterm limitation. VSEARCHterm includes most of the USEARCHterm functions in common use, and further development may add additional features. Here we describe the details of the VSEARCHterm implementation. To assess its performance in terms of speed and quality of results, we have evaluated some of the most important functions (searching, clustering, chimeraterm detection and subsampling) and compared them to USEARCHterm. We find that VSEARCHterm delivers results that are better or on a par with USEARCHterm results.
Materials and Methods Algorithms and implementation Below is a brief description of the most important functions of VSEARCHterm and details of their implementation. VSEARCHterm command line options are shown in italics, and should be preceded by a single (-) or double dash (-TI:\,-) when used.
Reading FASTA and FASTQterm files Most VSEARCHterm commands read files in FASTA or FASTQterm format. The parser for FASTQterm files in VSEARCHterm is compliant with the standard as described by Cock et al. (2010) and correctly parses all their tests files. FASTA and FASTQterm files are automatically detected and many commands accept both as input. Files compressed with gzip or bzip2 are automatically detected and decompressed using the zlib library by Gailly & Adler (2016) or the bzip2 library by Seward (2016) , respectively. Data may also be piped into or out of VSEARCHterm, allowing for instance many separate FASTA files to be piped into VSEARCHterm for simultaneous dereplication, or allowing the creation of complex pipelines without ever having to write on slow disks.
VSEARCHterm is a 64-bit program and allows very large datasets to be processed, essentially limited only by the amount of memoryterm available. The free USEARCHterm versions are 32-bit programs that limit the available memoryterm to somewhere less than 4GB, often seriously hampering the analysis of realistic datasets.
Writing result files VSEARCHterm can output results in a variety of formats (FASTA, FASTQterm, tables, alignments, SAM) depending on the input format and command used. When outputting FASTA files, the line width may be specified using the fasta_width option, where 0 means that line wrapping should be turned off. Similar controls are offered for pairwise or multiple sequence alignments.
Searching Global pairwise sequence comparisonterm is a core functionalityterm of VSEARCHterm. Several commands compare a query sequence against a database of sequences: all-vs-all alignment ( allpairs_global ), clustering ( cluster_fast , cluster_size , cluster_smallmem ), chimeraterm detection ( uchime_denovo and uchime_ref ) and searching ( usearchterm_global ). This comparison function proceeds in two phases: an initial heuristic filtering based on shared wordsterm, followed by optimal alignment of the query with the most promising candidates.
The first phase is presumably quite similar to USEARCHterm ( Edgar, 2010 ). Heuristics are used to identify a small set of database sequencesterm that have many wordsterm in common with the query sequence. Wordsterm (or k -mers) consist of a certain number k of consecutive nucleotides of a sequence (8 by default, adjustable with the wordlengthterm·var option). All overlapping wordsterm are included. A sequence of length n then contains at most n − k + 1 unique wordsterm. VSEARCHterm counts the number of shared wordsterm between the query and each database sequenceterm. Wordsterm that appear multiple times are counted only once. To count the wordsterm in the database sequencesterm quickly, VSEARCHterm creates an index of all the 4 k possible distinct wordsterm and stores information about which database sequencesterm they appear in. For extremely frequent wordsterm, the set of database sequencesterm is represented by a bitmapterm; otherwise the set is stored as a list. A finer control of k -mer indexing is described for USEARCHterm by the pattern (binary string indicating which positions must match) and slots options. USEARCHterm has such options but seems to ignore them. Currently, VSEARCHterm ignores these two options too. The minimum number of shared wordsterm required may be specified with the minwordmatches option (10 by default), but a lower value is automatically used for short or simple query sequences with less than 10 unique wordsterm.
Comparing sequences based on statistics of shared wordsterm is a common method to quickly assess the similarity between two sequences without aligning them, which is often time-consuming. The D 2 statistic and related metrics for alignment-free sequence comparison have often been used for rapid and approximate sequence matching and their statistical properties have been well studied ( Song et al., 2014 ). The approach used here has similarities to the D 2 statistic, but multiple matches of the same wordterm are ignored.
In the second phase, searching proceeds by considering the database sequencesterm in a specific order, starting with the sequence having the largest number of wordsterm in common with the query, and proceeding with a decreasing number of shared wordsterm. If two database sequencesterm have the same number of wordsterm in common with the query, the shortest sequence is considered first. The query sequence is compared with each database sequenceterm by computing the optimal global alignmentterm. The alignment is performed using a multi-threaded and vectorised full dynamic programmingterm algorithm ( Needleman & Wunsch, 1970 ) adapted from SWIPE ( RognespersName, 2011 ). Due to the extreme memoryterm requirements of this method when aligning two long sequences, an alternative algorithmterm described by Hirschberg (1975) and Myers & Miller (1988) is used when the product of the length of the sequences is greater than 25,000,000, corresponding to aligning two 5,000 bp sequences. This alternative algorithmterm uses only a linear amount of memoryterm but is considerably slower. This second phase is probably where USEARCHterm and VSEARCHterm differ the most, as USEARCHterm by default presumably performs heuristic seed-and-extend alignment similar to BLAST ( Altschul et al., 1997 ), and only performs optimal alignment when the option fulldp (full dynamic programmingterm) is used. Computing the optimal pairwise alignment in each case gives more accurate results but is also computationally more demanding. The efficient and vectorised full dynamic programmingterm implementation in VSEARCHterm compensates that extra cost, at least for sequences that are not too long.
If the resulting alignment indicates a similarity equal to or greater than the value specified with the id optionterm, the database sequenceterm is accepted. If the similarity is too low, it is rejected. Several other options may also be used to determine how similarity is computed ( iddef , as USEARCHterm used to offer up to version 6), and which sequences should be accepted and rejected, either before (e.g., self , minqsize ) or after alignment (e.g., maxgaps , maxsubs ). The search is terminated when either a certain number of sequences have been accepted (1 by default, adjustable with the maxaccepts option), or a certain number of sequences have been rejected (32 by default, adjustable with the maxrejects option). The accepted sequences are sorted by sequence similarityterm·var and presented as the search results.
VSEARCHterm also includes a search_exact command that only identifies exact matches to the query. It uses a hash tableterm in a way similar to the full-length dereplicationterm command described below.
Clustering VSEARCHterm includes commands to perform de novo clustering using a greedy and heuristic centroid-based algorithmterm with an adjustable sequence similarity thresholdterm specified with the id option (e.g., 0.97). The input sequences are either processed in the user supplied order ( cluster_smallmem ) or pre-sorted based on length ( cluster_fast ) or abundance (the new cluster_size option). Each input sequence is then used as a query in a search against an initially empty database of centroid sequences. The query sequence is clustered with the first centroid sequence found with similarity equal to or above the threshold. The search is performed using the heuristic approach described above which generally finds the most similar sequences first. If no matches are found, the query sequence becomes the centroid of a new cluster and is added to the database. If maxaccepts is higher than 1, several centroids with sufficient sequence similarityterm·var may be found and considered. By default, the query is clustered with the centroid presenting the highest sequence similarityterm·var (distance-based greedy clusteringterm, DGC), or, if the sizeorder option is turned on, the centroid with the highest abundance (abundance-based greedy clusteringterm, AGC) ( He et al., 2015 ; Westcott & Schloss, 2015 ; Schloss, 2016 ). VSEARCHterm performs multi-threaded clustering by searching the database of centroid sequences with several query sequences in parallel. If there are any non-matching query sequences giving rise to new centroids, the required internal comparisons between the query sequences are subsequently performed to achieve correct results. For each cluster, VSEARCHterm can create a simple multiple sequence alignment using the center star method ( Gusfield, 1993 ) with the centroid as the center sequence, and then compute a consensus sequence and a sequence profile.
Dereplication and rereplicationterm Full-length dereplicationterm ( derep_fulllength ) is performed using a hash tableterm with an open addressing and linear probing strategy based on the Google CityHash hash functions (written by Geoff Pike and Jyrki Alakuijala, and available at https://github.com/google/cityhash ). The hash tableterm is initially empty. For each input sequence, the hash is computed and a lookup in the hash tableterm is performed. If an identical sequence is found, the input sequence is clustered with the matching sequence; otherwise the input sequence is inserted into the hash tableterm.
Prefix dereplicationterm ( derep_prefix ) is also implemented. As with full-length dereplicationterm, identical sequences are clustered. In addition, sequences that are identical to prefixes of other sequences will also be clustered together. If a sequence is identical to the prefix of multiple sequences, it is generally not defined how prefix clustering should behave. VSEARCHterm resolves this ambiguity by clustering the sequence with the shortest of the candidate sequences. If they are equally long, priority will be given to the most abundant, the one with the lexicographically smaller identifier or the one with the earliest original position, in that order.
To perform prefix dereplicationterm, VSEARCHterm first creates an initially empty hash tableterm. It then sorts the input sequences by length and identifies the length s of the shortest sequence in the dataset. Each input sequence is then processed as follows, starting with the shortest: If an exact match to the full input sequence is found in the hash tableterm, the input sequence is clustered with the matching hash tableterm sequence. If no match to the full input sequence is found, the prefixes of the input sequence are considered, starting with the longest prefix and proceeding with shorter prefixes in order, down to prefixes of length s . If a match is now found in the hash tableterm, the sequences are clustered, the matching sequence is deleted from the hash tableterm and the full input sequence is inserted into the hash tableterm instead. If no match is found for any prefix, the full sequence is inserted into the hash tableterm. In the end, the remaining sequences in the hash tableterm will be output with accumulated abundances for all sequences in each cluster.
In order to identify matches in the hash tableterm during prefix dereplicationterm, a hash is computed for each full-length input sequence and all its prefixes. The hash function used is the 64-bit Fowler–Noll–Vo 1a hash functionterm ( Fowler, Noll & Vo, 1991 ), which is simple and quick to compute for such a series of sequences by adding one nucleotide at a time.
The sequences resulting from dereplication and many other commands may be relabeled with a given prefix followed by a sequentially increasing number. VSEARCHterm exclusively also offers the possibility of relabelling each sequence with the SHA-1term ( Eastlake & Jones, 2001 ) or MD5term ( Rivest, 1992 ) message digest (hash) of the sequence. These are strings that are highly likely to be unique for each sequence. Before the digest is computed, the sequence is normalized by converting U’s to T’s and converting all symbols to upper case. VSEARCHterm includes public domain code for the MD5term algorithm written by Alexander Peslyak, and for SHA1term by Steve Reid and others.
VSEARCHterm also includes a new command ( rereplicate ) to perform rereplicationterm that can be used to recreate datasets as they were before full-length dereplicationterm, but of course original labels cannot be recreated.
Chimeraterm detection Chimerasterm are detected either de novo ( uchime_denovo command) or with a reference database ( uchime_ref command) using the UCHIME algorithmterm described by Edgar et al. (2011) . VSEARCHterm will divide each query sequence into four segments and look for similarity of each segment to sequences in the set of potential parents using the heuristic search function described earlier. It will consider the four best candidates for each segment using maxaccepts 4 and maxrejects 16, and an id threshold of 0.55. VSEARCHterm optionally outputs borderline sequences, that is, sequences having a high enough score (as specified with the minh option) but with too small a divergence from the closest parent (as specified with the mindiv option). Multi-threading is supported for reference-based chimeraterm detection.
Low-complexity sequence masking VSEARCHterm includes a highly optimized and parallelized implementation of the Dust algorithmterm by Tatusov and Lipman for masking of simple repeats and low-complexity nucleotide sequencesterm. It is considerably faster than the implementation of the same algorithm in USEARCHterm. Their code available at ftp://ftp.ncbi.nlm.nih.gov/pub/tatusov/dust/version1/src/ is in the public domain. VSEARCHterm uses this algorithm by default, while USEARCHterm by default uses an undocumented rapid masking algorithm called fastnucleo . VSEARCHterm performs soft-maskingterm automatically for the pairwise alignment, search, clustering and chimeraterm detection commands. This behaviour can be controlled with the hardmask option to replace masked symbols with N’s instead of lower-casing them, and the dbmask and qmask options, which selects the masking algorithm (none, dust or soft) used for the database and query sequences, respectively. Masking may also be performed explicitly on an input file using the fastx_mask and maskfasta commands.
FASTQterm file processing VSEARCHterm includes commands to detect the FASTQterm file version and the range of quality scores used ( fastqterm_chars ), as well as two commands for computing sequence quality statistics ( fastqterm_stats and fastqterm_eestats ). It can also truncate and filter sequences in FASTQterm files based on various criteria ( fastqterm_filter ). A new command is added to convert between different FASTQterm file versions and quality encodings ( fastqterm_convert ), e.g., from the old Phred+64 encoded Illumina FASTQterm files to the newer Phred+33 format.
Merging of paired-end readsterm Merging of paired-end readsterm is supported by VSEARCHterm using the fastqterm_mergepairs command. The method used has some similarity to PEAR ( Zhang et al., 2014 ) and recognises options similar to USEARCHterm. The algorithm computes the optimal ungapped alignmentterm of the overlapping region of the forward sequence and the reverse-complemented reverse sequence. The alignment requires a minimum overlap length (specified with the fastqterm_minovlen option, default 10), a maximum number of mismatches ( fastqterm_maxdiffs option, default 5), and a minimum and maximum length of the merged sequence ( fastqterm_minmergelen option, default 1, and fastqterm_maxmergelen option, default infinite). Staggered read pairs, i.e., read pairs where the 3′ end of the reverse read has an overhang to the left of the 5′ end of the forward read, are not allowed by default, but may be turned on by the fastqterm_allowmergestagger option. VSEARCHterm uses a match score (alpha) of +4 and a mismatch score (beta) of −5 for perfect quality residues. These scores are weighted by the probability that these two residues really match or mismatch, respectively, taking quality scores into account. These probabilities are computed in a way similar to PEAR score method 2 described in ‘Algorithms and implementation’ of the PEAR paper ( Zhang et al., 2014 ), but VSEARCHterm assumes all nucleotide background frequencies are 0.25. When merging sequences, VSEARCHterm computes posterior quality scoresterm for the overlapping regions as described by Edgar & Flyvbjerg (2015) . For speed, scores and probabilities are pre-computed for all possible quality scores.
Sorting and shuffling VSEARCHterm can sort FASTA files by decreasing sequence lengthterm·var ( sortbylength ) or abundance ( sortbysize ). VSEARCHterm can also perform shuffling of FASTA files in random order ( shuffle ). A seed value for the pseudo random number generatorterm may be provided by the randseed option to obtain replicable results.
Subsampling Sequences in FASTA and FASTQterm files can be subsampledterm ( fastx_subsample ) by randomly extracting a certain number ( sample_size ) or percentage ( sample_pct ) of the input sequences. Abundances may be taken into account, giving results as if the input sequences were rereplicated, subsampledterm and then dereplicated.
Results and Discussion Supported commands and options VSEARCHterm implements the following commands available in USEARCHterm version 7: allpairs_global , cluster_fast , cluster_smallmem , derep_fulllength , derep_prefix , fastqterm_chars , fastqterm_filter , fastqterm_mergepairs , fastqterm_stats , fastx_mask , maskfasta , sortbylength , sortbysize , uchime_denovo , uchime_ref and usearchterm_global . In addition, the following commands available in USEARCHterm version 8 have been implemented: fastqterm_eestats , fastx_revcomp , fastx_subsample and search_exact . VSEARCHterm additionally includes a few new commands that do not exist in USEARCHterm: cluster_size , fastqterm_convert , rereplicate and shuffle .
Some USEARCHterm version 7 commands have not yet been implemented in VSEARCHterm. We have not prioritized commands related to amino acid sequences ( findorfs ), local alignment ( allpairs_local , pairs_local , search_local , ublast ), brute-force search ( search_global , pairs_global ), UDB databases ( makeudb_ublast , makeudb_usearchterm , udb2fasta , udbinfo , udbstats ), and the UPARSE pipeline ( cluster_otus , uparse_ref ).
Almost all USEARCHterm 7 options are supported, except for those related to non-standard database indexing ( alpha , dbaccelpct , dbstep , pattern , slots ) as well as local alignments and alignment heuristics ( band , hspw , lext , lopen , matrix , minhsp , xdrop_g , xdrop_nw , xdrop_u ).
The same command and option names as in USEARCHterm version 7 have generally been used in order to make VSEARCHterm an almost drop-in replacementterm. In fact, in QIIME many commands will run fine if an alias or link from usearchterm to vsearchterm is made. Detailed documentation of VSEARCHterm is available as a man page. We will consider adding further commands and options to VSEARCHterm in the future.
Performance assessment The performance of the most important functions of VSEARCHterm version 2.0.3 (64-bit) was evaluated and compared to the 32-bit versions of USEARCHterm version 7.0.1090 and 8.1.1861. All datasets used were small enough to fit comfortably in the memoryterm allocated to a 32-bit process. Chimeraterm detection was also compared to UCHIME version 4.2. All tests were run on GNU/Linux CentOS 6.7 compute nodes with 16 physical cores (Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60 GHz) and 64GB RAM. Programs were run with 8 threads, if possible. All times indicated are wall-clock times. All scripts and data necessary to perform the evaluations are available in the GitHub repository at https://github.com/torognes/vsearch-eval/ to enable independent replication.
Searching Evaluation of search accuracy was carried out as described in the USEARCHterm paper ( Edgar, 2010 ), its supplementary, and on the website ( http://drive5.com/usearchterm/benchmark_rfamterm.html ), by assessing the ability of the programs to identify RNA sequences belonging to the same family in RFAMterm ( Burge et al., 2013 ). The 383,004 sequences in Rfamterm version 11 were randomly shuffled and then the first sequence from each of the 2,085 (out of 2,208) families that contained at least 2 members was selected as a representative and used as a query against the remaining 380,919 sequences. The programs were run with options id 0.0, minseqlength 1, maxaccepts 1, maxrejects 32, and strand plus. If the matching sequence found belonged to the same family, it was considered a true positive, otherwise it was considered as a false positive. We combined the results from 20 shufflings and plotted the results in the ROC-like curve shown in Fig. 1 . For a false discovery rateterm between 0.010 and 0.015, VSEARCHterm is more accurate than USEARCHterm’s latest version. For lower values, the three programs have similar accuracies. At higher false discovery ratesterm, USEARCHterm version 8 has an advantage.
Search accuracy on the RFAMterm v11 dataset. USEARCHterm version 7 (blue), USEARCHterm version 8 (orange) and VSEARCHterm (black) was run using the usearchterm_global command on subsets of the RFAMterm dataset to identify members of the same families. The plot shows the true positive rate (also known as the recallterm or sensitivity) as a function of the false discovery rateterm at varying sequence similarityterm·var levels. This curve is based on data from 20 shufflings of the dataset.
The time to search the Rfamterm database as described above was measured. To avoid extremely short running times, 1,000 replicates of the datasets were used. USEARCHterm version 7 required on average 5 min 29 s for the search, USEARCHterm version 8 took 5 min 57 s, while VSEARCHterm took 5 min 26 s.
Clustering Westcott & Schloss (2015) have already carried out an evaluation of the clustering performance of VSEARCHterm. They tested the ability of several tools to assign OTUs for 16S rRNA sequences and “demonstrated that for the greedy algorithms VSEARCHterm produced assignments that were comparable to those produced by USEARCHterm making VSEARCHterm a viable free and open source alternative to USEARCHterm”. Schloss (2016) also evaluated de novo clustering by VSEARCHterm.
We independently evaluated the clustering accuracy of USEARCHterm and VSEARCHterm as described for Swarm ( MahépersName et al., 2014 ) using two mock datasets, one with an even and one with uneven composition of 57 archaea and bacteria. The datasets were first dereplicated. Then the taxonomy of the unique sequences was assigned by a search against the set of rRNA reference sequences representing the species in the mock datasets, carried out with the usearchterm_global command of USEARCHterm. The sequences were shuffled randomly 10 times and clustering was performed at 20 different similarity levels ranging from 80% to 99% in steps of 1%. Clustering was carried out in two ways, first using the cluster_fast command that pre-sorts the sequences by length, and then using the cluster_smallmem command that simply processes the sequences in the user-supplied order (in that case, we supplied sequences ordered by decreasing abundance using the sortbysize command). We then compared the clusters obtained to the assigned species and computed the recallterm, precisionterm and the adjusted Rand indexterm of the classifications. Recallterm measures to what extent amplicons assigned to the same speciesterm are grouped together in the same OTUterm (i.e., not over-splitting). Precisionterm measures to what extent amplicons in an OTU are assigned to the same speciesterm (i.e., not over-grouping). The adjusted Rand indexterm ( Rand, 1971 ; Hubert & Arabie, 1985 ) summarises both precisionterm and recallterm using a measure of agreement between two clusterings while adjusting for expected valuesterm by chance. The average values over the all shufflings are presented in Figs. 2 and 3 for the even and uneven datasets, respectively. For abundance-sorted sequences, the difference between VSEARCHterm and USEARCHterm version 8 is negligible. The difference is larger for length-sorted sequences. When using length sorting, USEARCHterm 8 (as well as version 7 on the even dataset) shows better precisionterm than VSEARCHterm for similarity levels below 93%. However, OTU delineation is usually performed at higher similarity values, typically 97%. In the case of our benchmark, overall accuracy as measured by the adjusted Rand indexterm is maximised at 95–97% similarity. This is precisely the region where for length sorting at least VSEARCHterm outperforms USEARCHterm.
Clustering accuracy on the even dataset. USEARCHterm version 7 (blue) and 8 (orange) and VSEARCHterm (black) was run using abundance sorting ( cluster_smallmem ) (A, C, E) and length sorting ( cluster_fast ) (B, D, F) on the even dataset. The performance is indicated with the adjusted Rand indexterm (A, B), recallterm (C, D) and precisionterm (E, F) metrics.
Clustering accuracy on the uneven dataset. USEARCHterm version 7 (blue) and 8 (orange) and VSEARCHterm (black) was run using abundance sorting ( cluster_smallmem ) (A, C, E) and length sorting ( cluster_fast ) (B, D, F) on the uneven dataset. The performance is indicated with the adjusted Rand indexterm (A, B), recallterm (C, D) and precisionterm (E, F) metrics.
The time usedterm for clustering is shown in Fig. 4 . The time usedterm depended on the dataset, algorithm and clustering thresholdterm. The USEARCHterm programs were in general 2–3 times faster than VSEARCHterm. In general the difference in speed was smaller for higher thresholds, especially at 99% similarity. Clustering with USEARCHterm using the fulldp option is an order of magnitude slower than VSEARCHterm, but contrary to our expectations it does not seem to improve accuracy.
Clustering speed. Median wall time in seconds to cluster the even (A, B) and uneven (C, D) datasets using USEARCHterm version 7 (blue) and 8 (orange) and VSEARCHterm (black) using abundance sorting ( cluster_smallmem ) (A, C) and length sorting ( cluster_fast ) (B, D).
Dereplication Measurements of dereplication speed were performed on the even and uneven datasets described earlier as well as on the BioMarKs dataset ( Logares et al., 2014 ). For full-length dereplicationterm ( derep_fulllength ) VSEARCHterm was about 40–50% faster than USEARCHterm version 7 and 50–70% faster than version 8 on all three datasets. All programs were approximately equally fast on prefix dereplicationterm ( derep_prefix ) of the even and uneven datasets. However, prefix dereplicationterm of the BioMarKs dataset was extremely slow with USEARCHterm. USEARCHterm version 7 used more than 4 min and version 8 more than 27 min, while VSEARCHterm used less than 4 s. The prefix dereplicationterm algorithm used in USEARCHterm appears ineffective when dealing with short sequences. Removing the 811 sequences shorter than 200 bp out of the 312,503 sequences of the BioMarKs dataset reduces the running time of USEARCHterm version 7 and 8 down to just 5 and 6 s, respectively.
Chimeraterm detection We evaluated the chimeraterm detection accuracy of VSEARCHterm and USEARCHterm in two ways, first using a method similar to that performed for UCHIME, and then using a new chimeraterm simulation procedure based on sequences from Greengenesterm ( DeSantis et al., 2006 ) and SILVAterm ( Quast et al., 2013 ) sequences.
Chimeraterm detection performance with the SIMM datasetterm. UCHIME (UC), USEARCHterm version 7 (U7) and 8 (U8), and VSEARCHterm (V) was run using the uchime_ref algorithm on the SIMM datasetterm that was originally also used to evaluate the UCHIME algorithmterm. Divergence is the percentage of similarity to the original sequences. Noise is either zero (–) or the percentage of indels (i1–i5) or substitutions (m1-5) added. The number of chimerasterm detected out of 100 of each type is shown. The best results in each category are shaded.
First we repeated the evaluation of the uchime_ref command described in the UCHIME paper ( Edgar et al., 2011 ) using the SIMM datasetterm downloaded from http://drive5.com/uchime/uchime_download.html . The dataset consists of 900 simulated chimerasterm that are approximately 250 bp long. The chimerasterm were generated from 2, 3 or 4 segments selected randomly from 86 original sequences and have similarities in the ranges 90–95%, 95–97% and 97–99% to the original sequences. They were either used unmodified or with 1–5% indels or 1–5% substitutions. We assessed the performance of (i) the original open-source UCHIME version 4.2 program, (ii) USEARCHterm version 7, (iii) USEARCHterm version 8, and (iv) VSEARCHterm. The results are shown in Table 1 and indicate that VSEARCHterm is superior to the other tools in almost all cases, and in particular when indels were added. The original UCHIME program was found to be quite, but also considerably slower than all the other tools. USEARCHterm was better than VSEARCHterm in only 4 out of 99 cases.
Next, we tested reference-based ( uchime_ref ) and de novo ( uchime_denovo ) chimeraterm detection using sequences from the 2011 version of Greengenesterm downloaded from http://greengenesterm.lbl.gov/Download/Sequence_Data/Fasta_data_files/ and from version 106 (May 2011) of the SILVAterm database downloaded from https://www.arb-silva.de/no_cache/download/archive/release_106/Exports/ . Sequences from the 16S rRNA V4 region was computationally extracted using the 515F (5′-GTGNCAGCMGCCGCGGTAA-3′) and 806R (5′-GGACTACHVGGGTWTCTAAT-3′) primers, and 8,000 reads were randomly selected from each database. PCR was simulated using a new simulation algorithm known as Simera ( NicholspersName & QuincepersName, 2016 ) (available at https://github.com/bnichols1979/Simera ) that includes amplification and creation of PCR artefacts like chimerasterm. We sampled 30,000 reads (-s 30,000) and generated 20,000 potential chimerasterm (-c 20,000). Defaults were used for other options to Simera. The output sequences were then fed into an Illumina MiSeq noise simulator ( Schirmer et al., 2015 ) ending up with 14,966 reads based on Greengenesterm and 14,952 reads based on SILVAterm, of which 1,262 and 1,640 reads contain chimeric sequences, respectively. Next, the sequences were either clustered using the cluster_fast command at 97% identity or dereplicated. VSEARCHterm and USEARCHterm version 7 and 8 were run using the uchime_denovo command and then using the uchime_ref command with the Gold database downloaded from http://drive5.com/uchime/uchime_download.html as the reference database. To assess the performance, the results were sorted based on the chimera scoreterm·var, and then the ability to classify individual sequences correctly into chimeric and non-chimeric was plotted as ROC curves. The curves reflect the accuracy of classifying individual reads, not clusters, as abundances were taken into account. The plots in Figs. 5 and 6 show that de novo chimera detectionterm performs better than reference-based detectionterm, with the SILVAterm dataset in particular, but it does of course depend on the reference database used. VSEARCHterm performs better than both versions of USEARCHterm for de novo chimera detectionterm. For reference-based detectionterm VSEARCHterm also performs better for the Greengenesterm dataset, while none of the programs work well with the SILVAterm dataset. Clustering at 97% appears to be more appropriate than dereplication. In this test, the USEARCHterm programs were about twice as fast as VSEARCHterm for de novo detection, while they were about 10–30% faster than VSEARCHterm for reference-based detectionterm.
Chimeraterm detection performance with the Greengenesterm dataset shown with ROC curves. USEARCHterm version 7 (blue) and 8 (orange) and VSEARCHterm (black) was run using the uchime_denovo (A, B) and the uchime_ref (C, D) commands on simulated Illumina data based on the Greengenesterm database that has either been clustered with a 97% identity threshold (using the cluster_fast command in VSEARCHterm) (A, C) or dereplicated (using the derep_fulllength command in VSEARCHterm) (B, D).
Chimeraterm detection performance on the SILVAterm dataset shown with ROC curves. USEARCHterm version 7 (blue) and 8 (orange) and VSEARCHterm (black) was run using the uchime_denovo (A, B) and the uchime_ref (C, D) commands on simulated Illumina data based on the SILVAterm database that has either been clustered with a 97% identity threshold (using the cluster_fast command in USEARCHterm) (A, C) or dereplicated (using the derep_fulllength command in VSEARCHterm) (B, D).
Merging of paired-end readsterm Evaluation of paired-end readsterm merging performance was carried out in a manner similar to that described for the evaluation of PEAR ( Zhang et al., 2014 ). We used whole genome sequencing data from Staphylococcus aureus subspecies aureus strain USA 300 TCH 1516 sequenced by MacCallum et al. (2009) and retrieved from the GAGE-B repository ( http://ccb.jhu.edu/gage_b/ ). The S.aureus reads were 101 bp long from on average 180 bp long fragments, giving a 45X coverage of the genome. We also used Methylococcus capsulatus strain Bath 16S rRNA V3 region amplicon reads sequenced by Masella et al. (2012) . These reads were 108 bp long and the pairs should have an overlap of exactly 18 bp. Merging options were set to allow a minimum overlap of 10 bp and a maximum of 5 mismatches (USEARCHterm 7 and 8 have different default values for those), while other options were left at defaults. All programs were run with 8 threads. Merged sequences that could be perfectly aligned to their respective reference sequences (either the entire genome or the specific rRNA region) using BWA MEM ( Li & Durbin, 2009 ) were considered correctly mergedterm. The results are shown in Table 2 . The numbers indicate that USEARCHterm version 7 merges the most reads for both bacteria, but also has the lowest percentage of correctly mergedterm pairs of those merged. USEARCHterm version 8 merges the fewest reads, but has the highest percentage of correctly mergedterm reads of those merged. VSEARCHterm is in the middle by merging more reads than USEARCHterm 8 with only a small decrease in the percentage of correct mergesterm·var. VSEARCHterm is about twice as fast as USEARCHterm 8 and 4–5 times faster than USEARCHterm version 7.
Paired-end readsterm merging performance. The number of sequence pairs, merged pairsterm·var, and correctly mergedterm pairs are shown for each bacterium and program. The percentage of reads merged, as well as the percentage of correctly mergedterm reads both of the merged reads and of all reads are also shown. Times are in seconds using 8 threads.
Subsampling performance. The observed distribution of the maximum amplicon abundance in 10,000 random subsamplings of 5% of the TARA V9 dataset using VSEARCHterm (A, black) and USEARCHterm version 8 (B, orange) is shown. The expected mean abundance is 782,133.5 (blue dashed line).
Subsampling We evaluated the subsampling commands of USEARCHterm version 8 and VSEARCHterm to check if the results obtained correspond to those expected. We performed 10,000 random subsamplings of 5% of the 9.5 million unique sequences in the TARA V9 dataset ( Karsenti et al., 2011 ). To make this possible with the 32-bit USEARCHterm, we first downsampled the dataset once to 10% using VSEARCHterm and then randomly subsampledterm it again at 50% with either USEARCHterm or VSEARCHterm. Plots of the distribution of the abundance of the most abundant sequence in each subsampling are shown in Fig. 7 . The highest amplicon abundance in the original dataset is 15,638,316. After the initial 10% subsampling, the highest abundance was 1,564,267. After the second subsampling, the top abundances should therefore have a distribution centred on a value of 782,133.5. As can be seen from the figure, the USEARCHterm distribution has a mean that is about 2,000 too small, while the VSEARCHterm distribution is correctly centred on the expected valueterm. Subsampling experiments were also performed at 2.5%, 1.5% and 0.5% with similar results, although the errors were of decreasing size. USEARCHterm seems to under-sample abundant ampliconsterm and to over-sample rare ampliconsterm.
Conclusions VSEARCHterm supports almost all of the commands and options for nucleotide sequence analysis in USEARCHterm version 7 as well as several new features. It has a 64-bit design and handles large datasets virtually only limited by the amount of available memoryterm. We have demonstrated that VSEARCHterm is in general more accurate than USEARCHterm when performing searching, clustering, chimeraterm detection and subsampling. The accuracy is on a par with USEARCHterm for paired-end readsterm merging. VSEARCHterm is faster than USEARCHterm when performing dereplication and merging of paired-end readsterm, but slower for clustering and chimeraterm detection. We will continue to improve the accuracy, speed and robustness of VSEARCHterm in the future, as well as adding new features.