You have a choice to make.
- hhblits allows you to specify a number of threads for HMM searching for each individual query. This means that that single query will finish faster.
- You can run each query with a single thread, but launch as many fasta jobs as your infrastructure will tolerate (up to your CPU count essentially).
Which of these will be faster, I have no idea.
Alternatively, lets say you had 30 cores, you could launch 6 fasta jobs at a time, each with 5 cores for the actual HMM searching.
To launch multiple jobs, look at some guides for GNU
Again, which of these scenarios will be fastest, I don’t know. If you opt for the last approach, combining parallel with the process having multiple threads, make sure the maths adds up to your total number of cores or less, else you’ll risk CPU thrashing.
After having a little chat with some colleagues and one of the developers of the tool, the general rule of thumb (not just for HHsuite) is that launching
n processes with 1 thread each will be faster than launching 1 process with
n threads (with some exceptions for disk IO and such like). There are also
mpi binaries for parallel processing which minimise the RAM requirements by sharing data between threads.
I.e., if you have 300 sequences and 32 cores, say, you’re best to launch 32 x 1 thread processes (one for each fasta), which you could do with
parallel as I mentioned before. As each 1 of the 32 finishes, the next can be started (
parallel takes care of this).