[maker-devel] Error running MAKER

[John Cornelius]

Hello, I'm using MAKER to annotate a tetraploid genome and while running it, I encountered the following error:

#--------- command -------------#

Widget::exonerate::est2genome:

/packages/exonerate-2.2.0/bin/exonerate  -q /tmp/maker_08Elxf/15/TRINITY_GG_19079_c1670_g1_i1.for.84770203-84771247.15.fasta -t /tmp/maker_08Elxf/15/chr9_10L.84770203-84771247.15.fasta -Q dna -T dna --model est2genome  --minintron 20 --maxintron 10000 --showcigar --percent 20 > /tmp/maker_08Elxf/15/chr9_10L.84770203-84771247.TRINITY_GG_19079_c1670_g1_i1.e.exonerate

#-------------------------------#

running  est2genome search.

#--------- command -------------#

Widget::exonerate::est2genome:

/packages/exonerate-2.2.0/bin/exonerate  -q /tmp/maker_08Elxf/10/TRINITY_GG_87963_c9694_g10_i12.for.49475083-49475985.10.fasta -t /tmp/maker_08Elxf/10/chr6L.49475083-49475985.10.fasta -Q dna -T dna --model est2genome  --minintron 20 --maxintron 10000 --showcigar --percent 20 > /tmp/maker_08Elxf/10/chr6L.49475083-49475985.TRINITY_GG_87963_c9694_g10_i12.e.exonerate

#-------------------------------#

===================================================================================

=   BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES

=   PID 132376 RUNNING AT pnap-pe7-s03

=   EXIT CODE: 135

=   CLEANING UP REMAINING PROCESSES

=   YOU CAN IGNORE THE BELOW CLEANUP MESSAGES

===================================================================================

YOUR APPLICATION TERMINATED WITH THE EXIT STRING: Bus error (signal 7)

This typically refers to a problem with your application.

Please see the FAQ page for debugging suggestions

The the command I ran was the following:

#PBS -l walltime=240:00:00

#PBS -N MAKER

#PBS -l nodes=1:ppn=16

##PBS -q hmem

#PBS -j oe

#PBS -m abe

#PBS -M jcorn...@tgen.org

#PBS -A tgen-205000

#PBS -o /scratch/jcornelius/xenopus_laevis/maker_run

# --- load required modules --- #

module load maker

# --- run maker --- #

cd /scratch/jcornelius/xenopus_laevis/maker_run

mpiexec -n 16 maker -base XLNEURO.run1 -fix_nucleotides

I'm not sure what could be causing this error and any help would be much appreciated. Thanks.

--

John Cornelius
MCB PhD Candidate
Arizona State University

[Carson Holt]

The cause of the error is probably further back in the STDERR. With MPI so many processes are producing status and notes, that you can get several seconds of output after ta failure. If you kept the whole STDERR, I can help you look through it.  searching for “ERROR” all caps is usually where you will see it. Also MAKER keeps a log of progress, so even on failure, you can just restart it and it will pick up the analysis from the last successful step.

—Carson

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

[Carson Holt]

To use less RAM, try lowering max_dna_len=, setting blast_depth= parameters to 20 pr 30 in maker_bopts.ctl (default is limitless), or when using MPI, starting fewer processes per node (requires manipulation of hostfile or using round robin distribution flag for MPI flavors where it is available).

The memory issue could be causing the lock failure as well.

—Carson

On Nov 17, 2016, at 7:53 PM, John Cornelius <jcor...@asu.edu> wrote:

Ok, so I went and searched one of the output logs for all the lines that say ERROR and I got 44 lines with the following message:

ERROR: Lock broken in runlog

With these lines found at the end:

ERROR: Failed while polishig ESTs

ERROR: Chunk failed at level:2, tier_type:3

ERROR: Could not query process table: Cannot allocate memory at /packages/maker/2.31.8/bin/../lib/Proc/ProcessTable_simple.pm line 62.

From that last line it looks like the process is running out of RAM would that be right? Thanks.

[John Cornelius]

Would the lock failure cause problems with the annotation? It looks like Maker is still progressing, just not as quickly as I thought it would be.

[Carson Holt]

A lock failure can become an issue if two separate jobs are running simultaneously. They may both try to process the same contig at the same time (modifying each others files) which will cause one or both to fail. On failure, it should always retry at some later point. So it can usually recover from this. If you see any partial lines in the resulting GFF3, then it did not recover and you need to just rerun whatever contig this happened on.

—Carson

[Carson Holt]

Yes. You can either separate out the contig using fasta_tool or find the contig in the datastore directory (failed contigs will have fasta created there just for the failed contig). Then you can use 'maker -g contig.fasta -base original_base_name’ (-g and -base options) to specify that you want it to use the new contig fasta but write results to the given base directory (i.e. same as previous output directory). Remember to set -t (or tries in the maker_opts.ctl file) to a higher count when doing this.

—Carson

On Nov 30, 2016, at 12:11 PM, John Cornelius <jcor...@asu.edu> wrote:

Awesome! Thanks for the help. MAKER finally finished it's initial run today however, I noticed that there was still one large sequence that failed. Would it be possible to run MAKER on just that sequence and then combine the result of that run with the output of my main maker run?