[maker-devel] maker dying on a contig

Fri Aug 31 14:47:33 MDT 2012

Looks like there is a slight format variation in one line of the
RepeatMasker outputs.  Not sure what could have caused it -->
249   30.8  1.9  0.9  scaffold_10105  22320 22372 (34998) + (TCCA)n
Simple_repeat          0    109    (0)

The position/compliment information in columns 12-14 give a start position
of 0 for part of the alignment.  A 0 is invalid because repeat masker
doesn't use 0 based coordinates.  This causes a bug downstream when MAKER
asks for the starting position of the alignment in another part of the
code.

This may be a RepeatMasker or rmblast bug.  When I replace rmblast with
wu-blast and then reconfigure RepeatMasker I get this line -->
249   30.8  1.9  0.9  scaffold_10105  22320 22372 (34998) + (TCCA)n
Simple_repeat          1    109    (0)

Notice the 0 becomes a 1 and all logic is restored to the world.

>From my end the fix is simple.  If I see a 0 when reading RepeatMaskers
output, then I just turn it into a 1.
I've attached a file that you should use to replace the
./maker/lib/Widget/RepeatMasker.pm file.  It will fix the failure issue.
I'll also make a note to the RepeatMasker developers.

Thanks,
Carson

On 12-08-25 12:21 PM, "Jeremy Semeiks" <jeremy.semeiks at utsw.edu> wrote:

>Attached.
>
>Thanks,
>J
>
>On Fri, Aug 24, 2012 at 5:23 PM, Carson Holt <carsonhh at gmail.com> wrote:
>> Could you send me the entire directory for just the failed contig?
>>
>> Thanks,
>> Carson
>>
>>
>> On 12-08-24 5:09 PM, "Jeremy Semeiks" <jeremy.semeiks at utsw.edu> wrote:
>>
>>>After doing this, I still get the same errors as I attached before.
>>>There was also nothing in the log supporting that maker tried this
>>>more than once. (Initially, I had tries=2, but I changed it to
>>>tries=10 for this run. I'm guessing that's what you mean by "retry
>>>count".) It also doesn't matter if I keep the same old contig
>>>directory and master log before rerunning, or if I delete them both.
>>>
>>>FWIW, maker's own version of blast is 2.2.26+, which is the same as my
>>>native version.
>>>
>>>Thanks,
>>>Jeremy
>>>
>>>On Fri, Aug 24, 2012 at 2:17 PM, Carson Holt <carsonhh at gmail.com> wrote:
>>>> Let maker install it's own blast (a version I know should work).
>>>>
>>>> cd ./maker/src
>>>> ./Build blast
>>>>
>>>> Then to finish up your job (this command will just update executable
>>>> locations in the maker_exe.ctl file) -->
>>>> maker -EXE
>>>>
>>>> Then run maker again with a higher retry count.  Let me know if the
>>>>contig
>>>> still fails.
>>>>
>>>> Thanks,
>>>> Carson
>>>>
>>>>
>>>>
>>>>
>>>> On 12-08-24 3:13 PM, "Jeremy Semeiks" <jeremy.semeiks at utsw.edu> wrote:
>>>>
>>>>>Carson,
>>>>>
>>>>>$ blastx -version
>>>>>blastx: 2.2.26+
>>>>>Package: blast 2.2.26, build Feb 22 2012 16:04:28
>>>>>
>>>>>- J
>>>>>
>>>>>On Fri, Aug 24, 2012 at 7:24 AM, Carson Holt <carsonhh at gmail.com>
>>>>>wrote:
>>>>>> Could you send the blast version informations for reference
>>>>>>purposes?
>>>>>>I
>>>>>> can see this being caused by BLAST.
>>>>>>
>>>>>> Thanks,
>>>>>> Carson
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 12-08-24 3:44 AM, "Michael Thon" <mike.thon at gmail.com> wrote:
>>>>>>
>>>>>>>I'm not sure if this is relevant to your problem but I had problems
>>>>>>>with
>>>>>>>maker failing on some contigs but not others.  I reinstalled maker
>>>>>>>and
>>>>>>>used the Build script to have it install all of its own
>>>>>>>dependencies.
>>>>>>>Now maker is running fine, although the culprit seems to have been
>>>>>>>the
>>>>>>>blast version I was using before.
>>>>>>>
>>>>>>>
>>>>>>>On Aug 21, 2012, at 6:26 PM, Jeremy Semeiks
>>>>>>><jeremy.semeiks at utsw.edu>
>>>>>>>wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I'm trying to annotate a mammalian genome with maker-2.26-beta. I
>>>>>>>>have
>>>>>>>> ~36,000 contigs, and per the master log maker FINISHED all of them
>>>>>>>> except one (scaffold_10105, ~60 kbp, not obviously weird) on the
>>>>>>>>first
>>>>>>>> run. It didn't report ERROR for that contig in the master log, but
>>>>>>>>it
>>>>>>>> did output two DIED lines in the contig's run.log and then just
>>>>>>>>hung
>>>>>>>> for a week until I killed it.
>>>>>>>>
>>>>>>>> I reran maker on just that contig by deleting the START line from
>>>>>>>>the
>>>>>>>> master log. maker again died on that contig.
>>>>>>>>
>>>>>>>> I attach the relevant part of the stderr stream; the rest was just
>>>>>>>> "--Next Contig--"-type lines. Any ideas?
>>>>>>>>
>>>>>>>> A related question. Is deleting lines in the master log, as I did
>>>>>>>> here, the best way to get maker to rerun on just a few contigs? I
>>>>>>>> often find myself needing to do this, sometimes because of ERROR
>>>>>>>>lines
>>>>>>>> or other assumed quirks in maker and sometimes just because I
>>>>>>>>needed
>>>>>>>> to pause a big run for a while. One disadvantage is that when I
>>>>>>>> restart, maker needs to manually scan over many completed contigs,
>>>>>>>> which takes a while.
>>>>>>>>
>>>>>>>> (I'd think the best solution would be for maker to automatically
>>>>>>>> recognize whether it's really currently running on contigs marked
>>>>>>>> STARTED but not FINISHED. It doesn't seem to do this now, but I
>>>>>>>> realize that might be hard to implement.)
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Jeremy
>>>>>>>> Grad student, Grishin lab
>>>>>>>> UT Southwestern, Dallas TX
>>>>>>>> 510.384.8959
>>>>>>>> <maker.stderr>_______________________________________________
>>>>>>>> maker-devel mailing list
>>>>>>>> maker-devel at box290.bluehost.com
>>>>>>>>
>>>>>>>>http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab
>>>>>>>>.o
>>>>>>>>rg
>>>>>>>
>>>>>>>
>>>>>>>_______________________________________________
>>>>>>>maker-devel mailing list
>>>>>>>maker-devel at box290.bluehost.com
>>>>>>>http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.
>>>>>>>or
>>>>>>>g
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: RepeatMasker.pm
Type: text/x-perl-script
Size: 9226 bytes
Desc: not available
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20120831/c248081c/attachment-0003.bin>