I am going to use the Train Ausgutus tool, but it reported the following error: Error: training set file /mnt/scratch/job_working_directory/008/978/8978590/working/genome.gff3 has neither Genbank nor GFF nor FASTA format!
Could anyone help me? Thank you very much!
Then, if you cannot solve the problem and want help, you can post back some of your data or the shared history and we can offer advice. How to share the parts of your data that will allow others to give specific feedback is below. We like details!
Hi jennaj, thanks for your help. However, the problem still exists. I have converted GFF to GTF, but it still didn’t work for Augusts training. Here is my history:Galaxy | Australia. Please feel free to have a look and see where the problem comes from.
As @jennaj said, it sounds like the input reference data has a format problem. I could not figure out what caused this issue, but it can be fixed using gffread tool in Galaxy. gffread is a GFF/GTF converter. Use it on Final annotation from Maker. Specify the output format as GFF. Make sure you do not modify or filter the data. The output file from gffread should have GFF3 datatype. You’ll see some obvious changes, such as appearnae of couple comment lines and absence of empty comment lines. My test Train Augustus jobs with “fixed” GFF3 file are running for twenty minutes now, while with the original GFF3 file the jobs failed in seconds.
@jennaj, we see similar errors occasionally with Train Augustus, but it is a mystery to me why it happens on some assemblies. Maybe a note can be added about the gffread fix to the Genome annotation with Maker tutorial. I don’t know if the fix universal or not, and my test jobs are not finished yet, so, technically, I cannot call it “fix” at this point, but it does address “not GFF format” issue.
This is a good idea! I’ve seen a few GTFs that are missing that final ; and it seems to just be the “transcript_id”“transcript” feature (3rd column) lines but I haven’t looked/tested in detail yet to figure out where that is coming from yet. Maybe a wrapper bug… or something that can be adjusted in the wrapper if that is from Maker directly. More soon and thanks for the workaround!!
Hopefully the IUC can help us to figure out exactly where things are going wrong! Seems like the format problem is both introduced and fixed by gffread with different uses!