&#1616;Dear Stefaan, and Lurance,<br>The interactively output of ulimit -a is:<br><br>core file size&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (blocks, -c) 0<br>data seg size&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (kbytes, -d) unlimited<br>scheduling priority&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (-e) 0<br>file size&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (blocks, -f) unlimited<br>pending signals&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (-i) 16375<br>max locked memory&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (kbytes, -l) 32<br>max memory size&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (kbytes, -m) unlimited<br>open files&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (-n) 1024<br>pipe
 size&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (512 bytes, -p) 8<br>POSIX message queues&nbsp;&nbsp;&nbsp;&nbsp; (bytes, -q) 819200<br>real-time priority&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (-r) 0<br>stack size&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (kbytes, -s) unlimited<br>cpu time&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (seconds, -t) unlimited<br>max user processes&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (-u) 16375<br>virtual memory&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (kbytes, -v) unlimited<br>file locks&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (-x) unlimited<br><br>The output of ulimit -a using at is:<br>core file size&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (blocks, -c)
 0<br>data seg size&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (kbytes, -d) unlimited<br>scheduling priority&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (-e) 0<br>file size&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (blocks, -f) unlimited<br>pending signals&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (-i) 16375<br>max locked memory&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (kbytes, -l) 32<br>max memory size&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (kbytes, -m) unlimited<br>open files&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (-n) 1024<br>pipe size&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (512 bytes, -p) 8<br>POSIX message queues&nbsp;&nbsp;&nbsp;&nbsp; (bytes, -q) 819200<br>real-time
 priority&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (-r) 0<br>stack size&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (kbytes, -s) 10240<br>cpu time&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (seconds, -t) unlimited<br>max user processes&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (-u) 16375<br>virtual memory&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (kbytes, -v) unlimited<br>file locks&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (-x) unlimited<br><br>The only difference between them is:<br>diff 1 2<br>12c12<br>&lt; stack size&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (kbytes, -s) unlimited<br>---<br>&gt; stack size&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (kbytes, -s)
 10240<br><br>So it looks that we should change the stack size of "at login" from 10240 to the unlimited stack size of "interactively login", right?<br><br>Regards,<br>S. Jalali.<br> <br><br><br><b><i>Laurence Marks &lt;L-marks@northwestern.edu&gt;</i></b> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> Check if your implimentation of at is exporting environmental<br>variables such as ulimit correctly.<br><br>On 9/18/07, Saeid Jalali <s_jalali_a@yahoo.com> wrote:<br>&gt; Dear all,<br>&gt; We are running the latest version of the code on Fedora Core 7 using the<br>&gt; latest MKL and ifc compiler. Our system is Intel(R) Core(TM)2 Quad CPU @<br>&gt; 2.40GHz.<br>&gt;<br>&gt; Our case, containing 60 atoms, is converged selfconsistently, if we perform<br>&gt; run_lapw -p interactively. However, we would run it in background using at<br>&gt; daemon. But surprisingly, we have observed the following error at
 first<br>&gt; cycle, when we perform run_lapw -p using "at now" command:<br>&gt; **  testerror: Error in Parallel LAPW2<br>&gt;<br>&gt; This is in the case that the at daemon works well for other lighter cases.<br>&gt; Even it works for this heave case, if we reduce the Rkmax.<br>&gt;<br>&gt; The RAM memory of our system is 2 GB, and the swap memorry is 4 GB. When the<br>&gt; 4 cores of our system are involved to run, in parallel, the lapw1, almost<br>&gt; 3.5 GB out of the 4 GB swap space is used.<br>&gt;<br>&gt; We are surprised from where the problem of running the 60 atoms case only at<br>&gt; background (and not interactively!) comes.<br>&gt;<br>&gt; Your,<br>&gt; S. Jalali.<br>&gt;<br>&gt;<br>&gt;<br>&gt; yxl@email.jlu.edu.cn wrote:<br>&gt;  Dear users,<br>&gt;  Do you have ever met the same situation? In step kgen the number of<br>&gt; k-points is<br>&gt; the same, if enter 'yes' in 'Shift k-mesh' then all things will be ok until<br>&gt; convergence,<br>&gt;  but if
 enter 'no' then lapw1 error: Cholesky INFO = 4715<br>&gt;  'SECLR4' - POTRF (Scalapack/LAPACK) failed.<br>&gt;  I couldn't understand it, what's the difference between them. Any<br>&gt; suggestions will<br>&gt; be appreciated.<br>&gt; Best wishes!<br>&gt;  yours sincerely,<br>&gt;  hongxia<br>&gt; _______________________________________________<br>&gt; Wien mailing list<br>&gt; Wien@zeus.theochem.tuwien.ac.at<br>&gt; http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien<br>&gt;<br>&gt;<br>&gt;<br>&gt;  ________________________________<br>&gt; Moody friends. Drama queens. Your life? Nope! - their life, your story.<br>&gt;  Play Sims Stories at Yahoo! Games.<br>&gt;<br>&gt;<br>&gt; _______________________________________________<br>&gt; Wien mailing list<br>&gt; Wien@zeus.theochem.tuwien.ac.at<br>&gt; http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien<br>&gt;<br>&gt;<br><br><br>-- <br>Laurence Marks<br>Department of Materials Science and Engineering<br>MSE Rm 2036
 Cook Hall<br>2220 N Campus Drive<br>Northwestern University<br>Evanston, IL 60208, USA<br>Tel: (847) 491-3996 Fax: (847) 491-7820<br>email: L-marks at northwestern dot edu<br>Web: www.numis.northwestern.edu<br>EMM2007 http://ns.crys.ras.ru/EMMM07/<br>Commission on Electron Diffraction of IUCR<br>www.numis.northwestern.edu/IUCR_CED<br>_______________________________________________<br>Wien mailing list<br>Wien@zeus.theochem.tuwien.ac.at<br>http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien<br></s_jalali_a@yahoo.com></blockquote><br><p>&#32;
      <hr size=1>Be a better Globetrotter. <a href="http://us.rd.yahoo.com/evt=48254/*http://answers.yahoo.com/dir/_ylc=X3oDMTI5MGx2aThyBF9TAzIxMTU1MDAzNTIEX3MDMzk2NTQ1MTAzBHNlYwNCQUJwaWxsYXJfTklfMzYwBHNsawNQcm9kdWN0X3F1ZXN0aW9uX3BhZ2U-?link=list&sid=396545469">Get better travel answers </a>from someone who knows.<br>Yahoo! Answers - Check it out.