<div dir="ltr"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Thanks very much for the reply Carson,</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">I've attached few files file of the most recently failed run: the shell script submitted to Slurm, the _opts.ctl file, and the pair of log files generated from the job. The reason there are a 1a and 1b pair of files is that I had initially set the number of cpus in the _opts.ctl file to "60", but then tried re-running it after setting it to "28". Both seem to have the same result.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">I certainly have access to more memory if needed. I'm using a pretty typical (I think?) cluster that controls jobs with Slurm using a Lustre file system - it's the main high performance computing center at our university. I have access to plenty of nodes that contain about 120-150g of RAM each with between 24-28 cpus each, as well a handful of higher memory nodes with about 1.5tb of RAM. As I'm writing this email, I've submitted a similar Maker job (i.e. same fasta/gff inputs) requesting 200g of RAM over 32 cpus; if that fails, I could certainly run again with even more memory.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Appreciate your insights; hope the weather in UT is filled with sun or snow or both.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Devon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 26, 2020 at 2:10 PM Carson Holt <<a href="mailto:carsonhh@gmail.com">carsonhh@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">If running under MPI, the reason for a failure may be further back in the STDERR (failures tend snowball other failures, so the initial cause is often way back). If you can capture the STDERR and send it, that would be the most informative. If its memory, you can also set all the blast_depth parameters in maker_botpts.ctl to a value like 20.<div><br></div><div>—Carson</div><div><br></div><div><br><div><br><blockquote type="cite"><div>On Feb 19, 2020, at 1:54 PM, Devon O'Rourke <<a href="mailto:devon.orourke@gmail.com" target="_blank">devon.orourke@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Hello,</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">I apologize for not posting directly to the archived forum but it appears that the option to enter new posts is disabled. Perhaps this is by design so emails go directly to this address. I hope this is what you are looking for.<br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br>Thank you for your continued support of Maker and your responses to the forum posts. I have been running Maker (V3.01.02-beta) to annotate a mammalian genome that consists of 22 chromosome-length scaffolds (between ~200-20Mb) and about 10,000 smaller fragments from 1Mb to 10kb in length. In my various tests in running Maker, the vast majority of the smaller fragments are annotated successfully, but nearly all the large scaffolds fail with the same error code when I look at the 'run.log.child.0' file:<br>```<br>DIED    RANK    0:6:0:0<br>DIED   COUNT   2<br>```<br>(the master 'run.log' file just shows "DIED        COUNT   2")<br><br>I struggled to find this exact error code anywhere on the forum and was hoping you might be able to help me determine where I should start troubleshooting. I thought perhaps it was an error concerning memory requirements, so I altered the chunk size from the default to a few larger sequence lengths (I've tried 1e6, 1e7, and 999,999,999 - all produce the same outcome). I've tried running the program with parallel support using either openMPI or mpich. I've tried running on a single node using 24 cpus and 120g of RAM. It always stalls at the same step.<br><br>Interestingly, one of the 22 large scaffolds always finishes and produces the .maker.proteins.fasta, .maker.transcripts.fasta, and .gff files, but the other 21 of 22 large scaffolds fail. This makes me think perhaps it's not a memory issue?<br><br>In the case of both the completed and failed scaffolds, the "theVoid.scaffoldX" subdirectory(ies) containing the .rb.cat.gz, .rb.out, .specific.ori.out, .specific.cat.gz, .specific.out, te_proteins*fasta.repeat runner, the est *fasta.blastn, the altest *fasta.tblastx, and protein *fasta.blastx files are all present (and appear finished from what I can tell).<br>However, the particular contents in the parent directory to the "theVoid.scaffold" folder differ. For the failed scaffolds, the contents generally always look something like this (that is, they stall with the same kind of files produced):<br>```<br>0<br>evidence_0.gff<br>query.fasta<br>query.masked.fasta<br>query.masked.fasta.index<br>query.masked.gff<br>run.log.child.0<br>scaffold22.0.final.section<br>scaffold22.0.pred.raw.section<br>scaffold22.0.raw.section<br>scaffold22.gff.ann<br>scaffold22.gff.def<br>scaffold22.gff.seq<br>```<br><br>For the completed scaffold, there are many more files created:<br>```<br>0<br>10<br>100<br>20<br>30<br>40<br>50<br>60<br>70<br>80<br>90<br>evidence_0.gff<br>evidence_10.gff<br>evidence_1.gff<br>evidence_2.gff<br>evidence_3.gff<br>evidence_4.gff<br>evidence_5.gff<br>evidence_6.gff<br>evidence_7.gff<br>evidence_8.gff<br>evidence_9.gff<br>query.fasta<br>query.masked.fasta<br>query.masked.fasta.index<br>query.masked.gff<br>run.log.child.0<br>run.log.child.1<br>run.log.child.10<br>run.log.child.2<br>run.log.child.3<br>run.log.child.4<br>run.log.child.5<br>run.log.child.6<br>run.log.child.7<br>run.log.child.8<br>run.log.child.9<br>scaffold4.0-1.raw.section<br>scaffold4.0.final.section<br>scaffold4.0.pred.raw.section<br>scaffold4.0.raw.section<br>scaffold4.10.final.section<br>scaffold4.10.pred.raw.section<br>scaffold4.10.raw.section<br>scaffold4.1-2.raw.section<br>scaffold4.1.final.section<br>scaffold4.1.pred.raw.section<br>scaffold4.1.raw.section<br>scaffold4.2-3.raw.section<br>scaffold4.2.final.section<br>scaffold4.2.pred.raw.section<br>scaffold4.2.raw.section<br>scaffold4.3-4.raw.section<br>scaffold4.3.final.section<br>scaffold4.3.pred.raw.section<br>scaffold4.3.raw.section<br>scaffold4.4-5.raw.section<br>scaffold4.4.final.section<br>scaffold4.4.pred.raw.section<br>scaffold4.4.raw.section<br>scaffold4.5-6.raw.section<br>scaffold4.5.final.section<br>scaffold4.5.pred.raw.section<br>scaffold4.5.raw.section<br>scaffold4.6-7.raw.section<br>scaffold4.6.final.section<br>scaffold4.6.pred.raw.section<br>scaffold4.6.raw.section<br>scaffold4.7-8.raw.section<br>scaffold4.7.final.section<br>scaffold4.7.pred.raw.section<br>scaffold4.7.raw.section<br>scaffold4.8-9.raw.section<br>scaffold4.8.final.section<br>scaffold4.8.pred.raw.section<br>scaffold4.8.raw.section<br>scaffold4.9-10.raw.section<br>scaffold4.9.final.section<br>scaffold4.9.pred.raw.section<br>scaffold4.9.raw.section<br>```<br><br>Thanks for any troubleshooting tips you can offer. <br><br>Cheers,<br>Devon</div><br>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><font face="tahoma, sans-serif">Devon O'Rourke</font></div><div><font face="tahoma, sans-serif">Postdoctoral researcher, Northern Arizona University</font></div><font face="tahoma, sans-serif"><span style="font-size:12.8px">Lab of Jeffrey T. Foster - </span></font><a href="https://fozlab.weebly.com/" target="_blank">https://fozlab.weebly.com/</a><br><div><span style="font-size:12.8px">twitter: @thesciencedork<br></span></div></div></div></div></div></div></div></div></div></div></div>
_______________________________________________<br>maker-devel mailing list<br><a href="mailto:maker-devel@yandell-lab.org" target="_blank">maker-devel@yandell-lab.org</a><br><a href="http://yandell-lab.org/mailman/listinfo/maker-devel_yandell-lab.org" target="_blank">http://yandell-lab.org/mailman/listinfo/maker-devel_yandell-lab.org</a><br></div></blockquote></div><br></div></div></blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><font face="tahoma, sans-serif">Devon O'Rourke</font></div><div><font face="tahoma, sans-serif">Postdoctoral researcher, Northern Arizona University</font></div><font face="tahoma, sans-serif"><span style="font-size:12.8px">Lab of Jeffrey T. Foster - </span></font><a href="https://fozlab.weebly.com/" target="_blank">https://fozlab.weebly.com/</a><br><div><span style="font-size:12.8px">twitter: @thesciencedork<br></span></div></div></div></div></div></div></div></div></div></div>