Home Software Services About Contact     
Follow on twitter

Robert C. Edgar on twitter

11-Aug-2018 New paper describes octave plots for visualizing alpha diversity.

12-Jun-2018 New paper shows that one in five taxonomy annotations in SILVA and Greengenes are wrong.

18-Apr-2018 New paper shows that taxonomy prediction accuracy is <50% for V4 sequences.

05-Oct-2017 PeerJ paper shows low accuracy of closed- and open-ref. QIIME OTUs.

22-Sep-2017 New paper shows 97% threshold is wrong, OTUs should be 99% full-length 16S, 100% for V4.

UPARSE tutorial video posted on YouTube. Make OTUs from MiSeq reads.




Many search and clustering commands in USEARCH support multithreading. Multithreading is parallel execution on a single CPU. All threads belong to the same process and share the same memory space.

You can  check if a given command supports multi-threading by checking the documentation page for a link to "Multithreading".

Database search commands generally parellelize very well (e.g. usearch_global, ublast), but commands based on clustering (e.g. cluster_fast, cluster_smallmem, cluster_otus, unoise2, uchime2_denovo) typically don't support multithreading or don't achieve much speedup from running multiple threads.

The -threads option species the requested number of threads, e.g. -threads 4.

Default is to run one thread per CPU core, or 10 threads if there are > 10 cores.

Performance may be improved by using more or fewer threads than the number of cores. If USEARCH is sharing a CPU with other resource-intensive programs, it may be better to set the number of threads so that the total number of executing threads in all programs does not exceed the number of cores. Using fewer threads can be faster if cache contention is reduced, and more threads can be faster if output is written via a slow network, in which case many threads may be stalled waiting for output to complete.