Thank you guys @althonos @gbouras13 @apcamargo! That’s called efficiency! Just tested it on a set of ~2000 metagenomic viral contigs and no problems observed!

Easiest commit I have made, sorry about that @althonos but fixed now 😃

@althonos @apcamargo I’m releasing v1.5.0 today. I’ve added a citation to the citations section for pyrodigal-gv as this:

Larradle M. and Camargo A., (2023) Pyrodigal-gv: A Pyrodigal extension to predict genes in giant viruses and viruses with alternative genetic code. https://github.com/althonos/pyrodigal-gv.

If you want to change it just let me know.

George

I’ve tested it out today on a number of single phages + a 673 contig gut phage test set (from Yutin et al), around 50MB fasta file.

The results look great, I get exactly what is expected and the output is easily parsable for me.

With pyrodigal v3.0.0-alpha2 & pyrodigal v0.1.0a1 implemented in Pharokka v1.5.0 (dev branch):

Running on Intel Core i7-10700K CPU @ 3.80GHz on a machine running Ubuntu 20.04.6 LTS, it took 305 seconds to run the pyrodigal-gv step (I didn’t do proper measurements with time, this is just coming from the Pharokka output log).

This compares to 184 seconds for regular pyrodigal on the same dataset.

For single phage contigs runtime is negligible for both (sub 1 second).

Overall, I am happy with the output for my purposes, when you release pyrodigal v3 and pyrodigal_gv as a stable release, I will soon after release Pharokka v1.5.0 with support for pyrodigal-gv.

Thanks @althonos and @apcamargo amazing stuff!

George

@gbouras13 : pip install -U --pre pyrodigal-gv if you wanna test 😉

Also more generally speaking as sort of mentioned in https://github.com/althonos/pyrodigal/issues/24, not sure what you have in mind but there’s some scope to build upon your methods for alternative coding prediction and within-genome stop codon reassignment (see e.g. https://github.com/gatech-genemark/Mgcod ).

On that note, I think within-genome stop codon reassignment is probably out of scope for Prodigal, because the dynamic programming needs to have the codons from the entire genome to start finding the highest scoring gene path. However, alternative coding prediction could be feasible, similarly to the meta mode, trying to nodes with several different genetic codes before extracting genes for the highest scoring one.

Work with @althonos to get prodigal-gv’s models added to pyrodigal https://github.com/althonos/pyrodigal/issues/24. But this seems like a lot of work to do when prodigal-gv already exists, plus it feels like more of a fork-related feature I think than a core pyrodigal feature (it’s up to Martin anyway after all).

I don’t think I will integrate it to “stock” Pyrodigal, but i can probably figure out a way to get that into a different dedicated package that has the prodigal-gv models, especially if you’d find it useful right away 👍

I’m still testing it out. But no problems so far!

MZ130495.1	pyrodigal_v3.0.0-alpha2	CDS	98636	101128	474.7	+	0	ID=MZ130495.1_100;partial=01;start_type=ATG;rbs_motif=TAA;rbs_spacer=12bp;gc_cont=0.361;transl_table=15;conf=99.99;score=474.69;cscore=467.02;sscore=7.67;rscore=5.99;uscore=1.68;tscore=0.00;

Beautiful, outputs look great to me.

More than happy to do any testing that you would find useful Martin.

George

@gbouras13 : I have made a new Pyrodigal pre-release that supports that (pip install -U --pre pyrodigal to get 3.0.0-alpha2), this way you get a new include_translation_table keyword argument among other things that outputs the translation table. (I’m using translation_table to remain consistent with Prodigal).

@althonos I’ve given it a test run (with the pyrodigal v3 alpha installed from source), it looks phenomenal mate.

The only thing lacking I can think that would be useful (in terms of recapitulating the pyrodigal-gv output and generally) is ‘genetic_code’ in the description (it’s between rbs_spacer and gc_cont).

prodigal-gv v2.11 output

MZ130495.1      Prodigal_v2.11.0-gv     CDS     98636   101128  474.7   +       0       ID=1_100;partial=01;start_type=ATG;rbs_motif=TAA;rbs_spacer=12bp;genetic_code=15;gc_cont=0.361;conf=99.99;score=474.69;cscore=467.02;sscore=7.67;rscore=5.99;uscore=1.68;tscore=0.00;

pyrodigal-gv output

MZ130495.1	pyrodigal_v3.0.0-alpha1	CDS	98636	101128	474.7	+	0	ID=MZ130495.1_100;partial=01;start_type=ATG;rbs_motif=TAA;rbs_spacer=12bp;gc_cont=0.361;conf=99.99;score=474.69;cscore=467.02;sscore=7.67;rscore=5.99;uscore=1.68;tscore=0.00;

the code:

def run_pyrodigal_gv(filepath_in, out_dir, coding_table):

    orf_finder = pyrodigal_gv.ViralGeneFinder(meta=True)

    with open(os.path.join(out_dir, "prodigal_out.gff"), "w") as dst:
        for i, record in enumerate(SeqIO.parse(filepath_in, "fasta")):
            genes = orf_finder.find_genes(str(record.seq))
            genes.write_gff(dst, sequence_id=record.id)

George

I think it would be very useful quite soon for lots of users in the gut metagenome/giant virus etc space.

Also more generally speaking as sort of mentioned in https://github.com/althonos/pyrodigal/issues/24, not sure what you have in mind but there’s some scope to build upon your methods for alternative coding prediction and within-genome stop codon reassignment (see e.g. https://github.com/gatech-genemark/Mgcod ).

Happy to help out and contribute whatever I can to help make this happen (and I’m sure @asierFernandezP and @apcamargo would be keen too by the looks).

George