All-by-All Blast configuration

[rbdavid]

• Timescaling of blast on multiple cpus. Explicitly define nProcessors (via -a input arg).
• Alternatively, make the num_fasta_shards number dynamically change to maintain a reasonable amount of sequences per shard to avoid memory limitations.
• Copy the outputs of formatdb call into a compute node-local storage space. Write output file to that same storage space and then copy to publishDir when completed.

[rbdavid]

The above bullet points are not inherently associated with nextflow configuration for the all-by-all blast process block. But work continues on these fronts:

• Timescaling of blast is on-going. The -a input arg is implemented as part of 377 - axa blast configuration #379.
• Figuring out the "correct" num_fasta_shards parameter value is on going as part of the timescaling efforts. Dynamic setting of this value has not been considered thoroughly enough to develop that feature at the moment.
• The blastp calls are not hugely IO intensive, even for large sized sequence sets, so copying the formatdb files to a compute-local storage space isn't high priority. There may still be value in investigating this if num_fasta_shards values remain high. A large number of readers of a single set of files may cause an unwanted computational bottle neck, especially when this is happening over the interconnect rather than on hard silicon in the compute node.