Closed IanDMedeiros closed 2 years ago
args.antismash
is from the command line option, it would be False if nothing was passed. So you don't have to pass the GBK file via the --antismash option, if the file is there it will be parsed (ie file will be put there from remote). otherwise it will use the file that exists, ie so if you pass an file there perhaps you re-ran it and it should not use existing file in that location.
Ok—don't use --antismash if I just ran antismash with remote, got it.
With that I am almost to the end of the pipeline ("writing genome annotation table!"), but there is one more error I have no idea what to do with... Seems to suggest that there is an "E" in the nucleotide CDS sequence, but I checked and there is not. Is there something else that could cause this?
Traceback (most recent call last):
File "/hpc/home/idm7/miniconda3/envs/funannotate/bin/funannotate", line 8, in
I have not seen this before, and yes it does suggest there is an E in the CDS transcript somehow. It should be writing that file line by line so if you look at the last record it wrote it should be the gene immediately after that causing the problem. Unfortunately you can't likely see the dictionary value it's trying to reverse complement. The data are loaded/parsed from the tbl file I believe and are actually all written again in annotate_results should also be a cds transcript file. So doesn't make a lot of sense if it wrote it correctly there but then failed later. You'd have to put a try/except to catch that error and then output the offending record.
Took a look at the cds transcript file in annotate_results as you suggested, and... bizarrely, it's doing the thing from #763 again — printing the same sequence to the output over and over. When I ran annotate
again without --rename
, everything completed without errors.
Weird. Perhaps try to install the latest release?
This turned out to be an error in how I was providing the locus tag prefix to funannotate; because of a poorly constructed table file, there was a hidden newline character in my variable $locus_tag that was messing everything else up. Closing since fixing the table file solved the problem.
funannotate v1.8.12
Funannotate annotate
failed when I included the argument--antismash /path/to/annotate_misc/antiSMASH.results.gbk
because the file did not exist. I dug into it and discovered that annotate was removing the file from annotate_misc. Is this a bug?As far as I can tell,
funannotate remote
creates a file antiSMASH.results.gbk in annotate_misc (from remote.py):Then,
funannotate annotate
deletes this file without using it (from annotate.py):