I am using GNU parallel to speed up BLAST and I am using this command:
cat test.fna | parallel --gnu --block 100k --recstart '>' --pipe blastn -db database -query - > test.fna.blastn
I am noticing that errors arise such as:
"Error: (1431.1) FASTA-Reader: Warning: FASTA-Reader: No residues given
BLAST engine error: Warning: Sequence contains no data"
As well, if I investigate the BLAST output, the first query name is not accurate (it is just a small string from the whole query name), and that some reads are lost in the process (e.g. 4979 reads in BLAST output, but 5000 reads in the original reads file).
I have checked to make sure there isn't another '>' in the header names so that recstart doesn't split incorrectly. Any other ideas?
Thanks!
edit: the pattern I am finding is that for each block that parallel makes, it loses the first ~7-8 reads in that block, and for the first read that actually gets put into the block, the query name is actually read in as the sequence and so it gives an error. Not sure if that helps in solving this issue or not.
cat test.fna | parallel --gnu --block 100k --recstart '>' --pipe blastn -db database -query - > test.fna.blastn
I am noticing that errors arise such as:
"Error: (1431.1) FASTA-Reader: Warning: FASTA-Reader: No residues given
BLAST engine error: Warning: Sequence contains no data"
As well, if I investigate the BLAST output, the first query name is not accurate (it is just a small string from the whole query name), and that some reads are lost in the process (e.g. 4979 reads in BLAST output, but 5000 reads in the original reads file).
I have checked to make sure there isn't another '>' in the header names so that recstart doesn't split incorrectly. Any other ideas?
Thanks!
edit: the pattern I am finding is that for each block that parallel makes, it loses the first ~7-8 reads in that block, and for the first read that actually gets put into the block, the query name is actually read in as the sequence and so it gives an error. Not sure if that helps in solving this issue or not.