[maker-devel] maker dying on a contig

Carson Holt carsonhh at gmail.com
Fri Aug 31 17:00:27 MDT 2012 

Your welcome.  I also submitted a bug report to RepeatMasker.  They said the
issue will go away with the next release since simple repeat detection is
going to be handled by TRF rather than rmblast.

Thanks,
Carson


On 8/31/12 6:48 PM, "Jeremy Semeiks" <jeremy.semeiks at utsw.edu> wrote:

> Carson, maker completed on the scaffold without error when I used your
> patch. Thanks!
> 
> - J
> 
> On Fri, Aug 31, 2012 at 3:47 PM, Carson Holt <carsonhh at gmail.com> wrote:
>> 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
>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>>

More information about the maker-devel mailing list