Difference between revisions of "BLAST"
(Created page with "[http://blast.ncbi.nlm.nih.gov/Blast.cgi?CMD=Web&PAGE_TYPE=BlastDocs Blast] (basic alignment search tool) is a software package for aligning nucleotide or amino acid sequences. I...") |
|||
Line 1: | Line 1: | ||
[http://blast.ncbi.nlm.nih.gov/Blast.cgi?CMD=Web&PAGE_TYPE=BlastDocs Blast] (basic alignment search tool) is a software package for aligning nucleotide or amino acid sequences. Its primary use is to search databases for sequences that are similar to a given candidate sequence. | [http://blast.ncbi.nlm.nih.gov/Blast.cgi?CMD=Web&PAGE_TYPE=BlastDocs Blast] (basic alignment search tool) is a software package for aligning nucleotide or amino acid sequences. Its primary use is to search databases for sequences that are similar to a given candidate sequence. | ||
+ | |||
+ | == Computational considerations == | ||
+ | |||
+ | === Work locally === | ||
+ | |||
+ | Many of the features in Blast require access to database flatfiles, and standard practice when running a compute cluster is to copy all necessary files to a node local directory before any work is done with them. This behaviour is highly encouraged on most resources, since multiple simultaneous accesses to the same large files on a shared disk is likely to cause problems for all computations currently running on the resource, and not only for the owner of the badly behaving jobs. For this reason, most SNIC resources have amenities in place to aid you in running your Blast jobs in an optimal manner (for example <code>prepare_db</code> and <code>$BLASTDB<code>, described for example [https://extras.csc.fi/mgrid/blast_re/ here]). | ||
+ | |||
+ | === Use all your processors === | ||
+ | |||
+ | Blast uses only one processor core by default, but you increase this number using the <code>-a</code> command line option, which can often provide a significant increase in speed. If you are using a preinstalled Blast version on a SNIC resource, the recommended number of cores to use is given by the <code>$BLAST_NUM_CPUS</code> environment variable (e.g. used like <code> blastall -a $BLAST_NUM_CPUS ... </code>). However, in some situations you may want to consider decreasing this number, particularly if your searches generate a large enough number of hits to deplete RAM, causing the OS to start swapping data and results to disk, which will near slow your job to a stop (see below). | ||
+ | |||
+ | === Do not run out of memory === | ||
+ | |||
+ | If possible, you should ensure that you have enough RAM to hold the database as well as the results and still have some headroom. This ensures that Blast will not need to read data from disk unnecessarily, which otherwise would cause significant slowdown. This can be done for example by: | ||
+ | |||
+ | * '''Choose a system with enough RAM''' <br/> Multiprocessor systems generally have more memory than single processor systems, and the database will also require proportionally less memory, since only one copy is needed in the OS file cache regardless of the number of processors using it. | ||
+ | * '''Partition the search space''' <br/> For huge databases or very restricted amounts available memory it may be required to split the database into manageable chunks and process them as separate jobs. |
Revision as of 10:18, 25 February 2011
Blast (basic alignment search tool) is a software package for aligning nucleotide or amino acid sequences. Its primary use is to search databases for sequences that are similar to a given candidate sequence.
Contents
Computational considerations
Work locally
Many of the features in Blast require access to database flatfiles, and standard practice when running a compute cluster is to copy all necessary files to a node local directory before any work is done with them. This behaviour is highly encouraged on most resources, since multiple simultaneous accesses to the same large files on a shared disk is likely to cause problems for all computations currently running on the resource, and not only for the owner of the badly behaving jobs. For this reason, most SNIC resources have amenities in place to aid you in running your Blast jobs in an optimal manner (for example prepare_db
and $BLASTDB
, described for example here).
Use all your processors
Blast uses only one processor core by default, but you increase this number using the -a
command line option, which can often provide a significant increase in speed. If you are using a preinstalled Blast version on a SNIC resource, the recommended number of cores to use is given by the $BLAST_NUM_CPUS
environment variable (e.g. used like blastall -a $BLAST_NUM_CPUS ...
). However, in some situations you may want to consider decreasing this number, particularly if your searches generate a large enough number of hits to deplete RAM, causing the OS to start swapping data and results to disk, which will near slow your job to a stop (see below).
Do not run out of memory
If possible, you should ensure that you have enough RAM to hold the database as well as the results and still have some headroom. This ensures that Blast will not need to read data from disk unnecessarily, which otherwise would cause significant slowdown. This can be done for example by:
- Choose a system with enough RAM
Multiprocessor systems generally have more memory than single processor systems, and the database will also require proportionally less memory, since only one copy is needed in the OS file cache regardless of the number of processors using it.
- Partition the search space
For huge databases or very restricted amounts available memory it may be required to split the database into manageable chunks and process them as separate jobs.