[maker-devel] Maker actions when using importied rm_gff file

Devon O'Rourke devon.orourke at gmail.com
Mon Mar 9 07:24:11 MDT 2020


Hi Carson,

I recently completed one round of Maker annotation successfully thanks to
your expert advise on resetting MPI parameters. Because earlier tests
(prior to this successful run) indicated that other dependency programs
might *also* be contributing to failed Maker jobs, this first successful
run consisted entirely of GFF data as input for the est, altest, and
protein evidence, as well as using a custom rm_gff file for complex repeats
(I was following the strategy posted in an earlier thread in this forum (
https://groups.google.com/forum/#!topic/maker-devel/patU-l_TQUM).

The good news is that using GFF files only will get the job to finish, the
bad news is that if I try to input the original fasta files instead of the
resulting GFF's for the evidence data, Maker gets *close* but fails to
finish the job at the stage where (I think) the per-scaffold chunks of
"evidence_*.gff", "scaffold*.*.pred.raw.section", and
"scaffold*.*.final.section" is collapsed into a set of "scaffold*.gff",
"scaffold*.maker.transcripts.fasta" and "scaffold*.maker.proteins.fasta"
files. The behavior is not entirely consistent across all scaffolds: most
scaffolds in fact produce finished files (the "scaffold*.gff",
"transcripts.fasta", etc.), however the majority of the failed scaffolds
are the longest ones (though at least a handful of longer scaffolds *do
finish*!).

The initial error in the run.log.child.* files in these failed scaffolds
aren't always the same. Here's a few:

```
DIED    RANK    4:6:0:4
DIED    RANK    5:6:0:4
DIED    RANK    6:6:0:53
```

The second error is always:
```
DIED    COUNT   1
```

You can view the .log file here: https://osf.io/4wn6h/download. I've
attached the .opts file to this message.

Maybe again there is something about our MPI parameters that are not
optimized for these jobs. I could certainly re-run the same data through a
machine without MPI at this point because all the jobs are basically
completed (no more blasting or repeat masking is needed). Thus I think the
question is - should I just restart the run without MPI and see if it
finishes? Or perhaps, there are alternative Maker scripts to try testing
directly (even on a single scaffold subdirectory) to see if these instances
where Maker doesn't quite finish *would* finish otherwise?

Thank you once more for your help with troubleshooting,
Devon

-- 
Devon O'Rourke
Postdoctoral researcher, Northern Arizona University
Lab of Jeffrey T. Foster - https://fozlab.weebly.com/
twitter: @thesciencedork
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20200309/d506783c/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: makerRun2_opts.ctl
Type: application/octet-stream
Size: 3855 bytes
Desc: not available
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20200309/d506783c/attachment-0003.obj>


More information about the maker-devel mailing list