Repository navigation
TransDecoder.Predict writes the ORFs of a transcript in a different order on each run #212
Description
Hi,
I run TransDecoder 5.7.1 (bioconda, Perl 5.32.1) inside transXpress (https://github.com/titodamiani/transXpress), a Snakemake pipeline, and I compare repeated runs byte for byte. TransDecoder.Predict gives the same ORFs every time, but not in the same order. Four runs on the same input gave four different md5 sums for the .pep file, with the same records in all four. The transcripts come out in the same order each time. It's the ORFs inside one transcript that move.
I think it comes from the gene loop in PerlLib/GFF3_utils2.pm. The loop over the assemblies above it is sorted, the one over the genes isn't. Master and 6.0.0 have the same lines:
$ grep -n 'keys %' PerlLib/GFF3_utils2.pm
137: foreach my $asmbl_id (sort keys %gene_coords) {
140: foreach my $gene_id (keys %$genes_href) {
146: foreach my $transcript_id (keys %$transcripts_href) {
159: if (scalar (keys %$cds_coords_href) == 1) {
167: foreach my $exon_end5 (keys %$exon_coords_href) {
Since Perl 5.18 each process gets its own random hash order (perlsec, "Algorithmic Complexity Attacks"), so an unsorted loop gives a new order in each run.
Setting PERL_HASH_SEED=0 before TransDecoder.LongOrfs and TransDecoder.Predict works around it for me. With it, two runs on an assembly with 131302 ORFs gave the same md5 for the .pep, .cds, .gff3 and .bed files, both for all ORFs and with --single_best_only.
One more thing I noticed while reading the code, though I haven't seen it happen: select_best_ORFs_per_transcript.pl ranks the ORFs of a transcript by homology count, then CDS score, then length (line 173). ORFs tied on all three keep the hash order, so I think --single_best_only could pick a different ORF in each run when there's a full tie.
Sorting the gene IDs at line 140 would make the output repeatable without the seed.
Thanks
Activity
brianjohnhaas commentedon Oct 20, 2026