A blast warning makes fur exit with status 1

[IvanTsers]

Hello Bernhard,

When I run fur on my laptop under WSL, I get this message:

fur - Failed Blast: Warning: [blastn] Number of threads was reduced to 4 to match the number of available CPUs

The program stops and returns no output at this point. This happens unless I override the default -t 8 threads option of fur with -t 4. Indeed, my laptop has 4 threads, so the warning makes sense:

Architecture:            x86_64
  CPU op-mode(s):        32-bit, 64-bit
  Address sizes:         46 bits physical, 48 bits virtual
  Byte Order:            Little Endian
CPU(s):                  4
  On-line CPU(s) list:   0-3
Vendor ID:               GenuineIntel
  Model name:            12th Gen Intel(R) Core(TM) i7-1270P
    CPU family:          6
    Model:               154
    Thread(s) per core:  1
    Core(s) per socket:  4
    Socket(s):           1

If I run blastn on 8 threads, it gives the same warning, changes the number of threads to 4 and continue running.

Well, this is fair enough, but I think the problem is a bit deeper than the default number of threads. I assume that log.Fatal() apparently interprets any warnings from a run of blast as fatal errors and forces an os.Exit(1). I think this issue is akin to the one Beatriz had last month, when there was a warning from blast complaining about masking.

Cheers, ivan

[haubold]

Thank you for pointing out this bug. The latest version of fur now takes the number of CPUs, c, as the default number of threads. If the user opts for a larger number of threads, this gets reduced to c and a warning is printed. I agree this still leaves the wider issue of parsing blast warnings without exiting, but the current fix should at least prevent an important class of warnings altogether.

[thom-ST]

(base) mahe@pop-os:~/Downloads/PhD/Automation Trial/Unique & Common/Input$ makeFurDb -t targets -n neighbors -d fur.db using Genome_A.fa as target representative making Blast database makeFurDb - exit status 3

[haubold]

Thank you for posting about this problem. Could you please also post a link for your fur.db so that I can reproduce the error?

[thom-ST]

targets.zip neighbors.zip fur.db.zip PFA

[haubold]

Thank you for posting the input data. In my hands this runs fine: I make the database test.db

makeFurDb -t targets/ -n neighbors/ -d test.db

and then run fur on it.

fur -d test.db/

This yields

  Step           Sequences  Length  Ns
  -------------  ---------  ------  --
  Subtraction_1          5     883   0
  Intersection           5     883   0
  Subtraction_2          3     480   0
>CP042804.1_(2888..3025)
ACTGGTCGCAGGCGTCGTCGAGCGCCGACAGACCTTGCCGGTACTGTCCAACGTGCTGTTGGTCGTCGAA
GGCCAGCAACTGTCGCTGACCGGTACCGACCTGGAAGTCGAGCTGGTCGGTCGTGTGCAACTCGAAGA
>CP042804.1_(3172..3372)
CCCTGCCGGCCAACGATTTCCCGACCGTCGAAGAAGGCCCGGGCTCGCTGACCTGCAGCCTGGAGCAAAG
CAAACTGCGTCGTCTGATCGAACGCACCAGCTTCGCCATGGCCCAGCAGGACGTGCGTTACTACCTCAAC
GGCATGCTGCTGGAAGTTTCCGCTGGTGTGATCCGCGCCGTGGCCACCGACGGACACCGTC
>CP042804.1_(8980..9120)
CCCGACAGTGGAAGAAGGCCCGGGCTCGCTGACCTTCAATCTGGTGCAGAGCAAGTTGCGCCGCCTGATT
GAACGCACCAGCTTTGCGATGGCCCAGCAGGATGTTCGCTACTACCTCAACGGCATGCTGCTTGAAGTGA
G

I did, however, notice that your fur.db lacks the file n.txt, which contains

length: 9520
GC-content: 0.594958

When this is added to your database fur.db, the subsequent analysis with fur again runs ok. So I wonder whether during your run of makeFurDb to construct fur.db the program might have run out of disk space?