From carsonhh at gmail.com  Sun Nov  3 21:16:03 2013
From: carsonhh at gmail.com (Carson Holt)
Date: Sun, 3 Nov 2013 20:16:03 -0700
Subject: [maker-devel] Serious Start Codon Problem
In-Reply-To: <CE8EE16A.212BC%graham.etherington@sainsbury-laboratory.ac.uk>
References: <CE7FA55D.10C4B%carsonhh@gmail.com>
	<CE8EE16A.212BC%graham.etherington@sainsbury-laboratory.ac.uk>
Message-ID: <CA+sW3ERmNDH2kO6616yLGZS3iJ2Z0XEUu_qL++iHN8HVo3_reA@mail.gmail.com>

2.30 beta is now available for use.  Sorry about the delay, between moving
and getting seriously ill for several days, I sort of dropped off the grid
for 2 weeks.  Give this version a try.

Thanks,
Carson




On Thu, Oct 24, 2013 at 7:42 AM, graham etherington (TSL) <
graham.etherington at sainsbury-laboratory.ac.uk> wrote:

> Hi,
> I notice that the latest version of Maker available from
> http://www.yandell-lab.org/software/maker.html is still v2.29b (4 Oct
> 2013). As we're also having the start codon problem we'd like to get hold
> of v2.30. Do you know when this will be released?
> Many thanks,
> Graham
>
>
> Dr. Graham Etherington
> Bioinformatics Support Officer,
> The Sainsbury Laboratory,
> Norwich Research Park,
> Norwich NR4 7UH.
> UK
> Tel: +44 (0)1603 450601
>
>
>
>
>
> On 13/10/2013 06:26, "Carson Holt" <carsonhh at gmail.com> wrote:
>
> >Before Wednesday, because after that I'm on a 6 day road trip, so I have
> >to have it wrapped up before I leave.
> >
> >--Carson
> >
> >
> >
> >
> >On 10/12/13 12:16 PM, "Felix Bemm" <felix.bemm at uni-wuerzburg.de> wrote:
> >
> >>Thx Carson! Do you now when 2.30 will be available? Bests
> >>
> >>On 12.10.2013 17:48, Carson Holt wrote:
> >>> This issue just came up this week on another e-mail as well.
> >>>
> >>> One way to fix it, is to edit the Bio::Tools::CodonTable module from
> >>> BioPerl (use maker --debug to have maker print out the locations of all
> >>> modules it uses).  Such a hack should only be done as a temporary work
> >>> around.
> >>>
> >>> You change line 256 from -->
> >>> ---M---------------M---------------M----------------------------
> >>>
> >>> To-->
> >>> -----------------------------------M----------------------------
> >>>
> >>>
> >>> Maker uses the BioPerl is_start_codon function to determine if the
> >>>codon
> >>> used in a result it receives is acceptable or if it should look
> >>>upstream
> >>> or downstream for a different one. Apparently there are actually 3
> >>> acceptable start codons in the standard codon table (2 rare ones and
> >>>one
> >>> common), so making the edit removes the two rare ones from the list.
> >>>
> >>> I'm also preparing a 2.30 release that exports a "strict" codon table
> >>>to
> >>> the BioPerl module, that will be used by default and should fix the
> >>>issue.
> >>>
> >>> Thanks,
> >>> Carson
> >>>
> >>>
> >>>
> >>> On 10/12/13 11:06 AM, "Felix Bemm" <felix.bemm at uni-wuerzburg.de>
> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> I have a serious problems with maker annotations especially the start
> >>>> codon placement. It started happening with maker version 2.27! About
> >>>>1/3
> >>>> of my genes are missing a proper start codon. When reviewing the GFF
> >>>> files gene predictors and est evidence standalone would predict the
> >>>> right gene structure including the start codon. I was thinking that
> >>>>this
> >>>> problem was somehow linked to my gene models but looking at their
> >>>> standalone prediction I discarded that theory. Just some stats about
> >>>> proteins with proper start codon (first column) and missing start
> >>>>codon
> >>>> (second column).
> >>>>
> >>>> Maker              9268    4215
> >>>> SNAP               16577   896
> >>>> Genemark   18764   290
> >>>>
> >>>> Numbers look the same when Augustus is used (currently retraining).
> >>>> Manually using EST's in Apollo often fixes the problems but I don't
> >>>>want
> >>>> to check > 4000 genes for this.
> >>>>
> >>>> Do you have any idea what could cause such a problem? If you need some
> >>>> example gff files I can send you.
> >>>>
> >>>> Best regards
> >>>> Felix
> >>>>
> >>>> --
> >>>> Felix Bemm
> >>>> Department of Bioinformatics
> >>>> University of W?rzburg, Germany
> >>>> Tel: +49 931 - 31 83696
> >>>> Fax: +49 931 - 31 84552
> >>>> felix.bemm at uni-wuerzburg.de
> >>>>
> >>>> _______________________________________________
> >>>> maker-devel mailing list
> >>>> maker-devel at box290.bluehost.com
> >>>>
> >>>>
> http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
> >>
> >>--
> >>Felix Bemm
> >>Department of Bioinformatics
> >>University of W?rzburg, Germany
> >>Tel: +49 931 - 31 83696
> >>Fax: +49 931 - 31 84552
> >>felix.bemm at uni-wuerzburg.de
> >
> >
> >
> >_______________________________________________
> >maker-devel mailing list
> >maker-devel at box290.bluehost.com
> >http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://box290.bluehost.com/pipermail/maker-devel_yandell-lab.org/attachments/20131103/136b60b8/attachment.html>

From jfierst at uoregon.edu  Mon Nov  4 10:50:36 2013
From: jfierst at uoregon.edu (Janna Fierst)
Date: Mon, 4 Nov 2013 08:50:36 -0800
Subject: [maker-devel] Serious Start Codon Problem
In-Reply-To: <CA+sW3ERmNDH2kO6616yLGZS3iJ2Z0XEUu_qL++iHN8HVo3_reA@mail.gmail.com>
References: <CE7FA55D.10C4B%carsonhh@gmail.com>
	<CE8EE16A.212BC%graham.etherington@sainsbury-laboratory.ac.uk>
	<CA+sW3ERmNDH2kO6616yLGZS3iJ2Z0XEUu_qL++iHN8HVo3_reA@mail.gmail.com>
Message-ID: <CAGoyurYpCrzcpZeTpYhaQZqZr5a8ZNwBs5UZ88+CPez1nhTA6w@mail.gmail.com>

Hi,

I can't get my message to post to the list but I had a problem with
2.29-beta in parallel - it seemed to restart the same scaffolds over and
over instead of moving on to a new set. I was running the same as the 2.28
version, is it something with our mpi system here at UO? Thanks -Janna
Fierst


On Sun, Nov 3, 2013 at 7:16 PM, Carson Holt <carsonhh at gmail.com> wrote:

> 2.30 beta is now available for use.  Sorry about the delay, between moving
> and getting seriously ill for several days, I sort of dropped off the grid
> for 2 weeks.  Give this version a try.
>
> Thanks,
> Carson
>
>
>
>
> On Thu, Oct 24, 2013 at 7:42 AM, graham etherington (TSL) <
> graham.etherington at sainsbury-laboratory.ac.uk> wrote:
>
>> Hi,
>> I notice that the latest version of Maker available from
>> http://www.yandell-lab.org/software/maker.html is still v2.29b (4 Oct
>> 2013). As we're also having the start codon problem we'd like to get hold
>> of v2.30. Do you know when this will be released?
>> Many thanks,
>> Graham
>>
>>
>> Dr. Graham Etherington
>> Bioinformatics Support Officer,
>> The Sainsbury Laboratory,
>> Norwich Research Park,
>> Norwich NR4 7UH.
>> UK
>> Tel: +44 (0)1603 450601
>>
>>
>>
>>
>>
>> On 13/10/2013 06:26, "Carson Holt" <carsonhh at gmail.com> wrote:
>>
>> >Before Wednesday, because after that I'm on a 6 day road trip, so I have
>> >to have it wrapped up before I leave.
>> >
>> >--Carson
>> >
>> >
>> >
>> >
>> >On 10/12/13 12:16 PM, "Felix Bemm" <felix.bemm at uni-wuerzburg.de> wrote:
>> >
>> >>Thx Carson! Do you now when 2.30 will be available? Bests
>> >>
>> >>On 12.10.2013 17:48, Carson Holt wrote:
>> >>> This issue just came up this week on another e-mail as well.
>> >>>
>> >>> One way to fix it, is to edit the Bio::Tools::CodonTable module from
>> >>> BioPerl (use maker --debug to have maker print out the locations of
>> all
>> >>> modules it uses).  Such a hack should only be done as a temporary work
>> >>> around.
>> >>>
>> >>> You change line 256 from -->
>> >>> ---M---------------M---------------M----------------------------
>> >>>
>> >>> To-->
>> >>> -----------------------------------M----------------------------
>> >>>
>> >>>
>> >>> Maker uses the BioPerl is_start_codon function to determine if the
>> >>>codon
>> >>> used in a result it receives is acceptable or if it should look
>> >>>upstream
>> >>> or downstream for a different one. Apparently there are actually 3
>> >>> acceptable start codons in the standard codon table (2 rare ones and
>> >>>one
>> >>> common), so making the edit removes the two rare ones from the list.
>> >>>
>> >>> I'm also preparing a 2.30 release that exports a "strict" codon table
>> >>>to
>> >>> the BioPerl module, that will be used by default and should fix the
>> >>>issue.
>> >>>
>> >>> Thanks,
>> >>> Carson
>> >>>
>> >>>
>> >>>
>> >>> On 10/12/13 11:06 AM, "Felix Bemm" <felix.bemm at uni-wuerzburg.de>
>> wrote:
>> >>>
>> >>>> Hi,
>> >>>>
>> >>>> I have a serious problems with maker annotations especially the start
>> >>>> codon placement. It started happening with maker version 2.27! About
>> >>>>1/3
>> >>>> of my genes are missing a proper start codon. When reviewing the GFF
>> >>>> files gene predictors and est evidence standalone would predict the
>> >>>> right gene structure including the start codon. I was thinking that
>> >>>>this
>> >>>> problem was somehow linked to my gene models but looking at their
>> >>>> standalone prediction I discarded that theory. Just some stats about
>> >>>> proteins with proper start codon (first column) and missing start
>> >>>>codon
>> >>>> (second column).
>> >>>>
>> >>>> Maker              9268    4215
>> >>>> SNAP               16577   896
>> >>>> Genemark   18764   290
>> >>>>
>> >>>> Numbers look the same when Augustus is used (currently retraining).
>> >>>> Manually using EST's in Apollo often fixes the problems but I don't
>> >>>>want
>> >>>> to check > 4000 genes for this.
>> >>>>
>> >>>> Do you have any idea what could cause such a problem? If you need
>> some
>> >>>> example gff files I can send you.
>> >>>>
>> >>>> Best regards
>> >>>> Felix
>> >>>>
>> >>>> --
>> >>>> Felix Bemm
>> >>>> Department of Bioinformatics
>> >>>> University of W?rzburg, Germany
>> >>>> Tel: +49 931 - 31 83696
>> >>>> Fax: +49 931 - 31 84552
>> >>>> felix.bemm at uni-wuerzburg.de
>> >>>>
>> >>>> _______________________________________________
>> >>>> maker-devel mailing list
>> >>>> maker-devel at box290.bluehost.com
>> >>>>
>> >>>>
>> http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>> >>
>> >>--
>> >>Felix Bemm
>> >>Department of Bioinformatics
>> >>University of W?rzburg, Germany
>> >>Tel: +49 931 - 31 83696
>> >>Fax: +49 931 - 31 84552
>> >>felix.bemm at uni-wuerzburg.de
>> >
>> >
>> >
>> >_______________________________________________
>> >maker-devel mailing list
>> >maker-devel at box290.bluehost.com
>> >http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>>
>>
>
> _______________________________________________
> maker-devel mailing list
> maker-devel at box290.bluehost.com
> http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://box290.bluehost.com/pipermail/maker-devel_yandell-lab.org/attachments/20131104/415de8e4/attachment.html>

From marc.hoeppner at imbim.uu.se  Tue Nov  5 02:55:31 2013
From: marc.hoeppner at imbim.uu.se (Marc P. Hoeppner)
Date: Tue, 05 Nov 2013 09:55:31 +0100
Subject: [maker-devel] Maker and external ab-inito predictions
Message-ID: <5278B283.3000601@imbim.uu.se>

Hi,

this is possibly a trivial question, but I am realizing that Maker does 
not seem to process augustus files I have produced externally (augustus 
2.7); at least they don't seem to make it into the final annotation file.

My question(s) therefore:

1) What exact GFF features does maker expect for a 'pred_gff' file? 
Would it happily accept an augustus gff, or would I need to modify the 
native augustus features somehow? (Trying to find out whether this is a 
Maker issue or some other problem)

2) Is there a way to feed hint files to Maker to use with augustus? 
Couldn't find anything about that specifically anyway.

Regards,

Marc

-- 
-----------
Marc P. Hoeppner, PhD
Researcher
Department of Medical Biochemistry and Microbiology
Uppsala University, Sweden
marc.hoepner at imbim.uu.se




From smg283 at gmail.com  Tue Nov  5 18:53:55 2013
From: smg283 at gmail.com (Scott Geib)
Date: Tue, 5 Nov 2013 14:53:55 -1000
Subject: [maker-devel] running maker on tacc stampede
Message-ID: <CAH221buRe6jsRyeVnkup3bhf3fbHJp+hW+TEgOpzTmbmZ8TOBA@mail.gmail.com>

Hi,
I was looking for help running maker on stampede at tacc.  Have run in the
past on lonestar with no issues, but am getting some errors on stampede
(have never run before on stampede.  I also tried downloading the same
maker version on lonestar and running the same test data and had no issues.
 In both cases, used TACC module command to load more current perl into my
environment before installing maker.  On lonestar, SGE is used so
submission script slightly different in syntax, but ran with same
parameters. I know repbase isn't installed, but I just wanted to get
software working
Thanks Scott


Using this SLURM script with the current maker beta release (30),
submitting with sbatch on dpp test data in a copy of maker data directory:

#!/bin/bash
#SBATCH -J testmaker
#SBATCH -o testmaker.o%J
#SBATCH -e testmaker.e%J
##SBATCH -N 2
#SBATCH -n 32
#SBATCH -p development
#SBATCH -t 2:00:00
#SBATCH --mail-user=XXXXXX
#SBATCH --mail-type=all

ibrun ../maker/bin/maker -base test


This results in the following errors in testmaker.ejobid:

STATUS: Parsing control files...
WARNING: RepBase is not installed for RepeatMasker. This limits
RepeatMasker's functionality and makes the model_org option in the
control files virtually meaningless. MAKER will now reconfigure
for simple repeat masking only.
STATUS: Processing and indexing input FASTA files...
[c559-001.stampede.tacc.utexas.edu:mpi_rank_2][error_sighandler] Caught
error: Segmentation fault (signal 11)
[c559-001.stampede.tacc.utexas.edu:mpispawn_0][child_handler] MPI process
(rank: 2, pid: 35423) terminated with signal 11 -> abort job
SIGINT received
SIGINT received
SIGINT received
SIGINT received
SIGINT received
SIGINT received
SIGINT received
SIGINT received
SIGINT received
SIGINT received
SIGINT received
[c559-001.stampede.tacc.utexas.edu:mpi_rank_1][error_sighandler] Caught
error: Segmentation fault (signal 11)
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
        eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
forks.pm line 609
        threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
line 586
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
        eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
forks.pm line 609
        threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
line 586
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
        eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
forks.pm line 609
        threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
line 586
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        eval {...} called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        Parallel::Application::MPI::__ANON__() called at
/work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
        Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x55efbc8)') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
        Parallel::Application::MPI::MPI_Recv('SCALAR(0x54f4908)', -2, 1111)
called at /work/02726/pbarc/maker/bin/maker line 530
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
        eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
forks.pm line 609
        threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
line 586
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
        eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
forks.pm line 609
        threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
line 586
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
        eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
forks.pm line 609
        threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
line 586
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
        eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
forks.pm line 609
        threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
line 586
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
        eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
forks.pm line 609
        threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
line 586
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
        eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
forks.pm line 609
        threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
line 586
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
        eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
forks.pm line 609
        threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
line 586

 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        eval {...} called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        Parallel::Application::MPI::__ANON__() called at
/work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
        Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x36ffd10)') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
        Parallel::Application::MPI::MPI_Recv('SCALAR(0x3606080)', 0, 4444)
called at /work/02726/pbarc/maker/bin/maker line 578
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        eval {...} called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        Parallel::Application::MPI::__ANON__() called at
/work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
        Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x4d77a00)') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
        Parallel::Application::MPI::MPI_Recv('SCALAR(0x4c7f080)', 0, 4444)
called at /work/02726/pbarc/maker/bin/maker line 578
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        eval {...} called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        Parallel::Application::MPI::__ANON__() called at
/work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
        Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x418ece0)') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
        Parallel::Application::MPI::MPI_Recv('SCALAR(0x4095080)', 0, 4444)
called at /work/02726/pbarc/maker/bin/maker line 578
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        eval {...} called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        Parallel::Application::MPI::__ANON__() called at
/work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
        Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x3c05a00)') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
        Parallel::Application::MPI::MPI_Recv('SCALAR(0x3b0d080)', 0, 4444)
called at /work/02726/pbarc/maker/bin/maker line 578
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        eval {...} called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        Parallel::Application::MPI::__ANON__() called at
/work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
        Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x3b50a00)') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
        Parallel::Application::MPI::MPI_Recv('SCALAR(0x3a58080)', 0, 4444)
called at /work/02726/pbarc/maker/bin/maker line 578
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        eval {...} called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        Parallel::Application::MPI::__ANON__() called at
/work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
        Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x55cecf0)') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
        Parallel::Application::MPI::MPI_Recv('SCALAR(0x54d5080)', 0, 4444)
called at /work/02726/pbarc/maker/bin/maker line 578
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        eval {...} called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        Parallel::Application::MPI::__ANON__() called at
/work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
        Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x4a7ccf0)') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
        Parallel::Application::MPI::MPI_Recv('SCALAR(0x4983080)', 0, 4444)
called at /work/02726/pbarc/maker/bin/maker line 578
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        eval {...} called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        Parallel::Application::MPI::__ANON__() called at
/work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
        Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x53f1a00)') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
        Parallel::Application::MPI::MPI_Recv('SCALAR(0x52f9080)', 0, 4444)
called at /work/02726/pbarc/maker/bin/maker line 578
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        eval {...} called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        Parallel::Application::MPI::__ANON__() called at
/work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
        Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x367da00)') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
        Parallel::Application::MPI::MPI_Recv('SCALAR(0x3585080)', 0, 4444)
called at /work/02726/pbarc/maker/bin/maker line 578
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 23, pid: 10976) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 20, pid: 10973) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 17, pid: 10970) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 18, pid: 10971) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 19, pid: 10972) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 16, pid: 10969) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 21, pid: 10974) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 22, pid: 10975) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 24, pid: 10977) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 25, pid: 10978) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 26, pid: 10979) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 27, pid: 10980) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 28, pid: 10981) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 29, pid: 10982) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 30, pid: 10983) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 31, pid: 10984) exited with status 2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://box290.bluehost.com/pipermail/maker-devel_yandell-lab.org/attachments/20131105/561e5847/attachment.html>

From carsonhh at gmail.com  Wed Nov  6 01:40:30 2013
From: carsonhh at gmail.com (Carson Holt)
Date: Wed, 6 Nov 2013 00:40:30 -0700
Subject: [maker-devel] Maker and external ab-inito predictions
In-Reply-To: <5278B283.3000601@imbim.uu.se>
References: <5278B283.3000601@imbim.uu.se>
Message-ID: <CA+sW3ETtKzitZurwUdLHbMauBwNYp49HOqhK6iY-AY=Oggwgbg@mail.gmail.com>

1) MAKER prefers match/match_part but should be able to handle any two
level feature or even gene/mRNA/exon/CDS features.  Make sure it's infact
GFF3 and not GTF or GFF2.

2) MAKER builds it's own hints based on the evidence alignments it finds,
providing user generated hint files is not supported.  If you already have
those, you can just run augustus directly, since one of the the main
benefit of MAKER is that it finds the hints for you and you would no longer
need that.

Perhaps you can give more details on what exactly you are trying to do, and
we could help you configure MAKER.

Thanks,
Carson



On Tue, Nov 5, 2013 at 1:55 AM, Marc P. Hoeppner
<marc.hoeppner at imbim.uu.se>wrote:

> Hi,
>
> this is possibly a trivial question, but I am realizing that Maker does
> not seem to process augustus files I have produced externally (augustus
> 2.7); at least they don't seem to make it into the final annotation file.
>
> My question(s) therefore:
>
> 1) What exact GFF features does maker expect for a 'pred_gff' file? Would
> it happily accept an augustus gff, or would I need to modify the native
> augustus features somehow? (Trying to find out whether this is a Maker
> issue or some other problem)
>
> 2) Is there a way to feed hint files to Maker to use with augustus?
> Couldn't find anything about that specifically anyway.
>
> Regards,
>
> Marc
>
> --
> -----------
> Marc P. Hoeppner, PhD
> Researcher
> Department of Medical Biochemistry and Microbiology
> Uppsala University, Sweden
> marc.hoepner at imbim.uu.se
>
>
> _______________________________________________
> maker-devel mailing list
> maker-devel at box290.bluehost.com
> http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://box290.bluehost.com/pipermail/maker-devel_yandell-lab.org/attachments/20131106/779c0953/attachment.html>

From marc.hoeppner at imbim.uu.se  Wed Nov  6 01:45:09 2013
From: marc.hoeppner at imbim.uu.se (Marc P. Hoeppner)
Date: Wed, 06 Nov 2013 08:45:09 +0100
Subject: [maker-devel] Maker and external ab-inito predictions
In-Reply-To: <CA+sW3ETtKzitZurwUdLHbMauBwNYp49HOqhK6iY-AY=Oggwgbg@mail.gmail.com>
References: <5278B283.3000601@imbim.uu.se>
	<CA+sW3ETtKzitZurwUdLHbMauBwNYp49HOqhK6iY-AY=Oggwgbg@mail.gmail.com>
Message-ID: <5279F385.5030005@imbim.uu.se>

Hi Carson,

thanks for the clarification. I saw in the code that the Augustus Widget 
uses hints, but wasn't sure if and how those were generated. If they are 
derived from the evidence alignments, prefect. That's all I needed 
anyway. As for the passing of an external phred_gff, I guess the native 
Augustus GFF output is a little wonky - I'll try to convert it to 
match/match_parts to see if that helps (but with Maker computing it's 
own hints, I don't actually have to...).

Anyway, thanks again!

/Marc
> 1) MAKER prefers match/match_part but should be able to handle any two 
> level feature or even gene/mRNA/exon/CDS features.  Make sure it's 
> infact GFF3 and not GTF or GFF2.
>
> 2) MAKER builds it's own hints based on the evidence alignments it 
> finds, providing user generated hint files is not supported.  If you 
> already have those, you can just run augustus directly, since one of 
> the the main benefit of MAKER is that it finds the hints for you and 
> you would no longer need that.
>
> Perhaps you can give more details on what exactly you are trying to 
> do, and we could help you configure MAKER.
>
> Thanks,
> Carson
>
>
>
> On Tue, Nov 5, 2013 at 1:55 AM, Marc P. Hoeppner 
> <marc.hoeppner at imbim.uu.se <mailto:marc.hoeppner at imbim.uu.se>> wrote:
>
>     Hi,
>
>     this is possibly a trivial question, but I am realizing that Maker
>     does not seem to process augustus files I have produced externally
>     (augustus 2.7); at least they don't seem to make it into the final
>     annotation file.
>
>     My question(s) therefore:
>
>     1) What exact GFF features does maker expect for a 'pred_gff'
>     file? Would it happily accept an augustus gff, or would I need to
>     modify the native augustus features somehow? (Trying to find out
>     whether this is a Maker issue or some other problem)
>
>     2) Is there a way to feed hint files to Maker to use with
>     augustus? Couldn't find anything about that specifically anyway.
>
>     Regards,
>
>     Marc
>
>     -- 
>     -----------
>     Marc P. Hoeppner, PhD
>     Researcher
>     Department of Medical Biochemistry and Microbiology
>     Uppsala University, Sweden
>     marc.hoepner at imbim.uu.se <mailto:marc.hoepner at imbim.uu.se>
>
>
>     _______________________________________________
>     maker-devel mailing list
>     maker-devel at box290.bluehost.com
>     <mailto:maker-devel at box290.bluehost.com>
>     http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>
>


-- 
-----------
Marc P. Hoeppner, PhD
Researcher
Department of Medical Biochemistry and Microbiology
Uppsala University, Sweden
marc.hoepner at imbim.uu.se

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://box290.bluehost.com/pipermail/maker-devel_yandell-lab.org/attachments/20131106/7de0b86d/attachment.html>

From carsonhh at gmail.com  Wed Nov  6 01:53:14 2013
From: carsonhh at gmail.com (Carson Holt)
Date: Wed, 6 Nov 2013 00:53:14 -0700
Subject: [maker-devel] running maker on tacc stampede
In-Reply-To: <CAH221buRe6jsRyeVnkup3bhf3fbHJp+hW+TEgOpzTmbmZ8TOBA@mail.gmail.com>
References: <CAH221buRe6jsRyeVnkup3bhf3fbHJp+hW+TEgOpzTmbmZ8TOBA@mail.gmail.com>
Message-ID: <CA+sW3ETCGE64JDvGc6v3JyOgmV5D1=P96NGTmqmi1k3nm8Uu0A@mail.gmail.com>

We're also seeing core dumps on Lonestar using the same version of MAKER
already installed when we do a "fresh install".  We're not sure why,
because everything should be the same.  Maybe something about what we are
seeing is also related to the issue you are experiencing and maybe not.
 Let me try and figure out what is happening on Lonestar and I'll send you
my install procedure, and maybe that will fix the stampede issue as well.

Thanks,
Carson



On Tue, Nov 5, 2013 at 5:53 PM, Scott Geib <smg283 at gmail.com> wrote:

> Hi,
> I was looking for help running maker on stampede at tacc.  Have run in the
> past on lonestar with no issues, but am getting some errors on stampede
> (have never run before on stampede.  I also tried downloading the same
> maker version on lonestar and running the same test data and had no issues.
>  In both cases, used TACC module command to load more current perl into my
> environment before installing maker.  On lonestar, SGE is used so
> submission script slightly different in syntax, but ran with same
> parameters. I know repbase isn't installed, but I just wanted to get
> software working
> Thanks Scott
>
>
> Using this SLURM script with the current maker beta release (30),
> submitting with sbatch on dpp test data in a copy of maker data directory:
>
> #!/bin/bash
> #SBATCH -J testmaker
> #SBATCH -o testmaker.o%J
> #SBATCH -e testmaker.e%J
> ##SBATCH -N 2
> #SBATCH -n 32
> #SBATCH -p development
> #SBATCH -t 2:00:00
> #SBATCH --mail-user=XXXXXX
> #SBATCH --mail-type=all
>
> ibrun ../maker/bin/maker -base test
>
>
> This results in the following errors in testmaker.ejobid:
>
> STATUS: Parsing control files...
> WARNING: RepBase is not installed for RepeatMasker. This limits
> RepeatMasker's functionality and makes the model_org option in the
> control files virtually meaningless. MAKER will now reconfigure
> for simple repeat masking only.
> STATUS: Processing and indexing input FASTA files...
> [c559-001.stampede.tacc.utexas.edu:mpi_rank_2][error_sighandler] Caught
> error: Segmentation fault (signal 11)
> [c559-001.stampede.tacc.utexas.edu:mpispawn_0][child_handler] MPI process
> (rank: 2, pid: 35423) terminated with signal 11 -> abort job
> SIGINT received
> SIGINT received
> SIGINT received
> SIGINT received
> SIGINT received
> SIGINT received
> SIGINT received
> SIGINT received
> SIGINT received
> SIGINT received
> SIGINT received
> [c559-001.stampede.tacc.utexas.edu:mpi_rank_1][error_sighandler] Caught
> error: Segmentation fault (signal 11)
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
>         eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
> forks.pm line 609
>         threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
> line 586
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
>         eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
> forks.pm line 609
>         threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
> line 586
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
>         eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
> forks.pm line 609
>         threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
> line 586
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         eval {...} called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         Parallel::Application::MPI::__ANON__() called at
> /work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
>         Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x55efbc8)') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
>         Parallel::Application::MPI::MPI_Recv('SCALAR(0x54f4908)', -2,
> 1111) called at /work/02726/pbarc/maker/bin/maker line 530
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
>         eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
> forks.pm line 609
>         threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
> line 586
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
>         eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
> forks.pm line 609
>         threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
> line 586
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
>         eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
> forks.pm line 609
>         threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
> line 586
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
>         eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
> forks.pm line 609
>         threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
> line 586
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
>         eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
> forks.pm line 609
>         threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
> line 586
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
>         eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
> forks.pm line 609
>         threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
> line 586
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
>         eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
> forks.pm line 609
>         threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
> line 586
>
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         eval {...} called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         Parallel::Application::MPI::__ANON__() called at
> /work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
>         Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x36ffd10)') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
>         Parallel::Application::MPI::MPI_Recv('SCALAR(0x3606080)', 0, 4444)
> called at /work/02726/pbarc/maker/bin/maker line 578
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         eval {...} called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         Parallel::Application::MPI::__ANON__() called at
> /work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
>         Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x4d77a00)') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
>         Parallel::Application::MPI::MPI_Recv('SCALAR(0x4c7f080)', 0, 4444)
> called at /work/02726/pbarc/maker/bin/maker line 578
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         eval {...} called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         Parallel::Application::MPI::__ANON__() called at
> /work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
>         Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x418ece0)') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
>         Parallel::Application::MPI::MPI_Recv('SCALAR(0x4095080)', 0, 4444)
> called at /work/02726/pbarc/maker/bin/maker line 578
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         eval {...} called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         Parallel::Application::MPI::__ANON__() called at
> /work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
>         Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x3c05a00)') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
>         Parallel::Application::MPI::MPI_Recv('SCALAR(0x3b0d080)', 0, 4444)
> called at /work/02726/pbarc/maker/bin/maker line 578
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         eval {...} called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         Parallel::Application::MPI::__ANON__() called at
> /work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
>         Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x3b50a00)') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
>         Parallel::Application::MPI::MPI_Recv('SCALAR(0x3a58080)', 0, 4444)
> called at /work/02726/pbarc/maker/bin/maker line 578
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         eval {...} called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         Parallel::Application::MPI::__ANON__() called at
> /work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
>         Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x55cecf0)') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
>         Parallel::Application::MPI::MPI_Recv('SCALAR(0x54d5080)', 0, 4444)
> called at /work/02726/pbarc/maker/bin/maker line 578
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         eval {...} called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         Parallel::Application::MPI::__ANON__() called at
> /work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
>         Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x4a7ccf0)') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
>         Parallel::Application::MPI::MPI_Recv('SCALAR(0x4983080)', 0, 4444)
> called at /work/02726/pbarc/maker/bin/maker line 578
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         eval {...} called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         Parallel::Application::MPI::__ANON__() called at
> /work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
>         Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x53f1a00)') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
>         Parallel::Application::MPI::MPI_Recv('SCALAR(0x52f9080)', 0, 4444)
> called at /work/02726/pbarc/maker/bin/maker line 578
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         eval {...} called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         Parallel::Application::MPI::__ANON__() called at
> /work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
>         Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x367da00)') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
>         Parallel::Application::MPI::MPI_Recv('SCALAR(0x3585080)', 0, 4444)
> called at /work/02726/pbarc/maker/bin/maker line 578
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 23, pid: 10976) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 20, pid: 10973) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 17, pid: 10970) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 18, pid: 10971) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 19, pid: 10972) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 16, pid: 10969) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 21, pid: 10974) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 22, pid: 10975) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 24, pid: 10977) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 25, pid: 10978) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 26, pid: 10979) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 27, pid: 10980) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 28, pid: 10981) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 29, pid: 10982) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 30, pid: 10983) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 31, pid: 10984) exited with status 2
>
>
> _______________________________________________
> maker-devel mailing list
> maker-devel at box290.bluehost.com
> http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://box290.bluehost.com/pipermail/maker-devel_yandell-lab.org/attachments/20131106/ab209d29/attachment.html>

From xh33 at georgetown.edu  Tue Nov  5 12:04:18 2013
From: xh33 at georgetown.edu (Xin Huang)
Date: Tue, 5 Nov 2013 13:04:18 -0500
Subject: [maker-devel] Inquiry about using Exonerate through Maker
Message-ID: <CACvYrQEZR-35Crcmxbp-+CrG+QPs9dz3jkn3u9x++PU6BDF6tA@mail.gmail.com>

Hi,

I have a question regarding the use of Exonerate for cDNA alignment to
genomic scaffolds through Maker.

We first did a blastn search to find out which genomic scaffolds a cDNA
sequence aligns to. There are two scaffolds we figured that host the gene
of interest. So we picked these two scaffolds as the reference genome
sequence in the maker_opts.ctl file. I used the default settings in
maker_bopts.ctl. In the maker_exe.ctl file, the Ab-initio Gene Prediction
Algorithms section has only snap installed. In the maker_opts.ctl file, I
indicated the path to the EST sequence right after "est=" under EST
Evidence, skipped RepeatMasker (when included, only the repeat masking
information was shown in the GFF files) to only do the blast and exonerate,
set "est2genome=1" and left other options at default. In the directory
where we put the Maker output (the control files are all in this
directory), I ran the Maker pipeline using "<path_to_maker> maker_opts.ctl
maker_bopts.ctl maker_exe.ctl". It turned out that there is no alignment
information in the scaffold GFF3 file, just a plain figure indicating that
the scaffold is a contig. Then I tried to use the entire genome scaffold
set as the reference genome and reran the pipeline, still getting the same
results in terms of the Exonerate alignments. Please see the example of a
GFF3 file generated:

##gff-version 3
scaffold3928    .       contig  1       172176  .       .       .
ID=scaffold3928;Name=scaffold3928
###
##FASTA
>scaffold3928
<scaffold_sequence_omitted>

What do I need to adjust to get the alignment information into the GFF file
so I can upload into a genome browser as tracks?

Thank you very much for considering my inquiry.

Sincerely,

Xin Huang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://box290.bluehost.com/pipermail/maker-devel_yandell-lab.org/attachments/20131105/b6a8065e/attachment.html>

From xh33 at georgetown.edu  Tue Nov  5 15:40:24 2013
From: xh33 at georgetown.edu (Xin Huang)
Date: Tue, 5 Nov 2013 16:40:24 -0500
Subject: [maker-devel] A suspected strange behavior of Maker...
Message-ID: <CACvYrQGP1dajOYyhiTDt6QuzCHdVR21vLYzmbtMKvF67d-fMiA@mail.gmail.com>

Hi,

I found a very bizarre thing when I ran Maker several times. The blastn
research seems to reverse query and subject the way it's specified in the
maker_opts.ctl file. When I put the scaffold sequence after genome= and the
cDNA sequence after est=, the blastn result actually used the scaffold as
query and the cDNA as subject. I realized that this sounds unreal, so I
reversed the places for the two and the blastn result is normal with the
cDNA as query and the scaffold as subject, but at the same time, the GFF
file is of the cDNA sequence. I tried a few times, and got the same result.
I deleted Maker (2.28) and reinstalled the beta version (2.30), still
getting the same result.

My wild guess was that this might be the reason why the est2genome
prediction using the EST sequence didn't go into the GFF3 file, as stated
in a previous email to the Maker-devel. I couldn't figure out how to test
this, though. I wonder if there's anything dramatically wrong that I've
been doing to get such odd results... If you'd like me to send you any
output files or control files, please let me know and I'll promptly pass
those along.

Thank you very much for considering my email.

Sincerely,

Xin Huang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://box290.bluehost.com/pipermail/maker-devel_yandell-lab.org/attachments/20131105/f942ccad/attachment.html>

From Kerry_Gendreau at student.uml.edu  Fri Nov  8 17:40:06 2013
From: Kerry_Gendreau at student.uml.edu (Gendreau, Kerry L)
Date: Fri, 8 Nov 2013 23:40:06 +0000
Subject: [maker-devel] Maker is not predicting any genes on scaffold
Message-ID: <ae5739936c8745d9aaf58a434906305b@CO1PR02MB046.namprd02.prod.outlook.com>

Hello,

I am attempting to annotate a small section of an arthropod genome. I ran Maker on the command line and the results showed only repetitive regions recognized by Repeat Masker -- no predicted ORFs. I submitted my scaffold through the web interface and got the same results.

I know that there are genes present on this scaffold and when I run it through Augustus there are 13 ORFs predicted.

Are there some options that I need to adjust to get ab initio gene predictions from Maker?


Thank you,

Kerry Gendreau
Graduate Student, Dept. of Biological Sciences
University of Massachusetts Lowell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://box290.bluehost.com/pipermail/maker-devel_yandell-lab.org/attachments/20131108/ae7546e5/attachment.html>

From dence at genetics.utah.edu  Sun Nov 10 20:43:12 2013
From: dence at genetics.utah.edu (Daniel Ence)
Date: Mon, 11 Nov 2013 02:43:12 +0000
Subject: [maker-devel] Maker is not predicting any genes on scaffold
In-Reply-To: <ae5739936c8745d9aaf58a434906305b@CO1PR02MB046.namprd02.prod.outlook.com>
References: <ae5739936c8745d9aaf58a434906305b@CO1PR02MB046.namprd02.prod.outlook.com>
Message-ID: <F2774D6F47BB9D449EEA8B0BF6679D9C65D3E471@mxb2.hg.genetics.utah.edu>

Hi Kerry, What evidence and abinitios did you use when you ran MAKER on your own machine?

Thanks,
Daniel

Daniel Ence
Graduate Student
Eccles Institute of Human Genetics
University of Utah
15 North 2030 East, Room 2100
Salt Lake City, UT 84112-5330
________________________________
From: maker-devel [maker-devel-bounces at yandell-lab.org] on behalf of Gendreau, Kerry L [Kerry_Gendreau at student.uml.edu]
Sent: Friday, November 08, 2013 4:40 PM
To: maker-devel at yandell-lab.org
Subject: [maker-devel] Maker is not predicting any genes on scaffold

Hello,

I am attempting to annotate a small section of an arthropod genome. I ran Maker on the command line and the results showed only repetitive regions recognized by Repeat Masker -- no predicted ORFs. I submitted my scaffold through the web interface and got the same results.

I know that there are genes present on this scaffold and when I run it through Augustus there are 13 ORFs predicted.

Are there some options that I need to adjust to get ab initio gene predictions from Maker?


Thank you,

Kerry Gendreau
Graduate Student, Dept. of Biological Sciences
University of Massachusetts Lowell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://box290.bluehost.com/pipermail/maker-devel_yandell-lab.org/attachments/20131111/a93b1101/attachment.html>

From carson.holt at genetics.utah.edu  Sun Nov 10 21:08:23 2013
From: carson.holt at genetics.utah.edu (Carson Holt)
Date: Mon, 11 Nov 2013 03:08:23 +0000
Subject: [maker-devel] Problems with Maker
In-Reply-To: <CAC18qO8DbAWchktQpUC=CaPSL446kOj3Jgbt0_S1Ha41oAOh_w@mail.gmail.com>
Message-ID: <CEA59757.69E6%carson.holt@genetics.utah.edu>

For the installation problem, it shouldn't take more tun  few minutes.  You might want to just try setting up repeat masker manually, since what is happening is probably system specific.

The second problem is caused by an edit you made to the maker_opt.ctl file.  You deleted the '#' character that separates the options from the instructions comment, so the entire line is being interpreted as an option

model_org=all select a model organism for RepBase masking in RepeatMasker

So it's trying to use the phrase 'all select a model organism for RepBase masking in RepeatMasker' as the species, which causes repeat masker to fail.

Just change the line to model_org=all

--Carson


From: Sanea Sheikh <saneasheikh at gmail.com<mailto:saneasheikh at gmail.com>>
Date: Thursday, November 7, 2013 8:22 AM
To: <maker-devel at yandell-lab.org<mailto:maker-devel at yandell-lab.org>>
Subject: Problems with Maker

Hello

I am trying to run Maker v2.28 on my computer. I am having two problems.

When I use ./Build repeatmasker command for installing RepeatMasker, I get stuck at the Configuring RepeatMasker step for days. It doesn't move forward from that point. See the log attached (repeatmasker_maker.txt).

When I install RepeatMasker and run Maker, I get error message attached in maker_error_RM.txt file.

Can you please tell me what I am doing wrong here? I have also attached the maker opts.ctl file for your reference. I would really appreciate it if you can help me in this regard.

Regards
Sanea


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://box290.bluehost.com/pipermail/maker-devel_yandell-lab.org/attachments/20131111/f5550f90/attachment.html>

From carsonhh at gmail.com  Sun Nov 10 23:10:08 2013
From: carsonhh at gmail.com (Carson Holt)
Date: Sun, 10 Nov 2013 22:10:08 -0700
Subject: [maker-devel] A suspected strange behavior of Maker...
In-Reply-To: <CACvYrQGP1dajOYyhiTDt6QuzCHdVR21vLYzmbtMKvF67d-fMiA@mail.gmail.com>
Message-ID: <CEA5B2C9.69F9%carsonhh@gmail.com>

Sorry for the slow reply, I was moving from Canada to the US, got sick, and
my moving truck got delayed one week. So I fell behind on the maker list.

What you observe is correct behavior.  The config is blasted against the
database of ESTs/proteins.  It really doesn't matter which way you blast,
you pick the direction that is most efficient for the question you are
asking, and you only have to adjust the Z value for database size if you
want alignment scores to be reproducible both ways.

Not getting results means they were filtered out for some reason (you don't
even have blastn results in your output).  If you can send a test dataset I
can take a look and tell you which filter.

Thanks,
Carson


From:  Xin Huang <xh33 at georgetown.edu>
Date:  Tuesday, November 5, 2013 2:40 PM
To:  <maker-devel at yandell-lab.org>
Subject:  [maker-devel] A suspected strange behavior of Maker...

Hi,

I found a very bizarre thing when I ran Maker several times. The blastn
research seems to reverse query and subject the way it's specified in the
maker_opts.ctl file. When I put the scaffold sequence after genome= and the
cDNA sequence after est=, the blastn result actually used the scaffold as
query and the cDNA as subject. I realized that this sounds unreal, so I
reversed the places for the two and the blastn result is normal with the
cDNA as query and the scaffold as subject, but at the same time, the GFF
file is of the cDNA sequence. I tried a few times, and got the same result.
I deleted Maker (2.28) and reinstalled the beta version (2.30), still
getting the same result.

My wild guess was that this might be the reason why the est2genome
prediction using the EST sequence didn't go into the GFF3 file, as stated in
a previous email to the Maker-devel. I couldn't figure out how to test this,
though. I wonder if there's anything dramatically wrong that I've been doing
to get such odd results... If you'd like me to send you any output files or
control files, please let me know and I'll promptly pass those along.

Thank you very much for considering my email.

Sincerely,

Xin Huang
_______________________________________________ maker-devel mailing list
maker-devel at box290.bluehost.com
http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://box290.bluehost.com/pipermail/maker-devel_yandell-lab.org/attachments/20131110/153ea1e5/attachment.html>

From kpepin at genome.wustl.edu  Mon Nov 11 14:01:26 2013
From: kpepin at genome.wustl.edu (Kymberlie Hallsworth-Pepin)
Date: Mon, 11 Nov 2013 14:01:26 -0600 (CST)
Subject: [maker-devel] re-annotation
In-Reply-To: <CA5CEF3B.6A42%carsonhh@gmail.com>
References: <CA5CEF3B.6A42%carsonhh@gmail.com>
Message-ID: <alpine.DEB.2.00.1311111355190.28492@linus40.gsc.wustl.edu>

Hi Carson,

I am trying to take an existing gene set and update it using new proteins. 
I have the gene set in gff3 format - validated as ok - and have put it in
the model_gff line. I set the protein db to the new database and I set the 
map_forward=1 to maintain naming, but the output has no gene predictions 
in it. I have tried setting keep_preds both 0 and 1. I have put the gff 
file in both the pred_gff and model_gff and just in the pred_gff field, 
but I still don't get any predictions maintained. Can you tell me what I 
might be missing ?

thanks
Kym


____
This email message is a private communication. The information transmitted, including attachments, is intended only for the person or entity to which it is addressed and may contain confidential, privileged, and/or proprietary material. Any review, duplication, retransmission, distribution, or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is unauthorized by the sender and is prohibited. If you have received this message in error, please contact the sender immediately by return email and delete the original message from all computer systems. Thank you.



From cjfields at illinois.edu  Tue Nov 12 13:18:36 2013
From: cjfields at illinois.edu (Fields, Christopher J)
Date: Tue, 12 Nov 2013 19:18:36 +0000
Subject: [maker-devel] Recommendations for visualization?
Message-ID: <9B60EB76-1920-4B75-A224-C44070452B84@illinois.edu>

Barry, Carson,

Are there any recommendations re: visualizing MAKER-generated GFF3?  I know it?s currently geared towards Apollo integration, but as everything is moving towards Webapollo, attempts at finding the old local client Apollo code are a bit of an archaeological expedition (not to mention Apollo has always been a joy to set up from code :).  Is everyone still trying to use the old Apollo, since it seems to no longer be supported?

At the moment I am really thinking of working on simple scripts to make IGV-friendly input (and possibly similar Artemis for our smaller genome projects), but I don?t want to repeat work already in place.

chris


From barry.utah at gmail.com  Tue Nov 12 16:03:12 2013
From: barry.utah at gmail.com (Barry Moore)
Date: Tue, 12 Nov 2013 15:03:12 -0700
Subject: [maker-devel] Recommendations for visualization?
In-Reply-To: <9B60EB76-1920-4B75-A224-C44070452B84@illinois.edu>
References: <9B60EB76-1920-4B75-A224-C44070452B84@illinois.edu>
Message-ID: <90397AC5-7FEA-4B81-8085-49BD48787A6F@genetics.utah.edu>

This is a VERY good point Chris.  I think the new web-apollo is developing into a great tool, but there is now a gapping hole in the area of a desktop application (i.e. no server setup) to view/edit genome annotations.  I'd love to hear what others are using.  Our group has been using a combination of old Apollo instances, Web-Apollo and Gbrowse.

B

On Nov 12, 2013, at 12:18 PM, Fields, Christopher J wrote:

> Barry, Carson,
> 
> Are there any recommendations re: visualizing MAKER-generated GFF3?  I know it?s currently geared towards Apollo integration, but as everything is moving towards Webapollo, attempts at finding the old local client Apollo code are a bit of an archaeological expedition (not to mention Apollo has always been a joy to set up from code :).  Is everyone still trying to use the old Apollo, since it seems to no longer be supported?
> 
> At the moment I am really thinking of working on simple scripts to make IGV-friendly input (and possibly similar Artemis for our smaller genome projects), but I don?t want to repeat work already in place.
> 
> chris
> _______________________________________________
> maker-devel mailing list
> maker-devel at box290.bluehost.com
> http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org

Barry Moore
Research Scientist
Dept. of Human Genetics
University of Utah
Salt Lake City, UT 84112
--------------------------------------------
(801) 585-3543




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://box290.bluehost.com/pipermail/maker-devel_yandell-lab.org/attachments/20131112/863f00a0/attachment.html>

From cjfields at illinois.edu  Tue Nov 12 16:25:21 2013
From: cjfields at illinois.edu (Fields, Christopher J)
Date: Tue, 12 Nov 2013 22:25:21 +0000
Subject: [maker-devel] Recommendations for visualization?
In-Reply-To: <90397AC5-7FEA-4B81-8085-49BD48787A6F@genetics.utah.edu>
References: <9B60EB76-1920-4B75-A224-C44070452B84@illinois.edu>
	<90397AC5-7FEA-4B81-8085-49BD48787A6F@genetics.utah.edu>
Message-ID: <8D26BC0C-74F6-43F4-A29B-10615BF7C6C0@illinois.edu>

I have considered using GMOD in the Cloud (we are likely to set something like this up on our local OpenStack when it?s up and running), but as a quick assessment of a test run it seems a bit overkill.

chris

On Nov 12, 2013, at 4:03 PM, Barry Moore <barry.utah at gmail.com<mailto:barry.utah at gmail.com>> wrote:

This is a VERY good point Chris.  I think the new web-apollo is developing into a great tool, but there is now a gapping hole in the area of a desktop application (i.e. no server setup) to view/edit genome annotations.  I'd love to hear what others are using.  Our group has been using a combination of old Apollo instances, Web-Apollo and Gbrowse.

B

On Nov 12, 2013, at 12:18 PM, Fields, Christopher J wrote:

Barry, Carson,

Are there any recommendations re: visualizing MAKER-generated GFF3?  I know it?s currently geared towards Apollo integration, but as everything is moving towards Webapollo, attempts at finding the old local client Apollo code are a bit of an archaeological expedition (not to mention Apollo has always been a joy to set up from code :).  Is everyone still trying to use the old Apollo, since it seems to no longer be supported?

At the moment I am really thinking of working on simple scripts to make IGV-friendly input (and possibly similar Artemis for our smaller genome projects), but I don?t want to repeat work already in place.

chris
_______________________________________________
maker-devel mailing list
maker-devel at box290.bluehost.com<mailto:maker-devel at box290.bluehost.com>
http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org

Barry Moore
Research Scientist
Dept. of Human Genetics
University of Utah
Salt Lake City, UT 84112
--------------------------------------------
(801) 585-3543





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://box290.bluehost.com/pipermail/maker-devel_yandell-lab.org/attachments/20131112/1ef63aa0/attachment.html>

From carsonhh at gmail.com  Tue Nov 12 22:04:45 2013
From: carsonhh at gmail.com (Carson Holt)
Date: Tue, 12 Nov 2013 21:04:45 -0700
Subject: [maker-devel] re-annotation
In-Reply-To: <alpine.DEB.2.00.1311111355190.28492@linus40.gsc.wustl.edu>
Message-ID: <CEA8485C.6E7B%carsonhh@gmail.com>

They should be maintained.  What version are you using?

--Carson


On 11/11/13 1:01 PM, "Kymberlie Hallsworth-Pepin"
<kpepin at genome.wustl.edu> wrote:

>Hi Carson,
>
>I am trying to take an existing gene set and update it using new
>proteins. 
>I have the gene set in gff3 format - validated as ok - and have put it in
>the model_gff line. I set the protein db to the new database and I set
>the 
>map_forward=1 to maintain naming, but the output has no gene predictions
>in it. I have tried setting keep_preds both 0 and 1. I have put the gff
>file in both the pred_gff and model_gff and just in the pred_gff field,
>but I still don't get any predictions maintained. Can you tell me what I
>might be missing ?
>
>thanks
>Kym
>
>
>____
>This email message is a private communication. The information
>transmitted, including attachments, is intended only for the person or
>entity to which it is addressed and may contain confidential, privileged,
>and/or proprietary material. Any review, duplication, retransmission,
>distribution, or other use of, or taking of any action in reliance upon,
>this information by persons or entities other than the intended recipient
>is unauthorized by the sender and is prohibited. If you have received
>this message in error, please contact the sender immediately by return
>email and delete the original message from all computer systems. Thank
>you.





From kpepin at genome.wustl.edu  Wed Nov 13 07:16:44 2013
From: kpepin at genome.wustl.edu (Kymberlie Hallsworth-Pepin)
Date: Wed, 13 Nov 2013 07:16:44 -0600 (CST)
Subject: [maker-devel] re-annotation
In-Reply-To: <CEA8485C.6E7B%carsonhh@gmail.com>
References: <CEA8485C.6E7B%carsonhh@gmail.com>
Message-ID: <alpine.DEB.2.00.1311130711440.28492@linus40.gsc.wustl.edu>


We are using v2.26. We recreated the gff3 file and I can now get gene 
predictions to show up using the pred_gff file as input for the gene set. 
The naming is not maintained with the map_forward=1 as I would expect, 
just the source field in the input gff file is added to the new maker 
name.  If I change the input to a model_gff file I still do not get 
predictions in the maker gff file.

thanks
Kym




On Tue, 12 Nov 2013, Carson Holt wrote:

> They should be maintained.  What version are you using?
>
> --Carson
>
>
> On 11/11/13 1:01 PM, "Kymberlie Hallsworth-Pepin"
> <kpepin at genome.wustl.edu> wrote:
>
>> Hi Carson,
>>
>> I am trying to take an existing gene set and update it using new
>> proteins.
>> I have the gene set in gff3 format - validated as ok - and have put it in
>> the model_gff line. I set the protein db to the new database and I set
>> the
>> map_forward=1 to maintain naming, but the output has no gene predictions
>> in it. I have tried setting keep_preds both 0 and 1. I have put the gff
>> file in both the pred_gff and model_gff and just in the pred_gff field,
>> but I still don't get any predictions maintained. Can you tell me what I
>> might be missing ?
>>
>> thanks
>> Kym
>>
>>
>> ____
>> This email message is a private communication. The information
>> transmitted, including attachments, is intended only for the person or
>> entity to which it is addressed and may contain confidential, privileged,
>> and/or proprietary material. Any review, duplication, retransmission,
>> distribution, or other use of, or taking of any action in reliance upon,
>> this information by persons or entities other than the intended recipient
>> is unauthorized by the sender and is prohibited. If you have received
>> this message in error, please contact the sender immediately by return
>> email and delete the original message from all computer systems. Thank
>> you.
>

____
This email message is a private communication. The information transmitted, including attachments, is intended only for the person or entity to which it is addressed and may contain confidential, privileged, and/or proprietary material. Any review, duplication, retransmission, distribution, or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is unauthorized by the sender and is prohibited. If you have received this message in error, please contact the sender immediately by return email and delete the original message from all computer systems. Thank you.



From carsonhh at gmail.com  Wed Nov 13 09:06:44 2013
From: carsonhh at gmail.com (Carson Holt)
Date: Wed, 13 Nov 2013 08:06:44 -0700
Subject: [maker-devel] re-annotation
In-Reply-To: <alpine.DEB.2.00.1311130711440.28492@linus40.gsc.wustl.edu>
Message-ID: <CEA8E2DE.6FBF%carsonhh@gmail.com>

So map_forward=1, will only maintain names derived from model_gff onto new
or updated models.  Could you try either 2.28 or 2.30-beta, just to see if
this is something that is already fixed.

Thanks,
Carson


On 11/13/13 6:16 AM, "Kymberlie Hallsworth-Pepin"
<kpepin at genome.wustl.edu> wrote:

>
>We are using v2.26. We recreated the gff3 file and I can now get gene
>predictions to show up using the pred_gff file as input for the gene set.
>The naming is not maintained with the map_forward=1 as I would expect,
>just the source field in the input gff file is added to the new maker
>name.  If I change the input to a model_gff file I still do not get
>predictions in the maker gff file.
>
>thanks
>Kym
>
>
>
>
>On Tue, 12 Nov 2013, Carson Holt wrote:
>
>> They should be maintained.  What version are you using?
>>
>> --Carson
>>
>>
>> On 11/11/13 1:01 PM, "Kymberlie Hallsworth-Pepin"
>> <kpepin at genome.wustl.edu> wrote:
>>
>>> Hi Carson,
>>>
>>> I am trying to take an existing gene set and update it using new
>>> proteins.
>>> I have the gene set in gff3 format - validated as ok - and have put it
>>>in
>>> the model_gff line. I set the protein db to the new database and I set
>>> the
>>> map_forward=1 to maintain naming, but the output has no gene
>>>predictions
>>> in it. I have tried setting keep_preds both 0 and 1. I have put the gff
>>> file in both the pred_gff and model_gff and just in the pred_gff field,
>>> but I still don't get any predictions maintained. Can you tell me what
>>>I
>>> might be missing ?
>>>
>>> thanks
>>> Kym
>>>
>>>
>>> ____
>>> This email message is a private communication. The information
>>> transmitted, including attachments, is intended only for the person or
>>> entity to which it is addressed and may contain confidential,
>>>privileged,
>>> and/or proprietary material. Any review, duplication, retransmission,
>>> distribution, or other use of, or taking of any action in reliance
>>>upon,
>>> this information by persons or entities other than the intended
>>>recipient
>>> is unauthorized by the sender and is prohibited. If you have received
>>> this message in error, please contact the sender immediately by return
>>> email and delete the original message from all computer systems. Thank
>>> you.
>>
>
>____
>This email message is a private communication. The information
>transmitted, including attachments, is intended only for the person or
>entity to which it is addressed and may contain confidential, privileged,
>and/or proprietary material. Any review, duplication, retransmission,
>distribution, or other use of, or taking of any action in reliance upon,
>this information by persons or entities other than the intended recipient
>is unauthorized by the sender and is prohibited. If you have received
>this message in error, please contact the sender immediately by return
>email and delete the original message from all computer systems. Thank
>you.





From kpepin at genome.wustl.edu  Wed Nov 13 09:15:48 2013
From: kpepin at genome.wustl.edu (Kymberlie Hallsworth-Pepin)
Date: Wed, 13 Nov 2013 09:15:48 -0600 (CST)
Subject: [maker-devel] re-annotation
In-Reply-To: <CEA8E2DE.6FBF%carsonhh@gmail.com>
References: <CEA8E2DE.6FBF%carsonhh@gmail.com>
Message-ID: <alpine.DEB.2.00.1311130913090.2847@linus40.gsc.wustl.edu>



Will do. Is there a difference between how the model_gff file and the 
pred_gff file use the match/match_part of CDS/mRNA designations and which 
is the best to use for model_gff input?

On Wed, 13 Nov 2013, Carson Holt wrote:

> So map_forward=1, will only maintain names derived from model_gff onto new
> or updated models.  Could you try either 2.28 or 2.30-beta, just to see if
> this is something that is already fixed.
>
> Thanks,
> Carson
>

____
This email message is a private communication. The information transmitted, including attachments, is intended only for the person or entity to which it is addressed and may contain confidential, privileged, and/or proprietary material. Any review, duplication, retransmission, distribution, or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is unauthorized by the sender and is prohibited. If you have received this message in error, please contact the sender immediately by return email and delete the original message from all computer systems. Thank you.



From carsonhh at gmail.com  Wed Nov 13 17:08:08 2013
From: carsonhh at gmail.com (Carson Holt)
Date: Wed, 13 Nov 2013 16:08:08 -0700
Subject: [maker-devel] re-annotation
In-Reply-To: <alpine.DEB.2.00.1311130913090.2847@linus40.gsc.wustl.edu>
Message-ID: <CEA953DA.6B86%carsonhh@gmail.com>

model_gff must be gene/mRNA/exon/CDS. pred_gff can be match/match_part or
gene/mRNA/exon/CDS.  Also model_gff always should make it into the final
result (unless replaced by something better) and will not be modified.  It
also affects clustering.  pref_gff will only make it into the final
results if it is supported by evidence.

?Carson


On 11/13/13, 8:15 AM, "Kymberlie Hallsworth-Pepin"
<kpepin at genome.wustl.edu> wrote:

>
>
>Will do. Is there a difference between how the model_gff file and the
>pred_gff file use the match/match_part of CDS/mRNA designations and which
>is the best to use for model_gff input?
>
>On Wed, 13 Nov 2013, Carson Holt wrote:
>
>> So map_forward=1, will only maintain names derived from model_gff onto
>>new
>> or updated models.  Could you try either 2.28 or 2.30-beta, just to see
>>if
>> this is something that is already fixed.
>>
>> Thanks,
>> Carson
>>
>
>____
>This email message is a private communication. The information
>transmitted, including attachments, is intended only for the person or
>entity to which it is addressed and may contain confidential, privileged,
>and/or proprietary material. Any review, duplication, retransmission,
>distribution, or other use of, or taking of any action in reliance upon,
>this information by persons or entities other than the intended recipient
>is unauthorized by the sender and is prohibited. If you have received
>this message in error, please contact the sender immediately by return
>email and delete the original message from all computer systems. Thank
>you.





From carsonhh at gmail.com  Wed Nov 13 20:59:44 2013
From: carsonhh at gmail.com (Carson Holt)
Date: Wed, 13 Nov 2013 19:59:44 -0700
Subject: [maker-devel] A suspected strange behavior of Maker...
In-Reply-To: <CACvYrQGf+QwTcbWEOLX0igUZWcByu-E2d8YD4m2ykzCGr_aJ-w@mail.gmail.com>
Message-ID: <CEA98904.6B9A%carsonhh@gmail.com>

For scaffold5347 I get results from exonerate and blastn without any
modification to default parameters.  For scaffold3928 the alignment is very
poor, and gets filtered out.  I can force it to keep it but I have to allow
for abnormally long introns of 65kb (introns that large are extremely rare
in biology ? as in if you took every gene from 100 organisms you might find
a single gene among all of them with that long of an intron), and I have to
allow for low end to end matching (less 30%).  This alignment definitely
should have been rejected.

Thanks,
Carson


From:  Xin Huang <xh33 at georgetown.edu>
Date:  Monday, November 11, 2013 at 8:52 AM
To:  Carson Holt <carsonhh at gmail.com>
Cc:  <maker-devel at yandell-lab.org>
Subject:  Re: [maker-devel] A suspected strange behavior of Maker...

Hi Carson,

Thank you very much for getting back to me on this. Sorry I was too quick to
jump to a suspicion! Thanks for pointing it out and please see attached the
EST (face_cDNA.fa) and genome scaffold sequences
(albo_scaf3928+5347_for_face_cDNA.fa) I used for Maker. We used blastn to
identify these two scaffolds for this cDNA sequence, and exonerate result
also showed that this cDNA can be aligned to the scaffolds.

Thanks!

Xin 


On Mon, Nov 11, 2013 at 12:10 AM, Carson Holt <carsonhh at gmail.com> wrote:
> Sorry for the slow reply, I was moving from Canada to the US, got sick, and my
> moving truck got delayed one week. So I fell behind on the maker list.
> 
> What you observe is correct behavior.  The config is blasted against the
> database of ESTs/proteins.  It really doesn't matter which way you blast, you
> pick the direction that is most efficient for the question you are asking, and
> you only have to adjust the Z value for database size if you want alignment
> scores to be reproducible both ways.
> 
> Not getting results means they were filtered out for some reason (you don't
> even have blastn results in your output).  If you can send a test dataset I
> can take a look and tell you which filter.
> 
> Thanks,
> Carson
> 
> 
> From:  Xin Huang <xh33 at georgetown.edu>
> Date:  Tuesday, November 5, 2013 2:40 PM
> To:  <maker-devel at yandell-lab.org>
> Subject:  [maker-devel] A suspected strange behavior of Maker...
> 
> Hi,
> 
> I found a very bizarre thing when I ran Maker several times. The blastn
> research seems to reverse query and subject the way it's specified in the
> maker_opts.ctl file. When I put the scaffold sequence after genome= and the
> cDNA sequence after est=, the blastn result actually used the scaffold as
> query and the cDNA as subject. I realized that this sounds unreal, so I
> reversed the places for the two and the blastn result is normal with the cDNA
> as query and the scaffold as subject, but at the same time, the GFF file is of
> the cDNA sequence. I tried a few times, and got the same result. I deleted
> Maker (2.28) and reinstalled the beta version (2.30), still getting the same
> result.
> 
> My wild guess was that this might be the reason why the est2genome prediction
> using the EST sequence didn't go into the GFF3 file, as stated in a previous
> email to the Maker-devel. I couldn't figure out how to test this, though. I
> wonder if there's anything dramatically wrong that I've been doing to get such
> odd results... If you'd like me to send you any output files or control files,
> please let me know and I'll promptly pass those along.
> 
> Thank you very much for considering my email.
> 
> Sincerely,
> 
> Xin Huang
> _______________________________________________ maker-devel mailing list
> maker-devel at box290.bluehost.comhttp://box290.bluehost.com/mailman/listinfo/mak
> er-devel_yandell-lab.org



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://box290.bluehost.com/pipermail/maker-devel_yandell-lab.org/attachments/20131113/047635c9/attachment.html>

From xh33 at georgetown.edu  Wed Nov 13 21:45:42 2013
From: xh33 at georgetown.edu (Xin Huang)
Date: Wed, 13 Nov 2013 22:45:42 -0500
Subject: [maker-devel] A suspected strange behavior of Maker...
In-Reply-To: <CEA98904.6B9A%carsonhh@gmail.com>
References: <CACvYrQGf+QwTcbWEOLX0igUZWcByu-E2d8YD4m2ykzCGr_aJ-w@mail.gmail.com>
	<CEA98904.6B9A%carsonhh@gmail.com>
Message-ID: <CACvYrQFPkZ+BwcQu0amq1kzO-0xAMTsLa0RqY+xy_sn6AfrZ0Q@mail.gmail.com>

Hi Carson,

Thanks a lot for doing the test for me! I didn't get any annotation in the
GFF file generated by Maker even if I only used scaffold5347 as the genome
and the face EST sequence as the est evidence. Is there something that I
can modify to put the alignment into the GFF file? I used est2genome=1
option to get prediction from exonerate, but still couldn't get any
prediction.

Thanks!

Xin


On Wed, Nov 13, 2013 at 9:59 PM, Carson Holt <carsonhh at gmail.com> wrote:

> For scaffold5347 I get results from exonerate and blastn without any
> modification to default parameters.  For scaffold3928 the alignment is very
> poor, and gets filtered out.  I can force it to keep it but I have to allow
> for abnormally long introns of 65kb (introns that large are extremely rare
> in biology ? as in if you took every gene from 100 organisms you might find
> a single gene among all of them with that long of an intron), and I have to
> allow for low end to end matching (less 30%).  This alignment definitely
> should have been rejected.
>
> Thanks,
> Carson
>
>
> From: Xin Huang <xh33 at georgetown.edu>
> Date: Monday, November 11, 2013 at 8:52 AM
> To: Carson Holt <carsonhh at gmail.com>
> Cc: <maker-devel at yandell-lab.org>
> Subject: Re: [maker-devel] A suspected strange behavior of Maker...
>
> Hi Carson,
>
> Thank you very much for getting back to me on this. Sorry I was too quick
> to jump to a suspicion! Thanks for pointing it out and please see attached
> the EST (face_cDNA.fa) and genome scaffold sequences
> (albo_scaf3928+5347_for_face_cDNA.fa) I used for Maker. We used blastn to
> identify these two scaffolds for this cDNA sequence, and exonerate result
> also showed that this cDNA can be aligned to the scaffolds.
>
> Thanks!
>
> Xin
>
>
> On Mon, Nov 11, 2013 at 12:10 AM, Carson Holt <carsonhh at gmail.com> wrote:
>
>> Sorry for the slow reply, I was moving from Canada to the US, got sick,
>> and my moving truck got delayed one week. So I fell behind on the maker
>> list.
>>
>> What you observe is correct behavior.  The config is blasted against the
>> database of ESTs/proteins.  It really doesn't matter which way you blast,
>> you pick the direction that is most efficient for the question you are
>> asking, and you only have to adjust the Z value for database size if you
>> want alignment scores to be reproducible both ways.
>>
>> Not getting results means they were filtered out for some reason (you
>> don't even have blastn results in your output).  If you can send a test
>> dataset I can take a look and tell you which filter.
>>
>> Thanks,
>> Carson
>>
>>
>> From: Xin Huang <xh33 at georgetown.edu>
>> Date: Tuesday, November 5, 2013 2:40 PM
>> To: <maker-devel at yandell-lab.org>
>> Subject: [maker-devel] A suspected strange behavior of Maker...
>>
>> Hi,
>>
>> I found a very bizarre thing when I ran Maker several times. The blastn
>> research seems to reverse query and subject the way it's specified in the
>> maker_opts.ctl file. When I put the scaffold sequence after genome= and the
>> cDNA sequence after est=, the blastn result actually used the scaffold as
>> query and the cDNA as subject. I realized that this sounds unreal, so I
>> reversed the places for the two and the blastn result is normal with the
>> cDNA as query and the scaffold as subject, but at the same time, the GFF
>> file is of the cDNA sequence. I tried a few times, and got the same result.
>> I deleted Maker (2.28) and reinstalled the beta version (2.30), still
>> getting the same result.
>>
>> My wild guess was that this might be the reason why the est2genome
>> prediction using the EST sequence didn't go into the GFF3 file, as stated
>> in a previous email to the Maker-devel. I couldn't figure out how to test
>> this, though. I wonder if there's anything dramatically wrong that I've
>> been doing to get such odd results... If you'd like me to send you any
>> output files or control files, please let me know and I'll promptly pass
>> those along.
>>
>> Thank you very much for considering my email.
>>
>> Sincerely,
>>
>> Xin Huang
>> _______________________________________________ maker-devel mailing list
>> maker-devel at box290.bluehost.com
>> http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://box290.bluehost.com/pipermail/maker-devel_yandell-lab.org/attachments/20131113/133d8f0a/attachment.html>

From carsonhh at gmail.com  Wed Nov 13 21:49:32 2013
From: carsonhh at gmail.com (Carson Holt)
Date: Wed, 13 Nov 2013 20:49:32 -0700
Subject: [maker-devel] A suspected strange behavior of Maker...
In-Reply-To: <CACvYrQFPkZ+BwcQu0amq1kzO-0xAMTsLa0RqY+xy_sn6AfrZ0Q@mail.gmail.com>
Message-ID: <CEA99613.6BAD%carsonhh@gmail.com>

All I did was supply the cDNA to est= and the scaffolds to genome=.  All the
other parameters I just used the default, then I ran MAKER.  I am using
version 2.30.

Thanks,
Carson


From:  Xin Huang <xh33 at georgetown.edu>
Date:  Wednesday, November 13, 2013 at 8:45 PM
To:  Carson Holt <carsonhh at gmail.com>
Cc:  <maker-devel at yandell-lab.org>
Subject:  Re: [maker-devel] A suspected strange behavior of Maker...

Hi Carson,

Thanks a lot for doing the test for me! I didn't get any annotation in the
GFF file generated by Maker even if I only used scaffold5347 as the genome
and the face EST sequence as the est evidence. Is there something that I can
modify to put the alignment into the GFF file? I used est2genome=1 option to
get prediction from exonerate, but still couldn't get any prediction.

Thanks!

Xin


On Wed, Nov 13, 2013 at 9:59 PM, Carson Holt <carsonhh at gmail.com> wrote:
> For scaffold5347 I get results from exonerate and blastn without any
> modification to default parameters.  For scaffold3928 the alignment is very
> poor, and gets filtered out.  I can force it to keep it but I have to allow
> for abnormally long introns of 65kb (introns that large are extremely rare in
> biology ? as in if you took every gene from 100 organisms you might find a
> single gene among all of them with that long of an intron), and I have to
> allow for low end to end matching (less 30%).  This alignment definitely
> should have been rejected.
> 
> Thanks,
> Carson
> 
> 
> From:  Xin Huang <xh33 at georgetown.edu>
> Date:  Monday, November 11, 2013 at 8:52 AM
> To:  Carson Holt <carsonhh at gmail.com>
> Cc:  <maker-devel at yandell-lab.org>
> Subject:  Re: [maker-devel] A suspected strange behavior of Maker...
> 
> Hi Carson,
> 
> Thank you very much for getting back to me on this. Sorry I was too quick to
> jump to a suspicion! Thanks for pointing it out and please see attached the
> EST (face_cDNA.fa) and genome scaffold sequences
> (albo_scaf3928+5347_for_face_cDNA.fa) I used for Maker. We used blastn to
> identify these two scaffolds for this cDNA sequence, and exonerate result also
> showed that this cDNA can be aligned to the scaffolds.
> 
> Thanks!
> 
> Xin 
> 
> 
> On Mon, Nov 11, 2013 at 12:10 AM, Carson Holt <carsonhh at gmail.com> wrote:
>> Sorry for the slow reply, I was moving from Canada to the US, got sick, and
>> my moving truck got delayed one week. So I fell behind on the maker list.
>> 
>> What you observe is correct behavior.  The config is blasted against the
>> database of ESTs/proteins.  It really doesn't matter which way you blast, you
>> pick the direction that is most efficient for the question you are asking,
>> and you only have to adjust the Z value for database size if you want
>> alignment scores to be reproducible both ways.
>> 
>> Not getting results means they were filtered out for some reason (you don't
>> even have blastn results in your output).  If you can send a test dataset I
>> can take a look and tell you which filter.
>> 
>> Thanks,
>> Carson
>> 
>> 
>> From:  Xin Huang <xh33 at georgetown.edu>
>> Date:  Tuesday, November 5, 2013 2:40 PM
>> To:  <maker-devel at yandell-lab.org>
>> Subject:  [maker-devel] A suspected strange behavior of Maker...
>> 
>> Hi,
>> 
>> I found a very bizarre thing when I ran Maker several times. The blastn
>> research seems to reverse query and subject the way it's specified in the
>> maker_opts.ctl file. When I put the scaffold sequence after genome= and the
>> cDNA sequence after est=, the blastn result actually used the scaffold as
>> query and the cDNA as subject. I realized that this sounds unreal, so I
>> reversed the places for the two and the blastn result is normal with the cDNA
>> as query and the scaffold as subject, but at the same time, the GFF file is
>> of the cDNA sequence. I tried a few times, and got the same result. I deleted
>> Maker (2.28) and reinstalled the beta version (2.30), still getting the same
>> result.
>> 
>> My wild guess was that this might be the reason why the est2genome prediction
>> using the EST sequence didn't go into the GFF3 file, as stated in a previous
>> email to the Maker-devel. I couldn't figure out how to test this, though. I
>> wonder if there's anything dramatically wrong that I've been doing to get
>> such odd results... If you'd like me to send you any output files or control
>> files, please let me know and I'll promptly pass those along.
>> 
>> Thank you very much for considering my email.
>> 
>> Sincerely,
>> 
>> Xin Huang
>> _______________________________________________ maker-devel mailing list
>> maker-devel at box290.bluehost.comhttp://box290.bluehost.com/mailman/listinfo/ma
>> ker-devel_yandell-lab.org
> 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://box290.bluehost.com/pipermail/maker-devel_yandell-lab.org/attachments/20131113/4d20127f/attachment.html>

From cjfields at illinois.edu  Wed Nov 13 21:51:36 2013
From: cjfields at illinois.edu (Fields, Christopher J)
Date: Thu, 14 Nov 2013 03:51:36 +0000
Subject: [maker-devel] Odd missing label bug
Message-ID: <73A19C36-ABA1-4A03-8D66-2A7F5574C386@illinois.edu>

I?m seeing an odd bug in GFF output where the label is being sporadically left off some child ?match_part' features.  This is when using maker-2.30p.  I found this while splitting out the data by source as individual tracks for IGV viewing; I have several sets of ESTs from individuals of the same species, so I have them labeled (from maker_opts):

est=./ESTs/Trinity_1128_v2_combined_pr2.clean.fasta:strain_1128
protein=./ESTs/xeno/Taeniopygia_guttata.taeGut3.2.4.73.pep.all.fa:TaeGut,./ESTs/xeno/Ficedula_albicollis.FicAlb_1.4.73.pep.all.fa:FicAlb

I planned on separating these into separate tracks, one for each BLASTX, BLASTN, etc.  

After a test run on a few scaffolds, a small number of the BLASTX and BLASTN look like this:

KB913263.1      blastx:TaeGut   protein_match   374736  401929  330     -       .       ID=KB913263.1:hit:9:3.10.0.3;Name=ENSTGUP00000000074
KB913263.1      blastx  match_part      401756  401929  312     -       .       ID=KB913263.1:hsp:55:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M58;Target=ENSTGUP00000000074 1 58
KB913263.1      blastx  match_part      394486  394665  186     -       .       ID=KB913263.1:hsp:56:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M42 D9 M9;Target=ENSTGUP00000000074 56 106
KB913263.1      blastx  match_part      392059  392178  204     -       .       ID=KB913263.1:hsp:57:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M40;Target=ENSTGUP00000000074 97 136
KB913263.1      blastx  match_part      387479  387547  116     -       .       ID=KB913263.1:hsp:58:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M23;Target=ENSTGUP00000000074 151 173
KB913263.1      blastx  match_part      383644  383742  156     -       .       ID=KB913263.1:hsp:59:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M33;Target=ENSTGUP00000000074 172 204
KB913263.1      blastx  match_part      382860  383063  242     -       .       ID=KB913263.1:hsp:60:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M68;Target=ENSTGUP00000000074 193 260
KB913263.1      blastx  match_part      382538  382648  186     -       .       ID=KB913263.1:hsp:61:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M37;Target=ENSTGUP00000000074 247 283
KB913263.1      blastx  match_part      382072  382236  268     -       .       ID=KB913263.1:hsp:62:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M55;Target=ENSTGUP00000000074 282 336
KB913263.1      blastx  match_part      379270  379458  330     -       .       ID=KB913263.1:hsp:63:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M63;Target=ENSTGUP00000000074 336 398
KB913263.1      blastx  match_part      374736  374900  147     -       .       ID=KB913263.1:hsp:64:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M55;Target=ENSTGUP00000000074 4 58

Note the missing label in the source column for the ?match_part? types.  Strangely, only a small # have this problem, but the exact same ones appear to be consistently popping up on repeated runs (this is from a test prior to a full launch using openmpi).  It does seem like only child ?match_part? appears affected.

Any ideas?

chris


From carsonhh at gmail.com  Wed Nov 13 21:58:32 2013
From: carsonhh at gmail.com (Carson Holt)
Date: Wed, 13 Nov 2013 20:58:32 -0700
Subject: [maker-devel] Odd missing label bug
In-Reply-To: <73A19C36-ABA1-4A03-8D66-2A7F5574C386@illinois.edu>
Message-ID: <CEA9978B.6BB3%carsonhh@gmail.com>

Could you put a contig and protein fasta into a test job that I could run
on?  Based on the hit position I imagine this may only happens when the
alignments spans two chunks (by default MAKER splits the input config into
100,000bp chunks).  The hit runs from 374736-401929.

?Carson


On 11/13/13, 8:51 PM, "Fields, Christopher J" <cjfields at illinois.edu>
wrote:

>I?m seeing an odd bug in GFF output where the label is being sporadically
>left off some child ?match_part' features.  This is when using
>maker-2.30p.  I found this while splitting out the data by source as
>individual tracks for IGV viewing; I have several sets of ESTs from
>individuals of the same species, so I have them labeled (from maker_opts):
>
>est=./ESTs/Trinity_1128_v2_combined_pr2.clean.fasta:strain_1128
>protein=./ESTs/xeno/Taeniopygia_guttata.taeGut3.2.4.73.pep.all.fa:TaeGut,.
>/ESTs/xeno/Ficedula_albicollis.FicAlb_1.4.73.pep.all.fa:FicAlb
>
>I planned on separating these into separate tracks, one for each BLASTX,
>BLASTN, etc.  
>
>After a test run on a few scaffolds, a small number of the BLASTX and
>BLASTN look like this:
>
>KB913263.1      blastx:TaeGut   protein_match   374736  401929  330     -
>      .       ID=KB913263.1:hit:9:3.10.0.3;Name=ENSTGUP00000000074
>KB913263.1      blastx  match_part      401756  401929  312     -       .
>      
>ID=KB913263.1:hsp:55:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M58;Tar
>get=ENSTGUP00000000074 1 58
>KB913263.1      blastx  match_part      394486  394665  186     -       .
>      
>ID=KB913263.1:hsp:56:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M42 D9
>M9;Target=ENSTGUP00000000074 56 106
>KB913263.1      blastx  match_part      392059  392178  204     -       .
>      
>ID=KB913263.1:hsp:57:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M40;Tar
>get=ENSTGUP00000000074 97 136
>KB913263.1      blastx  match_part      387479  387547  116     -       .
>      
>ID=KB913263.1:hsp:58:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M23;Tar
>get=ENSTGUP00000000074 151 173
>KB913263.1      blastx  match_part      383644  383742  156     -       .
>      
>ID=KB913263.1:hsp:59:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M33;Tar
>get=ENSTGUP00000000074 172 204
>KB913263.1      blastx  match_part      382860  383063  242     -       .
>      
>ID=KB913263.1:hsp:60:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M68;Tar
>get=ENSTGUP00000000074 193 260
>KB913263.1      blastx  match_part      382538  382648  186     -       .
>      
>ID=KB913263.1:hsp:61:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M37;Tar
>get=ENSTGUP00000000074 247 283
>KB913263.1      blastx  match_part      382072  382236  268     -       .
>      
>ID=KB913263.1:hsp:62:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M55;Tar
>get=ENSTGUP00000000074 282 336
>KB913263.1      blastx  match_part      379270  379458  330     -       .
>      
>ID=KB913263.1:hsp:63:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M63;Tar
>get=ENSTGUP00000000074 336 398
>KB913263.1      blastx  match_part      374736  374900  147     -       .
>      
>ID=KB913263.1:hsp:64:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M55;Tar
>get=ENSTGUP00000000074 4 58
>
>Note the missing label in the source column for the ?match_part? types.
>Strangely, only a small # have this problem, but the exact same ones
>appear to be consistently popping up on repeated runs (this is from a
>test prior to a full launch using openmpi).  It does seem like only child
>?match_part? appears affected.
>
>Any ideas?
>
>chris
>_______________________________________________
>maker-devel mailing list
>maker-devel at box290.bluehost.com
>http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org





From cjfields at illinois.edu  Wed Nov 13 22:20:46 2013
From: cjfields at illinois.edu (Fields, Christopher J)
Date: Thu, 14 Nov 2013 04:20:46 +0000
Subject: [maker-devel] Odd missing label bug
In-Reply-To: <CEA9978B.6BB3%carsonhh@gmail.com>
References: <CEA9978B.6BB3%carsonhh@gmail.com>
Message-ID: <6E70C69F-BAFD-4C9E-9293-04DB656B2A09@illinois.edu>

Yeah, that seems to be it (crossing around 100kbp increments).  I?ll run a reduced example set locally to make sure and will send.

-c

On Nov 13, 2013, at 9:58 PM, Carson Holt <carsonhh at gmail.com> wrote:

> Could you put a contig and protein fasta into a test job that I could run
> on?  Based on the hit position I imagine this may only happens when the
> alignments spans two chunks (by default MAKER splits the input config into
> 100,000bp chunks).  The hit runs from 374736-401929.
> 
> <Carson
> 
> 
> On 11/13/13, 8:51 PM, "Fields, Christopher J" <cjfields at illinois.edu>
> wrote:
> 
>> I?m seeing an odd bug in GFF output where the label is being sporadically
>> left off some child Omatch_part' features.  This is when using
>> maker-2.30p.  I found this while splitting out the data by source as
>> individual tracks for IGV viewing; I have several sets of ESTs from
>> individuals of the same species, so I have them labeled (from maker_opts):
>> 
>> est=./ESTs/Trinity_1128_v2_combined_pr2.clean.fasta:strain_1128
>> protein=./ESTs/xeno/Taeniopygia_guttata.taeGut3.2.4.73.pep.all.fa:TaeGut,.
>> /ESTs/xeno/Ficedula_albicollis.FicAlb_1.4.73.pep.all.fa:FicAlb
>> 
>> I planned on separating these into separate tracks, one for each BLASTX,
>> BLASTN, etc.  
>> 
>> After a test run on a few scaffolds, a small number of the BLASTX and
>> BLASTN look like this:
>> 
>> KB913263.1      blastx:TaeGut   protein_match   374736  401929  330     -
>>     .       ID=KB913263.1:hit:9:3.10.0.3;Name=ENSTGUP00000000074
>> KB913263.1      blastx  match_part      401756  401929  312     -       .
>> 
>> ID=KB913263.1:hsp:55:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M58;Tar
>> get=ENSTGUP00000000074 1 58
>> KB913263.1      blastx  match_part      394486  394665  186     -       .
>> 
>> ID=KB913263.1:hsp:56:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M42 D9
>> M9;Target=ENSTGUP00000000074 56 106
>> KB913263.1      blastx  match_part      392059  392178  204     -       .
>> 
>> ID=KB913263.1:hsp:57:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M40;Tar
>> get=ENSTGUP00000000074 97 136
>> KB913263.1      blastx  match_part      387479  387547  116     -       .
>> 
>> ID=KB913263.1:hsp:58:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M23;Tar
>> get=ENSTGUP00000000074 151 173
>> KB913263.1      blastx  match_part      383644  383742  156     -       .
>> 
>> ID=KB913263.1:hsp:59:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M33;Tar
>> get=ENSTGUP00000000074 172 204
>> KB913263.1      blastx  match_part      382860  383063  242     -       .
>> 
>> ID=KB913263.1:hsp:60:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M68;Tar
>> get=ENSTGUP00000000074 193 260
>> KB913263.1      blastx  match_part      382538  382648  186     -       .
>> 
>> ID=KB913263.1:hsp:61:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M37;Tar
>> get=ENSTGUP00000000074 247 283
>> KB913263.1      blastx  match_part      382072  382236  268     -       .
>> 
>> ID=KB913263.1:hsp:62:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M55;Tar
>> get=ENSTGUP00000000074 282 336
>> KB913263.1      blastx  match_part      379270  379458  330     -       .
>> 
>> ID=KB913263.1:hsp:63:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M63;Tar
>> get=ENSTGUP00000000074 336 398
>> KB913263.1      blastx  match_part      374736  374900  147     -       .
>> 
>> ID=KB913263.1:hsp:64:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M55;Tar
>> get=ENSTGUP00000000074 4 58
>> 
>> Note the missing label in the source column for the Omatch_part? types.
>> Strangely, only a small # have this problem, but the exact same ones
>> appear to be consistently popping up on repeated runs (this is from a
>> test prior to a full launch using openmpi).  It does seem like only child
>> Omatch_part? appears affected.
>> 
>> Any ideas?
>> 
>> chris
>> _______________________________________________
>> maker-devel mailing list
>> maker-devel at box290.bluehost.com
>> http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
> 
> 




From kpepin at genome.wustl.edu  Thu Nov 14 06:51:54 2013
From: kpepin at genome.wustl.edu (Kymberlie Hallsworth-Pepin)
Date: Thu, 14 Nov 2013 06:51:54 -0600 (CST)
Subject: [maker-devel] re-annotation
In-Reply-To: <CEA953DA.6B86%carsonhh@gmail.com>
References: <CEA953DA.6B86%carsonhh@gmail.com>
Message-ID: <alpine.DEB.2.00.1311140650400.28492@linus40.gsc.wustl.edu>


The new version and the change in the model gff to exon/cds did the trick.
thanks for the info.
Kym


On Wed, 13 Nov 2013, Carson Holt wrote:

> model_gff must be gene/mRNA/exon/CDS. pred_gff can be match/match_part or
> gene/mRNA/exon/CDS.  Also model_gff always should make it into the final
> result (unless replaced by something better) and will not be modified.  It
> also affects clustering.  pref_gff will only make it into the final
> results if it is supported by evidence.
>
> ?Carson
>
>
> On 11/13/13, 8:15 AM, "Kymberlie Hallsworth-Pepin"
> <kpepin at genome.wustl.edu> wrote:
>
>>
>>
>> Will do. Is there a difference between how the model_gff file and the
>> pred_gff file use the match/match_part of CDS/mRNA designations and which
>> is the best to use for model_gff input?
>>
>> On Wed, 13 Nov 2013, Carson Holt wrote:
>>
>>> So map_forward=1, will only maintain names derived from model_gff onto
>>> new
>>> or updated models.  Could you try either 2.28 or 2.30-beta, just to see
>>> if
>>> this is something that is already fixed.
>>>
>>> Thanks,
>>> Carson
>>>
>>
>> ____
>> This email message is a private communication. The information
>> transmitted, including attachments, is intended only for the person or
>> entity to which it is addressed and may contain confidential, privileged,
>> and/or proprietary material. Any review, duplication, retransmission,
>> distribution, or other use of, or taking of any action in reliance upon,
>> this information by persons or entities other than the intended recipient
>> is unauthorized by the sender and is prohibited. If you have received
>> this message in error, please contact the sender immediately by return
>> email and delete the original message from all computer systems. Thank
>> you.
>

____
This email message is a private communication. The information transmitted, including attachments, is intended only for the person or entity to which it is addressed and may contain confidential, privileged, and/or proprietary material. Any review, duplication, retransmission, distribution, or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is unauthorized by the sender and is prohibited. If you have received this message in error, please contact the sender immediately by return email and delete the original message from all computer systems. Thank you.



From xh33 at georgetown.edu  Mon Nov 11 09:52:48 2013
From: xh33 at georgetown.edu (Xin Huang)
Date: Mon, 11 Nov 2013 10:52:48 -0500
Subject: [maker-devel] A suspected strange behavior of Maker...
In-Reply-To: <CEA5B2C9.69F9%carsonhh@gmail.com>
References: <CACvYrQGP1dajOYyhiTDt6QuzCHdVR21vLYzmbtMKvF67d-fMiA@mail.gmail.com>
	<CEA5B2C9.69F9%carsonhh@gmail.com>
Message-ID: <CACvYrQGf+QwTcbWEOLX0igUZWcByu-E2d8YD4m2ykzCGr_aJ-w@mail.gmail.com>

Hi Carson,

Thank you very much for getting back to me on this. Sorry I was too quick
to jump to a suspicion! Thanks for pointing it out and please see attached
the EST (face_cDNA.fa) and genome scaffold sequences
(albo_scaf3928+5347_for_face_cDNA.fa) I used for Maker. We used blastn to
identify these two scaffolds for this cDNA sequence, and exonerate result
also showed that this cDNA can be aligned to the scaffolds.

Thanks!

Xin


On Mon, Nov 11, 2013 at 12:10 AM, Carson Holt <carsonhh at gmail.com> wrote:

> Sorry for the slow reply, I was moving from Canada to the US, got sick,
> and my moving truck got delayed one week. So I fell behind on the maker
> list.
>
> What you observe is correct behavior.  The config is blasted against the
> database of ESTs/proteins.  It really doesn't matter which way you blast,
> you pick the direction that is most efficient for the question you are
> asking, and you only have to adjust the Z value for database size if you
> want alignment scores to be reproducible both ways.
>
> Not getting results means they were filtered out for some reason (you
> don't even have blastn results in your output).  If you can send a test
> dataset I can take a look and tell you which filter.
>
> Thanks,
> Carson
>
>
> From: Xin Huang <xh33 at georgetown.edu>
> Date: Tuesday, November 5, 2013 2:40 PM
> To: <maker-devel at yandell-lab.org>
> Subject: [maker-devel] A suspected strange behavior of Maker...
>
> Hi,
>
> I found a very bizarre thing when I ran Maker several times. The blastn
> research seems to reverse query and subject the way it's specified in the
> maker_opts.ctl file. When I put the scaffold sequence after genome= and the
> cDNA sequence after est=, the blastn result actually used the scaffold as
> query and the cDNA as subject. I realized that this sounds unreal, so I
> reversed the places for the two and the blastn result is normal with the
> cDNA as query and the scaffold as subject, but at the same time, the GFF
> file is of the cDNA sequence. I tried a few times, and got the same result.
> I deleted Maker (2.28) and reinstalled the beta version (2.30), still
> getting the same result.
>
> My wild guess was that this might be the reason why the est2genome
> prediction using the EST sequence didn't go into the GFF3 file, as stated
> in a previous email to the Maker-devel. I couldn't figure out how to test
> this, though. I wonder if there's anything dramatically wrong that I've
> been doing to get such odd results... If you'd like me to send you any
> output files or control files, please let me know and I'll promptly pass
> those along.
>
> Thank you very much for considering my email.
>
> Sincerely,
>
> Xin Huang
> _______________________________________________ maker-devel mailing list
> maker-devel at box290.bluehost.com
> http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://box290.bluehost.com/pipermail/maker-devel_yandell-lab.org/attachments/20131111/aeac9298/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: face_cDNA.fa
Type: application/octet-stream
Size: 1977 bytes
Desc: not available
URL: <http://box290.bluehost.com/pipermail/maker-devel_yandell-lab.org/attachments/20131111/aeac9298/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: albo_scaf3928+5347_for_face_cDNA.fa
Type: application/octet-stream
Size: 306492 bytes
Desc: not available
URL: <http://box290.bluehost.com/pipermail/maker-devel_yandell-lab.org/attachments/20131111/aeac9298/attachment-0001.obj>

From ejr at stowers.org  Mon Nov 18 14:24:03 2013
From: ejr at stowers.org (Ross, Eric)
Date: Mon, 18 Nov 2013 20:24:03 +0000
Subject: [maker-devel] gff3_merge error - only half the contigs are
 reported
Message-ID: <CEAFD381.2B146%ejr@stowers.org>

I had the same problem Sujai reported  on the 25th.

When I run gff3_merge I only get back results from a subset of my
scaffolds.  Every scaffold has a gff file in the data store.  fasta_merge
works fine.  No errors are printed to STDOUT.

It took me some poking around, but this seems that if there is
insufficient space in /tmp to generate the temporary files merge_gff3
completes without error and just creates a gff file from whatever fit in
the temporary files.  I'm not sure why tempfile() doesn't return a useful
error.  

I was able to get around the error by setting the environment variable
TMPDIR to someplace with sufficient space, but if there is a way to
generate a useful error it might be worth adding.


Eric




--original below--
On Friday, October 25, 2013 11:22:08 AM UTC-5, Barry wrote:
Hi Sujai,
If you still have that original directory available a couple things you to
try:

# Does this give you the number of contigs you're expecting?
find datastore_directory -name '*.gff3' | wc -l

# If the above gives what you expect what does the file size look like on
the smallest files?
find ./ -type f | xargs ls -Sl | tail

Barry

On Oct 24, 2013, at 4:04 PM, Sujai wrote:


Hi Barry

The last stderr message in the job is from the maker command:

Maker is now finished!!!

my last 3 commands were (in my pbs/torque job script):

----job script----
...other commands to set variables etc...
mpiexec -n 12 maker -g $SPLITFILE -base $SPLITFILE maker_opts.ctl
maker_bopts.ctl maker_exe.ctl
gff3_merge -o $PBS_O_WORKDIR/$SPLITFILE.gff3 -d
$SPLITFILE.maker.output/${SPLITFILE}_master_datastore_index.log
fasta_merge -d 
$SPLITFILE.maker.output/${SPLITFILE}_master_datastore_index.log
-----

so, no gff3_merge stderr messages
the fasta_merge command (which came after gff3_merge) has completed
correctly, with all proteins and transcripts accounted for.
I just ran the same contigs again in smaller batches, and it seems to be
proceeding correctly (the final gff3 files are between 49-55MB for each
chunk of fasta files. In the previous case, the final GFF3 file was 99MB
or 100MB (which is why I thought there was some sort of filesize/memory
limit)

Thanks for looking into this,

- Sujai




On 24 October 2013 21:42, Barry Moore <barry... at genetics.utah.edu <>>
wrote:

Hi Sujai,
There are a couple of fatal errors that can be thrown by gff3_merge if it
encounters errors.  Did you capture STDERR and do you see any failures
there?

B

On Oct 24, 2013, at 10:43 AM, Sujai wrote:




Hi all
First of all, thank you to Carson Holt and Mark Yandell and team for an
excellent program with excellent installation instructions. Setting maker
2.28 up and running it (both with MPI and without) was a breeze on a PBS
cluster. Everything worked as expected (doesn't happen that often in
bioinformatics software! :-))

I did a test run on 150 longish contigs (>50kb each) and everything worked
fine, including gff3_merge, fasta_merge etc. I got predictions for all the
contigs etc.


However, when I ran it on the full 20,000 sequence file (minimum 300 bp, I
know - I could have set the min length in maker_opts.ctl but I wanted the
repeatmasker analysis done even for the smaller contigs), I had a problem:

1. the intermediate files were all fine (i.e. grep -c FINISHED
...master_datastore_index.log showed the right number of sequences)

2. But gff3_merge -d ...master_datastore_index.log  only gave a file with
about 9000 contigs. I ran it a few times and got the same result each
time. fasta_merge gave back sequences from all ~20,000 contigs, so I know
the contig_datastore was fine.

3. Could it be that gff3_merge hit some sort of output limit? the GFF3
file created seems to be almost exactly 100MB. Or could it be a limit of
my OS environment? I had a lot of memory (12 GB) and a large tmp directory
(10 GB) so that should not be a problem...

If anyone has seen this problem or can shed any light on this, that would
be great.

I'm going to try splitting the file into smaller sets and hoping for the
best.

Thanks

- Sujai




-- 
You received this message because you are subscribed to the Google Groups
"maker-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to maker-devel... at googlegroups.com <>.
To post to this group, send email to maker... at googlegroups.com <>.
Visit this group at http://groups.google.com/group/maker-devel.
For more options, visit https://groups.google.com/groups/opt_out.




Barry Moore
Research Scientist
Dept. of Human Genetics
University of Utah
Salt Lake City, UT 84112
--------------------------------------------
(801) 585-3543









-- 
You received this message because you are subscribed to a topic in the
Google Groups "maker-devel" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/maker-devel/bApnLPFgmRc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
maker-devel... at googlegroups.com <>.
To post to this group, send email to maker... at googlegroups.com <>.
Visit this group at http://groups.google.com/group/maker-devel.
For more options, visit https://groups.google.com/groups/opt_out.






-- 
You received this message because you are subscribed to the Google Groups
"maker-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to maker-devel... at googlegroups.com <>.
To post to this group, send email to maker... at googlegroups.com <>.
Visit this group at http://groups.google.com/group/maker-devel.
For more options, visit https://groups.google.com/groups/opt_out.




Barry Moore
Research Scientist
Dept. of Human Genetics
University of Utah
Salt Lake City, UT 84112
--------------------------------------------
(801) 585-3543











On Friday, October 25, 2013 11:22:08 AM UTC-5, Barry wrote:
Hi Sujai,
If you still have that original directory available a couple things you to
try:

# Does this give you the number of contigs you're expecting?
find datastore_directory -name '*.gff3' | wc -l

# If the above gives what you expect what does the file size look like on
the smallest files?
find ./ -type f | xargs ls -Sl | tail

Barry

On Oct 24, 2013, at 4:04 PM, Sujai wrote:


Hi Barry

The last stderr message in the job is from the maker command:

Maker is now finished!!!

my last 3 commands were (in my pbs/torque job script):

----job script----
...other commands to set variables etc...
mpiexec -n 12 maker -g $SPLITFILE -base $SPLITFILE maker_opts.ctl
maker_bopts.ctl maker_exe.ctl
gff3_merge -o $PBS_O_WORKDIR/$SPLITFILE.gff3 -d
$SPLITFILE.maker.output/${SPLITFILE}_master_datastore_index.log
fasta_merge -d 
$SPLITFILE.maker.output/${SPLITFILE}_master_datastore_index.log
-----

so, no gff3_merge stderr messages
the fasta_merge command (which came after gff3_merge) has completed
correctly, with all proteins and transcripts accounted for.
I just ran the same contigs again in smaller batches, and it seems to be
proceeding correctly (the final gff3 files are between 49-55MB for each
chunk of fasta files. In the previous case, the final GFF3 file was 99MB
or 100MB (which is why I thought there was some sort of filesize/memory
limit)

Thanks for looking into this,

- Sujai




On 24 October 2013 21:42, Barry Moore <barry... at genetics.utah.edu <>>
wrote:

Hi Sujai,
There are a couple of fatal errors that can be thrown by gff3_merge if it
encounters errors.  Did you capture STDERR and do you see any failures
there?

B

On Oct 24, 2013, at 10:43 AM, Sujai wrote:




Hi all
First of all, thank you to Carson Holt and Mark Yandell and team for an
excellent program with excellent installation instructions. Setting maker
2.28 up and running it (both with MPI and without) was a breeze on a PBS
cluster. Everything worked as expected (doesn't happen that often in
bioinformatics software! :-))

I did a test run on 150 longish contigs (>50kb each) and everything worked
fine, including gff3_merge, fasta_merge etc. I got predictions for all the
contigs etc.


However, when I ran it on the full 20,000 sequence file (minimum 300 bp, I
know - I could have set the min length in maker_opts.ctl but I wanted the
repeatmasker analysis done even for the smaller contigs), I had a problem:

1. the intermediate files were all fine (i.e. grep -c FINISHED
...master_datastore_index.log showed the right number of sequences)

2. But gff3_merge -d ...master_datastore_index.log  only gave a file with
about 9000 contigs. I ran it a few times and got the same result each
time. fasta_merge gave back sequences from all ~20,000 contigs, so I know
the contig_datastore was fine.

3. Could it be that gff3_merge hit some sort of output limit? the GFF3
file created seems to be almost exactly 100MB. Or could it be a limit of
my OS environment? I had a lot of memory (12 GB) and a large tmp directory
(10 GB) so that should not be a problem...

If anyone has seen this problem or can shed any light on this, that would
be great.

I'm going to try splitting the file into smaller sets and hoping for the
best.

Thanks

- Sujai




-- 
You received this message because you are subscribed to the Google Groups
"maker-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to maker-devel... at googlegroups.com <>.
To post to this group, send email to maker... at googlegroups.com <>.
Visit this group at http://groups.google.com/group/maker-devel.
For more options, visit https://groups.google.com/groups/opt_out.




Barry Moore
Research Scientist
Dept. of Human Genetics
University of Utah
Salt Lake City, UT 84112
--------------------------------------------
(801) 585-3543









-- 
You received this message because you are subscribed to a topic in the
Google Groups "maker-devel" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/maker-devel/bApnLPFgmRc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
maker-devel... at googlegroups.com <>.
To post to this group, send email to maker... at googlegroups.com <>.
Visit this group at http://groups.google.com/group/maker-devel.
For more options, visit https://groups.google.com/groups/opt_out.






-- 
You received this message because you are subscribed to the Google Groups
"maker-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to maker-devel... at googlegroups.com <>.
To post to this group, send email to maker... at googlegroups.com <>.
Visit this group at http://groups.google.com/group/maker-devel.
For more options, visit https://groups.google.com/groups/opt_out.




Barry Moore
Research Scientist
Dept. of Human Genetics
University of Utah
Salt Lake City, UT 84112
--------------------------------------------
(801) 585-3543














From sujaikumar at gmail.com  Tue Nov 19 02:33:06 2013
From: sujaikumar at gmail.com (Sujai)
Date: Tue, 19 Nov 2013 08:33:06 +0000
Subject: [maker-devel] gff3_merge error - only half the contigs are
	reported
In-Reply-To: <CEAFD381.2B146%ejr@stowers.org>
References: <CEAFD381.2B146%ejr@stowers.org>
Message-ID: <CAFADFFu7Re=kRTB6qbS3qjhAEGQ0DmbJeJ3wPBq-QonM9VYDtQ@mail.gmail.com>

Hi Eric

Thanks for uncovering the /tmp limitation. I had changed TMPDIR in my
maker_opts.ctl file, but I suppose gff3_merge would not use that setting,
and would use /tmp or whatever TMPDIR was set to in the current shell.

Cheers,

- Sujai



On 18 November 2013 20:24, Ross, Eric <ejr at stowers.org> wrote:

> I had the same problem Sujai reported  on the 25th.
>
> When I run gff3_merge I only get back results from a subset of my
> scaffolds.  Every scaffold has a gff file in the data store.  fasta_merge
> works fine.  No errors are printed to STDOUT.
>
> It took me some poking around, but this seems that if there is
> insufficient space in /tmp to generate the temporary files merge_gff3
> completes without error and just creates a gff file from whatever fit in
> the temporary files.  I'm not sure why tempfile() doesn't return a useful
> error.
>
> I was able to get around the error by setting the environment variable
> TMPDIR to someplace with sufficient space, but if there is a way to
> generate a useful error it might be worth adding.
>
>
> Eric
>
>
>
>
> --original below--
> On Friday, October 25, 2013 11:22:08 AM UTC-5, Barry wrote:
> Hi Sujai,
> If you still have that original directory available a couple things you to
> try:
>
> # Does this give you the number of contigs you're expecting?
> find datastore_directory -name '*.gff3' | wc -l
>
> # If the above gives what you expect what does the file size look like on
> the smallest files?
> find ./ -type f | xargs ls -Sl | tail
>
> Barry
>
> On Oct 24, 2013, at 4:04 PM, Sujai wrote:
>
>
> Hi Barry
>
> The last stderr message in the job is from the maker command:
>
> Maker is now finished!!!
>
> my last 3 commands were (in my pbs/torque job script):
>
> ----job script----
> ...other commands to set variables etc...
> mpiexec -n 12 maker -g $SPLITFILE -base $SPLITFILE maker_opts.ctl
> maker_bopts.ctl maker_exe.ctl
> gff3_merge -o $PBS_O_WORKDIR/$SPLITFILE.gff3 -d
> $SPLITFILE.maker.output/${SPLITFILE}_master_datastore_index.log
> fasta_merge -d
> $SPLITFILE.maker.output/${SPLITFILE}_master_datastore_index.log
> -----
>
> so, no gff3_merge stderr messages
> the fasta_merge command (which came after gff3_merge) has completed
> correctly, with all proteins and transcripts accounted for.
> I just ran the same contigs again in smaller batches, and it seems to be
> proceeding correctly (the final gff3 files are between 49-55MB for each
> chunk of fasta files. In the previous case, the final GFF3 file was 99MB
> or 100MB (which is why I thought there was some sort of filesize/memory
> limit)
>
> Thanks for looking into this,
>
> - Sujai
>
>
>
>
> On 24 October 2013 21:42, Barry Moore <barry... at genetics.utah.edu <>>
> wrote:
>
> Hi Sujai,
> There are a couple of fatal errors that can be thrown by gff3_merge if it
> encounters errors.  Did you capture STDERR and do you see any failures
> there?
>
> B
>
> On Oct 24, 2013, at 10:43 AM, Sujai wrote:
>
>
>
>
> Hi all
> First of all, thank you to Carson Holt and Mark Yandell and team for an
> excellent program with excellent installation instructions. Setting maker
> 2.28 up and running it (both with MPI and without) was a breeze on a PBS
> cluster. Everything worked as expected (doesn't happen that often in
> bioinformatics software! :-))
>
> I did a test run on 150 longish contigs (>50kb each) and everything worked
> fine, including gff3_merge, fasta_merge etc. I got predictions for all the
> contigs etc.
>
>
> However, when I ran it on the full 20,000 sequence file (minimum 300 bp, I
> know - I could have set the min length in maker_opts.ctl but I wanted the
> repeatmasker analysis done even for the smaller contigs), I had a problem:
>
> 1. the intermediate files were all fine (i.e. grep -c FINISHED
> ...master_datastore_index.log showed the right number of sequences)
>
> 2. But gff3_merge -d ...master_datastore_index.log  only gave a file with
> about 9000 contigs. I ran it a few times and got the same result each
> time. fasta_merge gave back sequences from all ~20,000 contigs, so I know
> the contig_datastore was fine.
>
> 3. Could it be that gff3_merge hit some sort of output limit? the GFF3
> file created seems to be almost exactly 100MB. Or could it be a limit of
> my OS environment? I had a lot of memory (12 GB) and a large tmp directory
> (10 GB) so that should not be a problem...
>
> If anyone has seen this problem or can shed any light on this, that would
> be great.
>
> I'm going to try splitting the file into smaller sets and hoping for the
> best.
>
> Thanks
>
> - Sujai
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "maker-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to maker-devel... at googlegroups.com <>.
> To post to this group, send email to maker... at googlegroups.com <>.
> Visit this group at http://groups.google.com/group/maker-devel.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
> Barry Moore
> Research Scientist
> Dept. of Human Genetics
> University of Utah
> Salt Lake City, UT 84112
> --------------------------------------------
> (801) 585-3543
>
>
>
>
>
>
>
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "maker-devel" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/maker-devel/bApnLPFgmRc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> maker-devel... at googlegroups.com <>.
> To post to this group, send email to maker... at googlegroups.com <>.
> Visit this group at http://groups.google.com/group/maker-devel.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "maker-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to maker-devel... at googlegroups.com <>.
> To post to this group, send email to maker... at googlegroups.com <>.
> Visit this group at http://groups.google.com/group/maker-devel.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
> Barry Moore
> Research Scientist
> Dept. of Human Genetics
> University of Utah
> Salt Lake City, UT 84112
> --------------------------------------------
> (801) 585-3543
>
>
>
>
>
>
>
>
>
>
>
> On Friday, October 25, 2013 11:22:08 AM UTC-5, Barry wrote:
> Hi Sujai,
> If you still have that original directory available a couple things you to
> try:
>
> # Does this give you the number of contigs you're expecting?
> find datastore_directory -name '*.gff3' | wc -l
>
> # If the above gives what you expect what does the file size look like on
> the smallest files?
> find ./ -type f | xargs ls -Sl | tail
>
> Barry
>
> On Oct 24, 2013, at 4:04 PM, Sujai wrote:
>
>
> Hi Barry
>
> The last stderr message in the job is from the maker command:
>
> Maker is now finished!!!
>
> my last 3 commands were (in my pbs/torque job script):
>
> ----job script----
> ...other commands to set variables etc...
> mpiexec -n 12 maker -g $SPLITFILE -base $SPLITFILE maker_opts.ctl
> maker_bopts.ctl maker_exe.ctl
> gff3_merge -o $PBS_O_WORKDIR/$SPLITFILE.gff3 -d
> $SPLITFILE.maker.output/${SPLITFILE}_master_datastore_index.log
> fasta_merge -d
> $SPLITFILE.maker.output/${SPLITFILE}_master_datastore_index.log
> -----
>
> so, no gff3_merge stderr messages
> the fasta_merge command (which came after gff3_merge) has completed
> correctly, with all proteins and transcripts accounted for.
> I just ran the same contigs again in smaller batches, and it seems to be
> proceeding correctly (the final gff3 files are between 49-55MB for each
> chunk of fasta files. In the previous case, the final GFF3 file was 99MB
> or 100MB (which is why I thought there was some sort of filesize/memory
> limit)
>
> Thanks for looking into this,
>
> - Sujai
>
>
>
>
> On 24 October 2013 21:42, Barry Moore <barry... at genetics.utah.edu <>>
> wrote:
>
> Hi Sujai,
> There are a couple of fatal errors that can be thrown by gff3_merge if it
> encounters errors.  Did you capture STDERR and do you see any failures
> there?
>
> B
>
> On Oct 24, 2013, at 10:43 AM, Sujai wrote:
>
>
>
>
> Hi all
> First of all, thank you to Carson Holt and Mark Yandell and team for an
> excellent program with excellent installation instructions. Setting maker
> 2.28 up and running it (both with MPI and without) was a breeze on a PBS
> cluster. Everything worked as expected (doesn't happen that often in
> bioinformatics software! :-))
>
> I did a test run on 150 longish contigs (>50kb each) and everything worked
> fine, including gff3_merge, fasta_merge etc. I got predictions for all the
> contigs etc.
>
>
> However, when I ran it on the full 20,000 sequence file (minimum 300 bp, I
> know - I could have set the min length in maker_opts.ctl but I wanted the
> repeatmasker analysis done even for the smaller contigs), I had a problem:
>
> 1. the intermediate files were all fine (i.e. grep -c FINISHED
> ...master_datastore_index.log showed the right number of sequences)
>
> 2. But gff3_merge -d ...master_datastore_index.log  only gave a file with
> about 9000 contigs. I ran it a few times and got the same result each
> time. fasta_merge gave back sequences from all ~20,000 contigs, so I know
> the contig_datastore was fine.
>
> 3. Could it be that gff3_merge hit some sort of output limit? the GFF3
> file created seems to be almost exactly 100MB. Or could it be a limit of
> my OS environment? I had a lot of memory (12 GB) and a large tmp directory
> (10 GB) so that should not be a problem...
>
> If anyone has seen this problem or can shed any light on this, that would
> be great.
>
> I'm going to try splitting the file into smaller sets and hoping for the
> best.
>
> Thanks
>
> - Sujai
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "maker-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to maker-devel... at googlegroups.com <>.
> To post to this group, send email to maker... at googlegroups.com <>.
> Visit this group at http://groups.google.com/group/maker-devel.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
> Barry Moore
> Research Scientist
> Dept. of Human Genetics
> University of Utah
> Salt Lake City, UT 84112
> --------------------------------------------
> (801) 585-3543
>
>
>
>
>
>
>
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "maker-devel" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/maker-devel/bApnLPFgmRc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> maker-devel... at googlegroups.com <>.
> To post to this group, send email to maker... at googlegroups.com <>.
> Visit this group at http://groups.google.com/group/maker-devel.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "maker-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to maker-devel... at googlegroups.com <>.
> To post to this group, send email to maker... at googlegroups.com <>.
> Visit this group at http://groups.google.com/group/maker-devel.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
> Barry Moore
> Research Scientist
> Dept. of Human Genetics
> University of Utah
> Salt Lake City, UT 84112
> --------------------------------------------
> (801) 585-3543
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> maker-devel mailing list
> maker-devel at box290.bluehost.com
> http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://box290.bluehost.com/pipermail/maker-devel_yandell-lab.org/attachments/20131119/7daa435c/attachment.html>

From carson.holt at genetics.utah.edu  Tue Nov 26 09:38:10 2013
From: carson.holt at genetics.utah.edu (Carson Holt)
Date: Tue, 26 Nov 2013 15:38:10 +0000
Subject: [maker-devel] no protein or transcript fasta output
In-Reply-To: <CAKbGhzW-uqNtpEmoOG-ygf6au06gQSmZUfuGpd=1PtFTD9MLtQ@mail.gmail.com>
References: <CAKbGhzW-uqNtpEmoOG-ygf6au06gQSmZUfuGpd=1PtFTD9MLtQ@mail.gmail.com>
Message-ID: <CEBA0E41.7169%carson.holt@genetics.utah.edu>

What version are you running?

Thanks,
Carson


From: mun hua <mh.tan85 at gmail.com<mailto:mh.tan85 at gmail.com>>
Date: Tuesday, November 26, 2013 at 2:32 AM
To: <maker-devel at yandell-lab.org<mailto:maker-devel at yandell-lab.org>>
Subject: no protein or transcript fasta output

Hi,

I tried out the example outlined by Maker, on the dpp_contig dataset.
Upon running maker, it only generated the gff output file, and none of the protein or transcript fasta files. I've checked the logs but have not seen any obvious errors.
Does anyone have any idea on why this is for me?

Thanks,
MH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://box290.bluehost.com/pipermail/maker-devel_yandell-lab.org/attachments/20131126/3ec95f21/attachment.html>

From mh.tan85 at gmail.com  Tue Nov 26 03:32:04 2013
From: mh.tan85 at gmail.com (mun hua)
Date: Tue, 26 Nov 2013 17:32:04 +0800
Subject: [maker-devel] no protein or transcript fasta output
Message-ID: <CAKbGhzW-uqNtpEmoOG-ygf6au06gQSmZUfuGpd=1PtFTD9MLtQ@mail.gmail.com>

Hi,

I tried out the example outlined by Maker, on the dpp_contig dataset.
Upon running maker, it only generated the gff output file, and none of the
protein or transcript fasta files. I've checked the logs but have not seen
any obvious errors.
Does anyone have any idea on why this is for me?

Thanks,
MH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://box290.bluehost.com/pipermail/maker-devel_yandell-lab.org/attachments/20131126/8a6d4e21/attachment.html>

From mh.tan85 at gmail.com  Tue Nov 26 19:03:45 2013
From: mh.tan85 at gmail.com (mun hua)
Date: Wed, 27 Nov 2013 09:03:45 +0800
Subject: [maker-devel] no protein or transcript fasta output
In-Reply-To: <CEBA0E41.7169%carson.holt@genetics.utah.edu>
References: <CAKbGhzW-uqNtpEmoOG-ygf6au06gQSmZUfuGpd=1PtFTD9MLtQ@mail.gmail.com>
	<CEBA0E41.7169%carson.holt@genetics.utah.edu>
Message-ID: <CAKbGhzWYr-6Sx4hVEq-1bPeQ5fZgNWxeF+61KYWZ8+0F-jNKow@mail.gmail.com>

I'm running Maker v2.28.

I tried Maker with protein2genome=1 instead of the recommended est2genome=1
and I managed to get transcript and protein fasta sequences.
That is strange, since I supplied the config file with both
the dpp_est.fasta and dpp_protein.fasta files?


On Tue, Nov 26, 2013 at 11:38 PM, Carson Holt <carson.holt at genetics.utah.edu
> wrote:

>  What version are you running?
>
>  Thanks,
> Carson
>
>
>   From: mun hua <mh.tan85 at gmail.com>
> Date: Tuesday, November 26, 2013 at 2:32 AM
> To: <maker-devel at yandell-lab.org>
> Subject: no protein or transcript fasta output
>
>  Hi,
>
>  I tried out the example outlined by Maker, on the dpp_contig dataset.
> Upon running maker, it only generated the gff output file, and none of the
> protein or transcript fasta files. I've checked the logs but have not seen
> any obvious errors.
> Does anyone have any idea on why this is for me?
>
>  Thanks,
> MH
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://box290.bluehost.com/pipermail/maker-devel_yandell-lab.org/attachments/20131127/eb47d812/attachment.html>

From carsonhh at gmail.com  Sun Nov  3 20:16:03 2013
From: carsonhh at gmail.com (Carson Holt)
Date: Sun, 3 Nov 2013 20:16:03 -0700
Subject: [maker-devel] Serious Start Codon Problem
In-Reply-To: <CE8EE16A.212BC%graham.etherington@sainsbury-laboratory.ac.uk>
References: <CE7FA55D.10C4B%carsonhh@gmail.com>
	<CE8EE16A.212BC%graham.etherington@sainsbury-laboratory.ac.uk>
Message-ID: <CA+sW3ERmNDH2kO6616yLGZS3iJ2Z0XEUu_qL++iHN8HVo3_reA@mail.gmail.com>

2.30 beta is now available for use.  Sorry about the delay, between moving
and getting seriously ill for several days, I sort of dropped off the grid
for 2 weeks.  Give this version a try.

Thanks,
Carson




On Thu, Oct 24, 2013 at 7:42 AM, graham etherington (TSL) <
graham.etherington at sainsbury-laboratory.ac.uk> wrote:

> Hi,
> I notice that the latest version of Maker available from
> http://www.yandell-lab.org/software/maker.html is still v2.29b (4 Oct
> 2013). As we're also having the start codon problem we'd like to get hold
> of v2.30. Do you know when this will be released?
> Many thanks,
> Graham
>
>
> Dr. Graham Etherington
> Bioinformatics Support Officer,
> The Sainsbury Laboratory,
> Norwich Research Park,
> Norwich NR4 7UH.
> UK
> Tel: +44 (0)1603 450601
>
>
>
>
>
> On 13/10/2013 06:26, "Carson Holt" <carsonhh at gmail.com> wrote:
>
> >Before Wednesday, because after that I'm on a 6 day road trip, so I have
> >to have it wrapped up before I leave.
> >
> >--Carson
> >
> >
> >
> >
> >On 10/12/13 12:16 PM, "Felix Bemm" <felix.bemm at uni-wuerzburg.de> wrote:
> >
> >>Thx Carson! Do you now when 2.30 will be available? Bests
> >>
> >>On 12.10.2013 17:48, Carson Holt wrote:
> >>> This issue just came up this week on another e-mail as well.
> >>>
> >>> One way to fix it, is to edit the Bio::Tools::CodonTable module from
> >>> BioPerl (use maker --debug to have maker print out the locations of all
> >>> modules it uses).  Such a hack should only be done as a temporary work
> >>> around.
> >>>
> >>> You change line 256 from -->
> >>> ---M---------------M---------------M----------------------------
> >>>
> >>> To-->
> >>> -----------------------------------M----------------------------
> >>>
> >>>
> >>> Maker uses the BioPerl is_start_codon function to determine if the
> >>>codon
> >>> used in a result it receives is acceptable or if it should look
> >>>upstream
> >>> or downstream for a different one. Apparently there are actually 3
> >>> acceptable start codons in the standard codon table (2 rare ones and
> >>>one
> >>> common), so making the edit removes the two rare ones from the list.
> >>>
> >>> I'm also preparing a 2.30 release that exports a "strict" codon table
> >>>to
> >>> the BioPerl module, that will be used by default and should fix the
> >>>issue.
> >>>
> >>> Thanks,
> >>> Carson
> >>>
> >>>
> >>>
> >>> On 10/12/13 11:06 AM, "Felix Bemm" <felix.bemm at uni-wuerzburg.de>
> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> I have a serious problems with maker annotations especially the start
> >>>> codon placement. It started happening with maker version 2.27! About
> >>>>1/3
> >>>> of my genes are missing a proper start codon. When reviewing the GFF
> >>>> files gene predictors and est evidence standalone would predict the
> >>>> right gene structure including the start codon. I was thinking that
> >>>>this
> >>>> problem was somehow linked to my gene models but looking at their
> >>>> standalone prediction I discarded that theory. Just some stats about
> >>>> proteins with proper start codon (first column) and missing start
> >>>>codon
> >>>> (second column).
> >>>>
> >>>> Maker              9268    4215
> >>>> SNAP               16577   896
> >>>> Genemark   18764   290
> >>>>
> >>>> Numbers look the same when Augustus is used (currently retraining).
> >>>> Manually using EST's in Apollo often fixes the problems but I don't
> >>>>want
> >>>> to check > 4000 genes for this.
> >>>>
> >>>> Do you have any idea what could cause such a problem? If you need some
> >>>> example gff files I can send you.
> >>>>
> >>>> Best regards
> >>>> Felix
> >>>>
> >>>> --
> >>>> Felix Bemm
> >>>> Department of Bioinformatics
> >>>> University of W?rzburg, Germany
> >>>> Tel: +49 931 - 31 83696
> >>>> Fax: +49 931 - 31 84552
> >>>> felix.bemm at uni-wuerzburg.de
> >>>>
> >>>> _______________________________________________
> >>>> maker-devel mailing list
> >>>> maker-devel at box290.bluehost.com
> >>>>
> >>>>
> http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
> >>
> >>--
> >>Felix Bemm
> >>Department of Bioinformatics
> >>University of W?rzburg, Germany
> >>Tel: +49 931 - 31 83696
> >>Fax: +49 931 - 31 84552
> >>felix.bemm at uni-wuerzburg.de
> >
> >
> >
> >_______________________________________________
> >maker-devel mailing list
> >maker-devel at box290.bluehost.com
> >http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131103/136b60b8/attachment-0001.html>

From jfierst at uoregon.edu  Mon Nov  4 09:50:36 2013
From: jfierst at uoregon.edu (Janna Fierst)
Date: Mon, 4 Nov 2013 08:50:36 -0800
Subject: [maker-devel] Serious Start Codon Problem
In-Reply-To: <CA+sW3ERmNDH2kO6616yLGZS3iJ2Z0XEUu_qL++iHN8HVo3_reA@mail.gmail.com>
References: <CE7FA55D.10C4B%carsonhh@gmail.com>
	<CE8EE16A.212BC%graham.etherington@sainsbury-laboratory.ac.uk>
	<CA+sW3ERmNDH2kO6616yLGZS3iJ2Z0XEUu_qL++iHN8HVo3_reA@mail.gmail.com>
Message-ID: <CAGoyurYpCrzcpZeTpYhaQZqZr5a8ZNwBs5UZ88+CPez1nhTA6w@mail.gmail.com>

Hi,

I can't get my message to post to the list but I had a problem with
2.29-beta in parallel - it seemed to restart the same scaffolds over and
over instead of moving on to a new set. I was running the same as the 2.28
version, is it something with our mpi system here at UO? Thanks -Janna
Fierst


On Sun, Nov 3, 2013 at 7:16 PM, Carson Holt <carsonhh at gmail.com> wrote:

> 2.30 beta is now available for use.  Sorry about the delay, between moving
> and getting seriously ill for several days, I sort of dropped off the grid
> for 2 weeks.  Give this version a try.
>
> Thanks,
> Carson
>
>
>
>
> On Thu, Oct 24, 2013 at 7:42 AM, graham etherington (TSL) <
> graham.etherington at sainsbury-laboratory.ac.uk> wrote:
>
>> Hi,
>> I notice that the latest version of Maker available from
>> http://www.yandell-lab.org/software/maker.html is still v2.29b (4 Oct
>> 2013). As we're also having the start codon problem we'd like to get hold
>> of v2.30. Do you know when this will be released?
>> Many thanks,
>> Graham
>>
>>
>> Dr. Graham Etherington
>> Bioinformatics Support Officer,
>> The Sainsbury Laboratory,
>> Norwich Research Park,
>> Norwich NR4 7UH.
>> UK
>> Tel: +44 (0)1603 450601
>>
>>
>>
>>
>>
>> On 13/10/2013 06:26, "Carson Holt" <carsonhh at gmail.com> wrote:
>>
>> >Before Wednesday, because after that I'm on a 6 day road trip, so I have
>> >to have it wrapped up before I leave.
>> >
>> >--Carson
>> >
>> >
>> >
>> >
>> >On 10/12/13 12:16 PM, "Felix Bemm" <felix.bemm at uni-wuerzburg.de> wrote:
>> >
>> >>Thx Carson! Do you now when 2.30 will be available? Bests
>> >>
>> >>On 12.10.2013 17:48, Carson Holt wrote:
>> >>> This issue just came up this week on another e-mail as well.
>> >>>
>> >>> One way to fix it, is to edit the Bio::Tools::CodonTable module from
>> >>> BioPerl (use maker --debug to have maker print out the locations of
>> all
>> >>> modules it uses).  Such a hack should only be done as a temporary work
>> >>> around.
>> >>>
>> >>> You change line 256 from -->
>> >>> ---M---------------M---------------M----------------------------
>> >>>
>> >>> To-->
>> >>> -----------------------------------M----------------------------
>> >>>
>> >>>
>> >>> Maker uses the BioPerl is_start_codon function to determine if the
>> >>>codon
>> >>> used in a result it receives is acceptable or if it should look
>> >>>upstream
>> >>> or downstream for a different one. Apparently there are actually 3
>> >>> acceptable start codons in the standard codon table (2 rare ones and
>> >>>one
>> >>> common), so making the edit removes the two rare ones from the list.
>> >>>
>> >>> I'm also preparing a 2.30 release that exports a "strict" codon table
>> >>>to
>> >>> the BioPerl module, that will be used by default and should fix the
>> >>>issue.
>> >>>
>> >>> Thanks,
>> >>> Carson
>> >>>
>> >>>
>> >>>
>> >>> On 10/12/13 11:06 AM, "Felix Bemm" <felix.bemm at uni-wuerzburg.de>
>> wrote:
>> >>>
>> >>>> Hi,
>> >>>>
>> >>>> I have a serious problems with maker annotations especially the start
>> >>>> codon placement. It started happening with maker version 2.27! About
>> >>>>1/3
>> >>>> of my genes are missing a proper start codon. When reviewing the GFF
>> >>>> files gene predictors and est evidence standalone would predict the
>> >>>> right gene structure including the start codon. I was thinking that
>> >>>>this
>> >>>> problem was somehow linked to my gene models but looking at their
>> >>>> standalone prediction I discarded that theory. Just some stats about
>> >>>> proteins with proper start codon (first column) and missing start
>> >>>>codon
>> >>>> (second column).
>> >>>>
>> >>>> Maker              9268    4215
>> >>>> SNAP               16577   896
>> >>>> Genemark   18764   290
>> >>>>
>> >>>> Numbers look the same when Augustus is used (currently retraining).
>> >>>> Manually using EST's in Apollo often fixes the problems but I don't
>> >>>>want
>> >>>> to check > 4000 genes for this.
>> >>>>
>> >>>> Do you have any idea what could cause such a problem? If you need
>> some
>> >>>> example gff files I can send you.
>> >>>>
>> >>>> Best regards
>> >>>> Felix
>> >>>>
>> >>>> --
>> >>>> Felix Bemm
>> >>>> Department of Bioinformatics
>> >>>> University of W?rzburg, Germany
>> >>>> Tel: +49 931 - 31 83696
>> >>>> Fax: +49 931 - 31 84552
>> >>>> felix.bemm at uni-wuerzburg.de
>> >>>>
>> >>>> _______________________________________________
>> >>>> maker-devel mailing list
>> >>>> maker-devel at box290.bluehost.com
>> >>>>
>> >>>>
>> http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>> >>
>> >>--
>> >>Felix Bemm
>> >>Department of Bioinformatics
>> >>University of W?rzburg, Germany
>> >>Tel: +49 931 - 31 83696
>> >>Fax: +49 931 - 31 84552
>> >>felix.bemm at uni-wuerzburg.de
>> >
>> >
>> >
>> >_______________________________________________
>> >maker-devel mailing list
>> >maker-devel at box290.bluehost.com
>> >http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>>
>>
>
> _______________________________________________
> maker-devel mailing list
> maker-devel at box290.bluehost.com
> http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131104/415de8e4/attachment-0001.html>

From marc.hoeppner at imbim.uu.se  Tue Nov  5 01:55:31 2013
From: marc.hoeppner at imbim.uu.se (Marc P. Hoeppner)
Date: Tue, 05 Nov 2013 09:55:31 +0100
Subject: [maker-devel] Maker and external ab-inito predictions
Message-ID: <5278B283.3000601@imbim.uu.se>

Hi,

this is possibly a trivial question, but I am realizing that Maker does 
not seem to process augustus files I have produced externally (augustus 
2.7); at least they don't seem to make it into the final annotation file.

My question(s) therefore:

1) What exact GFF features does maker expect for a 'pred_gff' file? 
Would it happily accept an augustus gff, or would I need to modify the 
native augustus features somehow? (Trying to find out whether this is a 
Maker issue or some other problem)

2) Is there a way to feed hint files to Maker to use with augustus? 
Couldn't find anything about that specifically anyway.

Regards,

Marc

-- 
-----------
Marc P. Hoeppner, PhD
Researcher
Department of Medical Biochemistry and Microbiology
Uppsala University, Sweden
marc.hoepner at imbim.uu.se




From smg283 at gmail.com  Tue Nov  5 17:53:55 2013
From: smg283 at gmail.com (Scott Geib)
Date: Tue, 5 Nov 2013 14:53:55 -1000
Subject: [maker-devel] running maker on tacc stampede
Message-ID: <CAH221buRe6jsRyeVnkup3bhf3fbHJp+hW+TEgOpzTmbmZ8TOBA@mail.gmail.com>

Hi,
I was looking for help running maker on stampede at tacc.  Have run in the
past on lonestar with no issues, but am getting some errors on stampede
(have never run before on stampede.  I also tried downloading the same
maker version on lonestar and running the same test data and had no issues.
 In both cases, used TACC module command to load more current perl into my
environment before installing maker.  On lonestar, SGE is used so
submission script slightly different in syntax, but ran with same
parameters. I know repbase isn't installed, but I just wanted to get
software working
Thanks Scott


Using this SLURM script with the current maker beta release (30),
submitting with sbatch on dpp test data in a copy of maker data directory:

#!/bin/bash
#SBATCH -J testmaker
#SBATCH -o testmaker.o%J
#SBATCH -e testmaker.e%J
##SBATCH -N 2
#SBATCH -n 32
#SBATCH -p development
#SBATCH -t 2:00:00
#SBATCH --mail-user=XXXXXX
#SBATCH --mail-type=all

ibrun ../maker/bin/maker -base test


This results in the following errors in testmaker.ejobid:

STATUS: Parsing control files...
WARNING: RepBase is not installed for RepeatMasker. This limits
RepeatMasker's functionality and makes the model_org option in the
control files virtually meaningless. MAKER will now reconfigure
for simple repeat masking only.
STATUS: Processing and indexing input FASTA files...
[c559-001.stampede.tacc.utexas.edu:mpi_rank_2][error_sighandler] Caught
error: Segmentation fault (signal 11)
[c559-001.stampede.tacc.utexas.edu:mpispawn_0][child_handler] MPI process
(rank: 2, pid: 35423) terminated with signal 11 -> abort job
SIGINT received
SIGINT received
SIGINT received
SIGINT received
SIGINT received
SIGINT received
SIGINT received
SIGINT received
SIGINT received
SIGINT received
SIGINT received
[c559-001.stampede.tacc.utexas.edu:mpi_rank_1][error_sighandler] Caught
error: Segmentation fault (signal 11)
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
        eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
forks.pm line 609
        threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
line 586
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
        eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
forks.pm line 609
        threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
line 586
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
        eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
forks.pm line 609
        threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
line 586
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        eval {...} called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        Parallel::Application::MPI::__ANON__() called at
/work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
        Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x55efbc8)') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
        Parallel::Application::MPI::MPI_Recv('SCALAR(0x54f4908)', -2, 1111)
called at /work/02726/pbarc/maker/bin/maker line 530
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
        eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
forks.pm line 609
        threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
line 586
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
        eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
forks.pm line 609
        threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
line 586
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
        eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
forks.pm line 609
        threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
line 586
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
        eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
forks.pm line 609
        threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
line 586
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
        eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
forks.pm line 609
        threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
line 586
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
        eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
forks.pm line 609
        threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
line 586
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
        eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
forks.pm line 609
        threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
line 586

 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        eval {...} called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        Parallel::Application::MPI::__ANON__() called at
/work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
        Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x36ffd10)') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
        Parallel::Application::MPI::MPI_Recv('SCALAR(0x3606080)', 0, 4444)
called at /work/02726/pbarc/maker/bin/maker line 578
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        eval {...} called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        Parallel::Application::MPI::__ANON__() called at
/work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
        Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x4d77a00)') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
        Parallel::Application::MPI::MPI_Recv('SCALAR(0x4c7f080)', 0, 4444)
called at /work/02726/pbarc/maker/bin/maker line 578
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        eval {...} called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        Parallel::Application::MPI::__ANON__() called at
/work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
        Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x418ece0)') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
        Parallel::Application::MPI::MPI_Recv('SCALAR(0x4095080)', 0, 4444)
called at /work/02726/pbarc/maker/bin/maker line 578
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        eval {...} called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        Parallel::Application::MPI::__ANON__() called at
/work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
        Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x3c05a00)') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
        Parallel::Application::MPI::MPI_Recv('SCALAR(0x3b0d080)', 0, 4444)
called at /work/02726/pbarc/maker/bin/maker line 578
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        eval {...} called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        Parallel::Application::MPI::__ANON__() called at
/work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
        Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x3b50a00)') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
        Parallel::Application::MPI::MPI_Recv('SCALAR(0x3a58080)', 0, 4444)
called at /work/02726/pbarc/maker/bin/maker line 578
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        eval {...} called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        Parallel::Application::MPI::__ANON__() called at
/work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
        Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x55cecf0)') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
        Parallel::Application::MPI::MPI_Recv('SCALAR(0x54d5080)', 0, 4444)
called at /work/02726/pbarc/maker/bin/maker line 578
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        eval {...} called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        Parallel::Application::MPI::__ANON__() called at
/work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
        Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x4a7ccf0)') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
        Parallel::Application::MPI::MPI_Recv('SCALAR(0x4983080)', 0, 4444)
called at /work/02726/pbarc/maker/bin/maker line 578
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        eval {...} called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        Parallel::Application::MPI::__ANON__() called at
/work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
        Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x53f1a00)') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
        Parallel::Application::MPI::MPI_Recv('SCALAR(0x52f9080)', 0, 4444)
called at /work/02726/pbarc/maker/bin/maker line 578
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        eval {...} called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        Parallel::Application::MPI::__ANON__() called at
/work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
        Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x367da00)') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
        Parallel::Application::MPI::MPI_Recv('SCALAR(0x3585080)', 0, 4444)
called at /work/02726/pbarc/maker/bin/maker line 578
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 23, pid: 10976) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 20, pid: 10973) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 17, pid: 10970) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 18, pid: 10971) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 19, pid: 10972) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 16, pid: 10969) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 21, pid: 10974) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 22, pid: 10975) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 24, pid: 10977) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 25, pid: 10978) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 26, pid: 10979) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 27, pid: 10980) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 28, pid: 10981) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 29, pid: 10982) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 30, pid: 10983) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 31, pid: 10984) exited with status 2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131105/561e5847/attachment-0001.html>

From carsonhh at gmail.com  Wed Nov  6 00:40:30 2013
From: carsonhh at gmail.com (Carson Holt)
Date: Wed, 6 Nov 2013 00:40:30 -0700
Subject: [maker-devel] Maker and external ab-inito predictions
In-Reply-To: <5278B283.3000601@imbim.uu.se>
References: <5278B283.3000601@imbim.uu.se>
Message-ID: <CA+sW3ETtKzitZurwUdLHbMauBwNYp49HOqhK6iY-AY=Oggwgbg@mail.gmail.com>

1) MAKER prefers match/match_part but should be able to handle any two
level feature or even gene/mRNA/exon/CDS features.  Make sure it's infact
GFF3 and not GTF or GFF2.

2) MAKER builds it's own hints based on the evidence alignments it finds,
providing user generated hint files is not supported.  If you already have
those, you can just run augustus directly, since one of the the main
benefit of MAKER is that it finds the hints for you and you would no longer
need that.

Perhaps you can give more details on what exactly you are trying to do, and
we could help you configure MAKER.

Thanks,
Carson



On Tue, Nov 5, 2013 at 1:55 AM, Marc P. Hoeppner
<marc.hoeppner at imbim.uu.se>wrote:

> Hi,
>
> this is possibly a trivial question, but I am realizing that Maker does
> not seem to process augustus files I have produced externally (augustus
> 2.7); at least they don't seem to make it into the final annotation file.
>
> My question(s) therefore:
>
> 1) What exact GFF features does maker expect for a 'pred_gff' file? Would
> it happily accept an augustus gff, or would I need to modify the native
> augustus features somehow? (Trying to find out whether this is a Maker
> issue or some other problem)
>
> 2) Is there a way to feed hint files to Maker to use with augustus?
> Couldn't find anything about that specifically anyway.
>
> Regards,
>
> Marc
>
> --
> -----------
> Marc P. Hoeppner, PhD
> Researcher
> Department of Medical Biochemistry and Microbiology
> Uppsala University, Sweden
> marc.hoepner at imbim.uu.se
>
>
> _______________________________________________
> maker-devel mailing list
> maker-devel at box290.bluehost.com
> http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131106/779c0953/attachment-0001.html>

From marc.hoeppner at imbim.uu.se  Wed Nov  6 00:45:09 2013
From: marc.hoeppner at imbim.uu.se (Marc P. Hoeppner)
Date: Wed, 06 Nov 2013 08:45:09 +0100
Subject: [maker-devel] Maker and external ab-inito predictions
In-Reply-To: <CA+sW3ETtKzitZurwUdLHbMauBwNYp49HOqhK6iY-AY=Oggwgbg@mail.gmail.com>
References: <5278B283.3000601@imbim.uu.se>
	<CA+sW3ETtKzitZurwUdLHbMauBwNYp49HOqhK6iY-AY=Oggwgbg@mail.gmail.com>
Message-ID: <5279F385.5030005@imbim.uu.se>

Hi Carson,

thanks for the clarification. I saw in the code that the Augustus Widget 
uses hints, but wasn't sure if and how those were generated. If they are 
derived from the evidence alignments, prefect. That's all I needed 
anyway. As for the passing of an external phred_gff, I guess the native 
Augustus GFF output is a little wonky - I'll try to convert it to 
match/match_parts to see if that helps (but with Maker computing it's 
own hints, I don't actually have to...).

Anyway, thanks again!

/Marc
> 1) MAKER prefers match/match_part but should be able to handle any two 
> level feature or even gene/mRNA/exon/CDS features.  Make sure it's 
> infact GFF3 and not GTF or GFF2.
>
> 2) MAKER builds it's own hints based on the evidence alignments it 
> finds, providing user generated hint files is not supported.  If you 
> already have those, you can just run augustus directly, since one of 
> the the main benefit of MAKER is that it finds the hints for you and 
> you would no longer need that.
>
> Perhaps you can give more details on what exactly you are trying to 
> do, and we could help you configure MAKER.
>
> Thanks,
> Carson
>
>
>
> On Tue, Nov 5, 2013 at 1:55 AM, Marc P. Hoeppner 
> <marc.hoeppner at imbim.uu.se <mailto:marc.hoeppner at imbim.uu.se>> wrote:
>
>     Hi,
>
>     this is possibly a trivial question, but I am realizing that Maker
>     does not seem to process augustus files I have produced externally
>     (augustus 2.7); at least they don't seem to make it into the final
>     annotation file.
>
>     My question(s) therefore:
>
>     1) What exact GFF features does maker expect for a 'pred_gff'
>     file? Would it happily accept an augustus gff, or would I need to
>     modify the native augustus features somehow? (Trying to find out
>     whether this is a Maker issue or some other problem)
>
>     2) Is there a way to feed hint files to Maker to use with
>     augustus? Couldn't find anything about that specifically anyway.
>
>     Regards,
>
>     Marc
>
>     -- 
>     -----------
>     Marc P. Hoeppner, PhD
>     Researcher
>     Department of Medical Biochemistry and Microbiology
>     Uppsala University, Sweden
>     marc.hoepner at imbim.uu.se <mailto:marc.hoepner at imbim.uu.se>
>
>
>     _______________________________________________
>     maker-devel mailing list
>     maker-devel at box290.bluehost.com
>     <mailto:maker-devel at box290.bluehost.com>
>     http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>
>


-- 
-----------
Marc P. Hoeppner, PhD
Researcher
Department of Medical Biochemistry and Microbiology
Uppsala University, Sweden
marc.hoepner at imbim.uu.se

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131106/7de0b86d/attachment-0001.html>

From carsonhh at gmail.com  Wed Nov  6 00:53:14 2013
From: carsonhh at gmail.com (Carson Holt)
Date: Wed, 6 Nov 2013 00:53:14 -0700
Subject: [maker-devel] running maker on tacc stampede
In-Reply-To: <CAH221buRe6jsRyeVnkup3bhf3fbHJp+hW+TEgOpzTmbmZ8TOBA@mail.gmail.com>
References: <CAH221buRe6jsRyeVnkup3bhf3fbHJp+hW+TEgOpzTmbmZ8TOBA@mail.gmail.com>
Message-ID: <CA+sW3ETCGE64JDvGc6v3JyOgmV5D1=P96NGTmqmi1k3nm8Uu0A@mail.gmail.com>

We're also seeing core dumps on Lonestar using the same version of MAKER
already installed when we do a "fresh install".  We're not sure why,
because everything should be the same.  Maybe something about what we are
seeing is also related to the issue you are experiencing and maybe not.
 Let me try and figure out what is happening on Lonestar and I'll send you
my install procedure, and maybe that will fix the stampede issue as well.

Thanks,
Carson



On Tue, Nov 5, 2013 at 5:53 PM, Scott Geib <smg283 at gmail.com> wrote:

> Hi,
> I was looking for help running maker on stampede at tacc.  Have run in the
> past on lonestar with no issues, but am getting some errors on stampede
> (have never run before on stampede.  I also tried downloading the same
> maker version on lonestar and running the same test data and had no issues.
>  In both cases, used TACC module command to load more current perl into my
> environment before installing maker.  On lonestar, SGE is used so
> submission script slightly different in syntax, but ran with same
> parameters. I know repbase isn't installed, but I just wanted to get
> software working
> Thanks Scott
>
>
> Using this SLURM script with the current maker beta release (30),
> submitting with sbatch on dpp test data in a copy of maker data directory:
>
> #!/bin/bash
> #SBATCH -J testmaker
> #SBATCH -o testmaker.o%J
> #SBATCH -e testmaker.e%J
> ##SBATCH -N 2
> #SBATCH -n 32
> #SBATCH -p development
> #SBATCH -t 2:00:00
> #SBATCH --mail-user=XXXXXX
> #SBATCH --mail-type=all
>
> ibrun ../maker/bin/maker -base test
>
>
> This results in the following errors in testmaker.ejobid:
>
> STATUS: Parsing control files...
> WARNING: RepBase is not installed for RepeatMasker. This limits
> RepeatMasker's functionality and makes the model_org option in the
> control files virtually meaningless. MAKER will now reconfigure
> for simple repeat masking only.
> STATUS: Processing and indexing input FASTA files...
> [c559-001.stampede.tacc.utexas.edu:mpi_rank_2][error_sighandler] Caught
> error: Segmentation fault (signal 11)
> [c559-001.stampede.tacc.utexas.edu:mpispawn_0][child_handler] MPI process
> (rank: 2, pid: 35423) terminated with signal 11 -> abort job
> SIGINT received
> SIGINT received
> SIGINT received
> SIGINT received
> SIGINT received
> SIGINT received
> SIGINT received
> SIGINT received
> SIGINT received
> SIGINT received
> SIGINT received
> [c559-001.stampede.tacc.utexas.edu:mpi_rank_1][error_sighandler] Caught
> error: Segmentation fault (signal 11)
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
>         eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
> forks.pm line 609
>         threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
> line 586
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
>         eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
> forks.pm line 609
>         threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
> line 586
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
>         eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
> forks.pm line 609
>         threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
> line 586
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         eval {...} called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         Parallel::Application::MPI::__ANON__() called at
> /work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
>         Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x55efbc8)') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
>         Parallel::Application::MPI::MPI_Recv('SCALAR(0x54f4908)', -2,
> 1111) called at /work/02726/pbarc/maker/bin/maker line 530
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
>         eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
> forks.pm line 609
>         threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
> line 586
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
>         eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
> forks.pm line 609
>         threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
> line 586
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
>         eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
> forks.pm line 609
>         threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
> line 586
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
>         eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
> forks.pm line 609
>         threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
> line 586
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
>         eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
> forks.pm line 609
>         threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
> line 586
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
>         eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
> forks.pm line 609
>         threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
> line 586
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
>         eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
> forks.pm line 609
>         threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
> line 586
>
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         eval {...} called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         Parallel::Application::MPI::__ANON__() called at
> /work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
>         Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x36ffd10)') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
>         Parallel::Application::MPI::MPI_Recv('SCALAR(0x3606080)', 0, 4444)
> called at /work/02726/pbarc/maker/bin/maker line 578
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         eval {...} called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         Parallel::Application::MPI::__ANON__() called at
> /work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
>         Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x4d77a00)') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
>         Parallel::Application::MPI::MPI_Recv('SCALAR(0x4c7f080)', 0, 4444)
> called at /work/02726/pbarc/maker/bin/maker line 578
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         eval {...} called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         Parallel::Application::MPI::__ANON__() called at
> /work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
>         Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x418ece0)') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
>         Parallel::Application::MPI::MPI_Recv('SCALAR(0x4095080)', 0, 4444)
> called at /work/02726/pbarc/maker/bin/maker line 578
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         eval {...} called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         Parallel::Application::MPI::__ANON__() called at
> /work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
>         Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x3c05a00)') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
>         Parallel::Application::MPI::MPI_Recv('SCALAR(0x3b0d080)', 0, 4444)
> called at /work/02726/pbarc/maker/bin/maker line 578
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         eval {...} called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         Parallel::Application::MPI::__ANON__() called at
> /work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
>         Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x3b50a00)') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
>         Parallel::Application::MPI::MPI_Recv('SCALAR(0x3a58080)', 0, 4444)
> called at /work/02726/pbarc/maker/bin/maker line 578
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         eval {...} called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         Parallel::Application::MPI::__ANON__() called at
> /work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
>         Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x55cecf0)') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
>         Parallel::Application::MPI::MPI_Recv('SCALAR(0x54d5080)', 0, 4444)
> called at /work/02726/pbarc/maker/bin/maker line 578
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         eval {...} called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         Parallel::Application::MPI::__ANON__() called at
> /work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
>         Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x4a7ccf0)') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
>         Parallel::Application::MPI::MPI_Recv('SCALAR(0x4983080)', 0, 4444)
> called at /work/02726/pbarc/maker/bin/maker line 578
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         eval {...} called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         Parallel::Application::MPI::__ANON__() called at
> /work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
>         Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x53f1a00)') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
>         Parallel::Application::MPI::MPI_Recv('SCALAR(0x52f9080)', 0, 4444)
> called at /work/02726/pbarc/maker/bin/maker line 578
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         eval {...} called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         Parallel::Application::MPI::__ANON__() called at
> /work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
>         Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x367da00)') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
>         Parallel::Application::MPI::MPI_Recv('SCALAR(0x3585080)', 0, 4444)
> called at /work/02726/pbarc/maker/bin/maker line 578
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 23, pid: 10976) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 20, pid: 10973) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 17, pid: 10970) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 18, pid: 10971) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 19, pid: 10972) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 16, pid: 10969) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 21, pid: 10974) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 22, pid: 10975) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 24, pid: 10977) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 25, pid: 10978) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 26, pid: 10979) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 27, pid: 10980) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 28, pid: 10981) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 29, pid: 10982) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 30, pid: 10983) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 31, pid: 10984) exited with status 2
>
>
> _______________________________________________
> maker-devel mailing list
> maker-devel at box290.bluehost.com
> http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131106/ab209d29/attachment-0001.html>

From xh33 at georgetown.edu  Tue Nov  5 11:04:18 2013
From: xh33 at georgetown.edu (Xin Huang)
Date: Tue, 5 Nov 2013 13:04:18 -0500
Subject: [maker-devel] Inquiry about using Exonerate through Maker
Message-ID: <CACvYrQEZR-35Crcmxbp-+CrG+QPs9dz3jkn3u9x++PU6BDF6tA@mail.gmail.com>

Hi,

I have a question regarding the use of Exonerate for cDNA alignment to
genomic scaffolds through Maker.

We first did a blastn search to find out which genomic scaffolds a cDNA
sequence aligns to. There are two scaffolds we figured that host the gene
of interest. So we picked these two scaffolds as the reference genome
sequence in the maker_opts.ctl file. I used the default settings in
maker_bopts.ctl. In the maker_exe.ctl file, the Ab-initio Gene Prediction
Algorithms section has only snap installed. In the maker_opts.ctl file, I
indicated the path to the EST sequence right after "est=" under EST
Evidence, skipped RepeatMasker (when included, only the repeat masking
information was shown in the GFF files) to only do the blast and exonerate,
set "est2genome=1" and left other options at default. In the directory
where we put the Maker output (the control files are all in this
directory), I ran the Maker pipeline using "<path_to_maker> maker_opts.ctl
maker_bopts.ctl maker_exe.ctl". It turned out that there is no alignment
information in the scaffold GFF3 file, just a plain figure indicating that
the scaffold is a contig. Then I tried to use the entire genome scaffold
set as the reference genome and reran the pipeline, still getting the same
results in terms of the Exonerate alignments. Please see the example of a
GFF3 file generated:

##gff-version 3
scaffold3928    .       contig  1       172176  .       .       .
ID=scaffold3928;Name=scaffold3928
###
##FASTA
>scaffold3928
<scaffold_sequence_omitted>

What do I need to adjust to get the alignment information into the GFF file
so I can upload into a genome browser as tracks?

Thank you very much for considering my inquiry.

Sincerely,

Xin Huang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131105/b6a8065e/attachment-0001.html>

From xh33 at georgetown.edu  Tue Nov  5 14:40:24 2013
From: xh33 at georgetown.edu (Xin Huang)
Date: Tue, 5 Nov 2013 16:40:24 -0500
Subject: [maker-devel] A suspected strange behavior of Maker...
Message-ID: <CACvYrQGP1dajOYyhiTDt6QuzCHdVR21vLYzmbtMKvF67d-fMiA@mail.gmail.com>

Hi,

I found a very bizarre thing when I ran Maker several times. The blastn
research seems to reverse query and subject the way it's specified in the
maker_opts.ctl file. When I put the scaffold sequence after genome= and the
cDNA sequence after est=, the blastn result actually used the scaffold as
query and the cDNA as subject. I realized that this sounds unreal, so I
reversed the places for the two and the blastn result is normal with the
cDNA as query and the scaffold as subject, but at the same time, the GFF
file is of the cDNA sequence. I tried a few times, and got the same result.
I deleted Maker (2.28) and reinstalled the beta version (2.30), still
getting the same result.

My wild guess was that this might be the reason why the est2genome
prediction using the EST sequence didn't go into the GFF3 file, as stated
in a previous email to the Maker-devel. I couldn't figure out how to test
this, though. I wonder if there's anything dramatically wrong that I've
been doing to get such odd results... If you'd like me to send you any
output files or control files, please let me know and I'll promptly pass
those along.

Thank you very much for considering my email.

Sincerely,

Xin Huang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131105/f942ccad/attachment-0001.html>

From Kerry_Gendreau at student.uml.edu  Fri Nov  8 16:40:06 2013
From: Kerry_Gendreau at student.uml.edu (Gendreau, Kerry L)
Date: Fri, 8 Nov 2013 23:40:06 +0000
Subject: [maker-devel] Maker is not predicting any genes on scaffold
Message-ID: <ae5739936c8745d9aaf58a434906305b@CO1PR02MB046.namprd02.prod.outlook.com>

Hello,

I am attempting to annotate a small section of an arthropod genome. I ran Maker on the command line and the results showed only repetitive regions recognized by Repeat Masker -- no predicted ORFs. I submitted my scaffold through the web interface and got the same results.

I know that there are genes present on this scaffold and when I run it through Augustus there are 13 ORFs predicted.

Are there some options that I need to adjust to get ab initio gene predictions from Maker?


Thank you,

Kerry Gendreau
Graduate Student, Dept. of Biological Sciences
University of Massachusetts Lowell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131108/ae7546e5/attachment-0001.html>

From dence at genetics.utah.edu  Sun Nov 10 19:43:12 2013
From: dence at genetics.utah.edu (Daniel Ence)
Date: Mon, 11 Nov 2013 02:43:12 +0000
Subject: [maker-devel] Maker is not predicting any genes on scaffold
In-Reply-To: <ae5739936c8745d9aaf58a434906305b@CO1PR02MB046.namprd02.prod.outlook.com>
References: <ae5739936c8745d9aaf58a434906305b@CO1PR02MB046.namprd02.prod.outlook.com>
Message-ID: <F2774D6F47BB9D449EEA8B0BF6679D9C65D3E471@mxb2.hg.genetics.utah.edu>

Hi Kerry, What evidence and abinitios did you use when you ran MAKER on your own machine?

Thanks,
Daniel

Daniel Ence
Graduate Student
Eccles Institute of Human Genetics
University of Utah
15 North 2030 East, Room 2100
Salt Lake City, UT 84112-5330
________________________________
From: maker-devel [maker-devel-bounces at yandell-lab.org] on behalf of Gendreau, Kerry L [Kerry_Gendreau at student.uml.edu]
Sent: Friday, November 08, 2013 4:40 PM
To: maker-devel at yandell-lab.org
Subject: [maker-devel] Maker is not predicting any genes on scaffold

Hello,

I am attempting to annotate a small section of an arthropod genome. I ran Maker on the command line and the results showed only repetitive regions recognized by Repeat Masker -- no predicted ORFs. I submitted my scaffold through the web interface and got the same results.

I know that there are genes present on this scaffold and when I run it through Augustus there are 13 ORFs predicted.

Are there some options that I need to adjust to get ab initio gene predictions from Maker?


Thank you,

Kerry Gendreau
Graduate Student, Dept. of Biological Sciences
University of Massachusetts Lowell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131111/a93b1101/attachment-0001.html>

From carson.holt at genetics.utah.edu  Sun Nov 10 20:08:23 2013
From: carson.holt at genetics.utah.edu (Carson Holt)
Date: Mon, 11 Nov 2013 03:08:23 +0000
Subject: [maker-devel] Problems with Maker
In-Reply-To: <CAC18qO8DbAWchktQpUC=CaPSL446kOj3Jgbt0_S1Ha41oAOh_w@mail.gmail.com>
Message-ID: <CEA59757.69E6%carson.holt@genetics.utah.edu>

For the installation problem, it shouldn't take more tun  few minutes.  You might want to just try setting up repeat masker manually, since what is happening is probably system specific.

The second problem is caused by an edit you made to the maker_opt.ctl file.  You deleted the '#' character that separates the options from the instructions comment, so the entire line is being interpreted as an option

model_org=all select a model organism for RepBase masking in RepeatMasker

So it's trying to use the phrase 'all select a model organism for RepBase masking in RepeatMasker' as the species, which causes repeat masker to fail.

Just change the line to model_org=all

--Carson


From: Sanea Sheikh <saneasheikh at gmail.com<mailto:saneasheikh at gmail.com>>
Date: Thursday, November 7, 2013 8:22 AM
To: <maker-devel at yandell-lab.org<mailto:maker-devel at yandell-lab.org>>
Subject: Problems with Maker

Hello

I am trying to run Maker v2.28 on my computer. I am having two problems.

When I use ./Build repeatmasker command for installing RepeatMasker, I get stuck at the Configuring RepeatMasker step for days. It doesn't move forward from that point. See the log attached (repeatmasker_maker.txt).

When I install RepeatMasker and run Maker, I get error message attached in maker_error_RM.txt file.

Can you please tell me what I am doing wrong here? I have also attached the maker opts.ctl file for your reference. I would really appreciate it if you can help me in this regard.

Regards
Sanea


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131111/f5550f90/attachment-0001.html>

From carsonhh at gmail.com  Sun Nov 10 22:10:08 2013
From: carsonhh at gmail.com (Carson Holt)
Date: Sun, 10 Nov 2013 22:10:08 -0700
Subject: [maker-devel] A suspected strange behavior of Maker...
In-Reply-To: <CACvYrQGP1dajOYyhiTDt6QuzCHdVR21vLYzmbtMKvF67d-fMiA@mail.gmail.com>
Message-ID: <CEA5B2C9.69F9%carsonhh@gmail.com>

Sorry for the slow reply, I was moving from Canada to the US, got sick, and
my moving truck got delayed one week. So I fell behind on the maker list.

What you observe is correct behavior.  The config is blasted against the
database of ESTs/proteins.  It really doesn't matter which way you blast,
you pick the direction that is most efficient for the question you are
asking, and you only have to adjust the Z value for database size if you
want alignment scores to be reproducible both ways.

Not getting results means they were filtered out for some reason (you don't
even have blastn results in your output).  If you can send a test dataset I
can take a look and tell you which filter.

Thanks,
Carson


From:  Xin Huang <xh33 at georgetown.edu>
Date:  Tuesday, November 5, 2013 2:40 PM
To:  <maker-devel at yandell-lab.org>
Subject:  [maker-devel] A suspected strange behavior of Maker...

Hi,

I found a very bizarre thing when I ran Maker several times. The blastn
research seems to reverse query and subject the way it's specified in the
maker_opts.ctl file. When I put the scaffold sequence after genome= and the
cDNA sequence after est=, the blastn result actually used the scaffold as
query and the cDNA as subject. I realized that this sounds unreal, so I
reversed the places for the two and the blastn result is normal with the
cDNA as query and the scaffold as subject, but at the same time, the GFF
file is of the cDNA sequence. I tried a few times, and got the same result.
I deleted Maker (2.28) and reinstalled the beta version (2.30), still
getting the same result.

My wild guess was that this might be the reason why the est2genome
prediction using the EST sequence didn't go into the GFF3 file, as stated in
a previous email to the Maker-devel. I couldn't figure out how to test this,
though. I wonder if there's anything dramatically wrong that I've been doing
to get such odd results... If you'd like me to send you any output files or
control files, please let me know and I'll promptly pass those along.

Thank you very much for considering my email.

Sincerely,

Xin Huang
_______________________________________________ maker-devel mailing list
maker-devel at box290.bluehost.com
http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131110/153ea1e5/attachment-0001.html>

From kpepin at genome.wustl.edu  Mon Nov 11 13:01:26 2013
From: kpepin at genome.wustl.edu (Kymberlie Hallsworth-Pepin)
Date: Mon, 11 Nov 2013 14:01:26 -0600 (CST)
Subject: [maker-devel] re-annotation
In-Reply-To: <CA5CEF3B.6A42%carsonhh@gmail.com>
References: <CA5CEF3B.6A42%carsonhh@gmail.com>
Message-ID: <alpine.DEB.2.00.1311111355190.28492@linus40.gsc.wustl.edu>

Hi Carson,

I am trying to take an existing gene set and update it using new proteins. 
I have the gene set in gff3 format - validated as ok - and have put it in
the model_gff line. I set the protein db to the new database and I set the 
map_forward=1 to maintain naming, but the output has no gene predictions 
in it. I have tried setting keep_preds both 0 and 1. I have put the gff 
file in both the pred_gff and model_gff and just in the pred_gff field, 
but I still don't get any predictions maintained. Can you tell me what I 
might be missing ?

thanks
Kym


____
This email message is a private communication. The information transmitted, including attachments, is intended only for the person or entity to which it is addressed and may contain confidential, privileged, and/or proprietary material. Any review, duplication, retransmission, distribution, or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is unauthorized by the sender and is prohibited. If you have received this message in error, please contact the sender immediately by return email and delete the original message from all computer systems. Thank you.



From cjfields at illinois.edu  Tue Nov 12 12:18:36 2013
From: cjfields at illinois.edu (Fields, Christopher J)
Date: Tue, 12 Nov 2013 19:18:36 +0000
Subject: [maker-devel] Recommendations for visualization?
Message-ID: <9B60EB76-1920-4B75-A224-C44070452B84@illinois.edu>

Barry, Carson,

Are there any recommendations re: visualizing MAKER-generated GFF3?  I know it?s currently geared towards Apollo integration, but as everything is moving towards Webapollo, attempts at finding the old local client Apollo code are a bit of an archaeological expedition (not to mention Apollo has always been a joy to set up from code :).  Is everyone still trying to use the old Apollo, since it seems to no longer be supported?

At the moment I am really thinking of working on simple scripts to make IGV-friendly input (and possibly similar Artemis for our smaller genome projects), but I don?t want to repeat work already in place.

chris


From barry.utah at gmail.com  Tue Nov 12 15:03:12 2013
From: barry.utah at gmail.com (Barry Moore)
Date: Tue, 12 Nov 2013 15:03:12 -0700
Subject: [maker-devel] Recommendations for visualization?
In-Reply-To: <9B60EB76-1920-4B75-A224-C44070452B84@illinois.edu>
References: <9B60EB76-1920-4B75-A224-C44070452B84@illinois.edu>
Message-ID: <90397AC5-7FEA-4B81-8085-49BD48787A6F@genetics.utah.edu>

This is a VERY good point Chris.  I think the new web-apollo is developing into a great tool, but there is now a gapping hole in the area of a desktop application (i.e. no server setup) to view/edit genome annotations.  I'd love to hear what others are using.  Our group has been using a combination of old Apollo instances, Web-Apollo and Gbrowse.

B

On Nov 12, 2013, at 12:18 PM, Fields, Christopher J wrote:

> Barry, Carson,
> 
> Are there any recommendations re: visualizing MAKER-generated GFF3?  I know it?s currently geared towards Apollo integration, but as everything is moving towards Webapollo, attempts at finding the old local client Apollo code are a bit of an archaeological expedition (not to mention Apollo has always been a joy to set up from code :).  Is everyone still trying to use the old Apollo, since it seems to no longer be supported?
> 
> At the moment I am really thinking of working on simple scripts to make IGV-friendly input (and possibly similar Artemis for our smaller genome projects), but I don?t want to repeat work already in place.
> 
> chris
> _______________________________________________
> maker-devel mailing list
> maker-devel at box290.bluehost.com
> http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org

Barry Moore
Research Scientist
Dept. of Human Genetics
University of Utah
Salt Lake City, UT 84112
--------------------------------------------
(801) 585-3543




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131112/863f00a0/attachment-0001.html>

From cjfields at illinois.edu  Tue Nov 12 15:25:21 2013
From: cjfields at illinois.edu (Fields, Christopher J)
Date: Tue, 12 Nov 2013 22:25:21 +0000
Subject: [maker-devel] Recommendations for visualization?
In-Reply-To: <90397AC5-7FEA-4B81-8085-49BD48787A6F@genetics.utah.edu>
References: <9B60EB76-1920-4B75-A224-C44070452B84@illinois.edu>
	<90397AC5-7FEA-4B81-8085-49BD48787A6F@genetics.utah.edu>
Message-ID: <8D26BC0C-74F6-43F4-A29B-10615BF7C6C0@illinois.edu>

I have considered using GMOD in the Cloud (we are likely to set something like this up on our local OpenStack when it?s up and running), but as a quick assessment of a test run it seems a bit overkill.

chris

On Nov 12, 2013, at 4:03 PM, Barry Moore <barry.utah at gmail.com<mailto:barry.utah at gmail.com>> wrote:

This is a VERY good point Chris.  I think the new web-apollo is developing into a great tool, but there is now a gapping hole in the area of a desktop application (i.e. no server setup) to view/edit genome annotations.  I'd love to hear what others are using.  Our group has been using a combination of old Apollo instances, Web-Apollo and Gbrowse.

B

On Nov 12, 2013, at 12:18 PM, Fields, Christopher J wrote:

Barry, Carson,

Are there any recommendations re: visualizing MAKER-generated GFF3?  I know it?s currently geared towards Apollo integration, but as everything is moving towards Webapollo, attempts at finding the old local client Apollo code are a bit of an archaeological expedition (not to mention Apollo has always been a joy to set up from code :).  Is everyone still trying to use the old Apollo, since it seems to no longer be supported?

At the moment I am really thinking of working on simple scripts to make IGV-friendly input (and possibly similar Artemis for our smaller genome projects), but I don?t want to repeat work already in place.

chris
_______________________________________________
maker-devel mailing list
maker-devel at box290.bluehost.com<mailto:maker-devel at box290.bluehost.com>
http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org

Barry Moore
Research Scientist
Dept. of Human Genetics
University of Utah
Salt Lake City, UT 84112
--------------------------------------------
(801) 585-3543





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131112/1ef63aa0/attachment-0001.html>

From carsonhh at gmail.com  Tue Nov 12 21:04:45 2013
From: carsonhh at gmail.com (Carson Holt)
Date: Tue, 12 Nov 2013 21:04:45 -0700
Subject: [maker-devel] re-annotation
In-Reply-To: <alpine.DEB.2.00.1311111355190.28492@linus40.gsc.wustl.edu>
Message-ID: <CEA8485C.6E7B%carsonhh@gmail.com>

They should be maintained.  What version are you using?

--Carson


On 11/11/13 1:01 PM, "Kymberlie Hallsworth-Pepin"
<kpepin at genome.wustl.edu> wrote:

>Hi Carson,
>
>I am trying to take an existing gene set and update it using new
>proteins. 
>I have the gene set in gff3 format - validated as ok - and have put it in
>the model_gff line. I set the protein db to the new database and I set
>the 
>map_forward=1 to maintain naming, but the output has no gene predictions
>in it. I have tried setting keep_preds both 0 and 1. I have put the gff
>file in both the pred_gff and model_gff and just in the pred_gff field,
>but I still don't get any predictions maintained. Can you tell me what I
>might be missing ?
>
>thanks
>Kym
>
>
>____
>This email message is a private communication. The information
>transmitted, including attachments, is intended only for the person or
>entity to which it is addressed and may contain confidential, privileged,
>and/or proprietary material. Any review, duplication, retransmission,
>distribution, or other use of, or taking of any action in reliance upon,
>this information by persons or entities other than the intended recipient
>is unauthorized by the sender and is prohibited. If you have received
>this message in error, please contact the sender immediately by return
>email and delete the original message from all computer systems. Thank
>you.





From kpepin at genome.wustl.edu  Wed Nov 13 06:16:44 2013
From: kpepin at genome.wustl.edu (Kymberlie Hallsworth-Pepin)
Date: Wed, 13 Nov 2013 07:16:44 -0600 (CST)
Subject: [maker-devel] re-annotation
In-Reply-To: <CEA8485C.6E7B%carsonhh@gmail.com>
References: <CEA8485C.6E7B%carsonhh@gmail.com>
Message-ID: <alpine.DEB.2.00.1311130711440.28492@linus40.gsc.wustl.edu>


We are using v2.26. We recreated the gff3 file and I can now get gene 
predictions to show up using the pred_gff file as input for the gene set. 
The naming is not maintained with the map_forward=1 as I would expect, 
just the source field in the input gff file is added to the new maker 
name.  If I change the input to a model_gff file I still do not get 
predictions in the maker gff file.

thanks
Kym




On Tue, 12 Nov 2013, Carson Holt wrote:

> They should be maintained.  What version are you using?
>
> --Carson
>
>
> On 11/11/13 1:01 PM, "Kymberlie Hallsworth-Pepin"
> <kpepin at genome.wustl.edu> wrote:
>
>> Hi Carson,
>>
>> I am trying to take an existing gene set and update it using new
>> proteins.
>> I have the gene set in gff3 format - validated as ok - and have put it in
>> the model_gff line. I set the protein db to the new database and I set
>> the
>> map_forward=1 to maintain naming, but the output has no gene predictions
>> in it. I have tried setting keep_preds both 0 and 1. I have put the gff
>> file in both the pred_gff and model_gff and just in the pred_gff field,
>> but I still don't get any predictions maintained. Can you tell me what I
>> might be missing ?
>>
>> thanks
>> Kym
>>
>>
>> ____
>> This email message is a private communication. The information
>> transmitted, including attachments, is intended only for the person or
>> entity to which it is addressed and may contain confidential, privileged,
>> and/or proprietary material. Any review, duplication, retransmission,
>> distribution, or other use of, or taking of any action in reliance upon,
>> this information by persons or entities other than the intended recipient
>> is unauthorized by the sender and is prohibited. If you have received
>> this message in error, please contact the sender immediately by return
>> email and delete the original message from all computer systems. Thank
>> you.
>

____
This email message is a private communication. The information transmitted, including attachments, is intended only for the person or entity to which it is addressed and may contain confidential, privileged, and/or proprietary material. Any review, duplication, retransmission, distribution, or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is unauthorized by the sender and is prohibited. If you have received this message in error, please contact the sender immediately by return email and delete the original message from all computer systems. Thank you.



From carsonhh at gmail.com  Wed Nov 13 08:06:44 2013
From: carsonhh at gmail.com (Carson Holt)
Date: Wed, 13 Nov 2013 08:06:44 -0700
Subject: [maker-devel] re-annotation
In-Reply-To: <alpine.DEB.2.00.1311130711440.28492@linus40.gsc.wustl.edu>
Message-ID: <CEA8E2DE.6FBF%carsonhh@gmail.com>

So map_forward=1, will only maintain names derived from model_gff onto new
or updated models.  Could you try either 2.28 or 2.30-beta, just to see if
this is something that is already fixed.

Thanks,
Carson


On 11/13/13 6:16 AM, "Kymberlie Hallsworth-Pepin"
<kpepin at genome.wustl.edu> wrote:

>
>We are using v2.26. We recreated the gff3 file and I can now get gene
>predictions to show up using the pred_gff file as input for the gene set.
>The naming is not maintained with the map_forward=1 as I would expect,
>just the source field in the input gff file is added to the new maker
>name.  If I change the input to a model_gff file I still do not get
>predictions in the maker gff file.
>
>thanks
>Kym
>
>
>
>
>On Tue, 12 Nov 2013, Carson Holt wrote:
>
>> They should be maintained.  What version are you using?
>>
>> --Carson
>>
>>
>> On 11/11/13 1:01 PM, "Kymberlie Hallsworth-Pepin"
>> <kpepin at genome.wustl.edu> wrote:
>>
>>> Hi Carson,
>>>
>>> I am trying to take an existing gene set and update it using new
>>> proteins.
>>> I have the gene set in gff3 format - validated as ok - and have put it
>>>in
>>> the model_gff line. I set the protein db to the new database and I set
>>> the
>>> map_forward=1 to maintain naming, but the output has no gene
>>>predictions
>>> in it. I have tried setting keep_preds both 0 and 1. I have put the gff
>>> file in both the pred_gff and model_gff and just in the pred_gff field,
>>> but I still don't get any predictions maintained. Can you tell me what
>>>I
>>> might be missing ?
>>>
>>> thanks
>>> Kym
>>>
>>>
>>> ____
>>> This email message is a private communication. The information
>>> transmitted, including attachments, is intended only for the person or
>>> entity to which it is addressed and may contain confidential,
>>>privileged,
>>> and/or proprietary material. Any review, duplication, retransmission,
>>> distribution, or other use of, or taking of any action in reliance
>>>upon,
>>> this information by persons or entities other than the intended
>>>recipient
>>> is unauthorized by the sender and is prohibited. If you have received
>>> this message in error, please contact the sender immediately by return
>>> email and delete the original message from all computer systems. Thank
>>> you.
>>
>
>____
>This email message is a private communication. The information
>transmitted, including attachments, is intended only for the person or
>entity to which it is addressed and may contain confidential, privileged,
>and/or proprietary material. Any review, duplication, retransmission,
>distribution, or other use of, or taking of any action in reliance upon,
>this information by persons or entities other than the intended recipient
>is unauthorized by the sender and is prohibited. If you have received
>this message in error, please contact the sender immediately by return
>email and delete the original message from all computer systems. Thank
>you.





From kpepin at genome.wustl.edu  Wed Nov 13 08:15:48 2013
From: kpepin at genome.wustl.edu (Kymberlie Hallsworth-Pepin)
Date: Wed, 13 Nov 2013 09:15:48 -0600 (CST)
Subject: [maker-devel] re-annotation
In-Reply-To: <CEA8E2DE.6FBF%carsonhh@gmail.com>
References: <CEA8E2DE.6FBF%carsonhh@gmail.com>
Message-ID: <alpine.DEB.2.00.1311130913090.2847@linus40.gsc.wustl.edu>



Will do. Is there a difference between how the model_gff file and the 
pred_gff file use the match/match_part of CDS/mRNA designations and which 
is the best to use for model_gff input?

On Wed, 13 Nov 2013, Carson Holt wrote:

> So map_forward=1, will only maintain names derived from model_gff onto new
> or updated models.  Could you try either 2.28 or 2.30-beta, just to see if
> this is something that is already fixed.
>
> Thanks,
> Carson
>

____
This email message is a private communication. The information transmitted, including attachments, is intended only for the person or entity to which it is addressed and may contain confidential, privileged, and/or proprietary material. Any review, duplication, retransmission, distribution, or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is unauthorized by the sender and is prohibited. If you have received this message in error, please contact the sender immediately by return email and delete the original message from all computer systems. Thank you.



From carsonhh at gmail.com  Wed Nov 13 16:08:08 2013
From: carsonhh at gmail.com (Carson Holt)
Date: Wed, 13 Nov 2013 16:08:08 -0700
Subject: [maker-devel] re-annotation
In-Reply-To: <alpine.DEB.2.00.1311130913090.2847@linus40.gsc.wustl.edu>
Message-ID: <CEA953DA.6B86%carsonhh@gmail.com>

model_gff must be gene/mRNA/exon/CDS. pred_gff can be match/match_part or
gene/mRNA/exon/CDS.  Also model_gff always should make it into the final
result (unless replaced by something better) and will not be modified.  It
also affects clustering.  pref_gff will only make it into the final
results if it is supported by evidence.

?Carson


On 11/13/13, 8:15 AM, "Kymberlie Hallsworth-Pepin"
<kpepin at genome.wustl.edu> wrote:

>
>
>Will do. Is there a difference between how the model_gff file and the
>pred_gff file use the match/match_part of CDS/mRNA designations and which
>is the best to use for model_gff input?
>
>On Wed, 13 Nov 2013, Carson Holt wrote:
>
>> So map_forward=1, will only maintain names derived from model_gff onto
>>new
>> or updated models.  Could you try either 2.28 or 2.30-beta, just to see
>>if
>> this is something that is already fixed.
>>
>> Thanks,
>> Carson
>>
>
>____
>This email message is a private communication. The information
>transmitted, including attachments, is intended only for the person or
>entity to which it is addressed and may contain confidential, privileged,
>and/or proprietary material. Any review, duplication, retransmission,
>distribution, or other use of, or taking of any action in reliance upon,
>this information by persons or entities other than the intended recipient
>is unauthorized by the sender and is prohibited. If you have received
>this message in error, please contact the sender immediately by return
>email and delete the original message from all computer systems. Thank
>you.





From carsonhh at gmail.com  Wed Nov 13 19:59:44 2013
From: carsonhh at gmail.com (Carson Holt)
Date: Wed, 13 Nov 2013 19:59:44 -0700
Subject: [maker-devel] A suspected strange behavior of Maker...
In-Reply-To: <CACvYrQGf+QwTcbWEOLX0igUZWcByu-E2d8YD4m2ykzCGr_aJ-w@mail.gmail.com>
Message-ID: <CEA98904.6B9A%carsonhh@gmail.com>

For scaffold5347 I get results from exonerate and blastn without any
modification to default parameters.  For scaffold3928 the alignment is very
poor, and gets filtered out.  I can force it to keep it but I have to allow
for abnormally long introns of 65kb (introns that large are extremely rare
in biology ? as in if you took every gene from 100 organisms you might find
a single gene among all of them with that long of an intron), and I have to
allow for low end to end matching (less 30%).  This alignment definitely
should have been rejected.

Thanks,
Carson


From:  Xin Huang <xh33 at georgetown.edu>
Date:  Monday, November 11, 2013 at 8:52 AM
To:  Carson Holt <carsonhh at gmail.com>
Cc:  <maker-devel at yandell-lab.org>
Subject:  Re: [maker-devel] A suspected strange behavior of Maker...

Hi Carson,

Thank you very much for getting back to me on this. Sorry I was too quick to
jump to a suspicion! Thanks for pointing it out and please see attached the
EST (face_cDNA.fa) and genome scaffold sequences
(albo_scaf3928+5347_for_face_cDNA.fa) I used for Maker. We used blastn to
identify these two scaffolds for this cDNA sequence, and exonerate result
also showed that this cDNA can be aligned to the scaffolds.

Thanks!

Xin 


On Mon, Nov 11, 2013 at 12:10 AM, Carson Holt <carsonhh at gmail.com> wrote:
> Sorry for the slow reply, I was moving from Canada to the US, got sick, and my
> moving truck got delayed one week. So I fell behind on the maker list.
> 
> What you observe is correct behavior.  The config is blasted against the
> database of ESTs/proteins.  It really doesn't matter which way you blast, you
> pick the direction that is most efficient for the question you are asking, and
> you only have to adjust the Z value for database size if you want alignment
> scores to be reproducible both ways.
> 
> Not getting results means they were filtered out for some reason (you don't
> even have blastn results in your output).  If you can send a test dataset I
> can take a look and tell you which filter.
> 
> Thanks,
> Carson
> 
> 
> From:  Xin Huang <xh33 at georgetown.edu>
> Date:  Tuesday, November 5, 2013 2:40 PM
> To:  <maker-devel at yandell-lab.org>
> Subject:  [maker-devel] A suspected strange behavior of Maker...
> 
> Hi,
> 
> I found a very bizarre thing when I ran Maker several times. The blastn
> research seems to reverse query and subject the way it's specified in the
> maker_opts.ctl file. When I put the scaffold sequence after genome= and the
> cDNA sequence after est=, the blastn result actually used the scaffold as
> query and the cDNA as subject. I realized that this sounds unreal, so I
> reversed the places for the two and the blastn result is normal with the cDNA
> as query and the scaffold as subject, but at the same time, the GFF file is of
> the cDNA sequence. I tried a few times, and got the same result. I deleted
> Maker (2.28) and reinstalled the beta version (2.30), still getting the same
> result.
> 
> My wild guess was that this might be the reason why the est2genome prediction
> using the EST sequence didn't go into the GFF3 file, as stated in a previous
> email to the Maker-devel. I couldn't figure out how to test this, though. I
> wonder if there's anything dramatically wrong that I've been doing to get such
> odd results... If you'd like me to send you any output files or control files,
> please let me know and I'll promptly pass those along.
> 
> Thank you very much for considering my email.
> 
> Sincerely,
> 
> Xin Huang
> _______________________________________________ maker-devel mailing list
> maker-devel at box290.bluehost.comhttp://box290.bluehost.com/mailman/listinfo/mak
> er-devel_yandell-lab.org



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131113/047635c9/attachment-0001.html>

From xh33 at georgetown.edu  Wed Nov 13 20:45:42 2013
From: xh33 at georgetown.edu (Xin Huang)
Date: Wed, 13 Nov 2013 22:45:42 -0500
Subject: [maker-devel] A suspected strange behavior of Maker...
In-Reply-To: <CEA98904.6B9A%carsonhh@gmail.com>
References: <CACvYrQGf+QwTcbWEOLX0igUZWcByu-E2d8YD4m2ykzCGr_aJ-w@mail.gmail.com>
	<CEA98904.6B9A%carsonhh@gmail.com>
Message-ID: <CACvYrQFPkZ+BwcQu0amq1kzO-0xAMTsLa0RqY+xy_sn6AfrZ0Q@mail.gmail.com>

Hi Carson,

Thanks a lot for doing the test for me! I didn't get any annotation in the
GFF file generated by Maker even if I only used scaffold5347 as the genome
and the face EST sequence as the est evidence. Is there something that I
can modify to put the alignment into the GFF file? I used est2genome=1
option to get prediction from exonerate, but still couldn't get any
prediction.

Thanks!

Xin


On Wed, Nov 13, 2013 at 9:59 PM, Carson Holt <carsonhh at gmail.com> wrote:

> For scaffold5347 I get results from exonerate and blastn without any
> modification to default parameters.  For scaffold3928 the alignment is very
> poor, and gets filtered out.  I can force it to keep it but I have to allow
> for abnormally long introns of 65kb (introns that large are extremely rare
> in biology ? as in if you took every gene from 100 organisms you might find
> a single gene among all of them with that long of an intron), and I have to
> allow for low end to end matching (less 30%).  This alignment definitely
> should have been rejected.
>
> Thanks,
> Carson
>
>
> From: Xin Huang <xh33 at georgetown.edu>
> Date: Monday, November 11, 2013 at 8:52 AM
> To: Carson Holt <carsonhh at gmail.com>
> Cc: <maker-devel at yandell-lab.org>
> Subject: Re: [maker-devel] A suspected strange behavior of Maker...
>
> Hi Carson,
>
> Thank you very much for getting back to me on this. Sorry I was too quick
> to jump to a suspicion! Thanks for pointing it out and please see attached
> the EST (face_cDNA.fa) and genome scaffold sequences
> (albo_scaf3928+5347_for_face_cDNA.fa) I used for Maker. We used blastn to
> identify these two scaffolds for this cDNA sequence, and exonerate result
> also showed that this cDNA can be aligned to the scaffolds.
>
> Thanks!
>
> Xin
>
>
> On Mon, Nov 11, 2013 at 12:10 AM, Carson Holt <carsonhh at gmail.com> wrote:
>
>> Sorry for the slow reply, I was moving from Canada to the US, got sick,
>> and my moving truck got delayed one week. So I fell behind on the maker
>> list.
>>
>> What you observe is correct behavior.  The config is blasted against the
>> database of ESTs/proteins.  It really doesn't matter which way you blast,
>> you pick the direction that is most efficient for the question you are
>> asking, and you only have to adjust the Z value for database size if you
>> want alignment scores to be reproducible both ways.
>>
>> Not getting results means they were filtered out for some reason (you
>> don't even have blastn results in your output).  If you can send a test
>> dataset I can take a look and tell you which filter.
>>
>> Thanks,
>> Carson
>>
>>
>> From: Xin Huang <xh33 at georgetown.edu>
>> Date: Tuesday, November 5, 2013 2:40 PM
>> To: <maker-devel at yandell-lab.org>
>> Subject: [maker-devel] A suspected strange behavior of Maker...
>>
>> Hi,
>>
>> I found a very bizarre thing when I ran Maker several times. The blastn
>> research seems to reverse query and subject the way it's specified in the
>> maker_opts.ctl file. When I put the scaffold sequence after genome= and the
>> cDNA sequence after est=, the blastn result actually used the scaffold as
>> query and the cDNA as subject. I realized that this sounds unreal, so I
>> reversed the places for the two and the blastn result is normal with the
>> cDNA as query and the scaffold as subject, but at the same time, the GFF
>> file is of the cDNA sequence. I tried a few times, and got the same result.
>> I deleted Maker (2.28) and reinstalled the beta version (2.30), still
>> getting the same result.
>>
>> My wild guess was that this might be the reason why the est2genome
>> prediction using the EST sequence didn't go into the GFF3 file, as stated
>> in a previous email to the Maker-devel. I couldn't figure out how to test
>> this, though. I wonder if there's anything dramatically wrong that I've
>> been doing to get such odd results... If you'd like me to send you any
>> output files or control files, please let me know and I'll promptly pass
>> those along.
>>
>> Thank you very much for considering my email.
>>
>> Sincerely,
>>
>> Xin Huang
>> _______________________________________________ maker-devel mailing list
>> maker-devel at box290.bluehost.com
>> http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131113/133d8f0a/attachment-0001.html>

From carsonhh at gmail.com  Wed Nov 13 20:49:32 2013
From: carsonhh at gmail.com (Carson Holt)
Date: Wed, 13 Nov 2013 20:49:32 -0700
Subject: [maker-devel] A suspected strange behavior of Maker...
In-Reply-To: <CACvYrQFPkZ+BwcQu0amq1kzO-0xAMTsLa0RqY+xy_sn6AfrZ0Q@mail.gmail.com>
Message-ID: <CEA99613.6BAD%carsonhh@gmail.com>

All I did was supply the cDNA to est= and the scaffolds to genome=.  All the
other parameters I just used the default, then I ran MAKER.  I am using
version 2.30.

Thanks,
Carson


From:  Xin Huang <xh33 at georgetown.edu>
Date:  Wednesday, November 13, 2013 at 8:45 PM
To:  Carson Holt <carsonhh at gmail.com>
Cc:  <maker-devel at yandell-lab.org>
Subject:  Re: [maker-devel] A suspected strange behavior of Maker...

Hi Carson,

Thanks a lot for doing the test for me! I didn't get any annotation in the
GFF file generated by Maker even if I only used scaffold5347 as the genome
and the face EST sequence as the est evidence. Is there something that I can
modify to put the alignment into the GFF file? I used est2genome=1 option to
get prediction from exonerate, but still couldn't get any prediction.

Thanks!

Xin


On Wed, Nov 13, 2013 at 9:59 PM, Carson Holt <carsonhh at gmail.com> wrote:
> For scaffold5347 I get results from exonerate and blastn without any
> modification to default parameters.  For scaffold3928 the alignment is very
> poor, and gets filtered out.  I can force it to keep it but I have to allow
> for abnormally long introns of 65kb (introns that large are extremely rare in
> biology ? as in if you took every gene from 100 organisms you might find a
> single gene among all of them with that long of an intron), and I have to
> allow for low end to end matching (less 30%).  This alignment definitely
> should have been rejected.
> 
> Thanks,
> Carson
> 
> 
> From:  Xin Huang <xh33 at georgetown.edu>
> Date:  Monday, November 11, 2013 at 8:52 AM
> To:  Carson Holt <carsonhh at gmail.com>
> Cc:  <maker-devel at yandell-lab.org>
> Subject:  Re: [maker-devel] A suspected strange behavior of Maker...
> 
> Hi Carson,
> 
> Thank you very much for getting back to me on this. Sorry I was too quick to
> jump to a suspicion! Thanks for pointing it out and please see attached the
> EST (face_cDNA.fa) and genome scaffold sequences
> (albo_scaf3928+5347_for_face_cDNA.fa) I used for Maker. We used blastn to
> identify these two scaffolds for this cDNA sequence, and exonerate result also
> showed that this cDNA can be aligned to the scaffolds.
> 
> Thanks!
> 
> Xin 
> 
> 
> On Mon, Nov 11, 2013 at 12:10 AM, Carson Holt <carsonhh at gmail.com> wrote:
>> Sorry for the slow reply, I was moving from Canada to the US, got sick, and
>> my moving truck got delayed one week. So I fell behind on the maker list.
>> 
>> What you observe is correct behavior.  The config is blasted against the
>> database of ESTs/proteins.  It really doesn't matter which way you blast, you
>> pick the direction that is most efficient for the question you are asking,
>> and you only have to adjust the Z value for database size if you want
>> alignment scores to be reproducible both ways.
>> 
>> Not getting results means they were filtered out for some reason (you don't
>> even have blastn results in your output).  If you can send a test dataset I
>> can take a look and tell you which filter.
>> 
>> Thanks,
>> Carson
>> 
>> 
>> From:  Xin Huang <xh33 at georgetown.edu>
>> Date:  Tuesday, November 5, 2013 2:40 PM
>> To:  <maker-devel at yandell-lab.org>
>> Subject:  [maker-devel] A suspected strange behavior of Maker...
>> 
>> Hi,
>> 
>> I found a very bizarre thing when I ran Maker several times. The blastn
>> research seems to reverse query and subject the way it's specified in the
>> maker_opts.ctl file. When I put the scaffold sequence after genome= and the
>> cDNA sequence after est=, the blastn result actually used the scaffold as
>> query and the cDNA as subject. I realized that this sounds unreal, so I
>> reversed the places for the two and the blastn result is normal with the cDNA
>> as query and the scaffold as subject, but at the same time, the GFF file is
>> of the cDNA sequence. I tried a few times, and got the same result. I deleted
>> Maker (2.28) and reinstalled the beta version (2.30), still getting the same
>> result.
>> 
>> My wild guess was that this might be the reason why the est2genome prediction
>> using the EST sequence didn't go into the GFF3 file, as stated in a previous
>> email to the Maker-devel. I couldn't figure out how to test this, though. I
>> wonder if there's anything dramatically wrong that I've been doing to get
>> such odd results... If you'd like me to send you any output files or control
>> files, please let me know and I'll promptly pass those along.
>> 
>> Thank you very much for considering my email.
>> 
>> Sincerely,
>> 
>> Xin Huang
>> _______________________________________________ maker-devel mailing list
>> maker-devel at box290.bluehost.comhttp://box290.bluehost.com/mailman/listinfo/ma
>> ker-devel_yandell-lab.org
> 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131113/4d20127f/attachment-0001.html>

From cjfields at illinois.edu  Wed Nov 13 20:51:36 2013
From: cjfields at illinois.edu (Fields, Christopher J)
Date: Thu, 14 Nov 2013 03:51:36 +0000
Subject: [maker-devel] Odd missing label bug
Message-ID: <73A19C36-ABA1-4A03-8D66-2A7F5574C386@illinois.edu>

I?m seeing an odd bug in GFF output where the label is being sporadically left off some child ?match_part' features.  This is when using maker-2.30p.  I found this while splitting out the data by source as individual tracks for IGV viewing; I have several sets of ESTs from individuals of the same species, so I have them labeled (from maker_opts):

est=./ESTs/Trinity_1128_v2_combined_pr2.clean.fasta:strain_1128
protein=./ESTs/xeno/Taeniopygia_guttata.taeGut3.2.4.73.pep.all.fa:TaeGut,./ESTs/xeno/Ficedula_albicollis.FicAlb_1.4.73.pep.all.fa:FicAlb

I planned on separating these into separate tracks, one for each BLASTX, BLASTN, etc.  

After a test run on a few scaffolds, a small number of the BLASTX and BLASTN look like this:

KB913263.1      blastx:TaeGut   protein_match   374736  401929  330     -       .       ID=KB913263.1:hit:9:3.10.0.3;Name=ENSTGUP00000000074
KB913263.1      blastx  match_part      401756  401929  312     -       .       ID=KB913263.1:hsp:55:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M58;Target=ENSTGUP00000000074 1 58
KB913263.1      blastx  match_part      394486  394665  186     -       .       ID=KB913263.1:hsp:56:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M42 D9 M9;Target=ENSTGUP00000000074 56 106
KB913263.1      blastx  match_part      392059  392178  204     -       .       ID=KB913263.1:hsp:57:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M40;Target=ENSTGUP00000000074 97 136
KB913263.1      blastx  match_part      387479  387547  116     -       .       ID=KB913263.1:hsp:58:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M23;Target=ENSTGUP00000000074 151 173
KB913263.1      blastx  match_part      383644  383742  156     -       .       ID=KB913263.1:hsp:59:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M33;Target=ENSTGUP00000000074 172 204
KB913263.1      blastx  match_part      382860  383063  242     -       .       ID=KB913263.1:hsp:60:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M68;Target=ENSTGUP00000000074 193 260
KB913263.1      blastx  match_part      382538  382648  186     -       .       ID=KB913263.1:hsp:61:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M37;Target=ENSTGUP00000000074 247 283
KB913263.1      blastx  match_part      382072  382236  268     -       .       ID=KB913263.1:hsp:62:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M55;Target=ENSTGUP00000000074 282 336
KB913263.1      blastx  match_part      379270  379458  330     -       .       ID=KB913263.1:hsp:63:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M63;Target=ENSTGUP00000000074 336 398
KB913263.1      blastx  match_part      374736  374900  147     -       .       ID=KB913263.1:hsp:64:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M55;Target=ENSTGUP00000000074 4 58

Note the missing label in the source column for the ?match_part? types.  Strangely, only a small # have this problem, but the exact same ones appear to be consistently popping up on repeated runs (this is from a test prior to a full launch using openmpi).  It does seem like only child ?match_part? appears affected.

Any ideas?

chris


From carsonhh at gmail.com  Wed Nov 13 20:58:32 2013
From: carsonhh at gmail.com (Carson Holt)
Date: Wed, 13 Nov 2013 20:58:32 -0700
Subject: [maker-devel] Odd missing label bug
In-Reply-To: <73A19C36-ABA1-4A03-8D66-2A7F5574C386@illinois.edu>
Message-ID: <CEA9978B.6BB3%carsonhh@gmail.com>

Could you put a contig and protein fasta into a test job that I could run
on?  Based on the hit position I imagine this may only happens when the
alignments spans two chunks (by default MAKER splits the input config into
100,000bp chunks).  The hit runs from 374736-401929.

?Carson


On 11/13/13, 8:51 PM, "Fields, Christopher J" <cjfields at illinois.edu>
wrote:

>I?m seeing an odd bug in GFF output where the label is being sporadically
>left off some child ?match_part' features.  This is when using
>maker-2.30p.  I found this while splitting out the data by source as
>individual tracks for IGV viewing; I have several sets of ESTs from
>individuals of the same species, so I have them labeled (from maker_opts):
>
>est=./ESTs/Trinity_1128_v2_combined_pr2.clean.fasta:strain_1128
>protein=./ESTs/xeno/Taeniopygia_guttata.taeGut3.2.4.73.pep.all.fa:TaeGut,.
>/ESTs/xeno/Ficedula_albicollis.FicAlb_1.4.73.pep.all.fa:FicAlb
>
>I planned on separating these into separate tracks, one for each BLASTX,
>BLASTN, etc.  
>
>After a test run on a few scaffolds, a small number of the BLASTX and
>BLASTN look like this:
>
>KB913263.1      blastx:TaeGut   protein_match   374736  401929  330     -
>      .       ID=KB913263.1:hit:9:3.10.0.3;Name=ENSTGUP00000000074
>KB913263.1      blastx  match_part      401756  401929  312     -       .
>      
>ID=KB913263.1:hsp:55:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M58;Tar
>get=ENSTGUP00000000074 1 58
>KB913263.1      blastx  match_part      394486  394665  186     -       .
>      
>ID=KB913263.1:hsp:56:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M42 D9
>M9;Target=ENSTGUP00000000074 56 106
>KB913263.1      blastx  match_part      392059  392178  204     -       .
>      
>ID=KB913263.1:hsp:57:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M40;Tar
>get=ENSTGUP00000000074 97 136
>KB913263.1      blastx  match_part      387479  387547  116     -       .
>      
>ID=KB913263.1:hsp:58:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M23;Tar
>get=ENSTGUP00000000074 151 173
>KB913263.1      blastx  match_part      383644  383742  156     -       .
>      
>ID=KB913263.1:hsp:59:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M33;Tar
>get=ENSTGUP00000000074 172 204
>KB913263.1      blastx  match_part      382860  383063  242     -       .
>      
>ID=KB913263.1:hsp:60:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M68;Tar
>get=ENSTGUP00000000074 193 260
>KB913263.1      blastx  match_part      382538  382648  186     -       .
>      
>ID=KB913263.1:hsp:61:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M37;Tar
>get=ENSTGUP00000000074 247 283
>KB913263.1      blastx  match_part      382072  382236  268     -       .
>      
>ID=KB913263.1:hsp:62:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M55;Tar
>get=ENSTGUP00000000074 282 336
>KB913263.1      blastx  match_part      379270  379458  330     -       .
>      
>ID=KB913263.1:hsp:63:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M63;Tar
>get=ENSTGUP00000000074 336 398
>KB913263.1      blastx  match_part      374736  374900  147     -       .
>      
>ID=KB913263.1:hsp:64:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M55;Tar
>get=ENSTGUP00000000074 4 58
>
>Note the missing label in the source column for the ?match_part? types.
>Strangely, only a small # have this problem, but the exact same ones
>appear to be consistently popping up on repeated runs (this is from a
>test prior to a full launch using openmpi).  It does seem like only child
>?match_part? appears affected.
>
>Any ideas?
>
>chris
>_______________________________________________
>maker-devel mailing list
>maker-devel at box290.bluehost.com
>http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org





From cjfields at illinois.edu  Wed Nov 13 21:20:46 2013
From: cjfields at illinois.edu (Fields, Christopher J)
Date: Thu, 14 Nov 2013 04:20:46 +0000
Subject: [maker-devel] Odd missing label bug
In-Reply-To: <CEA9978B.6BB3%carsonhh@gmail.com>
References: <CEA9978B.6BB3%carsonhh@gmail.com>
Message-ID: <6E70C69F-BAFD-4C9E-9293-04DB656B2A09@illinois.edu>

Yeah, that seems to be it (crossing around 100kbp increments).  I?ll run a reduced example set locally to make sure and will send.

-c

On Nov 13, 2013, at 9:58 PM, Carson Holt <carsonhh at gmail.com> wrote:

> Could you put a contig and protein fasta into a test job that I could run
> on?  Based on the hit position I imagine this may only happens when the
> alignments spans two chunks (by default MAKER splits the input config into
> 100,000bp chunks).  The hit runs from 374736-401929.
> 
> <Carson
> 
> 
> On 11/13/13, 8:51 PM, "Fields, Christopher J" <cjfields at illinois.edu>
> wrote:
> 
>> I?m seeing an odd bug in GFF output where the label is being sporadically
>> left off some child Omatch_part' features.  This is when using
>> maker-2.30p.  I found this while splitting out the data by source as
>> individual tracks for IGV viewing; I have several sets of ESTs from
>> individuals of the same species, so I have them labeled (from maker_opts):
>> 
>> est=./ESTs/Trinity_1128_v2_combined_pr2.clean.fasta:strain_1128
>> protein=./ESTs/xeno/Taeniopygia_guttata.taeGut3.2.4.73.pep.all.fa:TaeGut,.
>> /ESTs/xeno/Ficedula_albicollis.FicAlb_1.4.73.pep.all.fa:FicAlb
>> 
>> I planned on separating these into separate tracks, one for each BLASTX,
>> BLASTN, etc.  
>> 
>> After a test run on a few scaffolds, a small number of the BLASTX and
>> BLASTN look like this:
>> 
>> KB913263.1      blastx:TaeGut   protein_match   374736  401929  330     -
>>     .       ID=KB913263.1:hit:9:3.10.0.3;Name=ENSTGUP00000000074
>> KB913263.1      blastx  match_part      401756  401929  312     -       .
>> 
>> ID=KB913263.1:hsp:55:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M58;Tar
>> get=ENSTGUP00000000074 1 58
>> KB913263.1      blastx  match_part      394486  394665  186     -       .
>> 
>> ID=KB913263.1:hsp:56:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M42 D9
>> M9;Target=ENSTGUP00000000074 56 106
>> KB913263.1      blastx  match_part      392059  392178  204     -       .
>> 
>> ID=KB913263.1:hsp:57:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M40;Tar
>> get=ENSTGUP00000000074 97 136
>> KB913263.1      blastx  match_part      387479  387547  116     -       .
>> 
>> ID=KB913263.1:hsp:58:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M23;Tar
>> get=ENSTGUP00000000074 151 173
>> KB913263.1      blastx  match_part      383644  383742  156     -       .
>> 
>> ID=KB913263.1:hsp:59:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M33;Tar
>> get=ENSTGUP00000000074 172 204
>> KB913263.1      blastx  match_part      382860  383063  242     -       .
>> 
>> ID=KB913263.1:hsp:60:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M68;Tar
>> get=ENSTGUP00000000074 193 260
>> KB913263.1      blastx  match_part      382538  382648  186     -       .
>> 
>> ID=KB913263.1:hsp:61:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M37;Tar
>> get=ENSTGUP00000000074 247 283
>> KB913263.1      blastx  match_part      382072  382236  268     -       .
>> 
>> ID=KB913263.1:hsp:62:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M55;Tar
>> get=ENSTGUP00000000074 282 336
>> KB913263.1      blastx  match_part      379270  379458  330     -       .
>> 
>> ID=KB913263.1:hsp:63:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M63;Tar
>> get=ENSTGUP00000000074 336 398
>> KB913263.1      blastx  match_part      374736  374900  147     -       .
>> 
>> ID=KB913263.1:hsp:64:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M55;Tar
>> get=ENSTGUP00000000074 4 58
>> 
>> Note the missing label in the source column for the Omatch_part? types.
>> Strangely, only a small # have this problem, but the exact same ones
>> appear to be consistently popping up on repeated runs (this is from a
>> test prior to a full launch using openmpi).  It does seem like only child
>> Omatch_part? appears affected.
>> 
>> Any ideas?
>> 
>> chris
>> _______________________________________________
>> maker-devel mailing list
>> maker-devel at box290.bluehost.com
>> http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
> 
> 




From kpepin at genome.wustl.edu  Thu Nov 14 05:51:54 2013
From: kpepin at genome.wustl.edu (Kymberlie Hallsworth-Pepin)
Date: Thu, 14 Nov 2013 06:51:54 -0600 (CST)
Subject: [maker-devel] re-annotation
In-Reply-To: <CEA953DA.6B86%carsonhh@gmail.com>
References: <CEA953DA.6B86%carsonhh@gmail.com>
Message-ID: <alpine.DEB.2.00.1311140650400.28492@linus40.gsc.wustl.edu>


The new version and the change in the model gff to exon/cds did the trick.
thanks for the info.
Kym


On Wed, 13 Nov 2013, Carson Holt wrote:

> model_gff must be gene/mRNA/exon/CDS. pred_gff can be match/match_part or
> gene/mRNA/exon/CDS.  Also model_gff always should make it into the final
> result (unless replaced by something better) and will not be modified.  It
> also affects clustering.  pref_gff will only make it into the final
> results if it is supported by evidence.
>
> ?Carson
>
>
> On 11/13/13, 8:15 AM, "Kymberlie Hallsworth-Pepin"
> <kpepin at genome.wustl.edu> wrote:
>
>>
>>
>> Will do. Is there a difference between how the model_gff file and the
>> pred_gff file use the match/match_part of CDS/mRNA designations and which
>> is the best to use for model_gff input?
>>
>> On Wed, 13 Nov 2013, Carson Holt wrote:
>>
>>> So map_forward=1, will only maintain names derived from model_gff onto
>>> new
>>> or updated models.  Could you try either 2.28 or 2.30-beta, just to see
>>> if
>>> this is something that is already fixed.
>>>
>>> Thanks,
>>> Carson
>>>
>>
>> ____
>> This email message is a private communication. The information
>> transmitted, including attachments, is intended only for the person or
>> entity to which it is addressed and may contain confidential, privileged,
>> and/or proprietary material. Any review, duplication, retransmission,
>> distribution, or other use of, or taking of any action in reliance upon,
>> this information by persons or entities other than the intended recipient
>> is unauthorized by the sender and is prohibited. If you have received
>> this message in error, please contact the sender immediately by return
>> email and delete the original message from all computer systems. Thank
>> you.
>

____
This email message is a private communication. The information transmitted, including attachments, is intended only for the person or entity to which it is addressed and may contain confidential, privileged, and/or proprietary material. Any review, duplication, retransmission, distribution, or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is unauthorized by the sender and is prohibited. If you have received this message in error, please contact the sender immediately by return email and delete the original message from all computer systems. Thank you.



From xh33 at georgetown.edu  Mon Nov 11 08:52:48 2013
From: xh33 at georgetown.edu (Xin Huang)
Date: Mon, 11 Nov 2013 10:52:48 -0500
Subject: [maker-devel] A suspected strange behavior of Maker...
In-Reply-To: <CEA5B2C9.69F9%carsonhh@gmail.com>
References: <CACvYrQGP1dajOYyhiTDt6QuzCHdVR21vLYzmbtMKvF67d-fMiA@mail.gmail.com>
	<CEA5B2C9.69F9%carsonhh@gmail.com>
Message-ID: <CACvYrQGf+QwTcbWEOLX0igUZWcByu-E2d8YD4m2ykzCGr_aJ-w@mail.gmail.com>

Hi Carson,

Thank you very much for getting back to me on this. Sorry I was too quick
to jump to a suspicion! Thanks for pointing it out and please see attached
the EST (face_cDNA.fa) and genome scaffold sequences
(albo_scaf3928+5347_for_face_cDNA.fa) I used for Maker. We used blastn to
identify these two scaffolds for this cDNA sequence, and exonerate result
also showed that this cDNA can be aligned to the scaffolds.

Thanks!

Xin


On Mon, Nov 11, 2013 at 12:10 AM, Carson Holt <carsonhh at gmail.com> wrote:

> Sorry for the slow reply, I was moving from Canada to the US, got sick,
> and my moving truck got delayed one week. So I fell behind on the maker
> list.
>
> What you observe is correct behavior.  The config is blasted against the
> database of ESTs/proteins.  It really doesn't matter which way you blast,
> you pick the direction that is most efficient for the question you are
> asking, and you only have to adjust the Z value for database size if you
> want alignment scores to be reproducible both ways.
>
> Not getting results means they were filtered out for some reason (you
> don't even have blastn results in your output).  If you can send a test
> dataset I can take a look and tell you which filter.
>
> Thanks,
> Carson
>
>
> From: Xin Huang <xh33 at georgetown.edu>
> Date: Tuesday, November 5, 2013 2:40 PM
> To: <maker-devel at yandell-lab.org>
> Subject: [maker-devel] A suspected strange behavior of Maker...
>
> Hi,
>
> I found a very bizarre thing when I ran Maker several times. The blastn
> research seems to reverse query and subject the way it's specified in the
> maker_opts.ctl file. When I put the scaffold sequence after genome= and the
> cDNA sequence after est=, the blastn result actually used the scaffold as
> query and the cDNA as subject. I realized that this sounds unreal, so I
> reversed the places for the two and the blastn result is normal with the
> cDNA as query and the scaffold as subject, but at the same time, the GFF
> file is of the cDNA sequence. I tried a few times, and got the same result.
> I deleted Maker (2.28) and reinstalled the beta version (2.30), still
> getting the same result.
>
> My wild guess was that this might be the reason why the est2genome
> prediction using the EST sequence didn't go into the GFF3 file, as stated
> in a previous email to the Maker-devel. I couldn't figure out how to test
> this, though. I wonder if there's anything dramatically wrong that I've
> been doing to get such odd results... If you'd like me to send you any
> output files or control files, please let me know and I'll promptly pass
> those along.
>
> Thank you very much for considering my email.
>
> Sincerely,
>
> Xin Huang
> _______________________________________________ maker-devel mailing list
> maker-devel at box290.bluehost.com
> http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131111/aeac9298/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: face_cDNA.fa
Type: application/octet-stream
Size: 1977 bytes
Desc: not available
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131111/aeac9298/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: albo_scaf3928+5347_for_face_cDNA.fa
Type: application/octet-stream
Size: 306492 bytes
Desc: not available
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131111/aeac9298/attachment-0003.obj>

From ejr at stowers.org  Mon Nov 18 13:24:03 2013
From: ejr at stowers.org (Ross, Eric)
Date: Mon, 18 Nov 2013 20:24:03 +0000
Subject: [maker-devel] gff3_merge error - only half the contigs are
 reported
Message-ID: <CEAFD381.2B146%ejr@stowers.org>

I had the same problem Sujai reported  on the 25th.

When I run gff3_merge I only get back results from a subset of my
scaffolds.  Every scaffold has a gff file in the data store.  fasta_merge
works fine.  No errors are printed to STDOUT.

It took me some poking around, but this seems that if there is
insufficient space in /tmp to generate the temporary files merge_gff3
completes without error and just creates a gff file from whatever fit in
the temporary files.  I'm not sure why tempfile() doesn't return a useful
error.  

I was able to get around the error by setting the environment variable
TMPDIR to someplace with sufficient space, but if there is a way to
generate a useful error it might be worth adding.


Eric




--original below--
On Friday, October 25, 2013 11:22:08 AM UTC-5, Barry wrote:
Hi Sujai,
If you still have that original directory available a couple things you to
try:

# Does this give you the number of contigs you're expecting?
find datastore_directory -name '*.gff3' | wc -l

# If the above gives what you expect what does the file size look like on
the smallest files?
find ./ -type f | xargs ls -Sl | tail

Barry

On Oct 24, 2013, at 4:04 PM, Sujai wrote:


Hi Barry

The last stderr message in the job is from the maker command:

Maker is now finished!!!

my last 3 commands were (in my pbs/torque job script):

----job script----
...other commands to set variables etc...
mpiexec -n 12 maker -g $SPLITFILE -base $SPLITFILE maker_opts.ctl
maker_bopts.ctl maker_exe.ctl
gff3_merge -o $PBS_O_WORKDIR/$SPLITFILE.gff3 -d
$SPLITFILE.maker.output/${SPLITFILE}_master_datastore_index.log
fasta_merge -d 
$SPLITFILE.maker.output/${SPLITFILE}_master_datastore_index.log
-----

so, no gff3_merge stderr messages
the fasta_merge command (which came after gff3_merge) has completed
correctly, with all proteins and transcripts accounted for.
I just ran the same contigs again in smaller batches, and it seems to be
proceeding correctly (the final gff3 files are between 49-55MB for each
chunk of fasta files. In the previous case, the final GFF3 file was 99MB
or 100MB (which is why I thought there was some sort of filesize/memory
limit)

Thanks for looking into this,

- Sujai




On 24 October 2013 21:42, Barry Moore <barry... at genetics.utah.edu <>>
wrote:

Hi Sujai,
There are a couple of fatal errors that can be thrown by gff3_merge if it
encounters errors.  Did you capture STDERR and do you see any failures
there?

B

On Oct 24, 2013, at 10:43 AM, Sujai wrote:




Hi all
First of all, thank you to Carson Holt and Mark Yandell and team for an
excellent program with excellent installation instructions. Setting maker
2.28 up and running it (both with MPI and without) was a breeze on a PBS
cluster. Everything worked as expected (doesn't happen that often in
bioinformatics software! :-))

I did a test run on 150 longish contigs (>50kb each) and everything worked
fine, including gff3_merge, fasta_merge etc. I got predictions for all the
contigs etc.


However, when I ran it on the full 20,000 sequence file (minimum 300 bp, I
know - I could have set the min length in maker_opts.ctl but I wanted the
repeatmasker analysis done even for the smaller contigs), I had a problem:

1. the intermediate files were all fine (i.e. grep -c FINISHED
...master_datastore_index.log showed the right number of sequences)

2. But gff3_merge -d ...master_datastore_index.log  only gave a file with
about 9000 contigs. I ran it a few times and got the same result each
time. fasta_merge gave back sequences from all ~20,000 contigs, so I know
the contig_datastore was fine.

3. Could it be that gff3_merge hit some sort of output limit? the GFF3
file created seems to be almost exactly 100MB. Or could it be a limit of
my OS environment? I had a lot of memory (12 GB) and a large tmp directory
(10 GB) so that should not be a problem...

If anyone has seen this problem or can shed any light on this, that would
be great.

I'm going to try splitting the file into smaller sets and hoping for the
best.

Thanks

- Sujai




-- 
You received this message because you are subscribed to the Google Groups
"maker-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to maker-devel... at googlegroups.com <>.
To post to this group, send email to maker... at googlegroups.com <>.
Visit this group at http://groups.google.com/group/maker-devel.
For more options, visit https://groups.google.com/groups/opt_out.




Barry Moore
Research Scientist
Dept. of Human Genetics
University of Utah
Salt Lake City, UT 84112
--------------------------------------------
(801) 585-3543









-- 
You received this message because you are subscribed to a topic in the
Google Groups "maker-devel" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/maker-devel/bApnLPFgmRc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
maker-devel... at googlegroups.com <>.
To post to this group, send email to maker... at googlegroups.com <>.
Visit this group at http://groups.google.com/group/maker-devel.
For more options, visit https://groups.google.com/groups/opt_out.






-- 
You received this message because you are subscribed to the Google Groups
"maker-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to maker-devel... at googlegroups.com <>.
To post to this group, send email to maker... at googlegroups.com <>.
Visit this group at http://groups.google.com/group/maker-devel.
For more options, visit https://groups.google.com/groups/opt_out.




Barry Moore
Research Scientist
Dept. of Human Genetics
University of Utah
Salt Lake City, UT 84112
--------------------------------------------
(801) 585-3543











On Friday, October 25, 2013 11:22:08 AM UTC-5, Barry wrote:
Hi Sujai,
If you still have that original directory available a couple things you to
try:

# Does this give you the number of contigs you're expecting?
find datastore_directory -name '*.gff3' | wc -l

# If the above gives what you expect what does the file size look like on
the smallest files?
find ./ -type f | xargs ls -Sl | tail

Barry

On Oct 24, 2013, at 4:04 PM, Sujai wrote:


Hi Barry

The last stderr message in the job is from the maker command:

Maker is now finished!!!

my last 3 commands were (in my pbs/torque job script):

----job script----
...other commands to set variables etc...
mpiexec -n 12 maker -g $SPLITFILE -base $SPLITFILE maker_opts.ctl
maker_bopts.ctl maker_exe.ctl
gff3_merge -o $PBS_O_WORKDIR/$SPLITFILE.gff3 -d
$SPLITFILE.maker.output/${SPLITFILE}_master_datastore_index.log
fasta_merge -d 
$SPLITFILE.maker.output/${SPLITFILE}_master_datastore_index.log
-----

so, no gff3_merge stderr messages
the fasta_merge command (which came after gff3_merge) has completed
correctly, with all proteins and transcripts accounted for.
I just ran the same contigs again in smaller batches, and it seems to be
proceeding correctly (the final gff3 files are between 49-55MB for each
chunk of fasta files. In the previous case, the final GFF3 file was 99MB
or 100MB (which is why I thought there was some sort of filesize/memory
limit)

Thanks for looking into this,

- Sujai




On 24 October 2013 21:42, Barry Moore <barry... at genetics.utah.edu <>>
wrote:

Hi Sujai,
There are a couple of fatal errors that can be thrown by gff3_merge if it
encounters errors.  Did you capture STDERR and do you see any failures
there?

B

On Oct 24, 2013, at 10:43 AM, Sujai wrote:




Hi all
First of all, thank you to Carson Holt and Mark Yandell and team for an
excellent program with excellent installation instructions. Setting maker
2.28 up and running it (both with MPI and without) was a breeze on a PBS
cluster. Everything worked as expected (doesn't happen that often in
bioinformatics software! :-))

I did a test run on 150 longish contigs (>50kb each) and everything worked
fine, including gff3_merge, fasta_merge etc. I got predictions for all the
contigs etc.


However, when I ran it on the full 20,000 sequence file (minimum 300 bp, I
know - I could have set the min length in maker_opts.ctl but I wanted the
repeatmasker analysis done even for the smaller contigs), I had a problem:

1. the intermediate files were all fine (i.e. grep -c FINISHED
...master_datastore_index.log showed the right number of sequences)

2. But gff3_merge -d ...master_datastore_index.log  only gave a file with
about 9000 contigs. I ran it a few times and got the same result each
time. fasta_merge gave back sequences from all ~20,000 contigs, so I know
the contig_datastore was fine.

3. Could it be that gff3_merge hit some sort of output limit? the GFF3
file created seems to be almost exactly 100MB. Or could it be a limit of
my OS environment? I had a lot of memory (12 GB) and a large tmp directory
(10 GB) so that should not be a problem...

If anyone has seen this problem or can shed any light on this, that would
be great.

I'm going to try splitting the file into smaller sets and hoping for the
best.

Thanks

- Sujai




-- 
You received this message because you are subscribed to the Google Groups
"maker-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to maker-devel... at googlegroups.com <>.
To post to this group, send email to maker... at googlegroups.com <>.
Visit this group at http://groups.google.com/group/maker-devel.
For more options, visit https://groups.google.com/groups/opt_out.




Barry Moore
Research Scientist
Dept. of Human Genetics
University of Utah
Salt Lake City, UT 84112
--------------------------------------------
(801) 585-3543









-- 
You received this message because you are subscribed to a topic in the
Google Groups "maker-devel" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/maker-devel/bApnLPFgmRc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
maker-devel... at googlegroups.com <>.
To post to this group, send email to maker... at googlegroups.com <>.
Visit this group at http://groups.google.com/group/maker-devel.
For more options, visit https://groups.google.com/groups/opt_out.






-- 
You received this message because you are subscribed to the Google Groups
"maker-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to maker-devel... at googlegroups.com <>.
To post to this group, send email to maker... at googlegroups.com <>.
Visit this group at http://groups.google.com/group/maker-devel.
For more options, visit https://groups.google.com/groups/opt_out.




Barry Moore
Research Scientist
Dept. of Human Genetics
University of Utah
Salt Lake City, UT 84112
--------------------------------------------
(801) 585-3543














From sujaikumar at gmail.com  Tue Nov 19 01:33:06 2013
From: sujaikumar at gmail.com (Sujai)
Date: Tue, 19 Nov 2013 08:33:06 +0000
Subject: [maker-devel] gff3_merge error - only half the contigs are
	reported
In-Reply-To: <CEAFD381.2B146%ejr@stowers.org>
References: <CEAFD381.2B146%ejr@stowers.org>
Message-ID: <CAFADFFu7Re=kRTB6qbS3qjhAEGQ0DmbJeJ3wPBq-QonM9VYDtQ@mail.gmail.com>

Hi Eric

Thanks for uncovering the /tmp limitation. I had changed TMPDIR in my
maker_opts.ctl file, but I suppose gff3_merge would not use that setting,
and would use /tmp or whatever TMPDIR was set to in the current shell.

Cheers,

- Sujai



On 18 November 2013 20:24, Ross, Eric <ejr at stowers.org> wrote:

> I had the same problem Sujai reported  on the 25th.
>
> When I run gff3_merge I only get back results from a subset of my
> scaffolds.  Every scaffold has a gff file in the data store.  fasta_merge
> works fine.  No errors are printed to STDOUT.
>
> It took me some poking around, but this seems that if there is
> insufficient space in /tmp to generate the temporary files merge_gff3
> completes without error and just creates a gff file from whatever fit in
> the temporary files.  I'm not sure why tempfile() doesn't return a useful
> error.
>
> I was able to get around the error by setting the environment variable
> TMPDIR to someplace with sufficient space, but if there is a way to
> generate a useful error it might be worth adding.
>
>
> Eric
>
>
>
>
> --original below--
> On Friday, October 25, 2013 11:22:08 AM UTC-5, Barry wrote:
> Hi Sujai,
> If you still have that original directory available a couple things you to
> try:
>
> # Does this give you the number of contigs you're expecting?
> find datastore_directory -name '*.gff3' | wc -l
>
> # If the above gives what you expect what does the file size look like on
> the smallest files?
> find ./ -type f | xargs ls -Sl | tail
>
> Barry
>
> On Oct 24, 2013, at 4:04 PM, Sujai wrote:
>
>
> Hi Barry
>
> The last stderr message in the job is from the maker command:
>
> Maker is now finished!!!
>
> my last 3 commands were (in my pbs/torque job script):
>
> ----job script----
> ...other commands to set variables etc...
> mpiexec -n 12 maker -g $SPLITFILE -base $SPLITFILE maker_opts.ctl
> maker_bopts.ctl maker_exe.ctl
> gff3_merge -o $PBS_O_WORKDIR/$SPLITFILE.gff3 -d
> $SPLITFILE.maker.output/${SPLITFILE}_master_datastore_index.log
> fasta_merge -d
> $SPLITFILE.maker.output/${SPLITFILE}_master_datastore_index.log
> -----
>
> so, no gff3_merge stderr messages
> the fasta_merge command (which came after gff3_merge) has completed
> correctly, with all proteins and transcripts accounted for.
> I just ran the same contigs again in smaller batches, and it seems to be
> proceeding correctly (the final gff3 files are between 49-55MB for each
> chunk of fasta files. In the previous case, the final GFF3 file was 99MB
> or 100MB (which is why I thought there was some sort of filesize/memory
> limit)
>
> Thanks for looking into this,
>
> - Sujai
>
>
>
>
> On 24 October 2013 21:42, Barry Moore <barry... at genetics.utah.edu <>>
> wrote:
>
> Hi Sujai,
> There are a couple of fatal errors that can be thrown by gff3_merge if it
> encounters errors.  Did you capture STDERR and do you see any failures
> there?
>
> B
>
> On Oct 24, 2013, at 10:43 AM, Sujai wrote:
>
>
>
>
> Hi all
> First of all, thank you to Carson Holt and Mark Yandell and team for an
> excellent program with excellent installation instructions. Setting maker
> 2.28 up and running it (both with MPI and without) was a breeze on a PBS
> cluster. Everything worked as expected (doesn't happen that often in
> bioinformatics software! :-))
>
> I did a test run on 150 longish contigs (>50kb each) and everything worked
> fine, including gff3_merge, fasta_merge etc. I got predictions for all the
> contigs etc.
>
>
> However, when I ran it on the full 20,000 sequence file (minimum 300 bp, I
> know - I could have set the min length in maker_opts.ctl but I wanted the
> repeatmasker analysis done even for the smaller contigs), I had a problem:
>
> 1. the intermediate files were all fine (i.e. grep -c FINISHED
> ...master_datastore_index.log showed the right number of sequences)
>
> 2. But gff3_merge -d ...master_datastore_index.log  only gave a file with
> about 9000 contigs. I ran it a few times and got the same result each
> time. fasta_merge gave back sequences from all ~20,000 contigs, so I know
> the contig_datastore was fine.
>
> 3. Could it be that gff3_merge hit some sort of output limit? the GFF3
> file created seems to be almost exactly 100MB. Or could it be a limit of
> my OS environment? I had a lot of memory (12 GB) and a large tmp directory
> (10 GB) so that should not be a problem...
>
> If anyone has seen this problem or can shed any light on this, that would
> be great.
>
> I'm going to try splitting the file into smaller sets and hoping for the
> best.
>
> Thanks
>
> - Sujai
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "maker-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to maker-devel... at googlegroups.com <>.
> To post to this group, send email to maker... at googlegroups.com <>.
> Visit this group at http://groups.google.com/group/maker-devel.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
> Barry Moore
> Research Scientist
> Dept. of Human Genetics
> University of Utah
> Salt Lake City, UT 84112
> --------------------------------------------
> (801) 585-3543
>
>
>
>
>
>
>
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "maker-devel" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/maker-devel/bApnLPFgmRc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> maker-devel... at googlegroups.com <>.
> To post to this group, send email to maker... at googlegroups.com <>.
> Visit this group at http://groups.google.com/group/maker-devel.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "maker-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to maker-devel... at googlegroups.com <>.
> To post to this group, send email to maker... at googlegroups.com <>.
> Visit this group at http://groups.google.com/group/maker-devel.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
> Barry Moore
> Research Scientist
> Dept. of Human Genetics
> University of Utah
> Salt Lake City, UT 84112
> --------------------------------------------
> (801) 585-3543
>
>
>
>
>
>
>
>
>
>
>
> On Friday, October 25, 2013 11:22:08 AM UTC-5, Barry wrote:
> Hi Sujai,
> If you still have that original directory available a couple things you to
> try:
>
> # Does this give you the number of contigs you're expecting?
> find datastore_directory -name '*.gff3' | wc -l
>
> # If the above gives what you expect what does the file size look like on
> the smallest files?
> find ./ -type f | xargs ls -Sl | tail
>
> Barry
>
> On Oct 24, 2013, at 4:04 PM, Sujai wrote:
>
>
> Hi Barry
>
> The last stderr message in the job is from the maker command:
>
> Maker is now finished!!!
>
> my last 3 commands were (in my pbs/torque job script):
>
> ----job script----
> ...other commands to set variables etc...
> mpiexec -n 12 maker -g $SPLITFILE -base $SPLITFILE maker_opts.ctl
> maker_bopts.ctl maker_exe.ctl
> gff3_merge -o $PBS_O_WORKDIR/$SPLITFILE.gff3 -d
> $SPLITFILE.maker.output/${SPLITFILE}_master_datastore_index.log
> fasta_merge -d
> $SPLITFILE.maker.output/${SPLITFILE}_master_datastore_index.log
> -----
>
> so, no gff3_merge stderr messages
> the fasta_merge command (which came after gff3_merge) has completed
> correctly, with all proteins and transcripts accounted for.
> I just ran the same contigs again in smaller batches, and it seems to be
> proceeding correctly (the final gff3 files are between 49-55MB for each
> chunk of fasta files. In the previous case, the final GFF3 file was 99MB
> or 100MB (which is why I thought there was some sort of filesize/memory
> limit)
>
> Thanks for looking into this,
>
> - Sujai
>
>
>
>
> On 24 October 2013 21:42, Barry Moore <barry... at genetics.utah.edu <>>
> wrote:
>
> Hi Sujai,
> There are a couple of fatal errors that can be thrown by gff3_merge if it
> encounters errors.  Did you capture STDERR and do you see any failures
> there?
>
> B
>
> On Oct 24, 2013, at 10:43 AM, Sujai wrote:
>
>
>
>
> Hi all
> First of all, thank you to Carson Holt and Mark Yandell and team for an
> excellent program with excellent installation instructions. Setting maker
> 2.28 up and running it (both with MPI and without) was a breeze on a PBS
> cluster. Everything worked as expected (doesn't happen that often in
> bioinformatics software! :-))
>
> I did a test run on 150 longish contigs (>50kb each) and everything worked
> fine, including gff3_merge, fasta_merge etc. I got predictions for all the
> contigs etc.
>
>
> However, when I ran it on the full 20,000 sequence file (minimum 300 bp, I
> know - I could have set the min length in maker_opts.ctl but I wanted the
> repeatmasker analysis done even for the smaller contigs), I had a problem:
>
> 1. the intermediate files were all fine (i.e. grep -c FINISHED
> ...master_datastore_index.log showed the right number of sequences)
>
> 2. But gff3_merge -d ...master_datastore_index.log  only gave a file with
> about 9000 contigs. I ran it a few times and got the same result each
> time. fasta_merge gave back sequences from all ~20,000 contigs, so I know
> the contig_datastore was fine.
>
> 3. Could it be that gff3_merge hit some sort of output limit? the GFF3
> file created seems to be almost exactly 100MB. Or could it be a limit of
> my OS environment? I had a lot of memory (12 GB) and a large tmp directory
> (10 GB) so that should not be a problem...
>
> If anyone has seen this problem or can shed any light on this, that would
> be great.
>
> I'm going to try splitting the file into smaller sets and hoping for the
> best.
>
> Thanks
>
> - Sujai
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "maker-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to maker-devel... at googlegroups.com <>.
> To post to this group, send email to maker... at googlegroups.com <>.
> Visit this group at http://groups.google.com/group/maker-devel.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
> Barry Moore
> Research Scientist
> Dept. of Human Genetics
> University of Utah
> Salt Lake City, UT 84112
> --------------------------------------------
> (801) 585-3543
>
>
>
>
>
>
>
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "maker-devel" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/maker-devel/bApnLPFgmRc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> maker-devel... at googlegroups.com <>.
> To post to this group, send email to maker... at googlegroups.com <>.
> Visit this group at http://groups.google.com/group/maker-devel.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "maker-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to maker-devel... at googlegroups.com <>.
> To post to this group, send email to maker... at googlegroups.com <>.
> Visit this group at http://groups.google.com/group/maker-devel.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
> Barry Moore
> Research Scientist
> Dept. of Human Genetics
> University of Utah
> Salt Lake City, UT 84112
> --------------------------------------------
> (801) 585-3543
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> maker-devel mailing list
> maker-devel at box290.bluehost.com
> http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131119/7daa435c/attachment-0001.html>

From carson.holt at genetics.utah.edu  Tue Nov 26 08:38:10 2013
From: carson.holt at genetics.utah.edu (Carson Holt)
Date: Tue, 26 Nov 2013 15:38:10 +0000
Subject: [maker-devel] no protein or transcript fasta output
In-Reply-To: <CAKbGhzW-uqNtpEmoOG-ygf6au06gQSmZUfuGpd=1PtFTD9MLtQ@mail.gmail.com>
References: <CAKbGhzW-uqNtpEmoOG-ygf6au06gQSmZUfuGpd=1PtFTD9MLtQ@mail.gmail.com>
Message-ID: <CEBA0E41.7169%carson.holt@genetics.utah.edu>

What version are you running?

Thanks,
Carson


From: mun hua <mh.tan85 at gmail.com<mailto:mh.tan85 at gmail.com>>
Date: Tuesday, November 26, 2013 at 2:32 AM
To: <maker-devel at yandell-lab.org<mailto:maker-devel at yandell-lab.org>>
Subject: no protein or transcript fasta output

Hi,

I tried out the example outlined by Maker, on the dpp_contig dataset.
Upon running maker, it only generated the gff output file, and none of the protein or transcript fasta files. I've checked the logs but have not seen any obvious errors.
Does anyone have any idea on why this is for me?

Thanks,
MH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131126/3ec95f21/attachment-0001.html>

From mh.tan85 at gmail.com  Tue Nov 26 02:32:04 2013
From: mh.tan85 at gmail.com (mun hua)
Date: Tue, 26 Nov 2013 17:32:04 +0800
Subject: [maker-devel] no protein or transcript fasta output
Message-ID: <CAKbGhzW-uqNtpEmoOG-ygf6au06gQSmZUfuGpd=1PtFTD9MLtQ@mail.gmail.com>

Hi,

I tried out the example outlined by Maker, on the dpp_contig dataset.
Upon running maker, it only generated the gff output file, and none of the
protein or transcript fasta files. I've checked the logs but have not seen
any obvious errors.
Does anyone have any idea on why this is for me?

Thanks,
MH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131126/8a6d4e21/attachment-0001.html>

From mh.tan85 at gmail.com  Tue Nov 26 18:03:45 2013
From: mh.tan85 at gmail.com (mun hua)
Date: Wed, 27 Nov 2013 09:03:45 +0800
Subject: [maker-devel] no protein or transcript fasta output
In-Reply-To: <CEBA0E41.7169%carson.holt@genetics.utah.edu>
References: <CAKbGhzW-uqNtpEmoOG-ygf6au06gQSmZUfuGpd=1PtFTD9MLtQ@mail.gmail.com>
	<CEBA0E41.7169%carson.holt@genetics.utah.edu>
Message-ID: <CAKbGhzWYr-6Sx4hVEq-1bPeQ5fZgNWxeF+61KYWZ8+0F-jNKow@mail.gmail.com>

I'm running Maker v2.28.

I tried Maker with protein2genome=1 instead of the recommended est2genome=1
and I managed to get transcript and protein fasta sequences.
That is strange, since I supplied the config file with both
the dpp_est.fasta and dpp_protein.fasta files?


On Tue, Nov 26, 2013 at 11:38 PM, Carson Holt <carson.holt at genetics.utah.edu
> wrote:

>  What version are you running?
>
>  Thanks,
> Carson
>
>
>   From: mun hua <mh.tan85 at gmail.com>
> Date: Tuesday, November 26, 2013 at 2:32 AM
> To: <maker-devel at yandell-lab.org>
> Subject: no protein or transcript fasta output
>
>  Hi,
>
>  I tried out the example outlined by Maker, on the dpp_contig dataset.
> Upon running maker, it only generated the gff output file, and none of the
> protein or transcript fasta files. I've checked the logs but have not seen
> any obvious errors.
> Does anyone have any idea on why this is for me?
>
>  Thanks,
> MH
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131127/eb47d812/attachment-0001.html>

From carsonhh at gmail.com  Sun Nov  3 20:16:03 2013
From: carsonhh at gmail.com (Carson Holt)
Date: Sun, 3 Nov 2013 20:16:03 -0700
Subject: [maker-devel] Serious Start Codon Problem
In-Reply-To: <CE8EE16A.212BC%graham.etherington@sainsbury-laboratory.ac.uk>
References: <CE7FA55D.10C4B%carsonhh@gmail.com>
	<CE8EE16A.212BC%graham.etherington@sainsbury-laboratory.ac.uk>
Message-ID: <CA+sW3ERmNDH2kO6616yLGZS3iJ2Z0XEUu_qL++iHN8HVo3_reA@mail.gmail.com>

2.30 beta is now available for use.  Sorry about the delay, between moving
and getting seriously ill for several days, I sort of dropped off the grid
for 2 weeks.  Give this version a try.

Thanks,
Carson




On Thu, Oct 24, 2013 at 7:42 AM, graham etherington (TSL) <
graham.etherington at sainsbury-laboratory.ac.uk> wrote:

> Hi,
> I notice that the latest version of Maker available from
> http://www.yandell-lab.org/software/maker.html is still v2.29b (4 Oct
> 2013). As we're also having the start codon problem we'd like to get hold
> of v2.30. Do you know when this will be released?
> Many thanks,
> Graham
>
>
> Dr. Graham Etherington
> Bioinformatics Support Officer,
> The Sainsbury Laboratory,
> Norwich Research Park,
> Norwich NR4 7UH.
> UK
> Tel: +44 (0)1603 450601
>
>
>
>
>
> On 13/10/2013 06:26, "Carson Holt" <carsonhh at gmail.com> wrote:
>
> >Before Wednesday, because after that I'm on a 6 day road trip, so I have
> >to have it wrapped up before I leave.
> >
> >--Carson
> >
> >
> >
> >
> >On 10/12/13 12:16 PM, "Felix Bemm" <felix.bemm at uni-wuerzburg.de> wrote:
> >
> >>Thx Carson! Do you now when 2.30 will be available? Bests
> >>
> >>On 12.10.2013 17:48, Carson Holt wrote:
> >>> This issue just came up this week on another e-mail as well.
> >>>
> >>> One way to fix it, is to edit the Bio::Tools::CodonTable module from
> >>> BioPerl (use maker --debug to have maker print out the locations of all
> >>> modules it uses).  Such a hack should only be done as a temporary work
> >>> around.
> >>>
> >>> You change line 256 from -->
> >>> ---M---------------M---------------M----------------------------
> >>>
> >>> To-->
> >>> -----------------------------------M----------------------------
> >>>
> >>>
> >>> Maker uses the BioPerl is_start_codon function to determine if the
> >>>codon
> >>> used in a result it receives is acceptable or if it should look
> >>>upstream
> >>> or downstream for a different one. Apparently there are actually 3
> >>> acceptable start codons in the standard codon table (2 rare ones and
> >>>one
> >>> common), so making the edit removes the two rare ones from the list.
> >>>
> >>> I'm also preparing a 2.30 release that exports a "strict" codon table
> >>>to
> >>> the BioPerl module, that will be used by default and should fix the
> >>>issue.
> >>>
> >>> Thanks,
> >>> Carson
> >>>
> >>>
> >>>
> >>> On 10/12/13 11:06 AM, "Felix Bemm" <felix.bemm at uni-wuerzburg.de>
> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> I have a serious problems with maker annotations especially the start
> >>>> codon placement. It started happening with maker version 2.27! About
> >>>>1/3
> >>>> of my genes are missing a proper start codon. When reviewing the GFF
> >>>> files gene predictors and est evidence standalone would predict the
> >>>> right gene structure including the start codon. I was thinking that
> >>>>this
> >>>> problem was somehow linked to my gene models but looking at their
> >>>> standalone prediction I discarded that theory. Just some stats about
> >>>> proteins with proper start codon (first column) and missing start
> >>>>codon
> >>>> (second column).
> >>>>
> >>>> Maker              9268    4215
> >>>> SNAP               16577   896
> >>>> Genemark   18764   290
> >>>>
> >>>> Numbers look the same when Augustus is used (currently retraining).
> >>>> Manually using EST's in Apollo often fixes the problems but I don't
> >>>>want
> >>>> to check > 4000 genes for this.
> >>>>
> >>>> Do you have any idea what could cause such a problem? If you need some
> >>>> example gff files I can send you.
> >>>>
> >>>> Best regards
> >>>> Felix
> >>>>
> >>>> --
> >>>> Felix Bemm
> >>>> Department of Bioinformatics
> >>>> University of W?rzburg, Germany
> >>>> Tel: +49 931 - 31 83696
> >>>> Fax: +49 931 - 31 84552
> >>>> felix.bemm at uni-wuerzburg.de
> >>>>
> >>>> _______________________________________________
> >>>> maker-devel mailing list
> >>>> maker-devel at box290.bluehost.com
> >>>>
> >>>>
> http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
> >>
> >>--
> >>Felix Bemm
> >>Department of Bioinformatics
> >>University of W?rzburg, Germany
> >>Tel: +49 931 - 31 83696
> >>Fax: +49 931 - 31 84552
> >>felix.bemm at uni-wuerzburg.de
> >
> >
> >
> >_______________________________________________
> >maker-devel mailing list
> >maker-devel at box290.bluehost.com
> >http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131103/136b60b8/attachment-0002.html>

From jfierst at uoregon.edu  Mon Nov  4 09:50:36 2013
From: jfierst at uoregon.edu (Janna Fierst)
Date: Mon, 4 Nov 2013 08:50:36 -0800
Subject: [maker-devel] Serious Start Codon Problem
In-Reply-To: <CA+sW3ERmNDH2kO6616yLGZS3iJ2Z0XEUu_qL++iHN8HVo3_reA@mail.gmail.com>
References: <CE7FA55D.10C4B%carsonhh@gmail.com>
	<CE8EE16A.212BC%graham.etherington@sainsbury-laboratory.ac.uk>
	<CA+sW3ERmNDH2kO6616yLGZS3iJ2Z0XEUu_qL++iHN8HVo3_reA@mail.gmail.com>
Message-ID: <CAGoyurYpCrzcpZeTpYhaQZqZr5a8ZNwBs5UZ88+CPez1nhTA6w@mail.gmail.com>

Hi,

I can't get my message to post to the list but I had a problem with
2.29-beta in parallel - it seemed to restart the same scaffolds over and
over instead of moving on to a new set. I was running the same as the 2.28
version, is it something with our mpi system here at UO? Thanks -Janna
Fierst


On Sun, Nov 3, 2013 at 7:16 PM, Carson Holt <carsonhh at gmail.com> wrote:

> 2.30 beta is now available for use.  Sorry about the delay, between moving
> and getting seriously ill for several days, I sort of dropped off the grid
> for 2 weeks.  Give this version a try.
>
> Thanks,
> Carson
>
>
>
>
> On Thu, Oct 24, 2013 at 7:42 AM, graham etherington (TSL) <
> graham.etherington at sainsbury-laboratory.ac.uk> wrote:
>
>> Hi,
>> I notice that the latest version of Maker available from
>> http://www.yandell-lab.org/software/maker.html is still v2.29b (4 Oct
>> 2013). As we're also having the start codon problem we'd like to get hold
>> of v2.30. Do you know when this will be released?
>> Many thanks,
>> Graham
>>
>>
>> Dr. Graham Etherington
>> Bioinformatics Support Officer,
>> The Sainsbury Laboratory,
>> Norwich Research Park,
>> Norwich NR4 7UH.
>> UK
>> Tel: +44 (0)1603 450601
>>
>>
>>
>>
>>
>> On 13/10/2013 06:26, "Carson Holt" <carsonhh at gmail.com> wrote:
>>
>> >Before Wednesday, because after that I'm on a 6 day road trip, so I have
>> >to have it wrapped up before I leave.
>> >
>> >--Carson
>> >
>> >
>> >
>> >
>> >On 10/12/13 12:16 PM, "Felix Bemm" <felix.bemm at uni-wuerzburg.de> wrote:
>> >
>> >>Thx Carson! Do you now when 2.30 will be available? Bests
>> >>
>> >>On 12.10.2013 17:48, Carson Holt wrote:
>> >>> This issue just came up this week on another e-mail as well.
>> >>>
>> >>> One way to fix it, is to edit the Bio::Tools::CodonTable module from
>> >>> BioPerl (use maker --debug to have maker print out the locations of
>> all
>> >>> modules it uses).  Such a hack should only be done as a temporary work
>> >>> around.
>> >>>
>> >>> You change line 256 from -->
>> >>> ---M---------------M---------------M----------------------------
>> >>>
>> >>> To-->
>> >>> -----------------------------------M----------------------------
>> >>>
>> >>>
>> >>> Maker uses the BioPerl is_start_codon function to determine if the
>> >>>codon
>> >>> used in a result it receives is acceptable or if it should look
>> >>>upstream
>> >>> or downstream for a different one. Apparently there are actually 3
>> >>> acceptable start codons in the standard codon table (2 rare ones and
>> >>>one
>> >>> common), so making the edit removes the two rare ones from the list.
>> >>>
>> >>> I'm also preparing a 2.30 release that exports a "strict" codon table
>> >>>to
>> >>> the BioPerl module, that will be used by default and should fix the
>> >>>issue.
>> >>>
>> >>> Thanks,
>> >>> Carson
>> >>>
>> >>>
>> >>>
>> >>> On 10/12/13 11:06 AM, "Felix Bemm" <felix.bemm at uni-wuerzburg.de>
>> wrote:
>> >>>
>> >>>> Hi,
>> >>>>
>> >>>> I have a serious problems with maker annotations especially the start
>> >>>> codon placement. It started happening with maker version 2.27! About
>> >>>>1/3
>> >>>> of my genes are missing a proper start codon. When reviewing the GFF
>> >>>> files gene predictors and est evidence standalone would predict the
>> >>>> right gene structure including the start codon. I was thinking that
>> >>>>this
>> >>>> problem was somehow linked to my gene models but looking at their
>> >>>> standalone prediction I discarded that theory. Just some stats about
>> >>>> proteins with proper start codon (first column) and missing start
>> >>>>codon
>> >>>> (second column).
>> >>>>
>> >>>> Maker              9268    4215
>> >>>> SNAP               16577   896
>> >>>> Genemark   18764   290
>> >>>>
>> >>>> Numbers look the same when Augustus is used (currently retraining).
>> >>>> Manually using EST's in Apollo often fixes the problems but I don't
>> >>>>want
>> >>>> to check > 4000 genes for this.
>> >>>>
>> >>>> Do you have any idea what could cause such a problem? If you need
>> some
>> >>>> example gff files I can send you.
>> >>>>
>> >>>> Best regards
>> >>>> Felix
>> >>>>
>> >>>> --
>> >>>> Felix Bemm
>> >>>> Department of Bioinformatics
>> >>>> University of W?rzburg, Germany
>> >>>> Tel: +49 931 - 31 83696
>> >>>> Fax: +49 931 - 31 84552
>> >>>> felix.bemm at uni-wuerzburg.de
>> >>>>
>> >>>> _______________________________________________
>> >>>> maker-devel mailing list
>> >>>> maker-devel at box290.bluehost.com
>> >>>>
>> >>>>
>> http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>> >>
>> >>--
>> >>Felix Bemm
>> >>Department of Bioinformatics
>> >>University of W?rzburg, Germany
>> >>Tel: +49 931 - 31 83696
>> >>Fax: +49 931 - 31 84552
>> >>felix.bemm at uni-wuerzburg.de
>> >
>> >
>> >
>> >_______________________________________________
>> >maker-devel mailing list
>> >maker-devel at box290.bluehost.com
>> >http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>>
>>
>
> _______________________________________________
> maker-devel mailing list
> maker-devel at box290.bluehost.com
> http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131104/415de8e4/attachment-0002.html>

From marc.hoeppner at imbim.uu.se  Tue Nov  5 01:55:31 2013
From: marc.hoeppner at imbim.uu.se (Marc P. Hoeppner)
Date: Tue, 05 Nov 2013 09:55:31 +0100
Subject: [maker-devel] Maker and external ab-inito predictions
Message-ID: <5278B283.3000601@imbim.uu.se>

Hi,

this is possibly a trivial question, but I am realizing that Maker does 
not seem to process augustus files I have produced externally (augustus 
2.7); at least they don't seem to make it into the final annotation file.

My question(s) therefore:

1) What exact GFF features does maker expect for a 'pred_gff' file? 
Would it happily accept an augustus gff, or would I need to modify the 
native augustus features somehow? (Trying to find out whether this is a 
Maker issue or some other problem)

2) Is there a way to feed hint files to Maker to use with augustus? 
Couldn't find anything about that specifically anyway.

Regards,

Marc

-- 
-----------
Marc P. Hoeppner, PhD
Researcher
Department of Medical Biochemistry and Microbiology
Uppsala University, Sweden
marc.hoepner at imbim.uu.se




From smg283 at gmail.com  Tue Nov  5 17:53:55 2013
From: smg283 at gmail.com (Scott Geib)
Date: Tue, 5 Nov 2013 14:53:55 -1000
Subject: [maker-devel] running maker on tacc stampede
Message-ID: <CAH221buRe6jsRyeVnkup3bhf3fbHJp+hW+TEgOpzTmbmZ8TOBA@mail.gmail.com>

Hi,
I was looking for help running maker on stampede at tacc.  Have run in the
past on lonestar with no issues, but am getting some errors on stampede
(have never run before on stampede.  I also tried downloading the same
maker version on lonestar and running the same test data and had no issues.
 In both cases, used TACC module command to load more current perl into my
environment before installing maker.  On lonestar, SGE is used so
submission script slightly different in syntax, but ran with same
parameters. I know repbase isn't installed, but I just wanted to get
software working
Thanks Scott


Using this SLURM script with the current maker beta release (30),
submitting with sbatch on dpp test data in a copy of maker data directory:

#!/bin/bash
#SBATCH -J testmaker
#SBATCH -o testmaker.o%J
#SBATCH -e testmaker.e%J
##SBATCH -N 2
#SBATCH -n 32
#SBATCH -p development
#SBATCH -t 2:00:00
#SBATCH --mail-user=XXXXXX
#SBATCH --mail-type=all

ibrun ../maker/bin/maker -base test


This results in the following errors in testmaker.ejobid:

STATUS: Parsing control files...
WARNING: RepBase is not installed for RepeatMasker. This limits
RepeatMasker's functionality and makes the model_org option in the
control files virtually meaningless. MAKER will now reconfigure
for simple repeat masking only.
STATUS: Processing and indexing input FASTA files...
[c559-001.stampede.tacc.utexas.edu:mpi_rank_2][error_sighandler] Caught
error: Segmentation fault (signal 11)
[c559-001.stampede.tacc.utexas.edu:mpispawn_0][child_handler] MPI process
(rank: 2, pid: 35423) terminated with signal 11 -> abort job
SIGINT received
SIGINT received
SIGINT received
SIGINT received
SIGINT received
SIGINT received
SIGINT received
SIGINT received
SIGINT received
SIGINT received
SIGINT received
[c559-001.stampede.tacc.utexas.edu:mpi_rank_1][error_sighandler] Caught
error: Segmentation fault (signal 11)
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
        eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
forks.pm line 609
        threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
line 586
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
        eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
forks.pm line 609
        threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
line 586
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
        eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
forks.pm line 609
        threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
line 586
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        eval {...} called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        Parallel::Application::MPI::__ANON__() called at
/work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
        Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x55efbc8)') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
        Parallel::Application::MPI::MPI_Recv('SCALAR(0x54f4908)', -2, 1111)
called at /work/02726/pbarc/maker/bin/maker line 530
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
        eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
forks.pm line 609
        threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
line 586
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
        eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
forks.pm line 609
        threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
line 586
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
        eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
forks.pm line 609
        threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
line 586
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
        eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
forks.pm line 609
        threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
line 586
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
        eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
forks.pm line 609
        threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
line 586
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
        eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
forks.pm line 609
        threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
line 586
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
        eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
forks.pm line 609
        threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
line 586

 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        eval {...} called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        Parallel::Application::MPI::__ANON__() called at
/work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
        Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x36ffd10)') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
        Parallel::Application::MPI::MPI_Recv('SCALAR(0x3606080)', 0, 4444)
called at /work/02726/pbarc/maker/bin/maker line 578
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        eval {...} called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        Parallel::Application::MPI::__ANON__() called at
/work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
        Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x4d77a00)') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
        Parallel::Application::MPI::MPI_Recv('SCALAR(0x4c7f080)', 0, 4444)
called at /work/02726/pbarc/maker/bin/maker line 578
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        eval {...} called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        Parallel::Application::MPI::__ANON__() called at
/work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
        Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x418ece0)') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
        Parallel::Application::MPI::MPI_Recv('SCALAR(0x4095080)', 0, 4444)
called at /work/02726/pbarc/maker/bin/maker line 578
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        eval {...} called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        Parallel::Application::MPI::__ANON__() called at
/work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
        Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x3c05a00)') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
        Parallel::Application::MPI::MPI_Recv('SCALAR(0x3b0d080)', 0, 4444)
called at /work/02726/pbarc/maker/bin/maker line 578
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        eval {...} called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        Parallel::Application::MPI::__ANON__() called at
/work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
        Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x3b50a00)') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
        Parallel::Application::MPI::MPI_Recv('SCALAR(0x3a58080)', 0, 4444)
called at /work/02726/pbarc/maker/bin/maker line 578
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        eval {...} called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        Parallel::Application::MPI::__ANON__() called at
/work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
        Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x55cecf0)') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
        Parallel::Application::MPI::MPI_Recv('SCALAR(0x54d5080)', 0, 4444)
called at /work/02726/pbarc/maker/bin/maker line 578
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        eval {...} called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        Parallel::Application::MPI::__ANON__() called at
/work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
        Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x4a7ccf0)') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
        Parallel::Application::MPI::MPI_Recv('SCALAR(0x4983080)', 0, 4444)
called at /work/02726/pbarc/maker/bin/maker line 578
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        eval {...} called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        Parallel::Application::MPI::__ANON__() called at
/work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
        Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x53f1a00)') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
        Parallel::Application::MPI::MPI_Recv('SCALAR(0x52f9080)', 0, 4444)
called at /work/02726/pbarc/maker/bin/maker line 578
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        eval {...} called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        Parallel::Application::MPI::__ANON__() called at
/work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
        Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x367da00)') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
        Parallel::Application::MPI::MPI_Recv('SCALAR(0x3585080)', 0, 4444)
called at /work/02726/pbarc/maker/bin/maker line 578
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 23, pid: 10976) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 20, pid: 10973) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 17, pid: 10970) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 18, pid: 10971) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 19, pid: 10972) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 16, pid: 10969) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 21, pid: 10974) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 22, pid: 10975) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 24, pid: 10977) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 25, pid: 10978) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 26, pid: 10979) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 27, pid: 10980) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 28, pid: 10981) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 29, pid: 10982) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 30, pid: 10983) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 31, pid: 10984) exited with status 2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131105/561e5847/attachment-0002.html>

From carsonhh at gmail.com  Wed Nov  6 00:40:30 2013
From: carsonhh at gmail.com (Carson Holt)
Date: Wed, 6 Nov 2013 00:40:30 -0700
Subject: [maker-devel] Maker and external ab-inito predictions
In-Reply-To: <5278B283.3000601@imbim.uu.se>
References: <5278B283.3000601@imbim.uu.se>
Message-ID: <CA+sW3ETtKzitZurwUdLHbMauBwNYp49HOqhK6iY-AY=Oggwgbg@mail.gmail.com>

1) MAKER prefers match/match_part but should be able to handle any two
level feature or even gene/mRNA/exon/CDS features.  Make sure it's infact
GFF3 and not GTF or GFF2.

2) MAKER builds it's own hints based on the evidence alignments it finds,
providing user generated hint files is not supported.  If you already have
those, you can just run augustus directly, since one of the the main
benefit of MAKER is that it finds the hints for you and you would no longer
need that.

Perhaps you can give more details on what exactly you are trying to do, and
we could help you configure MAKER.

Thanks,
Carson



On Tue, Nov 5, 2013 at 1:55 AM, Marc P. Hoeppner
<marc.hoeppner at imbim.uu.se>wrote:

> Hi,
>
> this is possibly a trivial question, but I am realizing that Maker does
> not seem to process augustus files I have produced externally (augustus
> 2.7); at least they don't seem to make it into the final annotation file.
>
> My question(s) therefore:
>
> 1) What exact GFF features does maker expect for a 'pred_gff' file? Would
> it happily accept an augustus gff, or would I need to modify the native
> augustus features somehow? (Trying to find out whether this is a Maker
> issue or some other problem)
>
> 2) Is there a way to feed hint files to Maker to use with augustus?
> Couldn't find anything about that specifically anyway.
>
> Regards,
>
> Marc
>
> --
> -----------
> Marc P. Hoeppner, PhD
> Researcher
> Department of Medical Biochemistry and Microbiology
> Uppsala University, Sweden
> marc.hoepner at imbim.uu.se
>
>
> _______________________________________________
> maker-devel mailing list
> maker-devel at box290.bluehost.com
> http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131106/779c0953/attachment-0002.html>

From marc.hoeppner at imbim.uu.se  Wed Nov  6 00:45:09 2013
From: marc.hoeppner at imbim.uu.se (Marc P. Hoeppner)
Date: Wed, 06 Nov 2013 08:45:09 +0100
Subject: [maker-devel] Maker and external ab-inito predictions
In-Reply-To: <CA+sW3ETtKzitZurwUdLHbMauBwNYp49HOqhK6iY-AY=Oggwgbg@mail.gmail.com>
References: <5278B283.3000601@imbim.uu.se>
	<CA+sW3ETtKzitZurwUdLHbMauBwNYp49HOqhK6iY-AY=Oggwgbg@mail.gmail.com>
Message-ID: <5279F385.5030005@imbim.uu.se>

Hi Carson,

thanks for the clarification. I saw in the code that the Augustus Widget 
uses hints, but wasn't sure if and how those were generated. If they are 
derived from the evidence alignments, prefect. That's all I needed 
anyway. As for the passing of an external phred_gff, I guess the native 
Augustus GFF output is a little wonky - I'll try to convert it to 
match/match_parts to see if that helps (but with Maker computing it's 
own hints, I don't actually have to...).

Anyway, thanks again!

/Marc
> 1) MAKER prefers match/match_part but should be able to handle any two 
> level feature or even gene/mRNA/exon/CDS features.  Make sure it's 
> infact GFF3 and not GTF or GFF2.
>
> 2) MAKER builds it's own hints based on the evidence alignments it 
> finds, providing user generated hint files is not supported.  If you 
> already have those, you can just run augustus directly, since one of 
> the the main benefit of MAKER is that it finds the hints for you and 
> you would no longer need that.
>
> Perhaps you can give more details on what exactly you are trying to 
> do, and we could help you configure MAKER.
>
> Thanks,
> Carson
>
>
>
> On Tue, Nov 5, 2013 at 1:55 AM, Marc P. Hoeppner 
> <marc.hoeppner at imbim.uu.se <mailto:marc.hoeppner at imbim.uu.se>> wrote:
>
>     Hi,
>
>     this is possibly a trivial question, but I am realizing that Maker
>     does not seem to process augustus files I have produced externally
>     (augustus 2.7); at least they don't seem to make it into the final
>     annotation file.
>
>     My question(s) therefore:
>
>     1) What exact GFF features does maker expect for a 'pred_gff'
>     file? Would it happily accept an augustus gff, or would I need to
>     modify the native augustus features somehow? (Trying to find out
>     whether this is a Maker issue or some other problem)
>
>     2) Is there a way to feed hint files to Maker to use with
>     augustus? Couldn't find anything about that specifically anyway.
>
>     Regards,
>
>     Marc
>
>     -- 
>     -----------
>     Marc P. Hoeppner, PhD
>     Researcher
>     Department of Medical Biochemistry and Microbiology
>     Uppsala University, Sweden
>     marc.hoepner at imbim.uu.se <mailto:marc.hoepner at imbim.uu.se>
>
>
>     _______________________________________________
>     maker-devel mailing list
>     maker-devel at box290.bluehost.com
>     <mailto:maker-devel at box290.bluehost.com>
>     http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>
>


-- 
-----------
Marc P. Hoeppner, PhD
Researcher
Department of Medical Biochemistry and Microbiology
Uppsala University, Sweden
marc.hoepner at imbim.uu.se

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131106/7de0b86d/attachment-0002.html>

From carsonhh at gmail.com  Wed Nov  6 00:53:14 2013
From: carsonhh at gmail.com (Carson Holt)
Date: Wed, 6 Nov 2013 00:53:14 -0700
Subject: [maker-devel] running maker on tacc stampede
In-Reply-To: <CAH221buRe6jsRyeVnkup3bhf3fbHJp+hW+TEgOpzTmbmZ8TOBA@mail.gmail.com>
References: <CAH221buRe6jsRyeVnkup3bhf3fbHJp+hW+TEgOpzTmbmZ8TOBA@mail.gmail.com>
Message-ID: <CA+sW3ETCGE64JDvGc6v3JyOgmV5D1=P96NGTmqmi1k3nm8Uu0A@mail.gmail.com>

We're also seeing core dumps on Lonestar using the same version of MAKER
already installed when we do a "fresh install".  We're not sure why,
because everything should be the same.  Maybe something about what we are
seeing is also related to the issue you are experiencing and maybe not.
 Let me try and figure out what is happening on Lonestar and I'll send you
my install procedure, and maybe that will fix the stampede issue as well.

Thanks,
Carson



On Tue, Nov 5, 2013 at 5:53 PM, Scott Geib <smg283 at gmail.com> wrote:

> Hi,
> I was looking for help running maker on stampede at tacc.  Have run in the
> past on lonestar with no issues, but am getting some errors on stampede
> (have never run before on stampede.  I also tried downloading the same
> maker version on lonestar and running the same test data and had no issues.
>  In both cases, used TACC module command to load more current perl into my
> environment before installing maker.  On lonestar, SGE is used so
> submission script slightly different in syntax, but ran with same
> parameters. I know repbase isn't installed, but I just wanted to get
> software working
> Thanks Scott
>
>
> Using this SLURM script with the current maker beta release (30),
> submitting with sbatch on dpp test data in a copy of maker data directory:
>
> #!/bin/bash
> #SBATCH -J testmaker
> #SBATCH -o testmaker.o%J
> #SBATCH -e testmaker.e%J
> ##SBATCH -N 2
> #SBATCH -n 32
> #SBATCH -p development
> #SBATCH -t 2:00:00
> #SBATCH --mail-user=XXXXXX
> #SBATCH --mail-type=all
>
> ibrun ../maker/bin/maker -base test
>
>
> This results in the following errors in testmaker.ejobid:
>
> STATUS: Parsing control files...
> WARNING: RepBase is not installed for RepeatMasker. This limits
> RepeatMasker's functionality and makes the model_org option in the
> control files virtually meaningless. MAKER will now reconfigure
> for simple repeat masking only.
> STATUS: Processing and indexing input FASTA files...
> [c559-001.stampede.tacc.utexas.edu:mpi_rank_2][error_sighandler] Caught
> error: Segmentation fault (signal 11)
> [c559-001.stampede.tacc.utexas.edu:mpispawn_0][child_handler] MPI process
> (rank: 2, pid: 35423) terminated with signal 11 -> abort job
> SIGINT received
> SIGINT received
> SIGINT received
> SIGINT received
> SIGINT received
> SIGINT received
> SIGINT received
> SIGINT received
> SIGINT received
> SIGINT received
> SIGINT received
> [c559-001.stampede.tacc.utexas.edu:mpi_rank_1][error_sighandler] Caught
> error: Segmentation fault (signal 11)
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
>         eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
> forks.pm line 609
>         threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
> line 586
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
>         eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
> forks.pm line 609
>         threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
> line 586
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
>         eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
> forks.pm line 609
>         threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
> line 586
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         eval {...} called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         Parallel::Application::MPI::__ANON__() called at
> /work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
>         Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x55efbc8)') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
>         Parallel::Application::MPI::MPI_Recv('SCALAR(0x54f4908)', -2,
> 1111) called at /work/02726/pbarc/maker/bin/maker line 530
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
>         eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
> forks.pm line 609
>         threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
> line 586
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
>         eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
> forks.pm line 609
>         threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
> line 586
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
>         eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
> forks.pm line 609
>         threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
> line 586
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
>         eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
> forks.pm line 609
>         threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
> line 586
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
>         eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
> forks.pm line 609
>         threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
> line 586
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
>         eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
> forks.pm line 609
>         threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
> line 586
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
>         eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
> forks.pm line 609
>         threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
> line 586
>
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         eval {...} called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         Parallel::Application::MPI::__ANON__() called at
> /work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
>         Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x36ffd10)') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
>         Parallel::Application::MPI::MPI_Recv('SCALAR(0x3606080)', 0, 4444)
> called at /work/02726/pbarc/maker/bin/maker line 578
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         eval {...} called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         Parallel::Application::MPI::__ANON__() called at
> /work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
>         Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x4d77a00)') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
>         Parallel::Application::MPI::MPI_Recv('SCALAR(0x4c7f080)', 0, 4444)
> called at /work/02726/pbarc/maker/bin/maker line 578
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         eval {...} called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         Parallel::Application::MPI::__ANON__() called at
> /work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
>         Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x418ece0)') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
>         Parallel::Application::MPI::MPI_Recv('SCALAR(0x4095080)', 0, 4444)
> called at /work/02726/pbarc/maker/bin/maker line 578
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         eval {...} called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         Parallel::Application::MPI::__ANON__() called at
> /work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
>         Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x3c05a00)') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
>         Parallel::Application::MPI::MPI_Recv('SCALAR(0x3b0d080)', 0, 4444)
> called at /work/02726/pbarc/maker/bin/maker line 578
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         eval {...} called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         Parallel::Application::MPI::__ANON__() called at
> /work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
>         Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x3b50a00)') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
>         Parallel::Application::MPI::MPI_Recv('SCALAR(0x3a58080)', 0, 4444)
> called at /work/02726/pbarc/maker/bin/maker line 578
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         eval {...} called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         Parallel::Application::MPI::__ANON__() called at
> /work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
>         Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x55cecf0)') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
>         Parallel::Application::MPI::MPI_Recv('SCALAR(0x54d5080)', 0, 4444)
> called at /work/02726/pbarc/maker/bin/maker line 578
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         eval {...} called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         Parallel::Application::MPI::__ANON__() called at
> /work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
>         Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x4a7ccf0)') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
>         Parallel::Application::MPI::MPI_Recv('SCALAR(0x4983080)', 0, 4444)
> called at /work/02726/pbarc/maker/bin/maker line 578
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         eval {...} called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         Parallel::Application::MPI::__ANON__() called at
> /work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
>         Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x53f1a00)') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
>         Parallel::Application::MPI::MPI_Recv('SCALAR(0x52f9080)', 0, 4444)
> called at /work/02726/pbarc/maker/bin/maker line 578
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         eval {...} called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         Parallel::Application::MPI::__ANON__() called at
> /work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
>         Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x367da00)') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
>         Parallel::Application::MPI::MPI_Recv('SCALAR(0x3585080)', 0, 4444)
> called at /work/02726/pbarc/maker/bin/maker line 578
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 23, pid: 10976) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 20, pid: 10973) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 17, pid: 10970) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 18, pid: 10971) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 19, pid: 10972) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 16, pid: 10969) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 21, pid: 10974) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 22, pid: 10975) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 24, pid: 10977) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 25, pid: 10978) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 26, pid: 10979) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 27, pid: 10980) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 28, pid: 10981) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 29, pid: 10982) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 30, pid: 10983) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 31, pid: 10984) exited with status 2
>
>
> _______________________________________________
> maker-devel mailing list
> maker-devel at box290.bluehost.com
> http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131106/ab209d29/attachment-0002.html>

From xh33 at georgetown.edu  Tue Nov  5 11:04:18 2013
From: xh33 at georgetown.edu (Xin Huang)
Date: Tue, 5 Nov 2013 13:04:18 -0500
Subject: [maker-devel] Inquiry about using Exonerate through Maker
Message-ID: <CACvYrQEZR-35Crcmxbp-+CrG+QPs9dz3jkn3u9x++PU6BDF6tA@mail.gmail.com>

Hi,

I have a question regarding the use of Exonerate for cDNA alignment to
genomic scaffolds through Maker.

We first did a blastn search to find out which genomic scaffolds a cDNA
sequence aligns to. There are two scaffolds we figured that host the gene
of interest. So we picked these two scaffolds as the reference genome
sequence in the maker_opts.ctl file. I used the default settings in
maker_bopts.ctl. In the maker_exe.ctl file, the Ab-initio Gene Prediction
Algorithms section has only snap installed. In the maker_opts.ctl file, I
indicated the path to the EST sequence right after "est=" under EST
Evidence, skipped RepeatMasker (when included, only the repeat masking
information was shown in the GFF files) to only do the blast and exonerate,
set "est2genome=1" and left other options at default. In the directory
where we put the Maker output (the control files are all in this
directory), I ran the Maker pipeline using "<path_to_maker> maker_opts.ctl
maker_bopts.ctl maker_exe.ctl". It turned out that there is no alignment
information in the scaffold GFF3 file, just a plain figure indicating that
the scaffold is a contig. Then I tried to use the entire genome scaffold
set as the reference genome and reran the pipeline, still getting the same
results in terms of the Exonerate alignments. Please see the example of a
GFF3 file generated:

##gff-version 3
scaffold3928    .       contig  1       172176  .       .       .
ID=scaffold3928;Name=scaffold3928
###
##FASTA
>scaffold3928
<scaffold_sequence_omitted>

What do I need to adjust to get the alignment information into the GFF file
so I can upload into a genome browser as tracks?

Thank you very much for considering my inquiry.

Sincerely,

Xin Huang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131105/b6a8065e/attachment-0002.html>

From xh33 at georgetown.edu  Tue Nov  5 14:40:24 2013
From: xh33 at georgetown.edu (Xin Huang)
Date: Tue, 5 Nov 2013 16:40:24 -0500
Subject: [maker-devel] A suspected strange behavior of Maker...
Message-ID: <CACvYrQGP1dajOYyhiTDt6QuzCHdVR21vLYzmbtMKvF67d-fMiA@mail.gmail.com>

Hi,

I found a very bizarre thing when I ran Maker several times. The blastn
research seems to reverse query and subject the way it's specified in the
maker_opts.ctl file. When I put the scaffold sequence after genome= and the
cDNA sequence after est=, the blastn result actually used the scaffold as
query and the cDNA as subject. I realized that this sounds unreal, so I
reversed the places for the two and the blastn result is normal with the
cDNA as query and the scaffold as subject, but at the same time, the GFF
file is of the cDNA sequence. I tried a few times, and got the same result.
I deleted Maker (2.28) and reinstalled the beta version (2.30), still
getting the same result.

My wild guess was that this might be the reason why the est2genome
prediction using the EST sequence didn't go into the GFF3 file, as stated
in a previous email to the Maker-devel. I couldn't figure out how to test
this, though. I wonder if there's anything dramatically wrong that I've
been doing to get such odd results... If you'd like me to send you any
output files or control files, please let me know and I'll promptly pass
those along.

Thank you very much for considering my email.

Sincerely,

Xin Huang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131105/f942ccad/attachment-0002.html>

From Kerry_Gendreau at student.uml.edu  Fri Nov  8 16:40:06 2013
From: Kerry_Gendreau at student.uml.edu (Gendreau, Kerry L)
Date: Fri, 8 Nov 2013 23:40:06 +0000
Subject: [maker-devel] Maker is not predicting any genes on scaffold
Message-ID: <ae5739936c8745d9aaf58a434906305b@CO1PR02MB046.namprd02.prod.outlook.com>

Hello,

I am attempting to annotate a small section of an arthropod genome. I ran Maker on the command line and the results showed only repetitive regions recognized by Repeat Masker -- no predicted ORFs. I submitted my scaffold through the web interface and got the same results.

I know that there are genes present on this scaffold and when I run it through Augustus there are 13 ORFs predicted.

Are there some options that I need to adjust to get ab initio gene predictions from Maker?


Thank you,

Kerry Gendreau
Graduate Student, Dept. of Biological Sciences
University of Massachusetts Lowell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131108/ae7546e5/attachment-0002.html>

From dence at genetics.utah.edu  Sun Nov 10 19:43:12 2013
From: dence at genetics.utah.edu (Daniel Ence)
Date: Mon, 11 Nov 2013 02:43:12 +0000
Subject: [maker-devel] Maker is not predicting any genes on scaffold
In-Reply-To: <ae5739936c8745d9aaf58a434906305b@CO1PR02MB046.namprd02.prod.outlook.com>
References: <ae5739936c8745d9aaf58a434906305b@CO1PR02MB046.namprd02.prod.outlook.com>
Message-ID: <F2774D6F47BB9D449EEA8B0BF6679D9C65D3E471@mxb2.hg.genetics.utah.edu>

Hi Kerry, What evidence and abinitios did you use when you ran MAKER on your own machine?

Thanks,
Daniel

Daniel Ence
Graduate Student
Eccles Institute of Human Genetics
University of Utah
15 North 2030 East, Room 2100
Salt Lake City, UT 84112-5330
________________________________
From: maker-devel [maker-devel-bounces at yandell-lab.org] on behalf of Gendreau, Kerry L [Kerry_Gendreau at student.uml.edu]
Sent: Friday, November 08, 2013 4:40 PM
To: maker-devel at yandell-lab.org
Subject: [maker-devel] Maker is not predicting any genes on scaffold

Hello,

I am attempting to annotate a small section of an arthropod genome. I ran Maker on the command line and the results showed only repetitive regions recognized by Repeat Masker -- no predicted ORFs. I submitted my scaffold through the web interface and got the same results.

I know that there are genes present on this scaffold and when I run it through Augustus there are 13 ORFs predicted.

Are there some options that I need to adjust to get ab initio gene predictions from Maker?


Thank you,

Kerry Gendreau
Graduate Student, Dept. of Biological Sciences
University of Massachusetts Lowell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131111/a93b1101/attachment-0002.html>

From carson.holt at genetics.utah.edu  Sun Nov 10 20:08:23 2013
From: carson.holt at genetics.utah.edu (Carson Holt)
Date: Mon, 11 Nov 2013 03:08:23 +0000
Subject: [maker-devel] Problems with Maker
In-Reply-To: <CAC18qO8DbAWchktQpUC=CaPSL446kOj3Jgbt0_S1Ha41oAOh_w@mail.gmail.com>
Message-ID: <CEA59757.69E6%carson.holt@genetics.utah.edu>

For the installation problem, it shouldn't take more tun  few minutes.  You might want to just try setting up repeat masker manually, since what is happening is probably system specific.

The second problem is caused by an edit you made to the maker_opt.ctl file.  You deleted the '#' character that separates the options from the instructions comment, so the entire line is being interpreted as an option

model_org=all select a model organism for RepBase masking in RepeatMasker

So it's trying to use the phrase 'all select a model organism for RepBase masking in RepeatMasker' as the species, which causes repeat masker to fail.

Just change the line to model_org=all

--Carson


From: Sanea Sheikh <saneasheikh at gmail.com<mailto:saneasheikh at gmail.com>>
Date: Thursday, November 7, 2013 8:22 AM
To: <maker-devel at yandell-lab.org<mailto:maker-devel at yandell-lab.org>>
Subject: Problems with Maker

Hello

I am trying to run Maker v2.28 on my computer. I am having two problems.

When I use ./Build repeatmasker command for installing RepeatMasker, I get stuck at the Configuring RepeatMasker step for days. It doesn't move forward from that point. See the log attached (repeatmasker_maker.txt).

When I install RepeatMasker and run Maker, I get error message attached in maker_error_RM.txt file.

Can you please tell me what I am doing wrong here? I have also attached the maker opts.ctl file for your reference. I would really appreciate it if you can help me in this regard.

Regards
Sanea


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131111/f5550f90/attachment-0002.html>

From carsonhh at gmail.com  Sun Nov 10 22:10:08 2013
From: carsonhh at gmail.com (Carson Holt)
Date: Sun, 10 Nov 2013 22:10:08 -0700
Subject: [maker-devel] A suspected strange behavior of Maker...
In-Reply-To: <CACvYrQGP1dajOYyhiTDt6QuzCHdVR21vLYzmbtMKvF67d-fMiA@mail.gmail.com>
Message-ID: <CEA5B2C9.69F9%carsonhh@gmail.com>

Sorry for the slow reply, I was moving from Canada to the US, got sick, and
my moving truck got delayed one week. So I fell behind on the maker list.

What you observe is correct behavior.  The config is blasted against the
database of ESTs/proteins.  It really doesn't matter which way you blast,
you pick the direction that is most efficient for the question you are
asking, and you only have to adjust the Z value for database size if you
want alignment scores to be reproducible both ways.

Not getting results means they were filtered out for some reason (you don't
even have blastn results in your output).  If you can send a test dataset I
can take a look and tell you which filter.

Thanks,
Carson


From:  Xin Huang <xh33 at georgetown.edu>
Date:  Tuesday, November 5, 2013 2:40 PM
To:  <maker-devel at yandell-lab.org>
Subject:  [maker-devel] A suspected strange behavior of Maker...

Hi,

I found a very bizarre thing when I ran Maker several times. The blastn
research seems to reverse query and subject the way it's specified in the
maker_opts.ctl file. When I put the scaffold sequence after genome= and the
cDNA sequence after est=, the blastn result actually used the scaffold as
query and the cDNA as subject. I realized that this sounds unreal, so I
reversed the places for the two and the blastn result is normal with the
cDNA as query and the scaffold as subject, but at the same time, the GFF
file is of the cDNA sequence. I tried a few times, and got the same result.
I deleted Maker (2.28) and reinstalled the beta version (2.30), still
getting the same result.

My wild guess was that this might be the reason why the est2genome
prediction using the EST sequence didn't go into the GFF3 file, as stated in
a previous email to the Maker-devel. I couldn't figure out how to test this,
though. I wonder if there's anything dramatically wrong that I've been doing
to get such odd results... If you'd like me to send you any output files or
control files, please let me know and I'll promptly pass those along.

Thank you very much for considering my email.

Sincerely,

Xin Huang
_______________________________________________ maker-devel mailing list
maker-devel at box290.bluehost.com
http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131110/153ea1e5/attachment-0002.html>

From kpepin at genome.wustl.edu  Mon Nov 11 13:01:26 2013
From: kpepin at genome.wustl.edu (Kymberlie Hallsworth-Pepin)
Date: Mon, 11 Nov 2013 14:01:26 -0600 (CST)
Subject: [maker-devel] re-annotation
In-Reply-To: <CA5CEF3B.6A42%carsonhh@gmail.com>
References: <CA5CEF3B.6A42%carsonhh@gmail.com>
Message-ID: <alpine.DEB.2.00.1311111355190.28492@linus40.gsc.wustl.edu>

Hi Carson,

I am trying to take an existing gene set and update it using new proteins. 
I have the gene set in gff3 format - validated as ok - and have put it in
the model_gff line. I set the protein db to the new database and I set the 
map_forward=1 to maintain naming, but the output has no gene predictions 
in it. I have tried setting keep_preds both 0 and 1. I have put the gff 
file in both the pred_gff and model_gff and just in the pred_gff field, 
but I still don't get any predictions maintained. Can you tell me what I 
might be missing ?

thanks
Kym


____
This email message is a private communication. The information transmitted, including attachments, is intended only for the person or entity to which it is addressed and may contain confidential, privileged, and/or proprietary material. Any review, duplication, retransmission, distribution, or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is unauthorized by the sender and is prohibited. If you have received this message in error, please contact the sender immediately by return email and delete the original message from all computer systems. Thank you.



From cjfields at illinois.edu  Tue Nov 12 12:18:36 2013
From: cjfields at illinois.edu (Fields, Christopher J)
Date: Tue, 12 Nov 2013 19:18:36 +0000
Subject: [maker-devel] Recommendations for visualization?
Message-ID: <9B60EB76-1920-4B75-A224-C44070452B84@illinois.edu>

Barry, Carson,

Are there any recommendations re: visualizing MAKER-generated GFF3?  I know it?s currently geared towards Apollo integration, but as everything is moving towards Webapollo, attempts at finding the old local client Apollo code are a bit of an archaeological expedition (not to mention Apollo has always been a joy to set up from code :).  Is everyone still trying to use the old Apollo, since it seems to no longer be supported?

At the moment I am really thinking of working on simple scripts to make IGV-friendly input (and possibly similar Artemis for our smaller genome projects), but I don?t want to repeat work already in place.

chris


From barry.utah at gmail.com  Tue Nov 12 15:03:12 2013
From: barry.utah at gmail.com (Barry Moore)
Date: Tue, 12 Nov 2013 15:03:12 -0700
Subject: [maker-devel] Recommendations for visualization?
In-Reply-To: <9B60EB76-1920-4B75-A224-C44070452B84@illinois.edu>
References: <9B60EB76-1920-4B75-A224-C44070452B84@illinois.edu>
Message-ID: <90397AC5-7FEA-4B81-8085-49BD48787A6F@genetics.utah.edu>

This is a VERY good point Chris.  I think the new web-apollo is developing into a great tool, but there is now a gapping hole in the area of a desktop application (i.e. no server setup) to view/edit genome annotations.  I'd love to hear what others are using.  Our group has been using a combination of old Apollo instances, Web-Apollo and Gbrowse.

B

On Nov 12, 2013, at 12:18 PM, Fields, Christopher J wrote:

> Barry, Carson,
> 
> Are there any recommendations re: visualizing MAKER-generated GFF3?  I know it?s currently geared towards Apollo integration, but as everything is moving towards Webapollo, attempts at finding the old local client Apollo code are a bit of an archaeological expedition (not to mention Apollo has always been a joy to set up from code :).  Is everyone still trying to use the old Apollo, since it seems to no longer be supported?
> 
> At the moment I am really thinking of working on simple scripts to make IGV-friendly input (and possibly similar Artemis for our smaller genome projects), but I don?t want to repeat work already in place.
> 
> chris
> _______________________________________________
> maker-devel mailing list
> maker-devel at box290.bluehost.com
> http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org

Barry Moore
Research Scientist
Dept. of Human Genetics
University of Utah
Salt Lake City, UT 84112
--------------------------------------------
(801) 585-3543




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131112/863f00a0/attachment-0002.html>

From cjfields at illinois.edu  Tue Nov 12 15:25:21 2013
From: cjfields at illinois.edu (Fields, Christopher J)
Date: Tue, 12 Nov 2013 22:25:21 +0000
Subject: [maker-devel] Recommendations for visualization?
In-Reply-To: <90397AC5-7FEA-4B81-8085-49BD48787A6F@genetics.utah.edu>
References: <9B60EB76-1920-4B75-A224-C44070452B84@illinois.edu>
	<90397AC5-7FEA-4B81-8085-49BD48787A6F@genetics.utah.edu>
Message-ID: <8D26BC0C-74F6-43F4-A29B-10615BF7C6C0@illinois.edu>

I have considered using GMOD in the Cloud (we are likely to set something like this up on our local OpenStack when it?s up and running), but as a quick assessment of a test run it seems a bit overkill.

chris

On Nov 12, 2013, at 4:03 PM, Barry Moore <barry.utah at gmail.com<mailto:barry.utah at gmail.com>> wrote:

This is a VERY good point Chris.  I think the new web-apollo is developing into a great tool, but there is now a gapping hole in the area of a desktop application (i.e. no server setup) to view/edit genome annotations.  I'd love to hear what others are using.  Our group has been using a combination of old Apollo instances, Web-Apollo and Gbrowse.

B

On Nov 12, 2013, at 12:18 PM, Fields, Christopher J wrote:

Barry, Carson,

Are there any recommendations re: visualizing MAKER-generated GFF3?  I know it?s currently geared towards Apollo integration, but as everything is moving towards Webapollo, attempts at finding the old local client Apollo code are a bit of an archaeological expedition (not to mention Apollo has always been a joy to set up from code :).  Is everyone still trying to use the old Apollo, since it seems to no longer be supported?

At the moment I am really thinking of working on simple scripts to make IGV-friendly input (and possibly similar Artemis for our smaller genome projects), but I don?t want to repeat work already in place.

chris
_______________________________________________
maker-devel mailing list
maker-devel at box290.bluehost.com<mailto:maker-devel at box290.bluehost.com>
http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org

Barry Moore
Research Scientist
Dept. of Human Genetics
University of Utah
Salt Lake City, UT 84112
--------------------------------------------
(801) 585-3543





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131112/1ef63aa0/attachment-0002.html>

From carsonhh at gmail.com  Tue Nov 12 21:04:45 2013
From: carsonhh at gmail.com (Carson Holt)
Date: Tue, 12 Nov 2013 21:04:45 -0700
Subject: [maker-devel] re-annotation
In-Reply-To: <alpine.DEB.2.00.1311111355190.28492@linus40.gsc.wustl.edu>
Message-ID: <CEA8485C.6E7B%carsonhh@gmail.com>

They should be maintained.  What version are you using?

--Carson


On 11/11/13 1:01 PM, "Kymberlie Hallsworth-Pepin"
<kpepin at genome.wustl.edu> wrote:

>Hi Carson,
>
>I am trying to take an existing gene set and update it using new
>proteins. 
>I have the gene set in gff3 format - validated as ok - and have put it in
>the model_gff line. I set the protein db to the new database and I set
>the 
>map_forward=1 to maintain naming, but the output has no gene predictions
>in it. I have tried setting keep_preds both 0 and 1. I have put the gff
>file in both the pred_gff and model_gff and just in the pred_gff field,
>but I still don't get any predictions maintained. Can you tell me what I
>might be missing ?
>
>thanks
>Kym
>
>
>____
>This email message is a private communication. The information
>transmitted, including attachments, is intended only for the person or
>entity to which it is addressed and may contain confidential, privileged,
>and/or proprietary material. Any review, duplication, retransmission,
>distribution, or other use of, or taking of any action in reliance upon,
>this information by persons or entities other than the intended recipient
>is unauthorized by the sender and is prohibited. If you have received
>this message in error, please contact the sender immediately by return
>email and delete the original message from all computer systems. Thank
>you.





From kpepin at genome.wustl.edu  Wed Nov 13 06:16:44 2013
From: kpepin at genome.wustl.edu (Kymberlie Hallsworth-Pepin)
Date: Wed, 13 Nov 2013 07:16:44 -0600 (CST)
Subject: [maker-devel] re-annotation
In-Reply-To: <CEA8485C.6E7B%carsonhh@gmail.com>
References: <CEA8485C.6E7B%carsonhh@gmail.com>
Message-ID: <alpine.DEB.2.00.1311130711440.28492@linus40.gsc.wustl.edu>


We are using v2.26. We recreated the gff3 file and I can now get gene 
predictions to show up using the pred_gff file as input for the gene set. 
The naming is not maintained with the map_forward=1 as I would expect, 
just the source field in the input gff file is added to the new maker 
name.  If I change the input to a model_gff file I still do not get 
predictions in the maker gff file.

thanks
Kym




On Tue, 12 Nov 2013, Carson Holt wrote:

> They should be maintained.  What version are you using?
>
> --Carson
>
>
> On 11/11/13 1:01 PM, "Kymberlie Hallsworth-Pepin"
> <kpepin at genome.wustl.edu> wrote:
>
>> Hi Carson,
>>
>> I am trying to take an existing gene set and update it using new
>> proteins.
>> I have the gene set in gff3 format - validated as ok - and have put it in
>> the model_gff line. I set the protein db to the new database and I set
>> the
>> map_forward=1 to maintain naming, but the output has no gene predictions
>> in it. I have tried setting keep_preds both 0 and 1. I have put the gff
>> file in both the pred_gff and model_gff and just in the pred_gff field,
>> but I still don't get any predictions maintained. Can you tell me what I
>> might be missing ?
>>
>> thanks
>> Kym
>>
>>
>> ____
>> This email message is a private communication. The information
>> transmitted, including attachments, is intended only for the person or
>> entity to which it is addressed and may contain confidential, privileged,
>> and/or proprietary material. Any review, duplication, retransmission,
>> distribution, or other use of, or taking of any action in reliance upon,
>> this information by persons or entities other than the intended recipient
>> is unauthorized by the sender and is prohibited. If you have received
>> this message in error, please contact the sender immediately by return
>> email and delete the original message from all computer systems. Thank
>> you.
>

____
This email message is a private communication. The information transmitted, including attachments, is intended only for the person or entity to which it is addressed and may contain confidential, privileged, and/or proprietary material. Any review, duplication, retransmission, distribution, or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is unauthorized by the sender and is prohibited. If you have received this message in error, please contact the sender immediately by return email and delete the original message from all computer systems. Thank you.



From carsonhh at gmail.com  Wed Nov 13 08:06:44 2013
From: carsonhh at gmail.com (Carson Holt)
Date: Wed, 13 Nov 2013 08:06:44 -0700
Subject: [maker-devel] re-annotation
In-Reply-To: <alpine.DEB.2.00.1311130711440.28492@linus40.gsc.wustl.edu>
Message-ID: <CEA8E2DE.6FBF%carsonhh@gmail.com>

So map_forward=1, will only maintain names derived from model_gff onto new
or updated models.  Could you try either 2.28 or 2.30-beta, just to see if
this is something that is already fixed.

Thanks,
Carson


On 11/13/13 6:16 AM, "Kymberlie Hallsworth-Pepin"
<kpepin at genome.wustl.edu> wrote:

>
>We are using v2.26. We recreated the gff3 file and I can now get gene
>predictions to show up using the pred_gff file as input for the gene set.
>The naming is not maintained with the map_forward=1 as I would expect,
>just the source field in the input gff file is added to the new maker
>name.  If I change the input to a model_gff file I still do not get
>predictions in the maker gff file.
>
>thanks
>Kym
>
>
>
>
>On Tue, 12 Nov 2013, Carson Holt wrote:
>
>> They should be maintained.  What version are you using?
>>
>> --Carson
>>
>>
>> On 11/11/13 1:01 PM, "Kymberlie Hallsworth-Pepin"
>> <kpepin at genome.wustl.edu> wrote:
>>
>>> Hi Carson,
>>>
>>> I am trying to take an existing gene set and update it using new
>>> proteins.
>>> I have the gene set in gff3 format - validated as ok - and have put it
>>>in
>>> the model_gff line. I set the protein db to the new database and I set
>>> the
>>> map_forward=1 to maintain naming, but the output has no gene
>>>predictions
>>> in it. I have tried setting keep_preds both 0 and 1. I have put the gff
>>> file in both the pred_gff and model_gff and just in the pred_gff field,
>>> but I still don't get any predictions maintained. Can you tell me what
>>>I
>>> might be missing ?
>>>
>>> thanks
>>> Kym
>>>
>>>
>>> ____
>>> This email message is a private communication. The information
>>> transmitted, including attachments, is intended only for the person or
>>> entity to which it is addressed and may contain confidential,
>>>privileged,
>>> and/or proprietary material. Any review, duplication, retransmission,
>>> distribution, or other use of, or taking of any action in reliance
>>>upon,
>>> this information by persons or entities other than the intended
>>>recipient
>>> is unauthorized by the sender and is prohibited. If you have received
>>> this message in error, please contact the sender immediately by return
>>> email and delete the original message from all computer systems. Thank
>>> you.
>>
>
>____
>This email message is a private communication. The information
>transmitted, including attachments, is intended only for the person or
>entity to which it is addressed and may contain confidential, privileged,
>and/or proprietary material. Any review, duplication, retransmission,
>distribution, or other use of, or taking of any action in reliance upon,
>this information by persons or entities other than the intended recipient
>is unauthorized by the sender and is prohibited. If you have received
>this message in error, please contact the sender immediately by return
>email and delete the original message from all computer systems. Thank
>you.





From kpepin at genome.wustl.edu  Wed Nov 13 08:15:48 2013
From: kpepin at genome.wustl.edu (Kymberlie Hallsworth-Pepin)
Date: Wed, 13 Nov 2013 09:15:48 -0600 (CST)
Subject: [maker-devel] re-annotation
In-Reply-To: <CEA8E2DE.6FBF%carsonhh@gmail.com>
References: <CEA8E2DE.6FBF%carsonhh@gmail.com>
Message-ID: <alpine.DEB.2.00.1311130913090.2847@linus40.gsc.wustl.edu>



Will do. Is there a difference between how the model_gff file and the 
pred_gff file use the match/match_part of CDS/mRNA designations and which 
is the best to use for model_gff input?

On Wed, 13 Nov 2013, Carson Holt wrote:

> So map_forward=1, will only maintain names derived from model_gff onto new
> or updated models.  Could you try either 2.28 or 2.30-beta, just to see if
> this is something that is already fixed.
>
> Thanks,
> Carson
>

____
This email message is a private communication. The information transmitted, including attachments, is intended only for the person or entity to which it is addressed and may contain confidential, privileged, and/or proprietary material. Any review, duplication, retransmission, distribution, or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is unauthorized by the sender and is prohibited. If you have received this message in error, please contact the sender immediately by return email and delete the original message from all computer systems. Thank you.



From carsonhh at gmail.com  Wed Nov 13 16:08:08 2013
From: carsonhh at gmail.com (Carson Holt)
Date: Wed, 13 Nov 2013 16:08:08 -0700
Subject: [maker-devel] re-annotation
In-Reply-To: <alpine.DEB.2.00.1311130913090.2847@linus40.gsc.wustl.edu>
Message-ID: <CEA953DA.6B86%carsonhh@gmail.com>

model_gff must be gene/mRNA/exon/CDS. pred_gff can be match/match_part or
gene/mRNA/exon/CDS.  Also model_gff always should make it into the final
result (unless replaced by something better) and will not be modified.  It
also affects clustering.  pref_gff will only make it into the final
results if it is supported by evidence.

?Carson


On 11/13/13, 8:15 AM, "Kymberlie Hallsworth-Pepin"
<kpepin at genome.wustl.edu> wrote:

>
>
>Will do. Is there a difference between how the model_gff file and the
>pred_gff file use the match/match_part of CDS/mRNA designations and which
>is the best to use for model_gff input?
>
>On Wed, 13 Nov 2013, Carson Holt wrote:
>
>> So map_forward=1, will only maintain names derived from model_gff onto
>>new
>> or updated models.  Could you try either 2.28 or 2.30-beta, just to see
>>if
>> this is something that is already fixed.
>>
>> Thanks,
>> Carson
>>
>
>____
>This email message is a private communication. The information
>transmitted, including attachments, is intended only for the person or
>entity to which it is addressed and may contain confidential, privileged,
>and/or proprietary material. Any review, duplication, retransmission,
>distribution, or other use of, or taking of any action in reliance upon,
>this information by persons or entities other than the intended recipient
>is unauthorized by the sender and is prohibited. If you have received
>this message in error, please contact the sender immediately by return
>email and delete the original message from all computer systems. Thank
>you.





From carsonhh at gmail.com  Wed Nov 13 19:59:44 2013
From: carsonhh at gmail.com (Carson Holt)
Date: Wed, 13 Nov 2013 19:59:44 -0700
Subject: [maker-devel] A suspected strange behavior of Maker...
In-Reply-To: <CACvYrQGf+QwTcbWEOLX0igUZWcByu-E2d8YD4m2ykzCGr_aJ-w@mail.gmail.com>
Message-ID: <CEA98904.6B9A%carsonhh@gmail.com>

For scaffold5347 I get results from exonerate and blastn without any
modification to default parameters.  For scaffold3928 the alignment is very
poor, and gets filtered out.  I can force it to keep it but I have to allow
for abnormally long introns of 65kb (introns that large are extremely rare
in biology ? as in if you took every gene from 100 organisms you might find
a single gene among all of them with that long of an intron), and I have to
allow for low end to end matching (less 30%).  This alignment definitely
should have been rejected.

Thanks,
Carson


From:  Xin Huang <xh33 at georgetown.edu>
Date:  Monday, November 11, 2013 at 8:52 AM
To:  Carson Holt <carsonhh at gmail.com>
Cc:  <maker-devel at yandell-lab.org>
Subject:  Re: [maker-devel] A suspected strange behavior of Maker...

Hi Carson,

Thank you very much for getting back to me on this. Sorry I was too quick to
jump to a suspicion! Thanks for pointing it out and please see attached the
EST (face_cDNA.fa) and genome scaffold sequences
(albo_scaf3928+5347_for_face_cDNA.fa) I used for Maker. We used blastn to
identify these two scaffolds for this cDNA sequence, and exonerate result
also showed that this cDNA can be aligned to the scaffolds.

Thanks!

Xin 


On Mon, Nov 11, 2013 at 12:10 AM, Carson Holt <carsonhh at gmail.com> wrote:
> Sorry for the slow reply, I was moving from Canada to the US, got sick, and my
> moving truck got delayed one week. So I fell behind on the maker list.
> 
> What you observe is correct behavior.  The config is blasted against the
> database of ESTs/proteins.  It really doesn't matter which way you blast, you
> pick the direction that is most efficient for the question you are asking, and
> you only have to adjust the Z value for database size if you want alignment
> scores to be reproducible both ways.
> 
> Not getting results means they were filtered out for some reason (you don't
> even have blastn results in your output).  If you can send a test dataset I
> can take a look and tell you which filter.
> 
> Thanks,
> Carson
> 
> 
> From:  Xin Huang <xh33 at georgetown.edu>
> Date:  Tuesday, November 5, 2013 2:40 PM
> To:  <maker-devel at yandell-lab.org>
> Subject:  [maker-devel] A suspected strange behavior of Maker...
> 
> Hi,
> 
> I found a very bizarre thing when I ran Maker several times. The blastn
> research seems to reverse query and subject the way it's specified in the
> maker_opts.ctl file. When I put the scaffold sequence after genome= and the
> cDNA sequence after est=, the blastn result actually used the scaffold as
> query and the cDNA as subject. I realized that this sounds unreal, so I
> reversed the places for the two and the blastn result is normal with the cDNA
> as query and the scaffold as subject, but at the same time, the GFF file is of
> the cDNA sequence. I tried a few times, and got the same result. I deleted
> Maker (2.28) and reinstalled the beta version (2.30), still getting the same
> result.
> 
> My wild guess was that this might be the reason why the est2genome prediction
> using the EST sequence didn't go into the GFF3 file, as stated in a previous
> email to the Maker-devel. I couldn't figure out how to test this, though. I
> wonder if there's anything dramatically wrong that I've been doing to get such
> odd results... If you'd like me to send you any output files or control files,
> please let me know and I'll promptly pass those along.
> 
> Thank you very much for considering my email.
> 
> Sincerely,
> 
> Xin Huang
> _______________________________________________ maker-devel mailing list
> maker-devel at box290.bluehost.comhttp://box290.bluehost.com/mailman/listinfo/mak
> er-devel_yandell-lab.org



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131113/047635c9/attachment-0002.html>

From xh33 at georgetown.edu  Wed Nov 13 20:45:42 2013
From: xh33 at georgetown.edu (Xin Huang)
Date: Wed, 13 Nov 2013 22:45:42 -0500
Subject: [maker-devel] A suspected strange behavior of Maker...
In-Reply-To: <CEA98904.6B9A%carsonhh@gmail.com>
References: <CACvYrQGf+QwTcbWEOLX0igUZWcByu-E2d8YD4m2ykzCGr_aJ-w@mail.gmail.com>
	<CEA98904.6B9A%carsonhh@gmail.com>
Message-ID: <CACvYrQFPkZ+BwcQu0amq1kzO-0xAMTsLa0RqY+xy_sn6AfrZ0Q@mail.gmail.com>

Hi Carson,

Thanks a lot for doing the test for me! I didn't get any annotation in the
GFF file generated by Maker even if I only used scaffold5347 as the genome
and the face EST sequence as the est evidence. Is there something that I
can modify to put the alignment into the GFF file? I used est2genome=1
option to get prediction from exonerate, but still couldn't get any
prediction.

Thanks!

Xin


On Wed, Nov 13, 2013 at 9:59 PM, Carson Holt <carsonhh at gmail.com> wrote:

> For scaffold5347 I get results from exonerate and blastn without any
> modification to default parameters.  For scaffold3928 the alignment is very
> poor, and gets filtered out.  I can force it to keep it but I have to allow
> for abnormally long introns of 65kb (introns that large are extremely rare
> in biology ? as in if you took every gene from 100 organisms you might find
> a single gene among all of them with that long of an intron), and I have to
> allow for low end to end matching (less 30%).  This alignment definitely
> should have been rejected.
>
> Thanks,
> Carson
>
>
> From: Xin Huang <xh33 at georgetown.edu>
> Date: Monday, November 11, 2013 at 8:52 AM
> To: Carson Holt <carsonhh at gmail.com>
> Cc: <maker-devel at yandell-lab.org>
> Subject: Re: [maker-devel] A suspected strange behavior of Maker...
>
> Hi Carson,
>
> Thank you very much for getting back to me on this. Sorry I was too quick
> to jump to a suspicion! Thanks for pointing it out and please see attached
> the EST (face_cDNA.fa) and genome scaffold sequences
> (albo_scaf3928+5347_for_face_cDNA.fa) I used for Maker. We used blastn to
> identify these two scaffolds for this cDNA sequence, and exonerate result
> also showed that this cDNA can be aligned to the scaffolds.
>
> Thanks!
>
> Xin
>
>
> On Mon, Nov 11, 2013 at 12:10 AM, Carson Holt <carsonhh at gmail.com> wrote:
>
>> Sorry for the slow reply, I was moving from Canada to the US, got sick,
>> and my moving truck got delayed one week. So I fell behind on the maker
>> list.
>>
>> What you observe is correct behavior.  The config is blasted against the
>> database of ESTs/proteins.  It really doesn't matter which way you blast,
>> you pick the direction that is most efficient for the question you are
>> asking, and you only have to adjust the Z value for database size if you
>> want alignment scores to be reproducible both ways.
>>
>> Not getting results means they were filtered out for some reason (you
>> don't even have blastn results in your output).  If you can send a test
>> dataset I can take a look and tell you which filter.
>>
>> Thanks,
>> Carson
>>
>>
>> From: Xin Huang <xh33 at georgetown.edu>
>> Date: Tuesday, November 5, 2013 2:40 PM
>> To: <maker-devel at yandell-lab.org>
>> Subject: [maker-devel] A suspected strange behavior of Maker...
>>
>> Hi,
>>
>> I found a very bizarre thing when I ran Maker several times. The blastn
>> research seems to reverse query and subject the way it's specified in the
>> maker_opts.ctl file. When I put the scaffold sequence after genome= and the
>> cDNA sequence after est=, the blastn result actually used the scaffold as
>> query and the cDNA as subject. I realized that this sounds unreal, so I
>> reversed the places for the two and the blastn result is normal with the
>> cDNA as query and the scaffold as subject, but at the same time, the GFF
>> file is of the cDNA sequence. I tried a few times, and got the same result.
>> I deleted Maker (2.28) and reinstalled the beta version (2.30), still
>> getting the same result.
>>
>> My wild guess was that this might be the reason why the est2genome
>> prediction using the EST sequence didn't go into the GFF3 file, as stated
>> in a previous email to the Maker-devel. I couldn't figure out how to test
>> this, though. I wonder if there's anything dramatically wrong that I've
>> been doing to get such odd results... If you'd like me to send you any
>> output files or control files, please let me know and I'll promptly pass
>> those along.
>>
>> Thank you very much for considering my email.
>>
>> Sincerely,
>>
>> Xin Huang
>> _______________________________________________ maker-devel mailing list
>> maker-devel at box290.bluehost.com
>> http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131113/133d8f0a/attachment-0002.html>

From carsonhh at gmail.com  Wed Nov 13 20:49:32 2013
From: carsonhh at gmail.com (Carson Holt)
Date: Wed, 13 Nov 2013 20:49:32 -0700
Subject: [maker-devel] A suspected strange behavior of Maker...
In-Reply-To: <CACvYrQFPkZ+BwcQu0amq1kzO-0xAMTsLa0RqY+xy_sn6AfrZ0Q@mail.gmail.com>
Message-ID: <CEA99613.6BAD%carsonhh@gmail.com>

All I did was supply the cDNA to est= and the scaffolds to genome=.  All the
other parameters I just used the default, then I ran MAKER.  I am using
version 2.30.

Thanks,
Carson


From:  Xin Huang <xh33 at georgetown.edu>
Date:  Wednesday, November 13, 2013 at 8:45 PM
To:  Carson Holt <carsonhh at gmail.com>
Cc:  <maker-devel at yandell-lab.org>
Subject:  Re: [maker-devel] A suspected strange behavior of Maker...

Hi Carson,

Thanks a lot for doing the test for me! I didn't get any annotation in the
GFF file generated by Maker even if I only used scaffold5347 as the genome
and the face EST sequence as the est evidence. Is there something that I can
modify to put the alignment into the GFF file? I used est2genome=1 option to
get prediction from exonerate, but still couldn't get any prediction.

Thanks!

Xin


On Wed, Nov 13, 2013 at 9:59 PM, Carson Holt <carsonhh at gmail.com> wrote:
> For scaffold5347 I get results from exonerate and blastn without any
> modification to default parameters.  For scaffold3928 the alignment is very
> poor, and gets filtered out.  I can force it to keep it but I have to allow
> for abnormally long introns of 65kb (introns that large are extremely rare in
> biology ? as in if you took every gene from 100 organisms you might find a
> single gene among all of them with that long of an intron), and I have to
> allow for low end to end matching (less 30%).  This alignment definitely
> should have been rejected.
> 
> Thanks,
> Carson
> 
> 
> From:  Xin Huang <xh33 at georgetown.edu>
> Date:  Monday, November 11, 2013 at 8:52 AM
> To:  Carson Holt <carsonhh at gmail.com>
> Cc:  <maker-devel at yandell-lab.org>
> Subject:  Re: [maker-devel] A suspected strange behavior of Maker...
> 
> Hi Carson,
> 
> Thank you very much for getting back to me on this. Sorry I was too quick to
> jump to a suspicion! Thanks for pointing it out and please see attached the
> EST (face_cDNA.fa) and genome scaffold sequences
> (albo_scaf3928+5347_for_face_cDNA.fa) I used for Maker. We used blastn to
> identify these two scaffolds for this cDNA sequence, and exonerate result also
> showed that this cDNA can be aligned to the scaffolds.
> 
> Thanks!
> 
> Xin 
> 
> 
> On Mon, Nov 11, 2013 at 12:10 AM, Carson Holt <carsonhh at gmail.com> wrote:
>> Sorry for the slow reply, I was moving from Canada to the US, got sick, and
>> my moving truck got delayed one week. So I fell behind on the maker list.
>> 
>> What you observe is correct behavior.  The config is blasted against the
>> database of ESTs/proteins.  It really doesn't matter which way you blast, you
>> pick the direction that is most efficient for the question you are asking,
>> and you only have to adjust the Z value for database size if you want
>> alignment scores to be reproducible both ways.
>> 
>> Not getting results means they were filtered out for some reason (you don't
>> even have blastn results in your output).  If you can send a test dataset I
>> can take a look and tell you which filter.
>> 
>> Thanks,
>> Carson
>> 
>> 
>> From:  Xin Huang <xh33 at georgetown.edu>
>> Date:  Tuesday, November 5, 2013 2:40 PM
>> To:  <maker-devel at yandell-lab.org>
>> Subject:  [maker-devel] A suspected strange behavior of Maker...
>> 
>> Hi,
>> 
>> I found a very bizarre thing when I ran Maker several times. The blastn
>> research seems to reverse query and subject the way it's specified in the
>> maker_opts.ctl file. When I put the scaffold sequence after genome= and the
>> cDNA sequence after est=, the blastn result actually used the scaffold as
>> query and the cDNA as subject. I realized that this sounds unreal, so I
>> reversed the places for the two and the blastn result is normal with the cDNA
>> as query and the scaffold as subject, but at the same time, the GFF file is
>> of the cDNA sequence. I tried a few times, and got the same result. I deleted
>> Maker (2.28) and reinstalled the beta version (2.30), still getting the same
>> result.
>> 
>> My wild guess was that this might be the reason why the est2genome prediction
>> using the EST sequence didn't go into the GFF3 file, as stated in a previous
>> email to the Maker-devel. I couldn't figure out how to test this, though. I
>> wonder if there's anything dramatically wrong that I've been doing to get
>> such odd results... If you'd like me to send you any output files or control
>> files, please let me know and I'll promptly pass those along.
>> 
>> Thank you very much for considering my email.
>> 
>> Sincerely,
>> 
>> Xin Huang
>> _______________________________________________ maker-devel mailing list
>> maker-devel at box290.bluehost.comhttp://box290.bluehost.com/mailman/listinfo/ma
>> ker-devel_yandell-lab.org
> 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131113/4d20127f/attachment-0002.html>

From cjfields at illinois.edu  Wed Nov 13 20:51:36 2013
From: cjfields at illinois.edu (Fields, Christopher J)
Date: Thu, 14 Nov 2013 03:51:36 +0000
Subject: [maker-devel] Odd missing label bug
Message-ID: <73A19C36-ABA1-4A03-8D66-2A7F5574C386@illinois.edu>

I?m seeing an odd bug in GFF output where the label is being sporadically left off some child ?match_part' features.  This is when using maker-2.30p.  I found this while splitting out the data by source as individual tracks for IGV viewing; I have several sets of ESTs from individuals of the same species, so I have them labeled (from maker_opts):

est=./ESTs/Trinity_1128_v2_combined_pr2.clean.fasta:strain_1128
protein=./ESTs/xeno/Taeniopygia_guttata.taeGut3.2.4.73.pep.all.fa:TaeGut,./ESTs/xeno/Ficedula_albicollis.FicAlb_1.4.73.pep.all.fa:FicAlb

I planned on separating these into separate tracks, one for each BLASTX, BLASTN, etc.  

After a test run on a few scaffolds, a small number of the BLASTX and BLASTN look like this:

KB913263.1      blastx:TaeGut   protein_match   374736  401929  330     -       .       ID=KB913263.1:hit:9:3.10.0.3;Name=ENSTGUP00000000074
KB913263.1      blastx  match_part      401756  401929  312     -       .       ID=KB913263.1:hsp:55:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M58;Target=ENSTGUP00000000074 1 58
KB913263.1      blastx  match_part      394486  394665  186     -       .       ID=KB913263.1:hsp:56:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M42 D9 M9;Target=ENSTGUP00000000074 56 106
KB913263.1      blastx  match_part      392059  392178  204     -       .       ID=KB913263.1:hsp:57:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M40;Target=ENSTGUP00000000074 97 136
KB913263.1      blastx  match_part      387479  387547  116     -       .       ID=KB913263.1:hsp:58:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M23;Target=ENSTGUP00000000074 151 173
KB913263.1      blastx  match_part      383644  383742  156     -       .       ID=KB913263.1:hsp:59:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M33;Target=ENSTGUP00000000074 172 204
KB913263.1      blastx  match_part      382860  383063  242     -       .       ID=KB913263.1:hsp:60:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M68;Target=ENSTGUP00000000074 193 260
KB913263.1      blastx  match_part      382538  382648  186     -       .       ID=KB913263.1:hsp:61:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M37;Target=ENSTGUP00000000074 247 283
KB913263.1      blastx  match_part      382072  382236  268     -       .       ID=KB913263.1:hsp:62:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M55;Target=ENSTGUP00000000074 282 336
KB913263.1      blastx  match_part      379270  379458  330     -       .       ID=KB913263.1:hsp:63:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M63;Target=ENSTGUP00000000074 336 398
KB913263.1      blastx  match_part      374736  374900  147     -       .       ID=KB913263.1:hsp:64:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M55;Target=ENSTGUP00000000074 4 58

Note the missing label in the source column for the ?match_part? types.  Strangely, only a small # have this problem, but the exact same ones appear to be consistently popping up on repeated runs (this is from a test prior to a full launch using openmpi).  It does seem like only child ?match_part? appears affected.

Any ideas?

chris


From carsonhh at gmail.com  Wed Nov 13 20:58:32 2013
From: carsonhh at gmail.com (Carson Holt)
Date: Wed, 13 Nov 2013 20:58:32 -0700
Subject: [maker-devel] Odd missing label bug
In-Reply-To: <73A19C36-ABA1-4A03-8D66-2A7F5574C386@illinois.edu>
Message-ID: <CEA9978B.6BB3%carsonhh@gmail.com>

Could you put a contig and protein fasta into a test job that I could run
on?  Based on the hit position I imagine this may only happens when the
alignments spans two chunks (by default MAKER splits the input config into
100,000bp chunks).  The hit runs from 374736-401929.

?Carson


On 11/13/13, 8:51 PM, "Fields, Christopher J" <cjfields at illinois.edu>
wrote:

>I?m seeing an odd bug in GFF output where the label is being sporadically
>left off some child ?match_part' features.  This is when using
>maker-2.30p.  I found this while splitting out the data by source as
>individual tracks for IGV viewing; I have several sets of ESTs from
>individuals of the same species, so I have them labeled (from maker_opts):
>
>est=./ESTs/Trinity_1128_v2_combined_pr2.clean.fasta:strain_1128
>protein=./ESTs/xeno/Taeniopygia_guttata.taeGut3.2.4.73.pep.all.fa:TaeGut,.
>/ESTs/xeno/Ficedula_albicollis.FicAlb_1.4.73.pep.all.fa:FicAlb
>
>I planned on separating these into separate tracks, one for each BLASTX,
>BLASTN, etc.  
>
>After a test run on a few scaffolds, a small number of the BLASTX and
>BLASTN look like this:
>
>KB913263.1      blastx:TaeGut   protein_match   374736  401929  330     -
>      .       ID=KB913263.1:hit:9:3.10.0.3;Name=ENSTGUP00000000074
>KB913263.1      blastx  match_part      401756  401929  312     -       .
>      
>ID=KB913263.1:hsp:55:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M58;Tar
>get=ENSTGUP00000000074 1 58
>KB913263.1      blastx  match_part      394486  394665  186     -       .
>      
>ID=KB913263.1:hsp:56:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M42 D9
>M9;Target=ENSTGUP00000000074 56 106
>KB913263.1      blastx  match_part      392059  392178  204     -       .
>      
>ID=KB913263.1:hsp:57:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M40;Tar
>get=ENSTGUP00000000074 97 136
>KB913263.1      blastx  match_part      387479  387547  116     -       .
>      
>ID=KB913263.1:hsp:58:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M23;Tar
>get=ENSTGUP00000000074 151 173
>KB913263.1      blastx  match_part      383644  383742  156     -       .
>      
>ID=KB913263.1:hsp:59:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M33;Tar
>get=ENSTGUP00000000074 172 204
>KB913263.1      blastx  match_part      382860  383063  242     -       .
>      
>ID=KB913263.1:hsp:60:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M68;Tar
>get=ENSTGUP00000000074 193 260
>KB913263.1      blastx  match_part      382538  382648  186     -       .
>      
>ID=KB913263.1:hsp:61:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M37;Tar
>get=ENSTGUP00000000074 247 283
>KB913263.1      blastx  match_part      382072  382236  268     -       .
>      
>ID=KB913263.1:hsp:62:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M55;Tar
>get=ENSTGUP00000000074 282 336
>KB913263.1      blastx  match_part      379270  379458  330     -       .
>      
>ID=KB913263.1:hsp:63:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M63;Tar
>get=ENSTGUP00000000074 336 398
>KB913263.1      blastx  match_part      374736  374900  147     -       .
>      
>ID=KB913263.1:hsp:64:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M55;Tar
>get=ENSTGUP00000000074 4 58
>
>Note the missing label in the source column for the ?match_part? types.
>Strangely, only a small # have this problem, but the exact same ones
>appear to be consistently popping up on repeated runs (this is from a
>test prior to a full launch using openmpi).  It does seem like only child
>?match_part? appears affected.
>
>Any ideas?
>
>chris
>_______________________________________________
>maker-devel mailing list
>maker-devel at box290.bluehost.com
>http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org





From cjfields at illinois.edu  Wed Nov 13 21:20:46 2013
From: cjfields at illinois.edu (Fields, Christopher J)
Date: Thu, 14 Nov 2013 04:20:46 +0000
Subject: [maker-devel] Odd missing label bug
In-Reply-To: <CEA9978B.6BB3%carsonhh@gmail.com>
References: <CEA9978B.6BB3%carsonhh@gmail.com>
Message-ID: <6E70C69F-BAFD-4C9E-9293-04DB656B2A09@illinois.edu>

Yeah, that seems to be it (crossing around 100kbp increments).  I?ll run a reduced example set locally to make sure and will send.

-c

On Nov 13, 2013, at 9:58 PM, Carson Holt <carsonhh at gmail.com> wrote:

> Could you put a contig and protein fasta into a test job that I could run
> on?  Based on the hit position I imagine this may only happens when the
> alignments spans two chunks (by default MAKER splits the input config into
> 100,000bp chunks).  The hit runs from 374736-401929.
> 
> <Carson
> 
> 
> On 11/13/13, 8:51 PM, "Fields, Christopher J" <cjfields at illinois.edu>
> wrote:
> 
>> I?m seeing an odd bug in GFF output where the label is being sporadically
>> left off some child Omatch_part' features.  This is when using
>> maker-2.30p.  I found this while splitting out the data by source as
>> individual tracks for IGV viewing; I have several sets of ESTs from
>> individuals of the same species, so I have them labeled (from maker_opts):
>> 
>> est=./ESTs/Trinity_1128_v2_combined_pr2.clean.fasta:strain_1128
>> protein=./ESTs/xeno/Taeniopygia_guttata.taeGut3.2.4.73.pep.all.fa:TaeGut,.
>> /ESTs/xeno/Ficedula_albicollis.FicAlb_1.4.73.pep.all.fa:FicAlb
>> 
>> I planned on separating these into separate tracks, one for each BLASTX,
>> BLASTN, etc.  
>> 
>> After a test run on a few scaffolds, a small number of the BLASTX and
>> BLASTN look like this:
>> 
>> KB913263.1      blastx:TaeGut   protein_match   374736  401929  330     -
>>     .       ID=KB913263.1:hit:9:3.10.0.3;Name=ENSTGUP00000000074
>> KB913263.1      blastx  match_part      401756  401929  312     -       .
>> 
>> ID=KB913263.1:hsp:55:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M58;Tar
>> get=ENSTGUP00000000074 1 58
>> KB913263.1      blastx  match_part      394486  394665  186     -       .
>> 
>> ID=KB913263.1:hsp:56:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M42 D9
>> M9;Target=ENSTGUP00000000074 56 106
>> KB913263.1      blastx  match_part      392059  392178  204     -       .
>> 
>> ID=KB913263.1:hsp:57:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M40;Tar
>> get=ENSTGUP00000000074 97 136
>> KB913263.1      blastx  match_part      387479  387547  116     -       .
>> 
>> ID=KB913263.1:hsp:58:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M23;Tar
>> get=ENSTGUP00000000074 151 173
>> KB913263.1      blastx  match_part      383644  383742  156     -       .
>> 
>> ID=KB913263.1:hsp:59:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M33;Tar
>> get=ENSTGUP00000000074 172 204
>> KB913263.1      blastx  match_part      382860  383063  242     -       .
>> 
>> ID=KB913263.1:hsp:60:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M68;Tar
>> get=ENSTGUP00000000074 193 260
>> KB913263.1      blastx  match_part      382538  382648  186     -       .
>> 
>> ID=KB913263.1:hsp:61:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M37;Tar
>> get=ENSTGUP00000000074 247 283
>> KB913263.1      blastx  match_part      382072  382236  268     -       .
>> 
>> ID=KB913263.1:hsp:62:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M55;Tar
>> get=ENSTGUP00000000074 282 336
>> KB913263.1      blastx  match_part      379270  379458  330     -       .
>> 
>> ID=KB913263.1:hsp:63:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M63;Tar
>> get=ENSTGUP00000000074 336 398
>> KB913263.1      blastx  match_part      374736  374900  147     -       .
>> 
>> ID=KB913263.1:hsp:64:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M55;Tar
>> get=ENSTGUP00000000074 4 58
>> 
>> Note the missing label in the source column for the Omatch_part? types.
>> Strangely, only a small # have this problem, but the exact same ones
>> appear to be consistently popping up on repeated runs (this is from a
>> test prior to a full launch using openmpi).  It does seem like only child
>> Omatch_part? appears affected.
>> 
>> Any ideas?
>> 
>> chris
>> _______________________________________________
>> maker-devel mailing list
>> maker-devel at box290.bluehost.com
>> http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
> 
> 




From kpepin at genome.wustl.edu  Thu Nov 14 05:51:54 2013
From: kpepin at genome.wustl.edu (Kymberlie Hallsworth-Pepin)
Date: Thu, 14 Nov 2013 06:51:54 -0600 (CST)
Subject: [maker-devel] re-annotation
In-Reply-To: <CEA953DA.6B86%carsonhh@gmail.com>
References: <CEA953DA.6B86%carsonhh@gmail.com>
Message-ID: <alpine.DEB.2.00.1311140650400.28492@linus40.gsc.wustl.edu>


The new version and the change in the model gff to exon/cds did the trick.
thanks for the info.
Kym


On Wed, 13 Nov 2013, Carson Holt wrote:

> model_gff must be gene/mRNA/exon/CDS. pred_gff can be match/match_part or
> gene/mRNA/exon/CDS.  Also model_gff always should make it into the final
> result (unless replaced by something better) and will not be modified.  It
> also affects clustering.  pref_gff will only make it into the final
> results if it is supported by evidence.
>
> ?Carson
>
>
> On 11/13/13, 8:15 AM, "Kymberlie Hallsworth-Pepin"
> <kpepin at genome.wustl.edu> wrote:
>
>>
>>
>> Will do. Is there a difference between how the model_gff file and the
>> pred_gff file use the match/match_part of CDS/mRNA designations and which
>> is the best to use for model_gff input?
>>
>> On Wed, 13 Nov 2013, Carson Holt wrote:
>>
>>> So map_forward=1, will only maintain names derived from model_gff onto
>>> new
>>> or updated models.  Could you try either 2.28 or 2.30-beta, just to see
>>> if
>>> this is something that is already fixed.
>>>
>>> Thanks,
>>> Carson
>>>
>>
>> ____
>> This email message is a private communication. The information
>> transmitted, including attachments, is intended only for the person or
>> entity to which it is addressed and may contain confidential, privileged,
>> and/or proprietary material. Any review, duplication, retransmission,
>> distribution, or other use of, or taking of any action in reliance upon,
>> this information by persons or entities other than the intended recipient
>> is unauthorized by the sender and is prohibited. If you have received
>> this message in error, please contact the sender immediately by return
>> email and delete the original message from all computer systems. Thank
>> you.
>

____
This email message is a private communication. The information transmitted, including attachments, is intended only for the person or entity to which it is addressed and may contain confidential, privileged, and/or proprietary material. Any review, duplication, retransmission, distribution, or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is unauthorized by the sender and is prohibited. If you have received this message in error, please contact the sender immediately by return email and delete the original message from all computer systems. Thank you.



From xh33 at georgetown.edu  Mon Nov 11 08:52:48 2013
From: xh33 at georgetown.edu (Xin Huang)
Date: Mon, 11 Nov 2013 10:52:48 -0500
Subject: [maker-devel] A suspected strange behavior of Maker...
In-Reply-To: <CEA5B2C9.69F9%carsonhh@gmail.com>
References: <CACvYrQGP1dajOYyhiTDt6QuzCHdVR21vLYzmbtMKvF67d-fMiA@mail.gmail.com>
	<CEA5B2C9.69F9%carsonhh@gmail.com>
Message-ID: <CACvYrQGf+QwTcbWEOLX0igUZWcByu-E2d8YD4m2ykzCGr_aJ-w@mail.gmail.com>

Hi Carson,

Thank you very much for getting back to me on this. Sorry I was too quick
to jump to a suspicion! Thanks for pointing it out and please see attached
the EST (face_cDNA.fa) and genome scaffold sequences
(albo_scaf3928+5347_for_face_cDNA.fa) I used for Maker. We used blastn to
identify these two scaffolds for this cDNA sequence, and exonerate result
also showed that this cDNA can be aligned to the scaffolds.

Thanks!

Xin


On Mon, Nov 11, 2013 at 12:10 AM, Carson Holt <carsonhh at gmail.com> wrote:

> Sorry for the slow reply, I was moving from Canada to the US, got sick,
> and my moving truck got delayed one week. So I fell behind on the maker
> list.
>
> What you observe is correct behavior.  The config is blasted against the
> database of ESTs/proteins.  It really doesn't matter which way you blast,
> you pick the direction that is most efficient for the question you are
> asking, and you only have to adjust the Z value for database size if you
> want alignment scores to be reproducible both ways.
>
> Not getting results means they were filtered out for some reason (you
> don't even have blastn results in your output).  If you can send a test
> dataset I can take a look and tell you which filter.
>
> Thanks,
> Carson
>
>
> From: Xin Huang <xh33 at georgetown.edu>
> Date: Tuesday, November 5, 2013 2:40 PM
> To: <maker-devel at yandell-lab.org>
> Subject: [maker-devel] A suspected strange behavior of Maker...
>
> Hi,
>
> I found a very bizarre thing when I ran Maker several times. The blastn
> research seems to reverse query and subject the way it's specified in the
> maker_opts.ctl file. When I put the scaffold sequence after genome= and the
> cDNA sequence after est=, the blastn result actually used the scaffold as
> query and the cDNA as subject. I realized that this sounds unreal, so I
> reversed the places for the two and the blastn result is normal with the
> cDNA as query and the scaffold as subject, but at the same time, the GFF
> file is of the cDNA sequence. I tried a few times, and got the same result.
> I deleted Maker (2.28) and reinstalled the beta version (2.30), still
> getting the same result.
>
> My wild guess was that this might be the reason why the est2genome
> prediction using the EST sequence didn't go into the GFF3 file, as stated
> in a previous email to the Maker-devel. I couldn't figure out how to test
> this, though. I wonder if there's anything dramatically wrong that I've
> been doing to get such odd results... If you'd like me to send you any
> output files or control files, please let me know and I'll promptly pass
> those along.
>
> Thank you very much for considering my email.
>
> Sincerely,
>
> Xin Huang
> _______________________________________________ maker-devel mailing list
> maker-devel at box290.bluehost.com
> http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131111/aeac9298/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: face_cDNA.fa
Type: application/octet-stream
Size: 1977 bytes
Desc: not available
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131111/aeac9298/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: albo_scaf3928+5347_for_face_cDNA.fa
Type: application/octet-stream
Size: 306492 bytes
Desc: not available
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131111/aeac9298/attachment-0005.obj>

From ejr at stowers.org  Mon Nov 18 13:24:03 2013
From: ejr at stowers.org (Ross, Eric)
Date: Mon, 18 Nov 2013 20:24:03 +0000
Subject: [maker-devel] gff3_merge error - only half the contigs are
 reported
Message-ID: <CEAFD381.2B146%ejr@stowers.org>

I had the same problem Sujai reported  on the 25th.

When I run gff3_merge I only get back results from a subset of my
scaffolds.  Every scaffold has a gff file in the data store.  fasta_merge
works fine.  No errors are printed to STDOUT.

It took me some poking around, but this seems that if there is
insufficient space in /tmp to generate the temporary files merge_gff3
completes without error and just creates a gff file from whatever fit in
the temporary files.  I'm not sure why tempfile() doesn't return a useful
error.  

I was able to get around the error by setting the environment variable
TMPDIR to someplace with sufficient space, but if there is a way to
generate a useful error it might be worth adding.


Eric




--original below--
On Friday, October 25, 2013 11:22:08 AM UTC-5, Barry wrote:
Hi Sujai,
If you still have that original directory available a couple things you to
try:

# Does this give you the number of contigs you're expecting?
find datastore_directory -name '*.gff3' | wc -l

# If the above gives what you expect what does the file size look like on
the smallest files?
find ./ -type f | xargs ls -Sl | tail

Barry

On Oct 24, 2013, at 4:04 PM, Sujai wrote:


Hi Barry

The last stderr message in the job is from the maker command:

Maker is now finished!!!

my last 3 commands were (in my pbs/torque job script):

----job script----
...other commands to set variables etc...
mpiexec -n 12 maker -g $SPLITFILE -base $SPLITFILE maker_opts.ctl
maker_bopts.ctl maker_exe.ctl
gff3_merge -o $PBS_O_WORKDIR/$SPLITFILE.gff3 -d
$SPLITFILE.maker.output/${SPLITFILE}_master_datastore_index.log
fasta_merge -d 
$SPLITFILE.maker.output/${SPLITFILE}_master_datastore_index.log
-----

so, no gff3_merge stderr messages
the fasta_merge command (which came after gff3_merge) has completed
correctly, with all proteins and transcripts accounted for.
I just ran the same contigs again in smaller batches, and it seems to be
proceeding correctly (the final gff3 files are between 49-55MB for each
chunk of fasta files. In the previous case, the final GFF3 file was 99MB
or 100MB (which is why I thought there was some sort of filesize/memory
limit)

Thanks for looking into this,

- Sujai




On 24 October 2013 21:42, Barry Moore <barry... at genetics.utah.edu <>>
wrote:

Hi Sujai,
There are a couple of fatal errors that can be thrown by gff3_merge if it
encounters errors.  Did you capture STDERR and do you see any failures
there?

B

On Oct 24, 2013, at 10:43 AM, Sujai wrote:




Hi all
First of all, thank you to Carson Holt and Mark Yandell and team for an
excellent program with excellent installation instructions. Setting maker
2.28 up and running it (both with MPI and without) was a breeze on a PBS
cluster. Everything worked as expected (doesn't happen that often in
bioinformatics software! :-))

I did a test run on 150 longish contigs (>50kb each) and everything worked
fine, including gff3_merge, fasta_merge etc. I got predictions for all the
contigs etc.


However, when I ran it on the full 20,000 sequence file (minimum 300 bp, I
know - I could have set the min length in maker_opts.ctl but I wanted the
repeatmasker analysis done even for the smaller contigs), I had a problem:

1. the intermediate files were all fine (i.e. grep -c FINISHED
...master_datastore_index.log showed the right number of sequences)

2. But gff3_merge -d ...master_datastore_index.log  only gave a file with
about 9000 contigs. I ran it a few times and got the same result each
time. fasta_merge gave back sequences from all ~20,000 contigs, so I know
the contig_datastore was fine.

3. Could it be that gff3_merge hit some sort of output limit? the GFF3
file created seems to be almost exactly 100MB. Or could it be a limit of
my OS environment? I had a lot of memory (12 GB) and a large tmp directory
(10 GB) so that should not be a problem...

If anyone has seen this problem or can shed any light on this, that would
be great.

I'm going to try splitting the file into smaller sets and hoping for the
best.

Thanks

- Sujai




-- 
You received this message because you are subscribed to the Google Groups
"maker-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to maker-devel... at googlegroups.com <>.
To post to this group, send email to maker... at googlegroups.com <>.
Visit this group at http://groups.google.com/group/maker-devel.
For more options, visit https://groups.google.com/groups/opt_out.




Barry Moore
Research Scientist
Dept. of Human Genetics
University of Utah
Salt Lake City, UT 84112
--------------------------------------------
(801) 585-3543









-- 
You received this message because you are subscribed to a topic in the
Google Groups "maker-devel" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/maker-devel/bApnLPFgmRc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
maker-devel... at googlegroups.com <>.
To post to this group, send email to maker... at googlegroups.com <>.
Visit this group at http://groups.google.com/group/maker-devel.
For more options, visit https://groups.google.com/groups/opt_out.






-- 
You received this message because you are subscribed to the Google Groups
"maker-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to maker-devel... at googlegroups.com <>.
To post to this group, send email to maker... at googlegroups.com <>.
Visit this group at http://groups.google.com/group/maker-devel.
For more options, visit https://groups.google.com/groups/opt_out.




Barry Moore
Research Scientist
Dept. of Human Genetics
University of Utah
Salt Lake City, UT 84112
--------------------------------------------
(801) 585-3543











On Friday, October 25, 2013 11:22:08 AM UTC-5, Barry wrote:
Hi Sujai,
If you still have that original directory available a couple things you to
try:

# Does this give you the number of contigs you're expecting?
find datastore_directory -name '*.gff3' | wc -l

# If the above gives what you expect what does the file size look like on
the smallest files?
find ./ -type f | xargs ls -Sl | tail

Barry

On Oct 24, 2013, at 4:04 PM, Sujai wrote:


Hi Barry

The last stderr message in the job is from the maker command:

Maker is now finished!!!

my last 3 commands were (in my pbs/torque job script):

----job script----
...other commands to set variables etc...
mpiexec -n 12 maker -g $SPLITFILE -base $SPLITFILE maker_opts.ctl
maker_bopts.ctl maker_exe.ctl
gff3_merge -o $PBS_O_WORKDIR/$SPLITFILE.gff3 -d
$SPLITFILE.maker.output/${SPLITFILE}_master_datastore_index.log
fasta_merge -d 
$SPLITFILE.maker.output/${SPLITFILE}_master_datastore_index.log
-----

so, no gff3_merge stderr messages
the fasta_merge command (which came after gff3_merge) has completed
correctly, with all proteins and transcripts accounted for.
I just ran the same contigs again in smaller batches, and it seems to be
proceeding correctly (the final gff3 files are between 49-55MB for each
chunk of fasta files. In the previous case, the final GFF3 file was 99MB
or 100MB (which is why I thought there was some sort of filesize/memory
limit)

Thanks for looking into this,

- Sujai




On 24 October 2013 21:42, Barry Moore <barry... at genetics.utah.edu <>>
wrote:

Hi Sujai,
There are a couple of fatal errors that can be thrown by gff3_merge if it
encounters errors.  Did you capture STDERR and do you see any failures
there?

B

On Oct 24, 2013, at 10:43 AM, Sujai wrote:




Hi all
First of all, thank you to Carson Holt and Mark Yandell and team for an
excellent program with excellent installation instructions. Setting maker
2.28 up and running it (both with MPI and without) was a breeze on a PBS
cluster. Everything worked as expected (doesn't happen that often in
bioinformatics software! :-))

I did a test run on 150 longish contigs (>50kb each) and everything worked
fine, including gff3_merge, fasta_merge etc. I got predictions for all the
contigs etc.


However, when I ran it on the full 20,000 sequence file (minimum 300 bp, I
know - I could have set the min length in maker_opts.ctl but I wanted the
repeatmasker analysis done even for the smaller contigs), I had a problem:

1. the intermediate files were all fine (i.e. grep -c FINISHED
...master_datastore_index.log showed the right number of sequences)

2. But gff3_merge -d ...master_datastore_index.log  only gave a file with
about 9000 contigs. I ran it a few times and got the same result each
time. fasta_merge gave back sequences from all ~20,000 contigs, so I know
the contig_datastore was fine.

3. Could it be that gff3_merge hit some sort of output limit? the GFF3
file created seems to be almost exactly 100MB. Or could it be a limit of
my OS environment? I had a lot of memory (12 GB) and a large tmp directory
(10 GB) so that should not be a problem...

If anyone has seen this problem or can shed any light on this, that would
be great.

I'm going to try splitting the file into smaller sets and hoping for the
best.

Thanks

- Sujai




-- 
You received this message because you are subscribed to the Google Groups
"maker-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to maker-devel... at googlegroups.com <>.
To post to this group, send email to maker... at googlegroups.com <>.
Visit this group at http://groups.google.com/group/maker-devel.
For more options, visit https://groups.google.com/groups/opt_out.




Barry Moore
Research Scientist
Dept. of Human Genetics
University of Utah
Salt Lake City, UT 84112
--------------------------------------------
(801) 585-3543









-- 
You received this message because you are subscribed to a topic in the
Google Groups "maker-devel" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/maker-devel/bApnLPFgmRc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
maker-devel... at googlegroups.com <>.
To post to this group, send email to maker... at googlegroups.com <>.
Visit this group at http://groups.google.com/group/maker-devel.
For more options, visit https://groups.google.com/groups/opt_out.






-- 
You received this message because you are subscribed to the Google Groups
"maker-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to maker-devel... at googlegroups.com <>.
To post to this group, send email to maker... at googlegroups.com <>.
Visit this group at http://groups.google.com/group/maker-devel.
For more options, visit https://groups.google.com/groups/opt_out.




Barry Moore
Research Scientist
Dept. of Human Genetics
University of Utah
Salt Lake City, UT 84112
--------------------------------------------
(801) 585-3543














From sujaikumar at gmail.com  Tue Nov 19 01:33:06 2013
From: sujaikumar at gmail.com (Sujai)
Date: Tue, 19 Nov 2013 08:33:06 +0000
Subject: [maker-devel] gff3_merge error - only half the contigs are
	reported
In-Reply-To: <CEAFD381.2B146%ejr@stowers.org>
References: <CEAFD381.2B146%ejr@stowers.org>
Message-ID: <CAFADFFu7Re=kRTB6qbS3qjhAEGQ0DmbJeJ3wPBq-QonM9VYDtQ@mail.gmail.com>

Hi Eric

Thanks for uncovering the /tmp limitation. I had changed TMPDIR in my
maker_opts.ctl file, but I suppose gff3_merge would not use that setting,
and would use /tmp or whatever TMPDIR was set to in the current shell.

Cheers,

- Sujai



On 18 November 2013 20:24, Ross, Eric <ejr at stowers.org> wrote:

> I had the same problem Sujai reported  on the 25th.
>
> When I run gff3_merge I only get back results from a subset of my
> scaffolds.  Every scaffold has a gff file in the data store.  fasta_merge
> works fine.  No errors are printed to STDOUT.
>
> It took me some poking around, but this seems that if there is
> insufficient space in /tmp to generate the temporary files merge_gff3
> completes without error and just creates a gff file from whatever fit in
> the temporary files.  I'm not sure why tempfile() doesn't return a useful
> error.
>
> I was able to get around the error by setting the environment variable
> TMPDIR to someplace with sufficient space, but if there is a way to
> generate a useful error it might be worth adding.
>
>
> Eric
>
>
>
>
> --original below--
> On Friday, October 25, 2013 11:22:08 AM UTC-5, Barry wrote:
> Hi Sujai,
> If you still have that original directory available a couple things you to
> try:
>
> # Does this give you the number of contigs you're expecting?
> find datastore_directory -name '*.gff3' | wc -l
>
> # If the above gives what you expect what does the file size look like on
> the smallest files?
> find ./ -type f | xargs ls -Sl | tail
>
> Barry
>
> On Oct 24, 2013, at 4:04 PM, Sujai wrote:
>
>
> Hi Barry
>
> The last stderr message in the job is from the maker command:
>
> Maker is now finished!!!
>
> my last 3 commands were (in my pbs/torque job script):
>
> ----job script----
> ...other commands to set variables etc...
> mpiexec -n 12 maker -g $SPLITFILE -base $SPLITFILE maker_opts.ctl
> maker_bopts.ctl maker_exe.ctl
> gff3_merge -o $PBS_O_WORKDIR/$SPLITFILE.gff3 -d
> $SPLITFILE.maker.output/${SPLITFILE}_master_datastore_index.log
> fasta_merge -d
> $SPLITFILE.maker.output/${SPLITFILE}_master_datastore_index.log
> -----
>
> so, no gff3_merge stderr messages
> the fasta_merge command (which came after gff3_merge) has completed
> correctly, with all proteins and transcripts accounted for.
> I just ran the same contigs again in smaller batches, and it seems to be
> proceeding correctly (the final gff3 files are between 49-55MB for each
> chunk of fasta files. In the previous case, the final GFF3 file was 99MB
> or 100MB (which is why I thought there was some sort of filesize/memory
> limit)
>
> Thanks for looking into this,
>
> - Sujai
>
>
>
>
> On 24 October 2013 21:42, Barry Moore <barry... at genetics.utah.edu <>>
> wrote:
>
> Hi Sujai,
> There are a couple of fatal errors that can be thrown by gff3_merge if it
> encounters errors.  Did you capture STDERR and do you see any failures
> there?
>
> B
>
> On Oct 24, 2013, at 10:43 AM, Sujai wrote:
>
>
>
>
> Hi all
> First of all, thank you to Carson Holt and Mark Yandell and team for an
> excellent program with excellent installation instructions. Setting maker
> 2.28 up and running it (both with MPI and without) was a breeze on a PBS
> cluster. Everything worked as expected (doesn't happen that often in
> bioinformatics software! :-))
>
> I did a test run on 150 longish contigs (>50kb each) and everything worked
> fine, including gff3_merge, fasta_merge etc. I got predictions for all the
> contigs etc.
>
>
> However, when I ran it on the full 20,000 sequence file (minimum 300 bp, I
> know - I could have set the min length in maker_opts.ctl but I wanted the
> repeatmasker analysis done even for the smaller contigs), I had a problem:
>
> 1. the intermediate files were all fine (i.e. grep -c FINISHED
> ...master_datastore_index.log showed the right number of sequences)
>
> 2. But gff3_merge -d ...master_datastore_index.log  only gave a file with
> about 9000 contigs. I ran it a few times and got the same result each
> time. fasta_merge gave back sequences from all ~20,000 contigs, so I know
> the contig_datastore was fine.
>
> 3. Could it be that gff3_merge hit some sort of output limit? the GFF3
> file created seems to be almost exactly 100MB. Or could it be a limit of
> my OS environment? I had a lot of memory (12 GB) and a large tmp directory
> (10 GB) so that should not be a problem...
>
> If anyone has seen this problem or can shed any light on this, that would
> be great.
>
> I'm going to try splitting the file into smaller sets and hoping for the
> best.
>
> Thanks
>
> - Sujai
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "maker-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to maker-devel... at googlegroups.com <>.
> To post to this group, send email to maker... at googlegroups.com <>.
> Visit this group at http://groups.google.com/group/maker-devel.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
> Barry Moore
> Research Scientist
> Dept. of Human Genetics
> University of Utah
> Salt Lake City, UT 84112
> --------------------------------------------
> (801) 585-3543
>
>
>
>
>
>
>
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "maker-devel" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/maker-devel/bApnLPFgmRc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> maker-devel... at googlegroups.com <>.
> To post to this group, send email to maker... at googlegroups.com <>.
> Visit this group at http://groups.google.com/group/maker-devel.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "maker-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to maker-devel... at googlegroups.com <>.
> To post to this group, send email to maker... at googlegroups.com <>.
> Visit this group at http://groups.google.com/group/maker-devel.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
> Barry Moore
> Research Scientist
> Dept. of Human Genetics
> University of Utah
> Salt Lake City, UT 84112
> --------------------------------------------
> (801) 585-3543
>
>
>
>
>
>
>
>
>
>
>
> On Friday, October 25, 2013 11:22:08 AM UTC-5, Barry wrote:
> Hi Sujai,
> If you still have that original directory available a couple things you to
> try:
>
> # Does this give you the number of contigs you're expecting?
> find datastore_directory -name '*.gff3' | wc -l
>
> # If the above gives what you expect what does the file size look like on
> the smallest files?
> find ./ -type f | xargs ls -Sl | tail
>
> Barry
>
> On Oct 24, 2013, at 4:04 PM, Sujai wrote:
>
>
> Hi Barry
>
> The last stderr message in the job is from the maker command:
>
> Maker is now finished!!!
>
> my last 3 commands were (in my pbs/torque job script):
>
> ----job script----
> ...other commands to set variables etc...
> mpiexec -n 12 maker -g $SPLITFILE -base $SPLITFILE maker_opts.ctl
> maker_bopts.ctl maker_exe.ctl
> gff3_merge -o $PBS_O_WORKDIR/$SPLITFILE.gff3 -d
> $SPLITFILE.maker.output/${SPLITFILE}_master_datastore_index.log
> fasta_merge -d
> $SPLITFILE.maker.output/${SPLITFILE}_master_datastore_index.log
> -----
>
> so, no gff3_merge stderr messages
> the fasta_merge command (which came after gff3_merge) has completed
> correctly, with all proteins and transcripts accounted for.
> I just ran the same contigs again in smaller batches, and it seems to be
> proceeding correctly (the final gff3 files are between 49-55MB for each
> chunk of fasta files. In the previous case, the final GFF3 file was 99MB
> or 100MB (which is why I thought there was some sort of filesize/memory
> limit)
>
> Thanks for looking into this,
>
> - Sujai
>
>
>
>
> On 24 October 2013 21:42, Barry Moore <barry... at genetics.utah.edu <>>
> wrote:
>
> Hi Sujai,
> There are a couple of fatal errors that can be thrown by gff3_merge if it
> encounters errors.  Did you capture STDERR and do you see any failures
> there?
>
> B
>
> On Oct 24, 2013, at 10:43 AM, Sujai wrote:
>
>
>
>
> Hi all
> First of all, thank you to Carson Holt and Mark Yandell and team for an
> excellent program with excellent installation instructions. Setting maker
> 2.28 up and running it (both with MPI and without) was a breeze on a PBS
> cluster. Everything worked as expected (doesn't happen that often in
> bioinformatics software! :-))
>
> I did a test run on 150 longish contigs (>50kb each) and everything worked
> fine, including gff3_merge, fasta_merge etc. I got predictions for all the
> contigs etc.
>
>
> However, when I ran it on the full 20,000 sequence file (minimum 300 bp, I
> know - I could have set the min length in maker_opts.ctl but I wanted the
> repeatmasker analysis done even for the smaller contigs), I had a problem:
>
> 1. the intermediate files were all fine (i.e. grep -c FINISHED
> ...master_datastore_index.log showed the right number of sequences)
>
> 2. But gff3_merge -d ...master_datastore_index.log  only gave a file with
> about 9000 contigs. I ran it a few times and got the same result each
> time. fasta_merge gave back sequences from all ~20,000 contigs, so I know
> the contig_datastore was fine.
>
> 3. Could it be that gff3_merge hit some sort of output limit? the GFF3
> file created seems to be almost exactly 100MB. Or could it be a limit of
> my OS environment? I had a lot of memory (12 GB) and a large tmp directory
> (10 GB) so that should not be a problem...
>
> If anyone has seen this problem or can shed any light on this, that would
> be great.
>
> I'm going to try splitting the file into smaller sets and hoping for the
> best.
>
> Thanks
>
> - Sujai
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "maker-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to maker-devel... at googlegroups.com <>.
> To post to this group, send email to maker... at googlegroups.com <>.
> Visit this group at http://groups.google.com/group/maker-devel.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
> Barry Moore
> Research Scientist
> Dept. of Human Genetics
> University of Utah
> Salt Lake City, UT 84112
> --------------------------------------------
> (801) 585-3543
>
>
>
>
>
>
>
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "maker-devel" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/maker-devel/bApnLPFgmRc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> maker-devel... at googlegroups.com <>.
> To post to this group, send email to maker... at googlegroups.com <>.
> Visit this group at http://groups.google.com/group/maker-devel.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "maker-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to maker-devel... at googlegroups.com <>.
> To post to this group, send email to maker... at googlegroups.com <>.
> Visit this group at http://groups.google.com/group/maker-devel.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
> Barry Moore
> Research Scientist
> Dept. of Human Genetics
> University of Utah
> Salt Lake City, UT 84112
> --------------------------------------------
> (801) 585-3543
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> maker-devel mailing list
> maker-devel at box290.bluehost.com
> http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131119/7daa435c/attachment-0002.html>

From carson.holt at genetics.utah.edu  Tue Nov 26 08:38:10 2013
From: carson.holt at genetics.utah.edu (Carson Holt)
Date: Tue, 26 Nov 2013 15:38:10 +0000
Subject: [maker-devel] no protein or transcript fasta output
In-Reply-To: <CAKbGhzW-uqNtpEmoOG-ygf6au06gQSmZUfuGpd=1PtFTD9MLtQ@mail.gmail.com>
References: <CAKbGhzW-uqNtpEmoOG-ygf6au06gQSmZUfuGpd=1PtFTD9MLtQ@mail.gmail.com>
Message-ID: <CEBA0E41.7169%carson.holt@genetics.utah.edu>

What version are you running?

Thanks,
Carson


From: mun hua <mh.tan85 at gmail.com<mailto:mh.tan85 at gmail.com>>
Date: Tuesday, November 26, 2013 at 2:32 AM
To: <maker-devel at yandell-lab.org<mailto:maker-devel at yandell-lab.org>>
Subject: no protein or transcript fasta output

Hi,

I tried out the example outlined by Maker, on the dpp_contig dataset.
Upon running maker, it only generated the gff output file, and none of the protein or transcript fasta files. I've checked the logs but have not seen any obvious errors.
Does anyone have any idea on why this is for me?

Thanks,
MH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131126/3ec95f21/attachment-0002.html>

From mh.tan85 at gmail.com  Tue Nov 26 02:32:04 2013
From: mh.tan85 at gmail.com (mun hua)
Date: Tue, 26 Nov 2013 17:32:04 +0800
Subject: [maker-devel] no protein or transcript fasta output
Message-ID: <CAKbGhzW-uqNtpEmoOG-ygf6au06gQSmZUfuGpd=1PtFTD9MLtQ@mail.gmail.com>

Hi,

I tried out the example outlined by Maker, on the dpp_contig dataset.
Upon running maker, it only generated the gff output file, and none of the
protein or transcript fasta files. I've checked the logs but have not seen
any obvious errors.
Does anyone have any idea on why this is for me?

Thanks,
MH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131126/8a6d4e21/attachment-0002.html>

From mh.tan85 at gmail.com  Tue Nov 26 18:03:45 2013
From: mh.tan85 at gmail.com (mun hua)
Date: Wed, 27 Nov 2013 09:03:45 +0800
Subject: [maker-devel] no protein or transcript fasta output
In-Reply-To: <CEBA0E41.7169%carson.holt@genetics.utah.edu>
References: <CAKbGhzW-uqNtpEmoOG-ygf6au06gQSmZUfuGpd=1PtFTD9MLtQ@mail.gmail.com>
	<CEBA0E41.7169%carson.holt@genetics.utah.edu>
Message-ID: <CAKbGhzWYr-6Sx4hVEq-1bPeQ5fZgNWxeF+61KYWZ8+0F-jNKow@mail.gmail.com>

I'm running Maker v2.28.

I tried Maker with protein2genome=1 instead of the recommended est2genome=1
and I managed to get transcript and protein fasta sequences.
That is strange, since I supplied the config file with both
the dpp_est.fasta and dpp_protein.fasta files?


On Tue, Nov 26, 2013 at 11:38 PM, Carson Holt <carson.holt at genetics.utah.edu
> wrote:

>  What version are you running?
>
>  Thanks,
> Carson
>
>
>   From: mun hua <mh.tan85 at gmail.com>
> Date: Tuesday, November 26, 2013 at 2:32 AM
> To: <maker-devel at yandell-lab.org>
> Subject: no protein or transcript fasta output
>
>  Hi,
>
>  I tried out the example outlined by Maker, on the dpp_contig dataset.
> Upon running maker, it only generated the gff output file, and none of the
> protein or transcript fasta files. I've checked the logs but have not seen
> any obvious errors.
> Does anyone have any idea on why this is for me?
>
>  Thanks,
> MH
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131127/eb47d812/attachment-0002.html>

From carsonhh at gmail.com  Sun Nov  3 20:16:03 2013
From: carsonhh at gmail.com (Carson Holt)
Date: Sun, 3 Nov 2013 20:16:03 -0700
Subject: [maker-devel] Serious Start Codon Problem
In-Reply-To: <CE8EE16A.212BC%graham.etherington@sainsbury-laboratory.ac.uk>
References: <CE7FA55D.10C4B%carsonhh@gmail.com>
	<CE8EE16A.212BC%graham.etherington@sainsbury-laboratory.ac.uk>
Message-ID: <CA+sW3ERmNDH2kO6616yLGZS3iJ2Z0XEUu_qL++iHN8HVo3_reA@mail.gmail.com>

2.30 beta is now available for use.  Sorry about the delay, between moving
and getting seriously ill for several days, I sort of dropped off the grid
for 2 weeks.  Give this version a try.

Thanks,
Carson




On Thu, Oct 24, 2013 at 7:42 AM, graham etherington (TSL) <
graham.etherington at sainsbury-laboratory.ac.uk> wrote:

> Hi,
> I notice that the latest version of Maker available from
> http://www.yandell-lab.org/software/maker.html is still v2.29b (4 Oct
> 2013). As we're also having the start codon problem we'd like to get hold
> of v2.30. Do you know when this will be released?
> Many thanks,
> Graham
>
>
> Dr. Graham Etherington
> Bioinformatics Support Officer,
> The Sainsbury Laboratory,
> Norwich Research Park,
> Norwich NR4 7UH.
> UK
> Tel: +44 (0)1603 450601
>
>
>
>
>
> On 13/10/2013 06:26, "Carson Holt" <carsonhh at gmail.com> wrote:
>
> >Before Wednesday, because after that I'm on a 6 day road trip, so I have
> >to have it wrapped up before I leave.
> >
> >--Carson
> >
> >
> >
> >
> >On 10/12/13 12:16 PM, "Felix Bemm" <felix.bemm at uni-wuerzburg.de> wrote:
> >
> >>Thx Carson! Do you now when 2.30 will be available? Bests
> >>
> >>On 12.10.2013 17:48, Carson Holt wrote:
> >>> This issue just came up this week on another e-mail as well.
> >>>
> >>> One way to fix it, is to edit the Bio::Tools::CodonTable module from
> >>> BioPerl (use maker --debug to have maker print out the locations of all
> >>> modules it uses).  Such a hack should only be done as a temporary work
> >>> around.
> >>>
> >>> You change line 256 from -->
> >>> ---M---------------M---------------M----------------------------
> >>>
> >>> To-->
> >>> -----------------------------------M----------------------------
> >>>
> >>>
> >>> Maker uses the BioPerl is_start_codon function to determine if the
> >>>codon
> >>> used in a result it receives is acceptable or if it should look
> >>>upstream
> >>> or downstream for a different one. Apparently there are actually 3
> >>> acceptable start codons in the standard codon table (2 rare ones and
> >>>one
> >>> common), so making the edit removes the two rare ones from the list.
> >>>
> >>> I'm also preparing a 2.30 release that exports a "strict" codon table
> >>>to
> >>> the BioPerl module, that will be used by default and should fix the
> >>>issue.
> >>>
> >>> Thanks,
> >>> Carson
> >>>
> >>>
> >>>
> >>> On 10/12/13 11:06 AM, "Felix Bemm" <felix.bemm at uni-wuerzburg.de>
> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> I have a serious problems with maker annotations especially the start
> >>>> codon placement. It started happening with maker version 2.27! About
> >>>>1/3
> >>>> of my genes are missing a proper start codon. When reviewing the GFF
> >>>> files gene predictors and est evidence standalone would predict the
> >>>> right gene structure including the start codon. I was thinking that
> >>>>this
> >>>> problem was somehow linked to my gene models but looking at their
> >>>> standalone prediction I discarded that theory. Just some stats about
> >>>> proteins with proper start codon (first column) and missing start
> >>>>codon
> >>>> (second column).
> >>>>
> >>>> Maker              9268    4215
> >>>> SNAP               16577   896
> >>>> Genemark   18764   290
> >>>>
> >>>> Numbers look the same when Augustus is used (currently retraining).
> >>>> Manually using EST's in Apollo often fixes the problems but I don't
> >>>>want
> >>>> to check > 4000 genes for this.
> >>>>
> >>>> Do you have any idea what could cause such a problem? If you need some
> >>>> example gff files I can send you.
> >>>>
> >>>> Best regards
> >>>> Felix
> >>>>
> >>>> --
> >>>> Felix Bemm
> >>>> Department of Bioinformatics
> >>>> University of W?rzburg, Germany
> >>>> Tel: +49 931 - 31 83696
> >>>> Fax: +49 931 - 31 84552
> >>>> felix.bemm at uni-wuerzburg.de
> >>>>
> >>>> _______________________________________________
> >>>> maker-devel mailing list
> >>>> maker-devel at box290.bluehost.com
> >>>>
> >>>>
> http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
> >>
> >>--
> >>Felix Bemm
> >>Department of Bioinformatics
> >>University of W?rzburg, Germany
> >>Tel: +49 931 - 31 83696
> >>Fax: +49 931 - 31 84552
> >>felix.bemm at uni-wuerzburg.de
> >
> >
> >
> >_______________________________________________
> >maker-devel mailing list
> >maker-devel at box290.bluehost.com
> >http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131103/136b60b8/attachment-0003.html>

From jfierst at uoregon.edu  Mon Nov  4 09:50:36 2013
From: jfierst at uoregon.edu (Janna Fierst)
Date: Mon, 4 Nov 2013 08:50:36 -0800
Subject: [maker-devel] Serious Start Codon Problem
In-Reply-To: <CA+sW3ERmNDH2kO6616yLGZS3iJ2Z0XEUu_qL++iHN8HVo3_reA@mail.gmail.com>
References: <CE7FA55D.10C4B%carsonhh@gmail.com>
	<CE8EE16A.212BC%graham.etherington@sainsbury-laboratory.ac.uk>
	<CA+sW3ERmNDH2kO6616yLGZS3iJ2Z0XEUu_qL++iHN8HVo3_reA@mail.gmail.com>
Message-ID: <CAGoyurYpCrzcpZeTpYhaQZqZr5a8ZNwBs5UZ88+CPez1nhTA6w@mail.gmail.com>

Hi,

I can't get my message to post to the list but I had a problem with
2.29-beta in parallel - it seemed to restart the same scaffolds over and
over instead of moving on to a new set. I was running the same as the 2.28
version, is it something with our mpi system here at UO? Thanks -Janna
Fierst


On Sun, Nov 3, 2013 at 7:16 PM, Carson Holt <carsonhh at gmail.com> wrote:

> 2.30 beta is now available for use.  Sorry about the delay, between moving
> and getting seriously ill for several days, I sort of dropped off the grid
> for 2 weeks.  Give this version a try.
>
> Thanks,
> Carson
>
>
>
>
> On Thu, Oct 24, 2013 at 7:42 AM, graham etherington (TSL) <
> graham.etherington at sainsbury-laboratory.ac.uk> wrote:
>
>> Hi,
>> I notice that the latest version of Maker available from
>> http://www.yandell-lab.org/software/maker.html is still v2.29b (4 Oct
>> 2013). As we're also having the start codon problem we'd like to get hold
>> of v2.30. Do you know when this will be released?
>> Many thanks,
>> Graham
>>
>>
>> Dr. Graham Etherington
>> Bioinformatics Support Officer,
>> The Sainsbury Laboratory,
>> Norwich Research Park,
>> Norwich NR4 7UH.
>> UK
>> Tel: +44 (0)1603 450601
>>
>>
>>
>>
>>
>> On 13/10/2013 06:26, "Carson Holt" <carsonhh at gmail.com> wrote:
>>
>> >Before Wednesday, because after that I'm on a 6 day road trip, so I have
>> >to have it wrapped up before I leave.
>> >
>> >--Carson
>> >
>> >
>> >
>> >
>> >On 10/12/13 12:16 PM, "Felix Bemm" <felix.bemm at uni-wuerzburg.de> wrote:
>> >
>> >>Thx Carson! Do you now when 2.30 will be available? Bests
>> >>
>> >>On 12.10.2013 17:48, Carson Holt wrote:
>> >>> This issue just came up this week on another e-mail as well.
>> >>>
>> >>> One way to fix it, is to edit the Bio::Tools::CodonTable module from
>> >>> BioPerl (use maker --debug to have maker print out the locations of
>> all
>> >>> modules it uses).  Such a hack should only be done as a temporary work
>> >>> around.
>> >>>
>> >>> You change line 256 from -->
>> >>> ---M---------------M---------------M----------------------------
>> >>>
>> >>> To-->
>> >>> -----------------------------------M----------------------------
>> >>>
>> >>>
>> >>> Maker uses the BioPerl is_start_codon function to determine if the
>> >>>codon
>> >>> used in a result it receives is acceptable or if it should look
>> >>>upstream
>> >>> or downstream for a different one. Apparently there are actually 3
>> >>> acceptable start codons in the standard codon table (2 rare ones and
>> >>>one
>> >>> common), so making the edit removes the two rare ones from the list.
>> >>>
>> >>> I'm also preparing a 2.30 release that exports a "strict" codon table
>> >>>to
>> >>> the BioPerl module, that will be used by default and should fix the
>> >>>issue.
>> >>>
>> >>> Thanks,
>> >>> Carson
>> >>>
>> >>>
>> >>>
>> >>> On 10/12/13 11:06 AM, "Felix Bemm" <felix.bemm at uni-wuerzburg.de>
>> wrote:
>> >>>
>> >>>> Hi,
>> >>>>
>> >>>> I have a serious problems with maker annotations especially the start
>> >>>> codon placement. It started happening with maker version 2.27! About
>> >>>>1/3
>> >>>> of my genes are missing a proper start codon. When reviewing the GFF
>> >>>> files gene predictors and est evidence standalone would predict the
>> >>>> right gene structure including the start codon. I was thinking that
>> >>>>this
>> >>>> problem was somehow linked to my gene models but looking at their
>> >>>> standalone prediction I discarded that theory. Just some stats about
>> >>>> proteins with proper start codon (first column) and missing start
>> >>>>codon
>> >>>> (second column).
>> >>>>
>> >>>> Maker              9268    4215
>> >>>> SNAP               16577   896
>> >>>> Genemark   18764   290
>> >>>>
>> >>>> Numbers look the same when Augustus is used (currently retraining).
>> >>>> Manually using EST's in Apollo often fixes the problems but I don't
>> >>>>want
>> >>>> to check > 4000 genes for this.
>> >>>>
>> >>>> Do you have any idea what could cause such a problem? If you need
>> some
>> >>>> example gff files I can send you.
>> >>>>
>> >>>> Best regards
>> >>>> Felix
>> >>>>
>> >>>> --
>> >>>> Felix Bemm
>> >>>> Department of Bioinformatics
>> >>>> University of W?rzburg, Germany
>> >>>> Tel: +49 931 - 31 83696
>> >>>> Fax: +49 931 - 31 84552
>> >>>> felix.bemm at uni-wuerzburg.de
>> >>>>
>> >>>> _______________________________________________
>> >>>> maker-devel mailing list
>> >>>> maker-devel at box290.bluehost.com
>> >>>>
>> >>>>
>> http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>> >>
>> >>--
>> >>Felix Bemm
>> >>Department of Bioinformatics
>> >>University of W?rzburg, Germany
>> >>Tel: +49 931 - 31 83696
>> >>Fax: +49 931 - 31 84552
>> >>felix.bemm at uni-wuerzburg.de
>> >
>> >
>> >
>> >_______________________________________________
>> >maker-devel mailing list
>> >maker-devel at box290.bluehost.com
>> >http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>>
>>
>
> _______________________________________________
> maker-devel mailing list
> maker-devel at box290.bluehost.com
> http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131104/415de8e4/attachment-0003.html>

From marc.hoeppner at imbim.uu.se  Tue Nov  5 01:55:31 2013
From: marc.hoeppner at imbim.uu.se (Marc P. Hoeppner)
Date: Tue, 05 Nov 2013 09:55:31 +0100
Subject: [maker-devel] Maker and external ab-inito predictions
Message-ID: <5278B283.3000601@imbim.uu.se>

Hi,

this is possibly a trivial question, but I am realizing that Maker does 
not seem to process augustus files I have produced externally (augustus 
2.7); at least they don't seem to make it into the final annotation file.

My question(s) therefore:

1) What exact GFF features does maker expect for a 'pred_gff' file? 
Would it happily accept an augustus gff, or would I need to modify the 
native augustus features somehow? (Trying to find out whether this is a 
Maker issue or some other problem)

2) Is there a way to feed hint files to Maker to use with augustus? 
Couldn't find anything about that specifically anyway.

Regards,

Marc

-- 
-----------
Marc P. Hoeppner, PhD
Researcher
Department of Medical Biochemistry and Microbiology
Uppsala University, Sweden
marc.hoepner at imbim.uu.se




From smg283 at gmail.com  Tue Nov  5 17:53:55 2013
From: smg283 at gmail.com (Scott Geib)
Date: Tue, 5 Nov 2013 14:53:55 -1000
Subject: [maker-devel] running maker on tacc stampede
Message-ID: <CAH221buRe6jsRyeVnkup3bhf3fbHJp+hW+TEgOpzTmbmZ8TOBA@mail.gmail.com>

Hi,
I was looking for help running maker on stampede at tacc.  Have run in the
past on lonestar with no issues, but am getting some errors on stampede
(have never run before on stampede.  I also tried downloading the same
maker version on lonestar and running the same test data and had no issues.
 In both cases, used TACC module command to load more current perl into my
environment before installing maker.  On lonestar, SGE is used so
submission script slightly different in syntax, but ran with same
parameters. I know repbase isn't installed, but I just wanted to get
software working
Thanks Scott


Using this SLURM script with the current maker beta release (30),
submitting with sbatch on dpp test data in a copy of maker data directory:

#!/bin/bash
#SBATCH -J testmaker
#SBATCH -o testmaker.o%J
#SBATCH -e testmaker.e%J
##SBATCH -N 2
#SBATCH -n 32
#SBATCH -p development
#SBATCH -t 2:00:00
#SBATCH --mail-user=XXXXXX
#SBATCH --mail-type=all

ibrun ../maker/bin/maker -base test


This results in the following errors in testmaker.ejobid:

STATUS: Parsing control files...
WARNING: RepBase is not installed for RepeatMasker. This limits
RepeatMasker's functionality and makes the model_org option in the
control files virtually meaningless. MAKER will now reconfigure
for simple repeat masking only.
STATUS: Processing and indexing input FASTA files...
[c559-001.stampede.tacc.utexas.edu:mpi_rank_2][error_sighandler] Caught
error: Segmentation fault (signal 11)
[c559-001.stampede.tacc.utexas.edu:mpispawn_0][child_handler] MPI process
(rank: 2, pid: 35423) terminated with signal 11 -> abort job
SIGINT received
SIGINT received
SIGINT received
SIGINT received
SIGINT received
SIGINT received
SIGINT received
SIGINT received
SIGINT received
SIGINT received
SIGINT received
[c559-001.stampede.tacc.utexas.edu:mpi_rank_1][error_sighandler] Caught
error: Segmentation fault (signal 11)
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
        eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
forks.pm line 609
        threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
line 586
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
        eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
forks.pm line 609
        threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
line 586
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
        eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
forks.pm line 609
        threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
line 586
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        eval {...} called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        Parallel::Application::MPI::__ANON__() called at
/work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
        Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x55efbc8)') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
        Parallel::Application::MPI::MPI_Recv('SCALAR(0x54f4908)', -2, 1111)
called at /work/02726/pbarc/maker/bin/maker line 530
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
        eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
forks.pm line 609
        threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
line 586
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
        eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
forks.pm line 609
        threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
line 586
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
        eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
forks.pm line 609
        threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
line 586
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
        eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
forks.pm line 609
        threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
line 586
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
        eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
forks.pm line 609
        threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
line 586
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
        eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
forks.pm line 609
        threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
line 586
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
        eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
forks.pm line 609
        threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
line 586

 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        eval {...} called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        Parallel::Application::MPI::__ANON__() called at
/work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
        Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x36ffd10)') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
        Parallel::Application::MPI::MPI_Recv('SCALAR(0x3606080)', 0, 4444)
called at /work/02726/pbarc/maker/bin/maker line 578
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        eval {...} called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        Parallel::Application::MPI::__ANON__() called at
/work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
        Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x4d77a00)') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
        Parallel::Application::MPI::MPI_Recv('SCALAR(0x4c7f080)', 0, 4444)
called at /work/02726/pbarc/maker/bin/maker line 578
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        eval {...} called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        Parallel::Application::MPI::__ANON__() called at
/work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
        Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x418ece0)') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
        Parallel::Application::MPI::MPI_Recv('SCALAR(0x4095080)', 0, 4444)
called at /work/02726/pbarc/maker/bin/maker line 578
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        eval {...} called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        Parallel::Application::MPI::__ANON__() called at
/work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
        Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x3c05a00)') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
        Parallel::Application::MPI::MPI_Recv('SCALAR(0x3b0d080)', 0, 4444)
called at /work/02726/pbarc/maker/bin/maker line 578
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        eval {...} called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        Parallel::Application::MPI::__ANON__() called at
/work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
        Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x3b50a00)') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
        Parallel::Application::MPI::MPI_Recv('SCALAR(0x3a58080)', 0, 4444)
called at /work/02726/pbarc/maker/bin/maker line 578
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        eval {...} called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        Parallel::Application::MPI::__ANON__() called at
/work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
        Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x55cecf0)') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
        Parallel::Application::MPI::MPI_Recv('SCALAR(0x54d5080)', 0, 4444)
called at /work/02726/pbarc/maker/bin/maker line 578
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        eval {...} called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        Parallel::Application::MPI::__ANON__() called at
/work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
        Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x4a7ccf0)') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
        Parallel::Application::MPI::MPI_Recv('SCALAR(0x4983080)', 0, 4444)
called at /work/02726/pbarc/maker/bin/maker line 578
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        eval {...} called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        Parallel::Application::MPI::__ANON__() called at
/work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
        Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x53f1a00)') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
        Parallel::Application::MPI::MPI_Recv('SCALAR(0x52f9080)', 0, 4444)
called at /work/02726/pbarc/maker/bin/maker line 578
 at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
        forks::signals::__ANON__('INT') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        eval {...} called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
        Parallel::Application::MPI::__ANON__() called at
/work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
        Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x367da00)') called at
/work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
        Parallel::Application::MPI::MPI_Recv('SCALAR(0x3585080)', 0, 4444)
called at /work/02726/pbarc/maker/bin/maker line 578
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 23, pid: 10976) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 20, pid: 10973) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 17, pid: 10970) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 18, pid: 10971) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 19, pid: 10972) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 16, pid: 10969) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 21, pid: 10974) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 22, pid: 10975) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 24, pid: 10977) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 25, pid: 10978) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 26, pid: 10979) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 27, pid: 10980) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 28, pid: 10981) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 29, pid: 10982) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 30, pid: 10983) exited with status 2
[c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
(rank: 31, pid: 10984) exited with status 2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131105/561e5847/attachment-0003.html>

From carsonhh at gmail.com  Wed Nov  6 00:40:30 2013
From: carsonhh at gmail.com (Carson Holt)
Date: Wed, 6 Nov 2013 00:40:30 -0700
Subject: [maker-devel] Maker and external ab-inito predictions
In-Reply-To: <5278B283.3000601@imbim.uu.se>
References: <5278B283.3000601@imbim.uu.se>
Message-ID: <CA+sW3ETtKzitZurwUdLHbMauBwNYp49HOqhK6iY-AY=Oggwgbg@mail.gmail.com>

1) MAKER prefers match/match_part but should be able to handle any two
level feature or even gene/mRNA/exon/CDS features.  Make sure it's infact
GFF3 and not GTF or GFF2.

2) MAKER builds it's own hints based on the evidence alignments it finds,
providing user generated hint files is not supported.  If you already have
those, you can just run augustus directly, since one of the the main
benefit of MAKER is that it finds the hints for you and you would no longer
need that.

Perhaps you can give more details on what exactly you are trying to do, and
we could help you configure MAKER.

Thanks,
Carson



On Tue, Nov 5, 2013 at 1:55 AM, Marc P. Hoeppner
<marc.hoeppner at imbim.uu.se>wrote:

> Hi,
>
> this is possibly a trivial question, but I am realizing that Maker does
> not seem to process augustus files I have produced externally (augustus
> 2.7); at least they don't seem to make it into the final annotation file.
>
> My question(s) therefore:
>
> 1) What exact GFF features does maker expect for a 'pred_gff' file? Would
> it happily accept an augustus gff, or would I need to modify the native
> augustus features somehow? (Trying to find out whether this is a Maker
> issue or some other problem)
>
> 2) Is there a way to feed hint files to Maker to use with augustus?
> Couldn't find anything about that specifically anyway.
>
> Regards,
>
> Marc
>
> --
> -----------
> Marc P. Hoeppner, PhD
> Researcher
> Department of Medical Biochemistry and Microbiology
> Uppsala University, Sweden
> marc.hoepner at imbim.uu.se
>
>
> _______________________________________________
> maker-devel mailing list
> maker-devel at box290.bluehost.com
> http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131106/779c0953/attachment-0003.html>

From marc.hoeppner at imbim.uu.se  Wed Nov  6 00:45:09 2013
From: marc.hoeppner at imbim.uu.se (Marc P. Hoeppner)
Date: Wed, 06 Nov 2013 08:45:09 +0100
Subject: [maker-devel] Maker and external ab-inito predictions
In-Reply-To: <CA+sW3ETtKzitZurwUdLHbMauBwNYp49HOqhK6iY-AY=Oggwgbg@mail.gmail.com>
References: <5278B283.3000601@imbim.uu.se>
	<CA+sW3ETtKzitZurwUdLHbMauBwNYp49HOqhK6iY-AY=Oggwgbg@mail.gmail.com>
Message-ID: <5279F385.5030005@imbim.uu.se>

Hi Carson,

thanks for the clarification. I saw in the code that the Augustus Widget 
uses hints, but wasn't sure if and how those were generated. If they are 
derived from the evidence alignments, prefect. That's all I needed 
anyway. As for the passing of an external phred_gff, I guess the native 
Augustus GFF output is a little wonky - I'll try to convert it to 
match/match_parts to see if that helps (but with Maker computing it's 
own hints, I don't actually have to...).

Anyway, thanks again!

/Marc
> 1) MAKER prefers match/match_part but should be able to handle any two 
> level feature or even gene/mRNA/exon/CDS features.  Make sure it's 
> infact GFF3 and not GTF or GFF2.
>
> 2) MAKER builds it's own hints based on the evidence alignments it 
> finds, providing user generated hint files is not supported.  If you 
> already have those, you can just run augustus directly, since one of 
> the the main benefit of MAKER is that it finds the hints for you and 
> you would no longer need that.
>
> Perhaps you can give more details on what exactly you are trying to 
> do, and we could help you configure MAKER.
>
> Thanks,
> Carson
>
>
>
> On Tue, Nov 5, 2013 at 1:55 AM, Marc P. Hoeppner 
> <marc.hoeppner at imbim.uu.se <mailto:marc.hoeppner at imbim.uu.se>> wrote:
>
>     Hi,
>
>     this is possibly a trivial question, but I am realizing that Maker
>     does not seem to process augustus files I have produced externally
>     (augustus 2.7); at least they don't seem to make it into the final
>     annotation file.
>
>     My question(s) therefore:
>
>     1) What exact GFF features does maker expect for a 'pred_gff'
>     file? Would it happily accept an augustus gff, or would I need to
>     modify the native augustus features somehow? (Trying to find out
>     whether this is a Maker issue or some other problem)
>
>     2) Is there a way to feed hint files to Maker to use with
>     augustus? Couldn't find anything about that specifically anyway.
>
>     Regards,
>
>     Marc
>
>     -- 
>     -----------
>     Marc P. Hoeppner, PhD
>     Researcher
>     Department of Medical Biochemistry and Microbiology
>     Uppsala University, Sweden
>     marc.hoepner at imbim.uu.se <mailto:marc.hoepner at imbim.uu.se>
>
>
>     _______________________________________________
>     maker-devel mailing list
>     maker-devel at box290.bluehost.com
>     <mailto:maker-devel at box290.bluehost.com>
>     http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>
>


-- 
-----------
Marc P. Hoeppner, PhD
Researcher
Department of Medical Biochemistry and Microbiology
Uppsala University, Sweden
marc.hoepner at imbim.uu.se

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131106/7de0b86d/attachment-0003.html>

From carsonhh at gmail.com  Wed Nov  6 00:53:14 2013
From: carsonhh at gmail.com (Carson Holt)
Date: Wed, 6 Nov 2013 00:53:14 -0700
Subject: [maker-devel] running maker on tacc stampede
In-Reply-To: <CAH221buRe6jsRyeVnkup3bhf3fbHJp+hW+TEgOpzTmbmZ8TOBA@mail.gmail.com>
References: <CAH221buRe6jsRyeVnkup3bhf3fbHJp+hW+TEgOpzTmbmZ8TOBA@mail.gmail.com>
Message-ID: <CA+sW3ETCGE64JDvGc6v3JyOgmV5D1=P96NGTmqmi1k3nm8Uu0A@mail.gmail.com>

We're also seeing core dumps on Lonestar using the same version of MAKER
already installed when we do a "fresh install".  We're not sure why,
because everything should be the same.  Maybe something about what we are
seeing is also related to the issue you are experiencing and maybe not.
 Let me try and figure out what is happening on Lonestar and I'll send you
my install procedure, and maybe that will fix the stampede issue as well.

Thanks,
Carson



On Tue, Nov 5, 2013 at 5:53 PM, Scott Geib <smg283 at gmail.com> wrote:

> Hi,
> I was looking for help running maker on stampede at tacc.  Have run in the
> past on lonestar with no issues, but am getting some errors on stampede
> (have never run before on stampede.  I also tried downloading the same
> maker version on lonestar and running the same test data and had no issues.
>  In both cases, used TACC module command to load more current perl into my
> environment before installing maker.  On lonestar, SGE is used so
> submission script slightly different in syntax, but ran with same
> parameters. I know repbase isn't installed, but I just wanted to get
> software working
> Thanks Scott
>
>
> Using this SLURM script with the current maker beta release (30),
> submitting with sbatch on dpp test data in a copy of maker data directory:
>
> #!/bin/bash
> #SBATCH -J testmaker
> #SBATCH -o testmaker.o%J
> #SBATCH -e testmaker.e%J
> ##SBATCH -N 2
> #SBATCH -n 32
> #SBATCH -p development
> #SBATCH -t 2:00:00
> #SBATCH --mail-user=XXXXXX
> #SBATCH --mail-type=all
>
> ibrun ../maker/bin/maker -base test
>
>
> This results in the following errors in testmaker.ejobid:
>
> STATUS: Parsing control files...
> WARNING: RepBase is not installed for RepeatMasker. This limits
> RepeatMasker's functionality and makes the model_org option in the
> control files virtually meaningless. MAKER will now reconfigure
> for simple repeat masking only.
> STATUS: Processing and indexing input FASTA files...
> [c559-001.stampede.tacc.utexas.edu:mpi_rank_2][error_sighandler] Caught
> error: Segmentation fault (signal 11)
> [c559-001.stampede.tacc.utexas.edu:mpispawn_0][child_handler] MPI process
> (rank: 2, pid: 35423) terminated with signal 11 -> abort job
> SIGINT received
> SIGINT received
> SIGINT received
> SIGINT received
> SIGINT received
> SIGINT received
> SIGINT received
> SIGINT received
> SIGINT received
> SIGINT received
> SIGINT received
> [c559-001.stampede.tacc.utexas.edu:mpi_rank_1][error_sighandler] Caught
> error: Segmentation fault (signal 11)
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
>         eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
> forks.pm line 609
>         threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
> line 586
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
>         eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
> forks.pm line 609
>         threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
> line 586
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
>         eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
> forks.pm line 609
>         threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
> line 586
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         eval {...} called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         Parallel::Application::MPI::__ANON__() called at
> /work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
>         Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x55efbc8)') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
>         Parallel::Application::MPI::MPI_Recv('SCALAR(0x54f4908)', -2,
> 1111) called at /work/02726/pbarc/maker/bin/maker line 530
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
>         eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
> forks.pm line 609
>         threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
> line 586
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
>         eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
> forks.pm line 609
>         threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
> line 586
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
>         eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
> forks.pm line 609
>         threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
> line 586
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
>         eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
> forks.pm line 609
>         threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
> line 586
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
>         eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
> forks.pm line 609
>         threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
> line 586
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
>         eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
> forks.pm line 609
>         threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
> line 586
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/forks.pm line 609
>         eval {...} called at /work/02726/pbarc/maker/bin/../perl/lib/
> forks.pm line 609
>         threads::__ANON__(0.1) called at /work/02726/pbarc/maker/bin/maker
> line 586
>
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         eval {...} called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         Parallel::Application::MPI::__ANON__() called at
> /work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
>         Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x36ffd10)') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
>         Parallel::Application::MPI::MPI_Recv('SCALAR(0x3606080)', 0, 4444)
> called at /work/02726/pbarc/maker/bin/maker line 578
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         eval {...} called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         Parallel::Application::MPI::__ANON__() called at
> /work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
>         Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x4d77a00)') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
>         Parallel::Application::MPI::MPI_Recv('SCALAR(0x4c7f080)', 0, 4444)
> called at /work/02726/pbarc/maker/bin/maker line 578
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         eval {...} called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         Parallel::Application::MPI::__ANON__() called at
> /work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
>         Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x418ece0)') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
>         Parallel::Application::MPI::MPI_Recv('SCALAR(0x4095080)', 0, 4444)
> called at /work/02726/pbarc/maker/bin/maker line 578
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         eval {...} called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         Parallel::Application::MPI::__ANON__() called at
> /work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
>         Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x3c05a00)') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
>         Parallel::Application::MPI::MPI_Recv('SCALAR(0x3b0d080)', 0, 4444)
> called at /work/02726/pbarc/maker/bin/maker line 578
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         eval {...} called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         Parallel::Application::MPI::__ANON__() called at
> /work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
>         Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x3b50a00)') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
>         Parallel::Application::MPI::MPI_Recv('SCALAR(0x3a58080)', 0, 4444)
> called at /work/02726/pbarc/maker/bin/maker line 578
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         eval {...} called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         Parallel::Application::MPI::__ANON__() called at
> /work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
>         Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x55cecf0)') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
>         Parallel::Application::MPI::MPI_Recv('SCALAR(0x54d5080)', 0, 4444)
> called at /work/02726/pbarc/maker/bin/maker line 578
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         eval {...} called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         Parallel::Application::MPI::__ANON__() called at
> /work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
>         Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x4a7ccf0)') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
>         Parallel::Application::MPI::MPI_Recv('SCALAR(0x4983080)', 0, 4444)
> called at /work/02726/pbarc/maker/bin/maker line 578
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         eval {...} called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         Parallel::Application::MPI::__ANON__() called at
> /work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
>         Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x53f1a00)') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
>         Parallel::Application::MPI::MPI_Recv('SCALAR(0x52f9080)', 0, 4444)
> called at /work/02726/pbarc/maker/bin/maker line 578
>  at /work/02726/pbarc/maker/bin/../perl/lib/forks/signals.pm line 97.
>         forks::signals::__ANON__('INT') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         eval {...} called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 145
>         Parallel::Application::MPI::__ANON__() called at
> /work/02726/pbarc/maker/bin/../perl/lib/Perl/Unsafe/Signals.pm line 18
>         Perl::Unsafe::Signals::UNSAFE_SIGNALS('CODE(0x367da00)') called at
> /work/02726/pbarc/maker/bin/../perl/lib/Parallel/Application/MPI.pm line 146
>         Parallel::Application::MPI::MPI_Recv('SCALAR(0x3585080)', 0, 4444)
> called at /work/02726/pbarc/maker/bin/maker line 578
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 23, pid: 10976) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 20, pid: 10973) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 17, pid: 10970) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 18, pid: 10971) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 19, pid: 10972) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 16, pid: 10969) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 21, pid: 10974) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 22, pid: 10975) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 24, pid: 10977) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 25, pid: 10978) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 26, pid: 10979) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 27, pid: 10980) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 28, pid: 10981) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 29, pid: 10982) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 30, pid: 10983) exited with status 2
> [c559-002.stampede.tacc.utexas.edu:mpispawn_1][child_handler] MPI process
> (rank: 31, pid: 10984) exited with status 2
>
>
> _______________________________________________
> maker-devel mailing list
> maker-devel at box290.bluehost.com
> http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131106/ab209d29/attachment-0003.html>

From xh33 at georgetown.edu  Tue Nov  5 11:04:18 2013
From: xh33 at georgetown.edu (Xin Huang)
Date: Tue, 5 Nov 2013 13:04:18 -0500
Subject: [maker-devel] Inquiry about using Exonerate through Maker
Message-ID: <CACvYrQEZR-35Crcmxbp-+CrG+QPs9dz3jkn3u9x++PU6BDF6tA@mail.gmail.com>

Hi,

I have a question regarding the use of Exonerate for cDNA alignment to
genomic scaffolds through Maker.

We first did a blastn search to find out which genomic scaffolds a cDNA
sequence aligns to. There are two scaffolds we figured that host the gene
of interest. So we picked these two scaffolds as the reference genome
sequence in the maker_opts.ctl file. I used the default settings in
maker_bopts.ctl. In the maker_exe.ctl file, the Ab-initio Gene Prediction
Algorithms section has only snap installed. In the maker_opts.ctl file, I
indicated the path to the EST sequence right after "est=" under EST
Evidence, skipped RepeatMasker (when included, only the repeat masking
information was shown in the GFF files) to only do the blast and exonerate,
set "est2genome=1" and left other options at default. In the directory
where we put the Maker output (the control files are all in this
directory), I ran the Maker pipeline using "<path_to_maker> maker_opts.ctl
maker_bopts.ctl maker_exe.ctl". It turned out that there is no alignment
information in the scaffold GFF3 file, just a plain figure indicating that
the scaffold is a contig. Then I tried to use the entire genome scaffold
set as the reference genome and reran the pipeline, still getting the same
results in terms of the Exonerate alignments. Please see the example of a
GFF3 file generated:

##gff-version 3
scaffold3928    .       contig  1       172176  .       .       .
ID=scaffold3928;Name=scaffold3928
###
##FASTA
>scaffold3928
<scaffold_sequence_omitted>

What do I need to adjust to get the alignment information into the GFF file
so I can upload into a genome browser as tracks?

Thank you very much for considering my inquiry.

Sincerely,

Xin Huang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131105/b6a8065e/attachment-0003.html>

From xh33 at georgetown.edu  Tue Nov  5 14:40:24 2013
From: xh33 at georgetown.edu (Xin Huang)
Date: Tue, 5 Nov 2013 16:40:24 -0500
Subject: [maker-devel] A suspected strange behavior of Maker...
Message-ID: <CACvYrQGP1dajOYyhiTDt6QuzCHdVR21vLYzmbtMKvF67d-fMiA@mail.gmail.com>

Hi,

I found a very bizarre thing when I ran Maker several times. The blastn
research seems to reverse query and subject the way it's specified in the
maker_opts.ctl file. When I put the scaffold sequence after genome= and the
cDNA sequence after est=, the blastn result actually used the scaffold as
query and the cDNA as subject. I realized that this sounds unreal, so I
reversed the places for the two and the blastn result is normal with the
cDNA as query and the scaffold as subject, but at the same time, the GFF
file is of the cDNA sequence. I tried a few times, and got the same result.
I deleted Maker (2.28) and reinstalled the beta version (2.30), still
getting the same result.

My wild guess was that this might be the reason why the est2genome
prediction using the EST sequence didn't go into the GFF3 file, as stated
in a previous email to the Maker-devel. I couldn't figure out how to test
this, though. I wonder if there's anything dramatically wrong that I've
been doing to get such odd results... If you'd like me to send you any
output files or control files, please let me know and I'll promptly pass
those along.

Thank you very much for considering my email.

Sincerely,

Xin Huang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131105/f942ccad/attachment-0003.html>

From Kerry_Gendreau at student.uml.edu  Fri Nov  8 16:40:06 2013
From: Kerry_Gendreau at student.uml.edu (Gendreau, Kerry L)
Date: Fri, 8 Nov 2013 23:40:06 +0000
Subject: [maker-devel] Maker is not predicting any genes on scaffold
Message-ID: <ae5739936c8745d9aaf58a434906305b@CO1PR02MB046.namprd02.prod.outlook.com>

Hello,

I am attempting to annotate a small section of an arthropod genome. I ran Maker on the command line and the results showed only repetitive regions recognized by Repeat Masker -- no predicted ORFs. I submitted my scaffold through the web interface and got the same results.

I know that there are genes present on this scaffold and when I run it through Augustus there are 13 ORFs predicted.

Are there some options that I need to adjust to get ab initio gene predictions from Maker?


Thank you,

Kerry Gendreau
Graduate Student, Dept. of Biological Sciences
University of Massachusetts Lowell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131108/ae7546e5/attachment-0003.html>

From dence at genetics.utah.edu  Sun Nov 10 19:43:12 2013
From: dence at genetics.utah.edu (Daniel Ence)
Date: Mon, 11 Nov 2013 02:43:12 +0000
Subject: [maker-devel] Maker is not predicting any genes on scaffold
In-Reply-To: <ae5739936c8745d9aaf58a434906305b@CO1PR02MB046.namprd02.prod.outlook.com>
References: <ae5739936c8745d9aaf58a434906305b@CO1PR02MB046.namprd02.prod.outlook.com>
Message-ID: <F2774D6F47BB9D449EEA8B0BF6679D9C65D3E471@mxb2.hg.genetics.utah.edu>

Hi Kerry, What evidence and abinitios did you use when you ran MAKER on your own machine?

Thanks,
Daniel

Daniel Ence
Graduate Student
Eccles Institute of Human Genetics
University of Utah
15 North 2030 East, Room 2100
Salt Lake City, UT 84112-5330
________________________________
From: maker-devel [maker-devel-bounces at yandell-lab.org] on behalf of Gendreau, Kerry L [Kerry_Gendreau at student.uml.edu]
Sent: Friday, November 08, 2013 4:40 PM
To: maker-devel at yandell-lab.org
Subject: [maker-devel] Maker is not predicting any genes on scaffold

Hello,

I am attempting to annotate a small section of an arthropod genome. I ran Maker on the command line and the results showed only repetitive regions recognized by Repeat Masker -- no predicted ORFs. I submitted my scaffold through the web interface and got the same results.

I know that there are genes present on this scaffold and when I run it through Augustus there are 13 ORFs predicted.

Are there some options that I need to adjust to get ab initio gene predictions from Maker?


Thank you,

Kerry Gendreau
Graduate Student, Dept. of Biological Sciences
University of Massachusetts Lowell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131111/a93b1101/attachment-0003.html>

From carson.holt at genetics.utah.edu  Sun Nov 10 20:08:23 2013
From: carson.holt at genetics.utah.edu (Carson Holt)
Date: Mon, 11 Nov 2013 03:08:23 +0000
Subject: [maker-devel] Problems with Maker
In-Reply-To: <CAC18qO8DbAWchktQpUC=CaPSL446kOj3Jgbt0_S1Ha41oAOh_w@mail.gmail.com>
Message-ID: <CEA59757.69E6%carson.holt@genetics.utah.edu>

For the installation problem, it shouldn't take more tun  few minutes.  You might want to just try setting up repeat masker manually, since what is happening is probably system specific.

The second problem is caused by an edit you made to the maker_opt.ctl file.  You deleted the '#' character that separates the options from the instructions comment, so the entire line is being interpreted as an option

model_org=all select a model organism for RepBase masking in RepeatMasker

So it's trying to use the phrase 'all select a model organism for RepBase masking in RepeatMasker' as the species, which causes repeat masker to fail.

Just change the line to model_org=all

--Carson


From: Sanea Sheikh <saneasheikh at gmail.com<mailto:saneasheikh at gmail.com>>
Date: Thursday, November 7, 2013 8:22 AM
To: <maker-devel at yandell-lab.org<mailto:maker-devel at yandell-lab.org>>
Subject: Problems with Maker

Hello

I am trying to run Maker v2.28 on my computer. I am having two problems.

When I use ./Build repeatmasker command for installing RepeatMasker, I get stuck at the Configuring RepeatMasker step for days. It doesn't move forward from that point. See the log attached (repeatmasker_maker.txt).

When I install RepeatMasker and run Maker, I get error message attached in maker_error_RM.txt file.

Can you please tell me what I am doing wrong here? I have also attached the maker opts.ctl file for your reference. I would really appreciate it if you can help me in this regard.

Regards
Sanea


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131111/f5550f90/attachment-0003.html>

From carsonhh at gmail.com  Sun Nov 10 22:10:08 2013
From: carsonhh at gmail.com (Carson Holt)
Date: Sun, 10 Nov 2013 22:10:08 -0700
Subject: [maker-devel] A suspected strange behavior of Maker...
In-Reply-To: <CACvYrQGP1dajOYyhiTDt6QuzCHdVR21vLYzmbtMKvF67d-fMiA@mail.gmail.com>
Message-ID: <CEA5B2C9.69F9%carsonhh@gmail.com>

Sorry for the slow reply, I was moving from Canada to the US, got sick, and
my moving truck got delayed one week. So I fell behind on the maker list.

What you observe is correct behavior.  The config is blasted against the
database of ESTs/proteins.  It really doesn't matter which way you blast,
you pick the direction that is most efficient for the question you are
asking, and you only have to adjust the Z value for database size if you
want alignment scores to be reproducible both ways.

Not getting results means they were filtered out for some reason (you don't
even have blastn results in your output).  If you can send a test dataset I
can take a look and tell you which filter.

Thanks,
Carson


From:  Xin Huang <xh33 at georgetown.edu>
Date:  Tuesday, November 5, 2013 2:40 PM
To:  <maker-devel at yandell-lab.org>
Subject:  [maker-devel] A suspected strange behavior of Maker...

Hi,

I found a very bizarre thing when I ran Maker several times. The blastn
research seems to reverse query and subject the way it's specified in the
maker_opts.ctl file. When I put the scaffold sequence after genome= and the
cDNA sequence after est=, the blastn result actually used the scaffold as
query and the cDNA as subject. I realized that this sounds unreal, so I
reversed the places for the two and the blastn result is normal with the
cDNA as query and the scaffold as subject, but at the same time, the GFF
file is of the cDNA sequence. I tried a few times, and got the same result.
I deleted Maker (2.28) and reinstalled the beta version (2.30), still
getting the same result.

My wild guess was that this might be the reason why the est2genome
prediction using the EST sequence didn't go into the GFF3 file, as stated in
a previous email to the Maker-devel. I couldn't figure out how to test this,
though. I wonder if there's anything dramatically wrong that I've been doing
to get such odd results... If you'd like me to send you any output files or
control files, please let me know and I'll promptly pass those along.

Thank you very much for considering my email.

Sincerely,

Xin Huang
_______________________________________________ maker-devel mailing list
maker-devel at box290.bluehost.com
http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131110/153ea1e5/attachment-0003.html>

From kpepin at genome.wustl.edu  Mon Nov 11 13:01:26 2013
From: kpepin at genome.wustl.edu (Kymberlie Hallsworth-Pepin)
Date: Mon, 11 Nov 2013 14:01:26 -0600 (CST)
Subject: [maker-devel] re-annotation
In-Reply-To: <CA5CEF3B.6A42%carsonhh@gmail.com>
References: <CA5CEF3B.6A42%carsonhh@gmail.com>
Message-ID: <alpine.DEB.2.00.1311111355190.28492@linus40.gsc.wustl.edu>

Hi Carson,

I am trying to take an existing gene set and update it using new proteins. 
I have the gene set in gff3 format - validated as ok - and have put it in
the model_gff line. I set the protein db to the new database and I set the 
map_forward=1 to maintain naming, but the output has no gene predictions 
in it. I have tried setting keep_preds both 0 and 1. I have put the gff 
file in both the pred_gff and model_gff and just in the pred_gff field, 
but I still don't get any predictions maintained. Can you tell me what I 
might be missing ?

thanks
Kym


____
This email message is a private communication. The information transmitted, including attachments, is intended only for the person or entity to which it is addressed and may contain confidential, privileged, and/or proprietary material. Any review, duplication, retransmission, distribution, or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is unauthorized by the sender and is prohibited. If you have received this message in error, please contact the sender immediately by return email and delete the original message from all computer systems. Thank you.



From cjfields at illinois.edu  Tue Nov 12 12:18:36 2013
From: cjfields at illinois.edu (Fields, Christopher J)
Date: Tue, 12 Nov 2013 19:18:36 +0000
Subject: [maker-devel] Recommendations for visualization?
Message-ID: <9B60EB76-1920-4B75-A224-C44070452B84@illinois.edu>

Barry, Carson,

Are there any recommendations re: visualizing MAKER-generated GFF3?  I know it?s currently geared towards Apollo integration, but as everything is moving towards Webapollo, attempts at finding the old local client Apollo code are a bit of an archaeological expedition (not to mention Apollo has always been a joy to set up from code :).  Is everyone still trying to use the old Apollo, since it seems to no longer be supported?

At the moment I am really thinking of working on simple scripts to make IGV-friendly input (and possibly similar Artemis for our smaller genome projects), but I don?t want to repeat work already in place.

chris


From barry.utah at gmail.com  Tue Nov 12 15:03:12 2013
From: barry.utah at gmail.com (Barry Moore)
Date: Tue, 12 Nov 2013 15:03:12 -0700
Subject: [maker-devel] Recommendations for visualization?
In-Reply-To: <9B60EB76-1920-4B75-A224-C44070452B84@illinois.edu>
References: <9B60EB76-1920-4B75-A224-C44070452B84@illinois.edu>
Message-ID: <90397AC5-7FEA-4B81-8085-49BD48787A6F@genetics.utah.edu>

This is a VERY good point Chris.  I think the new web-apollo is developing into a great tool, but there is now a gapping hole in the area of a desktop application (i.e. no server setup) to view/edit genome annotations.  I'd love to hear what others are using.  Our group has been using a combination of old Apollo instances, Web-Apollo and Gbrowse.

B

On Nov 12, 2013, at 12:18 PM, Fields, Christopher J wrote:

> Barry, Carson,
> 
> Are there any recommendations re: visualizing MAKER-generated GFF3?  I know it?s currently geared towards Apollo integration, but as everything is moving towards Webapollo, attempts at finding the old local client Apollo code are a bit of an archaeological expedition (not to mention Apollo has always been a joy to set up from code :).  Is everyone still trying to use the old Apollo, since it seems to no longer be supported?
> 
> At the moment I am really thinking of working on simple scripts to make IGV-friendly input (and possibly similar Artemis for our smaller genome projects), but I don?t want to repeat work already in place.
> 
> chris
> _______________________________________________
> maker-devel mailing list
> maker-devel at box290.bluehost.com
> http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org

Barry Moore
Research Scientist
Dept. of Human Genetics
University of Utah
Salt Lake City, UT 84112
--------------------------------------------
(801) 585-3543




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131112/863f00a0/attachment-0003.html>

From cjfields at illinois.edu  Tue Nov 12 15:25:21 2013
From: cjfields at illinois.edu (Fields, Christopher J)
Date: Tue, 12 Nov 2013 22:25:21 +0000
Subject: [maker-devel] Recommendations for visualization?
In-Reply-To: <90397AC5-7FEA-4B81-8085-49BD48787A6F@genetics.utah.edu>
References: <9B60EB76-1920-4B75-A224-C44070452B84@illinois.edu>
	<90397AC5-7FEA-4B81-8085-49BD48787A6F@genetics.utah.edu>
Message-ID: <8D26BC0C-74F6-43F4-A29B-10615BF7C6C0@illinois.edu>

I have considered using GMOD in the Cloud (we are likely to set something like this up on our local OpenStack when it?s up and running), but as a quick assessment of a test run it seems a bit overkill.

chris

On Nov 12, 2013, at 4:03 PM, Barry Moore <barry.utah at gmail.com<mailto:barry.utah at gmail.com>> wrote:

This is a VERY good point Chris.  I think the new web-apollo is developing into a great tool, but there is now a gapping hole in the area of a desktop application (i.e. no server setup) to view/edit genome annotations.  I'd love to hear what others are using.  Our group has been using a combination of old Apollo instances, Web-Apollo and Gbrowse.

B

On Nov 12, 2013, at 12:18 PM, Fields, Christopher J wrote:

Barry, Carson,

Are there any recommendations re: visualizing MAKER-generated GFF3?  I know it?s currently geared towards Apollo integration, but as everything is moving towards Webapollo, attempts at finding the old local client Apollo code are a bit of an archaeological expedition (not to mention Apollo has always been a joy to set up from code :).  Is everyone still trying to use the old Apollo, since it seems to no longer be supported?

At the moment I am really thinking of working on simple scripts to make IGV-friendly input (and possibly similar Artemis for our smaller genome projects), but I don?t want to repeat work already in place.

chris
_______________________________________________
maker-devel mailing list
maker-devel at box290.bluehost.com<mailto:maker-devel at box290.bluehost.com>
http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org

Barry Moore
Research Scientist
Dept. of Human Genetics
University of Utah
Salt Lake City, UT 84112
--------------------------------------------
(801) 585-3543





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131112/1ef63aa0/attachment-0003.html>

From carsonhh at gmail.com  Tue Nov 12 21:04:45 2013
From: carsonhh at gmail.com (Carson Holt)
Date: Tue, 12 Nov 2013 21:04:45 -0700
Subject: [maker-devel] re-annotation
In-Reply-To: <alpine.DEB.2.00.1311111355190.28492@linus40.gsc.wustl.edu>
Message-ID: <CEA8485C.6E7B%carsonhh@gmail.com>

They should be maintained.  What version are you using?

--Carson


On 11/11/13 1:01 PM, "Kymberlie Hallsworth-Pepin"
<kpepin at genome.wustl.edu> wrote:

>Hi Carson,
>
>I am trying to take an existing gene set and update it using new
>proteins. 
>I have the gene set in gff3 format - validated as ok - and have put it in
>the model_gff line. I set the protein db to the new database and I set
>the 
>map_forward=1 to maintain naming, but the output has no gene predictions
>in it. I have tried setting keep_preds both 0 and 1. I have put the gff
>file in both the pred_gff and model_gff and just in the pred_gff field,
>but I still don't get any predictions maintained. Can you tell me what I
>might be missing ?
>
>thanks
>Kym
>
>
>____
>This email message is a private communication. The information
>transmitted, including attachments, is intended only for the person or
>entity to which it is addressed and may contain confidential, privileged,
>and/or proprietary material. Any review, duplication, retransmission,
>distribution, or other use of, or taking of any action in reliance upon,
>this information by persons or entities other than the intended recipient
>is unauthorized by the sender and is prohibited. If you have received
>this message in error, please contact the sender immediately by return
>email and delete the original message from all computer systems. Thank
>you.





From kpepin at genome.wustl.edu  Wed Nov 13 06:16:44 2013
From: kpepin at genome.wustl.edu (Kymberlie Hallsworth-Pepin)
Date: Wed, 13 Nov 2013 07:16:44 -0600 (CST)
Subject: [maker-devel] re-annotation
In-Reply-To: <CEA8485C.6E7B%carsonhh@gmail.com>
References: <CEA8485C.6E7B%carsonhh@gmail.com>
Message-ID: <alpine.DEB.2.00.1311130711440.28492@linus40.gsc.wustl.edu>


We are using v2.26. We recreated the gff3 file and I can now get gene 
predictions to show up using the pred_gff file as input for the gene set. 
The naming is not maintained with the map_forward=1 as I would expect, 
just the source field in the input gff file is added to the new maker 
name.  If I change the input to a model_gff file I still do not get 
predictions in the maker gff file.

thanks
Kym




On Tue, 12 Nov 2013, Carson Holt wrote:

> They should be maintained.  What version are you using?
>
> --Carson
>
>
> On 11/11/13 1:01 PM, "Kymberlie Hallsworth-Pepin"
> <kpepin at genome.wustl.edu> wrote:
>
>> Hi Carson,
>>
>> I am trying to take an existing gene set and update it using new
>> proteins.
>> I have the gene set in gff3 format - validated as ok - and have put it in
>> the model_gff line. I set the protein db to the new database and I set
>> the
>> map_forward=1 to maintain naming, but the output has no gene predictions
>> in it. I have tried setting keep_preds both 0 and 1. I have put the gff
>> file in both the pred_gff and model_gff and just in the pred_gff field,
>> but I still don't get any predictions maintained. Can you tell me what I
>> might be missing ?
>>
>> thanks
>> Kym
>>
>>
>> ____
>> This email message is a private communication. The information
>> transmitted, including attachments, is intended only for the person or
>> entity to which it is addressed and may contain confidential, privileged,
>> and/or proprietary material. Any review, duplication, retransmission,
>> distribution, or other use of, or taking of any action in reliance upon,
>> this information by persons or entities other than the intended recipient
>> is unauthorized by the sender and is prohibited. If you have received
>> this message in error, please contact the sender immediately by return
>> email and delete the original message from all computer systems. Thank
>> you.
>

____
This email message is a private communication. The information transmitted, including attachments, is intended only for the person or entity to which it is addressed and may contain confidential, privileged, and/or proprietary material. Any review, duplication, retransmission, distribution, or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is unauthorized by the sender and is prohibited. If you have received this message in error, please contact the sender immediately by return email and delete the original message from all computer systems. Thank you.



From carsonhh at gmail.com  Wed Nov 13 08:06:44 2013
From: carsonhh at gmail.com (Carson Holt)
Date: Wed, 13 Nov 2013 08:06:44 -0700
Subject: [maker-devel] re-annotation
In-Reply-To: <alpine.DEB.2.00.1311130711440.28492@linus40.gsc.wustl.edu>
Message-ID: <CEA8E2DE.6FBF%carsonhh@gmail.com>

So map_forward=1, will only maintain names derived from model_gff onto new
or updated models.  Could you try either 2.28 or 2.30-beta, just to see if
this is something that is already fixed.

Thanks,
Carson


On 11/13/13 6:16 AM, "Kymberlie Hallsworth-Pepin"
<kpepin at genome.wustl.edu> wrote:

>
>We are using v2.26. We recreated the gff3 file and I can now get gene
>predictions to show up using the pred_gff file as input for the gene set.
>The naming is not maintained with the map_forward=1 as I would expect,
>just the source field in the input gff file is added to the new maker
>name.  If I change the input to a model_gff file I still do not get
>predictions in the maker gff file.
>
>thanks
>Kym
>
>
>
>
>On Tue, 12 Nov 2013, Carson Holt wrote:
>
>> They should be maintained.  What version are you using?
>>
>> --Carson
>>
>>
>> On 11/11/13 1:01 PM, "Kymberlie Hallsworth-Pepin"
>> <kpepin at genome.wustl.edu> wrote:
>>
>>> Hi Carson,
>>>
>>> I am trying to take an existing gene set and update it using new
>>> proteins.
>>> I have the gene set in gff3 format - validated as ok - and have put it
>>>in
>>> the model_gff line. I set the protein db to the new database and I set
>>> the
>>> map_forward=1 to maintain naming, but the output has no gene
>>>predictions
>>> in it. I have tried setting keep_preds both 0 and 1. I have put the gff
>>> file in both the pred_gff and model_gff and just in the pred_gff field,
>>> but I still don't get any predictions maintained. Can you tell me what
>>>I
>>> might be missing ?
>>>
>>> thanks
>>> Kym
>>>
>>>
>>> ____
>>> This email message is a private communication. The information
>>> transmitted, including attachments, is intended only for the person or
>>> entity to which it is addressed and may contain confidential,
>>>privileged,
>>> and/or proprietary material. Any review, duplication, retransmission,
>>> distribution, or other use of, or taking of any action in reliance
>>>upon,
>>> this information by persons or entities other than the intended
>>>recipient
>>> is unauthorized by the sender and is prohibited. If you have received
>>> this message in error, please contact the sender immediately by return
>>> email and delete the original message from all computer systems. Thank
>>> you.
>>
>
>____
>This email message is a private communication. The information
>transmitted, including attachments, is intended only for the person or
>entity to which it is addressed and may contain confidential, privileged,
>and/or proprietary material. Any review, duplication, retransmission,
>distribution, or other use of, or taking of any action in reliance upon,
>this information by persons or entities other than the intended recipient
>is unauthorized by the sender and is prohibited. If you have received
>this message in error, please contact the sender immediately by return
>email and delete the original message from all computer systems. Thank
>you.





From kpepin at genome.wustl.edu  Wed Nov 13 08:15:48 2013
From: kpepin at genome.wustl.edu (Kymberlie Hallsworth-Pepin)
Date: Wed, 13 Nov 2013 09:15:48 -0600 (CST)
Subject: [maker-devel] re-annotation
In-Reply-To: <CEA8E2DE.6FBF%carsonhh@gmail.com>
References: <CEA8E2DE.6FBF%carsonhh@gmail.com>
Message-ID: <alpine.DEB.2.00.1311130913090.2847@linus40.gsc.wustl.edu>



Will do. Is there a difference between how the model_gff file and the 
pred_gff file use the match/match_part of CDS/mRNA designations and which 
is the best to use for model_gff input?

On Wed, 13 Nov 2013, Carson Holt wrote:

> So map_forward=1, will only maintain names derived from model_gff onto new
> or updated models.  Could you try either 2.28 or 2.30-beta, just to see if
> this is something that is already fixed.
>
> Thanks,
> Carson
>

____
This email message is a private communication. The information transmitted, including attachments, is intended only for the person or entity to which it is addressed and may contain confidential, privileged, and/or proprietary material. Any review, duplication, retransmission, distribution, or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is unauthorized by the sender and is prohibited. If you have received this message in error, please contact the sender immediately by return email and delete the original message from all computer systems. Thank you.



From carsonhh at gmail.com  Wed Nov 13 16:08:08 2013
From: carsonhh at gmail.com (Carson Holt)
Date: Wed, 13 Nov 2013 16:08:08 -0700
Subject: [maker-devel] re-annotation
In-Reply-To: <alpine.DEB.2.00.1311130913090.2847@linus40.gsc.wustl.edu>
Message-ID: <CEA953DA.6B86%carsonhh@gmail.com>

model_gff must be gene/mRNA/exon/CDS. pred_gff can be match/match_part or
gene/mRNA/exon/CDS.  Also model_gff always should make it into the final
result (unless replaced by something better) and will not be modified.  It
also affects clustering.  pref_gff will only make it into the final
results if it is supported by evidence.

?Carson


On 11/13/13, 8:15 AM, "Kymberlie Hallsworth-Pepin"
<kpepin at genome.wustl.edu> wrote:

>
>
>Will do. Is there a difference between how the model_gff file and the
>pred_gff file use the match/match_part of CDS/mRNA designations and which
>is the best to use for model_gff input?
>
>On Wed, 13 Nov 2013, Carson Holt wrote:
>
>> So map_forward=1, will only maintain names derived from model_gff onto
>>new
>> or updated models.  Could you try either 2.28 or 2.30-beta, just to see
>>if
>> this is something that is already fixed.
>>
>> Thanks,
>> Carson
>>
>
>____
>This email message is a private communication. The information
>transmitted, including attachments, is intended only for the person or
>entity to which it is addressed and may contain confidential, privileged,
>and/or proprietary material. Any review, duplication, retransmission,
>distribution, or other use of, or taking of any action in reliance upon,
>this information by persons or entities other than the intended recipient
>is unauthorized by the sender and is prohibited. If you have received
>this message in error, please contact the sender immediately by return
>email and delete the original message from all computer systems. Thank
>you.





From carsonhh at gmail.com  Wed Nov 13 19:59:44 2013
From: carsonhh at gmail.com (Carson Holt)
Date: Wed, 13 Nov 2013 19:59:44 -0700
Subject: [maker-devel] A suspected strange behavior of Maker...
In-Reply-To: <CACvYrQGf+QwTcbWEOLX0igUZWcByu-E2d8YD4m2ykzCGr_aJ-w@mail.gmail.com>
Message-ID: <CEA98904.6B9A%carsonhh@gmail.com>

For scaffold5347 I get results from exonerate and blastn without any
modification to default parameters.  For scaffold3928 the alignment is very
poor, and gets filtered out.  I can force it to keep it but I have to allow
for abnormally long introns of 65kb (introns that large are extremely rare
in biology ? as in if you took every gene from 100 organisms you might find
a single gene among all of them with that long of an intron), and I have to
allow for low end to end matching (less 30%).  This alignment definitely
should have been rejected.

Thanks,
Carson


From:  Xin Huang <xh33 at georgetown.edu>
Date:  Monday, November 11, 2013 at 8:52 AM
To:  Carson Holt <carsonhh at gmail.com>
Cc:  <maker-devel at yandell-lab.org>
Subject:  Re: [maker-devel] A suspected strange behavior of Maker...

Hi Carson,

Thank you very much for getting back to me on this. Sorry I was too quick to
jump to a suspicion! Thanks for pointing it out and please see attached the
EST (face_cDNA.fa) and genome scaffold sequences
(albo_scaf3928+5347_for_face_cDNA.fa) I used for Maker. We used blastn to
identify these two scaffolds for this cDNA sequence, and exonerate result
also showed that this cDNA can be aligned to the scaffolds.

Thanks!

Xin 


On Mon, Nov 11, 2013 at 12:10 AM, Carson Holt <carsonhh at gmail.com> wrote:
> Sorry for the slow reply, I was moving from Canada to the US, got sick, and my
> moving truck got delayed one week. So I fell behind on the maker list.
> 
> What you observe is correct behavior.  The config is blasted against the
> database of ESTs/proteins.  It really doesn't matter which way you blast, you
> pick the direction that is most efficient for the question you are asking, and
> you only have to adjust the Z value for database size if you want alignment
> scores to be reproducible both ways.
> 
> Not getting results means they were filtered out for some reason (you don't
> even have blastn results in your output).  If you can send a test dataset I
> can take a look and tell you which filter.
> 
> Thanks,
> Carson
> 
> 
> From:  Xin Huang <xh33 at georgetown.edu>
> Date:  Tuesday, November 5, 2013 2:40 PM
> To:  <maker-devel at yandell-lab.org>
> Subject:  [maker-devel] A suspected strange behavior of Maker...
> 
> Hi,
> 
> I found a very bizarre thing when I ran Maker several times. The blastn
> research seems to reverse query and subject the way it's specified in the
> maker_opts.ctl file. When I put the scaffold sequence after genome= and the
> cDNA sequence after est=, the blastn result actually used the scaffold as
> query and the cDNA as subject. I realized that this sounds unreal, so I
> reversed the places for the two and the blastn result is normal with the cDNA
> as query and the scaffold as subject, but at the same time, the GFF file is of
> the cDNA sequence. I tried a few times, and got the same result. I deleted
> Maker (2.28) and reinstalled the beta version (2.30), still getting the same
> result.
> 
> My wild guess was that this might be the reason why the est2genome prediction
> using the EST sequence didn't go into the GFF3 file, as stated in a previous
> email to the Maker-devel. I couldn't figure out how to test this, though. I
> wonder if there's anything dramatically wrong that I've been doing to get such
> odd results... If you'd like me to send you any output files or control files,
> please let me know and I'll promptly pass those along.
> 
> Thank you very much for considering my email.
> 
> Sincerely,
> 
> Xin Huang
> _______________________________________________ maker-devel mailing list
> maker-devel at box290.bluehost.comhttp://box290.bluehost.com/mailman/listinfo/mak
> er-devel_yandell-lab.org



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131113/047635c9/attachment-0003.html>

From xh33 at georgetown.edu  Wed Nov 13 20:45:42 2013
From: xh33 at georgetown.edu (Xin Huang)
Date: Wed, 13 Nov 2013 22:45:42 -0500
Subject: [maker-devel] A suspected strange behavior of Maker...
In-Reply-To: <CEA98904.6B9A%carsonhh@gmail.com>
References: <CACvYrQGf+QwTcbWEOLX0igUZWcByu-E2d8YD4m2ykzCGr_aJ-w@mail.gmail.com>
	<CEA98904.6B9A%carsonhh@gmail.com>
Message-ID: <CACvYrQFPkZ+BwcQu0amq1kzO-0xAMTsLa0RqY+xy_sn6AfrZ0Q@mail.gmail.com>

Hi Carson,

Thanks a lot for doing the test for me! I didn't get any annotation in the
GFF file generated by Maker even if I only used scaffold5347 as the genome
and the face EST sequence as the est evidence. Is there something that I
can modify to put the alignment into the GFF file? I used est2genome=1
option to get prediction from exonerate, but still couldn't get any
prediction.

Thanks!

Xin


On Wed, Nov 13, 2013 at 9:59 PM, Carson Holt <carsonhh at gmail.com> wrote:

> For scaffold5347 I get results from exonerate and blastn without any
> modification to default parameters.  For scaffold3928 the alignment is very
> poor, and gets filtered out.  I can force it to keep it but I have to allow
> for abnormally long introns of 65kb (introns that large are extremely rare
> in biology ? as in if you took every gene from 100 organisms you might find
> a single gene among all of them with that long of an intron), and I have to
> allow for low end to end matching (less 30%).  This alignment definitely
> should have been rejected.
>
> Thanks,
> Carson
>
>
> From: Xin Huang <xh33 at georgetown.edu>
> Date: Monday, November 11, 2013 at 8:52 AM
> To: Carson Holt <carsonhh at gmail.com>
> Cc: <maker-devel at yandell-lab.org>
> Subject: Re: [maker-devel] A suspected strange behavior of Maker...
>
> Hi Carson,
>
> Thank you very much for getting back to me on this. Sorry I was too quick
> to jump to a suspicion! Thanks for pointing it out and please see attached
> the EST (face_cDNA.fa) and genome scaffold sequences
> (albo_scaf3928+5347_for_face_cDNA.fa) I used for Maker. We used blastn to
> identify these two scaffolds for this cDNA sequence, and exonerate result
> also showed that this cDNA can be aligned to the scaffolds.
>
> Thanks!
>
> Xin
>
>
> On Mon, Nov 11, 2013 at 12:10 AM, Carson Holt <carsonhh at gmail.com> wrote:
>
>> Sorry for the slow reply, I was moving from Canada to the US, got sick,
>> and my moving truck got delayed one week. So I fell behind on the maker
>> list.
>>
>> What you observe is correct behavior.  The config is blasted against the
>> database of ESTs/proteins.  It really doesn't matter which way you blast,
>> you pick the direction that is most efficient for the question you are
>> asking, and you only have to adjust the Z value for database size if you
>> want alignment scores to be reproducible both ways.
>>
>> Not getting results means they were filtered out for some reason (you
>> don't even have blastn results in your output).  If you can send a test
>> dataset I can take a look and tell you which filter.
>>
>> Thanks,
>> Carson
>>
>>
>> From: Xin Huang <xh33 at georgetown.edu>
>> Date: Tuesday, November 5, 2013 2:40 PM
>> To: <maker-devel at yandell-lab.org>
>> Subject: [maker-devel] A suspected strange behavior of Maker...
>>
>> Hi,
>>
>> I found a very bizarre thing when I ran Maker several times. The blastn
>> research seems to reverse query and subject the way it's specified in the
>> maker_opts.ctl file. When I put the scaffold sequence after genome= and the
>> cDNA sequence after est=, the blastn result actually used the scaffold as
>> query and the cDNA as subject. I realized that this sounds unreal, so I
>> reversed the places for the two and the blastn result is normal with the
>> cDNA as query and the scaffold as subject, but at the same time, the GFF
>> file is of the cDNA sequence. I tried a few times, and got the same result.
>> I deleted Maker (2.28) and reinstalled the beta version (2.30), still
>> getting the same result.
>>
>> My wild guess was that this might be the reason why the est2genome
>> prediction using the EST sequence didn't go into the GFF3 file, as stated
>> in a previous email to the Maker-devel. I couldn't figure out how to test
>> this, though. I wonder if there's anything dramatically wrong that I've
>> been doing to get such odd results... If you'd like me to send you any
>> output files or control files, please let me know and I'll promptly pass
>> those along.
>>
>> Thank you very much for considering my email.
>>
>> Sincerely,
>>
>> Xin Huang
>> _______________________________________________ maker-devel mailing list
>> maker-devel at box290.bluehost.com
>> http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131113/133d8f0a/attachment-0003.html>

From carsonhh at gmail.com  Wed Nov 13 20:49:32 2013
From: carsonhh at gmail.com (Carson Holt)
Date: Wed, 13 Nov 2013 20:49:32 -0700
Subject: [maker-devel] A suspected strange behavior of Maker...
In-Reply-To: <CACvYrQFPkZ+BwcQu0amq1kzO-0xAMTsLa0RqY+xy_sn6AfrZ0Q@mail.gmail.com>
Message-ID: <CEA99613.6BAD%carsonhh@gmail.com>

All I did was supply the cDNA to est= and the scaffolds to genome=.  All the
other parameters I just used the default, then I ran MAKER.  I am using
version 2.30.

Thanks,
Carson


From:  Xin Huang <xh33 at georgetown.edu>
Date:  Wednesday, November 13, 2013 at 8:45 PM
To:  Carson Holt <carsonhh at gmail.com>
Cc:  <maker-devel at yandell-lab.org>
Subject:  Re: [maker-devel] A suspected strange behavior of Maker...

Hi Carson,

Thanks a lot for doing the test for me! I didn't get any annotation in the
GFF file generated by Maker even if I only used scaffold5347 as the genome
and the face EST sequence as the est evidence. Is there something that I can
modify to put the alignment into the GFF file? I used est2genome=1 option to
get prediction from exonerate, but still couldn't get any prediction.

Thanks!

Xin


On Wed, Nov 13, 2013 at 9:59 PM, Carson Holt <carsonhh at gmail.com> wrote:
> For scaffold5347 I get results from exonerate and blastn without any
> modification to default parameters.  For scaffold3928 the alignment is very
> poor, and gets filtered out.  I can force it to keep it but I have to allow
> for abnormally long introns of 65kb (introns that large are extremely rare in
> biology ? as in if you took every gene from 100 organisms you might find a
> single gene among all of them with that long of an intron), and I have to
> allow for low end to end matching (less 30%).  This alignment definitely
> should have been rejected.
> 
> Thanks,
> Carson
> 
> 
> From:  Xin Huang <xh33 at georgetown.edu>
> Date:  Monday, November 11, 2013 at 8:52 AM
> To:  Carson Holt <carsonhh at gmail.com>
> Cc:  <maker-devel at yandell-lab.org>
> Subject:  Re: [maker-devel] A suspected strange behavior of Maker...
> 
> Hi Carson,
> 
> Thank you very much for getting back to me on this. Sorry I was too quick to
> jump to a suspicion! Thanks for pointing it out and please see attached the
> EST (face_cDNA.fa) and genome scaffold sequences
> (albo_scaf3928+5347_for_face_cDNA.fa) I used for Maker. We used blastn to
> identify these two scaffolds for this cDNA sequence, and exonerate result also
> showed that this cDNA can be aligned to the scaffolds.
> 
> Thanks!
> 
> Xin 
> 
> 
> On Mon, Nov 11, 2013 at 12:10 AM, Carson Holt <carsonhh at gmail.com> wrote:
>> Sorry for the slow reply, I was moving from Canada to the US, got sick, and
>> my moving truck got delayed one week. So I fell behind on the maker list.
>> 
>> What you observe is correct behavior.  The config is blasted against the
>> database of ESTs/proteins.  It really doesn't matter which way you blast, you
>> pick the direction that is most efficient for the question you are asking,
>> and you only have to adjust the Z value for database size if you want
>> alignment scores to be reproducible both ways.
>> 
>> Not getting results means they were filtered out for some reason (you don't
>> even have blastn results in your output).  If you can send a test dataset I
>> can take a look and tell you which filter.
>> 
>> Thanks,
>> Carson
>> 
>> 
>> From:  Xin Huang <xh33 at georgetown.edu>
>> Date:  Tuesday, November 5, 2013 2:40 PM
>> To:  <maker-devel at yandell-lab.org>
>> Subject:  [maker-devel] A suspected strange behavior of Maker...
>> 
>> Hi,
>> 
>> I found a very bizarre thing when I ran Maker several times. The blastn
>> research seems to reverse query and subject the way it's specified in the
>> maker_opts.ctl file. When I put the scaffold sequence after genome= and the
>> cDNA sequence after est=, the blastn result actually used the scaffold as
>> query and the cDNA as subject. I realized that this sounds unreal, so I
>> reversed the places for the two and the blastn result is normal with the cDNA
>> as query and the scaffold as subject, but at the same time, the GFF file is
>> of the cDNA sequence. I tried a few times, and got the same result. I deleted
>> Maker (2.28) and reinstalled the beta version (2.30), still getting the same
>> result.
>> 
>> My wild guess was that this might be the reason why the est2genome prediction
>> using the EST sequence didn't go into the GFF3 file, as stated in a previous
>> email to the Maker-devel. I couldn't figure out how to test this, though. I
>> wonder if there's anything dramatically wrong that I've been doing to get
>> such odd results... If you'd like me to send you any output files or control
>> files, please let me know and I'll promptly pass those along.
>> 
>> Thank you very much for considering my email.
>> 
>> Sincerely,
>> 
>> Xin Huang
>> _______________________________________________ maker-devel mailing list
>> maker-devel at box290.bluehost.comhttp://box290.bluehost.com/mailman/listinfo/ma
>> ker-devel_yandell-lab.org
> 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131113/4d20127f/attachment-0003.html>

From cjfields at illinois.edu  Wed Nov 13 20:51:36 2013
From: cjfields at illinois.edu (Fields, Christopher J)
Date: Thu, 14 Nov 2013 03:51:36 +0000
Subject: [maker-devel] Odd missing label bug
Message-ID: <73A19C36-ABA1-4A03-8D66-2A7F5574C386@illinois.edu>

I?m seeing an odd bug in GFF output where the label is being sporadically left off some child ?match_part' features.  This is when using maker-2.30p.  I found this while splitting out the data by source as individual tracks for IGV viewing; I have several sets of ESTs from individuals of the same species, so I have them labeled (from maker_opts):

est=./ESTs/Trinity_1128_v2_combined_pr2.clean.fasta:strain_1128
protein=./ESTs/xeno/Taeniopygia_guttata.taeGut3.2.4.73.pep.all.fa:TaeGut,./ESTs/xeno/Ficedula_albicollis.FicAlb_1.4.73.pep.all.fa:FicAlb

I planned on separating these into separate tracks, one for each BLASTX, BLASTN, etc.  

After a test run on a few scaffolds, a small number of the BLASTX and BLASTN look like this:

KB913263.1      blastx:TaeGut   protein_match   374736  401929  330     -       .       ID=KB913263.1:hit:9:3.10.0.3;Name=ENSTGUP00000000074
KB913263.1      blastx  match_part      401756  401929  312     -       .       ID=KB913263.1:hsp:55:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M58;Target=ENSTGUP00000000074 1 58
KB913263.1      blastx  match_part      394486  394665  186     -       .       ID=KB913263.1:hsp:56:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M42 D9 M9;Target=ENSTGUP00000000074 56 106
KB913263.1      blastx  match_part      392059  392178  204     -       .       ID=KB913263.1:hsp:57:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M40;Target=ENSTGUP00000000074 97 136
KB913263.1      blastx  match_part      387479  387547  116     -       .       ID=KB913263.1:hsp:58:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M23;Target=ENSTGUP00000000074 151 173
KB913263.1      blastx  match_part      383644  383742  156     -       .       ID=KB913263.1:hsp:59:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M33;Target=ENSTGUP00000000074 172 204
KB913263.1      blastx  match_part      382860  383063  242     -       .       ID=KB913263.1:hsp:60:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M68;Target=ENSTGUP00000000074 193 260
KB913263.1      blastx  match_part      382538  382648  186     -       .       ID=KB913263.1:hsp:61:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M37;Target=ENSTGUP00000000074 247 283
KB913263.1      blastx  match_part      382072  382236  268     -       .       ID=KB913263.1:hsp:62:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M55;Target=ENSTGUP00000000074 282 336
KB913263.1      blastx  match_part      379270  379458  330     -       .       ID=KB913263.1:hsp:63:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M63;Target=ENSTGUP00000000074 336 398
KB913263.1      blastx  match_part      374736  374900  147     -       .       ID=KB913263.1:hsp:64:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M55;Target=ENSTGUP00000000074 4 58

Note the missing label in the source column for the ?match_part? types.  Strangely, only a small # have this problem, but the exact same ones appear to be consistently popping up on repeated runs (this is from a test prior to a full launch using openmpi).  It does seem like only child ?match_part? appears affected.

Any ideas?

chris


From carsonhh at gmail.com  Wed Nov 13 20:58:32 2013
From: carsonhh at gmail.com (Carson Holt)
Date: Wed, 13 Nov 2013 20:58:32 -0700
Subject: [maker-devel] Odd missing label bug
In-Reply-To: <73A19C36-ABA1-4A03-8D66-2A7F5574C386@illinois.edu>
Message-ID: <CEA9978B.6BB3%carsonhh@gmail.com>

Could you put a contig and protein fasta into a test job that I could run
on?  Based on the hit position I imagine this may only happens when the
alignments spans two chunks (by default MAKER splits the input config into
100,000bp chunks).  The hit runs from 374736-401929.

?Carson


On 11/13/13, 8:51 PM, "Fields, Christopher J" <cjfields at illinois.edu>
wrote:

>I?m seeing an odd bug in GFF output where the label is being sporadically
>left off some child ?match_part' features.  This is when using
>maker-2.30p.  I found this while splitting out the data by source as
>individual tracks for IGV viewing; I have several sets of ESTs from
>individuals of the same species, so I have them labeled (from maker_opts):
>
>est=./ESTs/Trinity_1128_v2_combined_pr2.clean.fasta:strain_1128
>protein=./ESTs/xeno/Taeniopygia_guttata.taeGut3.2.4.73.pep.all.fa:TaeGut,.
>/ESTs/xeno/Ficedula_albicollis.FicAlb_1.4.73.pep.all.fa:FicAlb
>
>I planned on separating these into separate tracks, one for each BLASTX,
>BLASTN, etc.  
>
>After a test run on a few scaffolds, a small number of the BLASTX and
>BLASTN look like this:
>
>KB913263.1      blastx:TaeGut   protein_match   374736  401929  330     -
>      .       ID=KB913263.1:hit:9:3.10.0.3;Name=ENSTGUP00000000074
>KB913263.1      blastx  match_part      401756  401929  312     -       .
>      
>ID=KB913263.1:hsp:55:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M58;Tar
>get=ENSTGUP00000000074 1 58
>KB913263.1      blastx  match_part      394486  394665  186     -       .
>      
>ID=KB913263.1:hsp:56:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M42 D9
>M9;Target=ENSTGUP00000000074 56 106
>KB913263.1      blastx  match_part      392059  392178  204     -       .
>      
>ID=KB913263.1:hsp:57:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M40;Tar
>get=ENSTGUP00000000074 97 136
>KB913263.1      blastx  match_part      387479  387547  116     -       .
>      
>ID=KB913263.1:hsp:58:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M23;Tar
>get=ENSTGUP00000000074 151 173
>KB913263.1      blastx  match_part      383644  383742  156     -       .
>      
>ID=KB913263.1:hsp:59:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M33;Tar
>get=ENSTGUP00000000074 172 204
>KB913263.1      blastx  match_part      382860  383063  242     -       .
>      
>ID=KB913263.1:hsp:60:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M68;Tar
>get=ENSTGUP00000000074 193 260
>KB913263.1      blastx  match_part      382538  382648  186     -       .
>      
>ID=KB913263.1:hsp:61:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M37;Tar
>get=ENSTGUP00000000074 247 283
>KB913263.1      blastx  match_part      382072  382236  268     -       .
>      
>ID=KB913263.1:hsp:62:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M55;Tar
>get=ENSTGUP00000000074 282 336
>KB913263.1      blastx  match_part      379270  379458  330     -       .
>      
>ID=KB913263.1:hsp:63:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M63;Tar
>get=ENSTGUP00000000074 336 398
>KB913263.1      blastx  match_part      374736  374900  147     -       .
>      
>ID=KB913263.1:hsp:64:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M55;Tar
>get=ENSTGUP00000000074 4 58
>
>Note the missing label in the source column for the ?match_part? types.
>Strangely, only a small # have this problem, but the exact same ones
>appear to be consistently popping up on repeated runs (this is from a
>test prior to a full launch using openmpi).  It does seem like only child
>?match_part? appears affected.
>
>Any ideas?
>
>chris
>_______________________________________________
>maker-devel mailing list
>maker-devel at box290.bluehost.com
>http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org





From cjfields at illinois.edu  Wed Nov 13 21:20:46 2013
From: cjfields at illinois.edu (Fields, Christopher J)
Date: Thu, 14 Nov 2013 04:20:46 +0000
Subject: [maker-devel] Odd missing label bug
In-Reply-To: <CEA9978B.6BB3%carsonhh@gmail.com>
References: <CEA9978B.6BB3%carsonhh@gmail.com>
Message-ID: <6E70C69F-BAFD-4C9E-9293-04DB656B2A09@illinois.edu>

Yeah, that seems to be it (crossing around 100kbp increments).  I?ll run a reduced example set locally to make sure and will send.

-c

On Nov 13, 2013, at 9:58 PM, Carson Holt <carsonhh at gmail.com> wrote:

> Could you put a contig and protein fasta into a test job that I could run
> on?  Based on the hit position I imagine this may only happens when the
> alignments spans two chunks (by default MAKER splits the input config into
> 100,000bp chunks).  The hit runs from 374736-401929.
> 
> <Carson
> 
> 
> On 11/13/13, 8:51 PM, "Fields, Christopher J" <cjfields at illinois.edu>
> wrote:
> 
>> I?m seeing an odd bug in GFF output where the label is being sporadically
>> left off some child Omatch_part' features.  This is when using
>> maker-2.30p.  I found this while splitting out the data by source as
>> individual tracks for IGV viewing; I have several sets of ESTs from
>> individuals of the same species, so I have them labeled (from maker_opts):
>> 
>> est=./ESTs/Trinity_1128_v2_combined_pr2.clean.fasta:strain_1128
>> protein=./ESTs/xeno/Taeniopygia_guttata.taeGut3.2.4.73.pep.all.fa:TaeGut,.
>> /ESTs/xeno/Ficedula_albicollis.FicAlb_1.4.73.pep.all.fa:FicAlb
>> 
>> I planned on separating these into separate tracks, one for each BLASTX,
>> BLASTN, etc.  
>> 
>> After a test run on a few scaffolds, a small number of the BLASTX and
>> BLASTN look like this:
>> 
>> KB913263.1      blastx:TaeGut   protein_match   374736  401929  330     -
>>     .       ID=KB913263.1:hit:9:3.10.0.3;Name=ENSTGUP00000000074
>> KB913263.1      blastx  match_part      401756  401929  312     -       .
>> 
>> ID=KB913263.1:hsp:55:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M58;Tar
>> get=ENSTGUP00000000074 1 58
>> KB913263.1      blastx  match_part      394486  394665  186     -       .
>> 
>> ID=KB913263.1:hsp:56:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M42 D9
>> M9;Target=ENSTGUP00000000074 56 106
>> KB913263.1      blastx  match_part      392059  392178  204     -       .
>> 
>> ID=KB913263.1:hsp:57:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M40;Tar
>> get=ENSTGUP00000000074 97 136
>> KB913263.1      blastx  match_part      387479  387547  116     -       .
>> 
>> ID=KB913263.1:hsp:58:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M23;Tar
>> get=ENSTGUP00000000074 151 173
>> KB913263.1      blastx  match_part      383644  383742  156     -       .
>> 
>> ID=KB913263.1:hsp:59:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M33;Tar
>> get=ENSTGUP00000000074 172 204
>> KB913263.1      blastx  match_part      382860  383063  242     -       .
>> 
>> ID=KB913263.1:hsp:60:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M68;Tar
>> get=ENSTGUP00000000074 193 260
>> KB913263.1      blastx  match_part      382538  382648  186     -       .
>> 
>> ID=KB913263.1:hsp:61:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M37;Tar
>> get=ENSTGUP00000000074 247 283
>> KB913263.1      blastx  match_part      382072  382236  268     -       .
>> 
>> ID=KB913263.1:hsp:62:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M55;Tar
>> get=ENSTGUP00000000074 282 336
>> KB913263.1      blastx  match_part      379270  379458  330     -       .
>> 
>> ID=KB913263.1:hsp:63:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M63;Tar
>> get=ENSTGUP00000000074 336 398
>> KB913263.1      blastx  match_part      374736  374900  147     -       .
>> 
>> ID=KB913263.1:hsp:64:3.10.0.3;Parent=KB913263.1:hit:9:3.10.0.3;Gap=M55;Tar
>> get=ENSTGUP00000000074 4 58
>> 
>> Note the missing label in the source column for the Omatch_part? types.
>> Strangely, only a small # have this problem, but the exact same ones
>> appear to be consistently popping up on repeated runs (this is from a
>> test prior to a full launch using openmpi).  It does seem like only child
>> Omatch_part? appears affected.
>> 
>> Any ideas?
>> 
>> chris
>> _______________________________________________
>> maker-devel mailing list
>> maker-devel at box290.bluehost.com
>> http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
> 
> 




From kpepin at genome.wustl.edu  Thu Nov 14 05:51:54 2013
From: kpepin at genome.wustl.edu (Kymberlie Hallsworth-Pepin)
Date: Thu, 14 Nov 2013 06:51:54 -0600 (CST)
Subject: [maker-devel] re-annotation
In-Reply-To: <CEA953DA.6B86%carsonhh@gmail.com>
References: <CEA953DA.6B86%carsonhh@gmail.com>
Message-ID: <alpine.DEB.2.00.1311140650400.28492@linus40.gsc.wustl.edu>


The new version and the change in the model gff to exon/cds did the trick.
thanks for the info.
Kym


On Wed, 13 Nov 2013, Carson Holt wrote:

> model_gff must be gene/mRNA/exon/CDS. pred_gff can be match/match_part or
> gene/mRNA/exon/CDS.  Also model_gff always should make it into the final
> result (unless replaced by something better) and will not be modified.  It
> also affects clustering.  pref_gff will only make it into the final
> results if it is supported by evidence.
>
> ?Carson
>
>
> On 11/13/13, 8:15 AM, "Kymberlie Hallsworth-Pepin"
> <kpepin at genome.wustl.edu> wrote:
>
>>
>>
>> Will do. Is there a difference between how the model_gff file and the
>> pred_gff file use the match/match_part of CDS/mRNA designations and which
>> is the best to use for model_gff input?
>>
>> On Wed, 13 Nov 2013, Carson Holt wrote:
>>
>>> So map_forward=1, will only maintain names derived from model_gff onto
>>> new
>>> or updated models.  Could you try either 2.28 or 2.30-beta, just to see
>>> if
>>> this is something that is already fixed.
>>>
>>> Thanks,
>>> Carson
>>>
>>
>> ____
>> This email message is a private communication. The information
>> transmitted, including attachments, is intended only for the person or
>> entity to which it is addressed and may contain confidential, privileged,
>> and/or proprietary material. Any review, duplication, retransmission,
>> distribution, or other use of, or taking of any action in reliance upon,
>> this information by persons or entities other than the intended recipient
>> is unauthorized by the sender and is prohibited. If you have received
>> this message in error, please contact the sender immediately by return
>> email and delete the original message from all computer systems. Thank
>> you.
>

____
This email message is a private communication. The information transmitted, including attachments, is intended only for the person or entity to which it is addressed and may contain confidential, privileged, and/or proprietary material. Any review, duplication, retransmission, distribution, or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is unauthorized by the sender and is prohibited. If you have received this message in error, please contact the sender immediately by return email and delete the original message from all computer systems. Thank you.



From xh33 at georgetown.edu  Mon Nov 11 08:52:48 2013
From: xh33 at georgetown.edu (Xin Huang)
Date: Mon, 11 Nov 2013 10:52:48 -0500
Subject: [maker-devel] A suspected strange behavior of Maker...
In-Reply-To: <CEA5B2C9.69F9%carsonhh@gmail.com>
References: <CACvYrQGP1dajOYyhiTDt6QuzCHdVR21vLYzmbtMKvF67d-fMiA@mail.gmail.com>
	<CEA5B2C9.69F9%carsonhh@gmail.com>
Message-ID: <CACvYrQGf+QwTcbWEOLX0igUZWcByu-E2d8YD4m2ykzCGr_aJ-w@mail.gmail.com>

Hi Carson,

Thank you very much for getting back to me on this. Sorry I was too quick
to jump to a suspicion! Thanks for pointing it out and please see attached
the EST (face_cDNA.fa) and genome scaffold sequences
(albo_scaf3928+5347_for_face_cDNA.fa) I used for Maker. We used blastn to
identify these two scaffolds for this cDNA sequence, and exonerate result
also showed that this cDNA can be aligned to the scaffolds.

Thanks!

Xin


On Mon, Nov 11, 2013 at 12:10 AM, Carson Holt <carsonhh at gmail.com> wrote:

> Sorry for the slow reply, I was moving from Canada to the US, got sick,
> and my moving truck got delayed one week. So I fell behind on the maker
> list.
>
> What you observe is correct behavior.  The config is blasted against the
> database of ESTs/proteins.  It really doesn't matter which way you blast,
> you pick the direction that is most efficient for the question you are
> asking, and you only have to adjust the Z value for database size if you
> want alignment scores to be reproducible both ways.
>
> Not getting results means they were filtered out for some reason (you
> don't even have blastn results in your output).  If you can send a test
> dataset I can take a look and tell you which filter.
>
> Thanks,
> Carson
>
>
> From: Xin Huang <xh33 at georgetown.edu>
> Date: Tuesday, November 5, 2013 2:40 PM
> To: <maker-devel at yandell-lab.org>
> Subject: [maker-devel] A suspected strange behavior of Maker...
>
> Hi,
>
> I found a very bizarre thing when I ran Maker several times. The blastn
> research seems to reverse query and subject the way it's specified in the
> maker_opts.ctl file. When I put the scaffold sequence after genome= and the
> cDNA sequence after est=, the blastn result actually used the scaffold as
> query and the cDNA as subject. I realized that this sounds unreal, so I
> reversed the places for the two and the blastn result is normal with the
> cDNA as query and the scaffold as subject, but at the same time, the GFF
> file is of the cDNA sequence. I tried a few times, and got the same result.
> I deleted Maker (2.28) and reinstalled the beta version (2.30), still
> getting the same result.
>
> My wild guess was that this might be the reason why the est2genome
> prediction using the EST sequence didn't go into the GFF3 file, as stated
> in a previous email to the Maker-devel. I couldn't figure out how to test
> this, though. I wonder if there's anything dramatically wrong that I've
> been doing to get such odd results... If you'd like me to send you any
> output files or control files, please let me know and I'll promptly pass
> those along.
>
> Thank you very much for considering my email.
>
> Sincerely,
>
> Xin Huang
> _______________________________________________ maker-devel mailing list
> maker-devel at box290.bluehost.com
> http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131111/aeac9298/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: face_cDNA.fa
Type: application/octet-stream
Size: 1977 bytes
Desc: not available
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131111/aeac9298/attachment-0006.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: albo_scaf3928+5347_for_face_cDNA.fa
Type: application/octet-stream
Size: 306492 bytes
Desc: not available
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131111/aeac9298/attachment-0007.obj>

From ejr at stowers.org  Mon Nov 18 13:24:03 2013
From: ejr at stowers.org (Ross, Eric)
Date: Mon, 18 Nov 2013 20:24:03 +0000
Subject: [maker-devel] gff3_merge error - only half the contigs are
 reported
Message-ID: <CEAFD381.2B146%ejr@stowers.org>

I had the same problem Sujai reported  on the 25th.

When I run gff3_merge I only get back results from a subset of my
scaffolds.  Every scaffold has a gff file in the data store.  fasta_merge
works fine.  No errors are printed to STDOUT.

It took me some poking around, but this seems that if there is
insufficient space in /tmp to generate the temporary files merge_gff3
completes without error and just creates a gff file from whatever fit in
the temporary files.  I'm not sure why tempfile() doesn't return a useful
error.  

I was able to get around the error by setting the environment variable
TMPDIR to someplace with sufficient space, but if there is a way to
generate a useful error it might be worth adding.


Eric




--original below--
On Friday, October 25, 2013 11:22:08 AM UTC-5, Barry wrote:
Hi Sujai,
If you still have that original directory available a couple things you to
try:

# Does this give you the number of contigs you're expecting?
find datastore_directory -name '*.gff3' | wc -l

# If the above gives what you expect what does the file size look like on
the smallest files?
find ./ -type f | xargs ls -Sl | tail

Barry

On Oct 24, 2013, at 4:04 PM, Sujai wrote:


Hi Barry

The last stderr message in the job is from the maker command:

Maker is now finished!!!

my last 3 commands were (in my pbs/torque job script):

----job script----
...other commands to set variables etc...
mpiexec -n 12 maker -g $SPLITFILE -base $SPLITFILE maker_opts.ctl
maker_bopts.ctl maker_exe.ctl
gff3_merge -o $PBS_O_WORKDIR/$SPLITFILE.gff3 -d
$SPLITFILE.maker.output/${SPLITFILE}_master_datastore_index.log
fasta_merge -d 
$SPLITFILE.maker.output/${SPLITFILE}_master_datastore_index.log
-----

so, no gff3_merge stderr messages
the fasta_merge command (which came after gff3_merge) has completed
correctly, with all proteins and transcripts accounted for.
I just ran the same contigs again in smaller batches, and it seems to be
proceeding correctly (the final gff3 files are between 49-55MB for each
chunk of fasta files. In the previous case, the final GFF3 file was 99MB
or 100MB (which is why I thought there was some sort of filesize/memory
limit)

Thanks for looking into this,

- Sujai




On 24 October 2013 21:42, Barry Moore <barry... at genetics.utah.edu <>>
wrote:

Hi Sujai,
There are a couple of fatal errors that can be thrown by gff3_merge if it
encounters errors.  Did you capture STDERR and do you see any failures
there?

B

On Oct 24, 2013, at 10:43 AM, Sujai wrote:




Hi all
First of all, thank you to Carson Holt and Mark Yandell and team for an
excellent program with excellent installation instructions. Setting maker
2.28 up and running it (both with MPI and without) was a breeze on a PBS
cluster. Everything worked as expected (doesn't happen that often in
bioinformatics software! :-))

I did a test run on 150 longish contigs (>50kb each) and everything worked
fine, including gff3_merge, fasta_merge etc. I got predictions for all the
contigs etc.


However, when I ran it on the full 20,000 sequence file (minimum 300 bp, I
know - I could have set the min length in maker_opts.ctl but I wanted the
repeatmasker analysis done even for the smaller contigs), I had a problem:

1. the intermediate files were all fine (i.e. grep -c FINISHED
...master_datastore_index.log showed the right number of sequences)

2. But gff3_merge -d ...master_datastore_index.log  only gave a file with
about 9000 contigs. I ran it a few times and got the same result each
time. fasta_merge gave back sequences from all ~20,000 contigs, so I know
the contig_datastore was fine.

3. Could it be that gff3_merge hit some sort of output limit? the GFF3
file created seems to be almost exactly 100MB. Or could it be a limit of
my OS environment? I had a lot of memory (12 GB) and a large tmp directory
(10 GB) so that should not be a problem...

If anyone has seen this problem or can shed any light on this, that would
be great.

I'm going to try splitting the file into smaller sets and hoping for the
best.

Thanks

- Sujai




-- 
You received this message because you are subscribed to the Google Groups
"maker-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to maker-devel... at googlegroups.com <>.
To post to this group, send email to maker... at googlegroups.com <>.
Visit this group at http://groups.google.com/group/maker-devel.
For more options, visit https://groups.google.com/groups/opt_out.




Barry Moore
Research Scientist
Dept. of Human Genetics
University of Utah
Salt Lake City, UT 84112
--------------------------------------------
(801) 585-3543









-- 
You received this message because you are subscribed to a topic in the
Google Groups "maker-devel" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/maker-devel/bApnLPFgmRc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
maker-devel... at googlegroups.com <>.
To post to this group, send email to maker... at googlegroups.com <>.
Visit this group at http://groups.google.com/group/maker-devel.
For more options, visit https://groups.google.com/groups/opt_out.






-- 
You received this message because you are subscribed to the Google Groups
"maker-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to maker-devel... at googlegroups.com <>.
To post to this group, send email to maker... at googlegroups.com <>.
Visit this group at http://groups.google.com/group/maker-devel.
For more options, visit https://groups.google.com/groups/opt_out.




Barry Moore
Research Scientist
Dept. of Human Genetics
University of Utah
Salt Lake City, UT 84112
--------------------------------------------
(801) 585-3543











On Friday, October 25, 2013 11:22:08 AM UTC-5, Barry wrote:
Hi Sujai,
If you still have that original directory available a couple things you to
try:

# Does this give you the number of contigs you're expecting?
find datastore_directory -name '*.gff3' | wc -l

# If the above gives what you expect what does the file size look like on
the smallest files?
find ./ -type f | xargs ls -Sl | tail

Barry

On Oct 24, 2013, at 4:04 PM, Sujai wrote:


Hi Barry

The last stderr message in the job is from the maker command:

Maker is now finished!!!

my last 3 commands were (in my pbs/torque job script):

----job script----
...other commands to set variables etc...
mpiexec -n 12 maker -g $SPLITFILE -base $SPLITFILE maker_opts.ctl
maker_bopts.ctl maker_exe.ctl
gff3_merge -o $PBS_O_WORKDIR/$SPLITFILE.gff3 -d
$SPLITFILE.maker.output/${SPLITFILE}_master_datastore_index.log
fasta_merge -d 
$SPLITFILE.maker.output/${SPLITFILE}_master_datastore_index.log
-----

so, no gff3_merge stderr messages
the fasta_merge command (which came after gff3_merge) has completed
correctly, with all proteins and transcripts accounted for.
I just ran the same contigs again in smaller batches, and it seems to be
proceeding correctly (the final gff3 files are between 49-55MB for each
chunk of fasta files. In the previous case, the final GFF3 file was 99MB
or 100MB (which is why I thought there was some sort of filesize/memory
limit)

Thanks for looking into this,

- Sujai




On 24 October 2013 21:42, Barry Moore <barry... at genetics.utah.edu <>>
wrote:

Hi Sujai,
There are a couple of fatal errors that can be thrown by gff3_merge if it
encounters errors.  Did you capture STDERR and do you see any failures
there?

B

On Oct 24, 2013, at 10:43 AM, Sujai wrote:




Hi all
First of all, thank you to Carson Holt and Mark Yandell and team for an
excellent program with excellent installation instructions. Setting maker
2.28 up and running it (both with MPI and without) was a breeze on a PBS
cluster. Everything worked as expected (doesn't happen that often in
bioinformatics software! :-))

I did a test run on 150 longish contigs (>50kb each) and everything worked
fine, including gff3_merge, fasta_merge etc. I got predictions for all the
contigs etc.


However, when I ran it on the full 20,000 sequence file (minimum 300 bp, I
know - I could have set the min length in maker_opts.ctl but I wanted the
repeatmasker analysis done even for the smaller contigs), I had a problem:

1. the intermediate files were all fine (i.e. grep -c FINISHED
...master_datastore_index.log showed the right number of sequences)

2. But gff3_merge -d ...master_datastore_index.log  only gave a file with
about 9000 contigs. I ran it a few times and got the same result each
time. fasta_merge gave back sequences from all ~20,000 contigs, so I know
the contig_datastore was fine.

3. Could it be that gff3_merge hit some sort of output limit? the GFF3
file created seems to be almost exactly 100MB. Or could it be a limit of
my OS environment? I had a lot of memory (12 GB) and a large tmp directory
(10 GB) so that should not be a problem...

If anyone has seen this problem or can shed any light on this, that would
be great.

I'm going to try splitting the file into smaller sets and hoping for the
best.

Thanks

- Sujai




-- 
You received this message because you are subscribed to the Google Groups
"maker-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to maker-devel... at googlegroups.com <>.
To post to this group, send email to maker... at googlegroups.com <>.
Visit this group at http://groups.google.com/group/maker-devel.
For more options, visit https://groups.google.com/groups/opt_out.




Barry Moore
Research Scientist
Dept. of Human Genetics
University of Utah
Salt Lake City, UT 84112
--------------------------------------------
(801) 585-3543









-- 
You received this message because you are subscribed to a topic in the
Google Groups "maker-devel" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/maker-devel/bApnLPFgmRc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
maker-devel... at googlegroups.com <>.
To post to this group, send email to maker... at googlegroups.com <>.
Visit this group at http://groups.google.com/group/maker-devel.
For more options, visit https://groups.google.com/groups/opt_out.






-- 
You received this message because you are subscribed to the Google Groups
"maker-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to maker-devel... at googlegroups.com <>.
To post to this group, send email to maker... at googlegroups.com <>.
Visit this group at http://groups.google.com/group/maker-devel.
For more options, visit https://groups.google.com/groups/opt_out.




Barry Moore
Research Scientist
Dept. of Human Genetics
University of Utah
Salt Lake City, UT 84112
--------------------------------------------
(801) 585-3543














From sujaikumar at gmail.com  Tue Nov 19 01:33:06 2013
From: sujaikumar at gmail.com (Sujai)
Date: Tue, 19 Nov 2013 08:33:06 +0000
Subject: [maker-devel] gff3_merge error - only half the contigs are
	reported
In-Reply-To: <CEAFD381.2B146%ejr@stowers.org>
References: <CEAFD381.2B146%ejr@stowers.org>
Message-ID: <CAFADFFu7Re=kRTB6qbS3qjhAEGQ0DmbJeJ3wPBq-QonM9VYDtQ@mail.gmail.com>

Hi Eric

Thanks for uncovering the /tmp limitation. I had changed TMPDIR in my
maker_opts.ctl file, but I suppose gff3_merge would not use that setting,
and would use /tmp or whatever TMPDIR was set to in the current shell.

Cheers,

- Sujai



On 18 November 2013 20:24, Ross, Eric <ejr at stowers.org> wrote:

> I had the same problem Sujai reported  on the 25th.
>
> When I run gff3_merge I only get back results from a subset of my
> scaffolds.  Every scaffold has a gff file in the data store.  fasta_merge
> works fine.  No errors are printed to STDOUT.
>
> It took me some poking around, but this seems that if there is
> insufficient space in /tmp to generate the temporary files merge_gff3
> completes without error and just creates a gff file from whatever fit in
> the temporary files.  I'm not sure why tempfile() doesn't return a useful
> error.
>
> I was able to get around the error by setting the environment variable
> TMPDIR to someplace with sufficient space, but if there is a way to
> generate a useful error it might be worth adding.
>
>
> Eric
>
>
>
>
> --original below--
> On Friday, October 25, 2013 11:22:08 AM UTC-5, Barry wrote:
> Hi Sujai,
> If you still have that original directory available a couple things you to
> try:
>
> # Does this give you the number of contigs you're expecting?
> find datastore_directory -name '*.gff3' | wc -l
>
> # If the above gives what you expect what does the file size look like on
> the smallest files?
> find ./ -type f | xargs ls -Sl | tail
>
> Barry
>
> On Oct 24, 2013, at 4:04 PM, Sujai wrote:
>
>
> Hi Barry
>
> The last stderr message in the job is from the maker command:
>
> Maker is now finished!!!
>
> my last 3 commands were (in my pbs/torque job script):
>
> ----job script----
> ...other commands to set variables etc...
> mpiexec -n 12 maker -g $SPLITFILE -base $SPLITFILE maker_opts.ctl
> maker_bopts.ctl maker_exe.ctl
> gff3_merge -o $PBS_O_WORKDIR/$SPLITFILE.gff3 -d
> $SPLITFILE.maker.output/${SPLITFILE}_master_datastore_index.log
> fasta_merge -d
> $SPLITFILE.maker.output/${SPLITFILE}_master_datastore_index.log
> -----
>
> so, no gff3_merge stderr messages
> the fasta_merge command (which came after gff3_merge) has completed
> correctly, with all proteins and transcripts accounted for.
> I just ran the same contigs again in smaller batches, and it seems to be
> proceeding correctly (the final gff3 files are between 49-55MB for each
> chunk of fasta files. In the previous case, the final GFF3 file was 99MB
> or 100MB (which is why I thought there was some sort of filesize/memory
> limit)
>
> Thanks for looking into this,
>
> - Sujai
>
>
>
>
> On 24 October 2013 21:42, Barry Moore <barry... at genetics.utah.edu <>>
> wrote:
>
> Hi Sujai,
> There are a couple of fatal errors that can be thrown by gff3_merge if it
> encounters errors.  Did you capture STDERR and do you see any failures
> there?
>
> B
>
> On Oct 24, 2013, at 10:43 AM, Sujai wrote:
>
>
>
>
> Hi all
> First of all, thank you to Carson Holt and Mark Yandell and team for an
> excellent program with excellent installation instructions. Setting maker
> 2.28 up and running it (both with MPI and without) was a breeze on a PBS
> cluster. Everything worked as expected (doesn't happen that often in
> bioinformatics software! :-))
>
> I did a test run on 150 longish contigs (>50kb each) and everything worked
> fine, including gff3_merge, fasta_merge etc. I got predictions for all the
> contigs etc.
>
>
> However, when I ran it on the full 20,000 sequence file (minimum 300 bp, I
> know - I could have set the min length in maker_opts.ctl but I wanted the
> repeatmasker analysis done even for the smaller contigs), I had a problem:
>
> 1. the intermediate files were all fine (i.e. grep -c FINISHED
> ...master_datastore_index.log showed the right number of sequences)
>
> 2. But gff3_merge -d ...master_datastore_index.log  only gave a file with
> about 9000 contigs. I ran it a few times and got the same result each
> time. fasta_merge gave back sequences from all ~20,000 contigs, so I know
> the contig_datastore was fine.
>
> 3. Could it be that gff3_merge hit some sort of output limit? the GFF3
> file created seems to be almost exactly 100MB. Or could it be a limit of
> my OS environment? I had a lot of memory (12 GB) and a large tmp directory
> (10 GB) so that should not be a problem...
>
> If anyone has seen this problem or can shed any light on this, that would
> be great.
>
> I'm going to try splitting the file into smaller sets and hoping for the
> best.
>
> Thanks
>
> - Sujai
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "maker-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to maker-devel... at googlegroups.com <>.
> To post to this group, send email to maker... at googlegroups.com <>.
> Visit this group at http://groups.google.com/group/maker-devel.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
> Barry Moore
> Research Scientist
> Dept. of Human Genetics
> University of Utah
> Salt Lake City, UT 84112
> --------------------------------------------
> (801) 585-3543
>
>
>
>
>
>
>
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "maker-devel" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/maker-devel/bApnLPFgmRc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> maker-devel... at googlegroups.com <>.
> To post to this group, send email to maker... at googlegroups.com <>.
> Visit this group at http://groups.google.com/group/maker-devel.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "maker-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to maker-devel... at googlegroups.com <>.
> To post to this group, send email to maker... at googlegroups.com <>.
> Visit this group at http://groups.google.com/group/maker-devel.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
> Barry Moore
> Research Scientist
> Dept. of Human Genetics
> University of Utah
> Salt Lake City, UT 84112
> --------------------------------------------
> (801) 585-3543
>
>
>
>
>
>
>
>
>
>
>
> On Friday, October 25, 2013 11:22:08 AM UTC-5, Barry wrote:
> Hi Sujai,
> If you still have that original directory available a couple things you to
> try:
>
> # Does this give you the number of contigs you're expecting?
> find datastore_directory -name '*.gff3' | wc -l
>
> # If the above gives what you expect what does the file size look like on
> the smallest files?
> find ./ -type f | xargs ls -Sl | tail
>
> Barry
>
> On Oct 24, 2013, at 4:04 PM, Sujai wrote:
>
>
> Hi Barry
>
> The last stderr message in the job is from the maker command:
>
> Maker is now finished!!!
>
> my last 3 commands were (in my pbs/torque job script):
>
> ----job script----
> ...other commands to set variables etc...
> mpiexec -n 12 maker -g $SPLITFILE -base $SPLITFILE maker_opts.ctl
> maker_bopts.ctl maker_exe.ctl
> gff3_merge -o $PBS_O_WORKDIR/$SPLITFILE.gff3 -d
> $SPLITFILE.maker.output/${SPLITFILE}_master_datastore_index.log
> fasta_merge -d
> $SPLITFILE.maker.output/${SPLITFILE}_master_datastore_index.log
> -----
>
> so, no gff3_merge stderr messages
> the fasta_merge command (which came after gff3_merge) has completed
> correctly, with all proteins and transcripts accounted for.
> I just ran the same contigs again in smaller batches, and it seems to be
> proceeding correctly (the final gff3 files are between 49-55MB for each
> chunk of fasta files. In the previous case, the final GFF3 file was 99MB
> or 100MB (which is why I thought there was some sort of filesize/memory
> limit)
>
> Thanks for looking into this,
>
> - Sujai
>
>
>
>
> On 24 October 2013 21:42, Barry Moore <barry... at genetics.utah.edu <>>
> wrote:
>
> Hi Sujai,
> There are a couple of fatal errors that can be thrown by gff3_merge if it
> encounters errors.  Did you capture STDERR and do you see any failures
> there?
>
> B
>
> On Oct 24, 2013, at 10:43 AM, Sujai wrote:
>
>
>
>
> Hi all
> First of all, thank you to Carson Holt and Mark Yandell and team for an
> excellent program with excellent installation instructions. Setting maker
> 2.28 up and running it (both with MPI and without) was a breeze on a PBS
> cluster. Everything worked as expected (doesn't happen that often in
> bioinformatics software! :-))
>
> I did a test run on 150 longish contigs (>50kb each) and everything worked
> fine, including gff3_merge, fasta_merge etc. I got predictions for all the
> contigs etc.
>
>
> However, when I ran it on the full 20,000 sequence file (minimum 300 bp, I
> know - I could have set the min length in maker_opts.ctl but I wanted the
> repeatmasker analysis done even for the smaller contigs), I had a problem:
>
> 1. the intermediate files were all fine (i.e. grep -c FINISHED
> ...master_datastore_index.log showed the right number of sequences)
>
> 2. But gff3_merge -d ...master_datastore_index.log  only gave a file with
> about 9000 contigs. I ran it a few times and got the same result each
> time. fasta_merge gave back sequences from all ~20,000 contigs, so I know
> the contig_datastore was fine.
>
> 3. Could it be that gff3_merge hit some sort of output limit? the GFF3
> file created seems to be almost exactly 100MB. Or could it be a limit of
> my OS environment? I had a lot of memory (12 GB) and a large tmp directory
> (10 GB) so that should not be a problem...
>
> If anyone has seen this problem or can shed any light on this, that would
> be great.
>
> I'm going to try splitting the file into smaller sets and hoping for the
> best.
>
> Thanks
>
> - Sujai
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "maker-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to maker-devel... at googlegroups.com <>.
> To post to this group, send email to maker... at googlegroups.com <>.
> Visit this group at http://groups.google.com/group/maker-devel.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
> Barry Moore
> Research Scientist
> Dept. of Human Genetics
> University of Utah
> Salt Lake City, UT 84112
> --------------------------------------------
> (801) 585-3543
>
>
>
>
>
>
>
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "maker-devel" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/maker-devel/bApnLPFgmRc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> maker-devel... at googlegroups.com <>.
> To post to this group, send email to maker... at googlegroups.com <>.
> Visit this group at http://groups.google.com/group/maker-devel.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "maker-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to maker-devel... at googlegroups.com <>.
> To post to this group, send email to maker... at googlegroups.com <>.
> Visit this group at http://groups.google.com/group/maker-devel.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
> Barry Moore
> Research Scientist
> Dept. of Human Genetics
> University of Utah
> Salt Lake City, UT 84112
> --------------------------------------------
> (801) 585-3543
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> maker-devel mailing list
> maker-devel at box290.bluehost.com
> http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131119/7daa435c/attachment-0003.html>

From carson.holt at genetics.utah.edu  Tue Nov 26 08:38:10 2013
From: carson.holt at genetics.utah.edu (Carson Holt)
Date: Tue, 26 Nov 2013 15:38:10 +0000
Subject: [maker-devel] no protein or transcript fasta output
In-Reply-To: <CAKbGhzW-uqNtpEmoOG-ygf6au06gQSmZUfuGpd=1PtFTD9MLtQ@mail.gmail.com>
References: <CAKbGhzW-uqNtpEmoOG-ygf6au06gQSmZUfuGpd=1PtFTD9MLtQ@mail.gmail.com>
Message-ID: <CEBA0E41.7169%carson.holt@genetics.utah.edu>

What version are you running?

Thanks,
Carson


From: mun hua <mh.tan85 at gmail.com<mailto:mh.tan85 at gmail.com>>
Date: Tuesday, November 26, 2013 at 2:32 AM
To: <maker-devel at yandell-lab.org<mailto:maker-devel at yandell-lab.org>>
Subject: no protein or transcript fasta output

Hi,

I tried out the example outlined by Maker, on the dpp_contig dataset.
Upon running maker, it only generated the gff output file, and none of the protein or transcript fasta files. I've checked the logs but have not seen any obvious errors.
Does anyone have any idea on why this is for me?

Thanks,
MH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131126/3ec95f21/attachment-0003.html>

From mh.tan85 at gmail.com  Tue Nov 26 02:32:04 2013
From: mh.tan85 at gmail.com (mun hua)
Date: Tue, 26 Nov 2013 17:32:04 +0800
Subject: [maker-devel] no protein or transcript fasta output
Message-ID: <CAKbGhzW-uqNtpEmoOG-ygf6au06gQSmZUfuGpd=1PtFTD9MLtQ@mail.gmail.com>

Hi,

I tried out the example outlined by Maker, on the dpp_contig dataset.
Upon running maker, it only generated the gff output file, and none of the
protein or transcript fasta files. I've checked the logs but have not seen
any obvious errors.
Does anyone have any idea on why this is for me?

Thanks,
MH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131126/8a6d4e21/attachment-0003.html>

From mh.tan85 at gmail.com  Tue Nov 26 18:03:45 2013
From: mh.tan85 at gmail.com (mun hua)
Date: Wed, 27 Nov 2013 09:03:45 +0800
Subject: [maker-devel] no protein or transcript fasta output
In-Reply-To: <CEBA0E41.7169%carson.holt@genetics.utah.edu>
References: <CAKbGhzW-uqNtpEmoOG-ygf6au06gQSmZUfuGpd=1PtFTD9MLtQ@mail.gmail.com>
	<CEBA0E41.7169%carson.holt@genetics.utah.edu>
Message-ID: <CAKbGhzWYr-6Sx4hVEq-1bPeQ5fZgNWxeF+61KYWZ8+0F-jNKow@mail.gmail.com>

I'm running Maker v2.28.

I tried Maker with protein2genome=1 instead of the recommended est2genome=1
and I managed to get transcript and protein fasta sequences.
That is strange, since I supplied the config file with both
the dpp_est.fasta and dpp_protein.fasta files?


On Tue, Nov 26, 2013 at 11:38 PM, Carson Holt <carson.holt at genetics.utah.edu
> wrote:

>  What version are you running?
>
>  Thanks,
> Carson
>
>
>   From: mun hua <mh.tan85 at gmail.com>
> Date: Tuesday, November 26, 2013 at 2:32 AM
> To: <maker-devel at yandell-lab.org>
> Subject: no protein or transcript fasta output
>
>  Hi,
>
>  I tried out the example outlined by Maker, on the dpp_contig dataset.
> Upon running maker, it only generated the gff output file, and none of the
> protein or transcript fasta files. I've checked the logs but have not seen
> any obvious errors.
> Does anyone have any idea on why this is for me?
>
>  Thanks,
> MH
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20131127/eb47d812/attachment-0003.html>