Hi Laurence,<div><br></div><div>I will try all you have said. I didn&#39;t know about the -assu buff option - I suppose it is valid for ifort, right?</div><div><br></div><div>My scratch is already set. In fact, it was one of the variables I had the care to set, because I saw the size of the vector files (scary...)</div>

<div><br></div><div>Finally, no problem with slowing down things a little. I&#39;d rather have things slowed down a few seconds than have two hours lost (that is roughly the time it takes for running lapw1 -up/dn for my system) plus the hours when nothing happen until I realize the job has died... And I stil have to include U and spin-orbit after that!</div>

<div><br></div><div>Thanks a lot,</div><div><br></div><div>Marcos<br><br><div class="gmail_quote">On Wed, Jul 28, 2010 at 9:00 PM, Laurence Marks <span dir="ltr">&lt;<a href="mailto:L-marks@northwestern.edu">L-marks@northwestern.edu</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">This could be quite a lot of work. Some simpler suggestions:<br>
<br>
1) In param.inc in SRC_lapw[0-2] change to<br>
      PARAMETER          (restrict_output= 1)<br>
This will reduce the size of the log files<br>
<br>
2) Use -assu buff in your compilation options -- this writes data in<br>
big chunks not line-by-line and is much<br>
friendlier on file servers.<br>
<br>
3) Set the environmental variable SCRATCH (export it from bash should<br>
work) so large data files such<br>
as the case.vector_X are local.<br>
<br>
4) In $WIENROOT/parallel_options add (or edit)<br>
set sleepy      = XX             # additional sleep before checking<br>
set delay = YY<br>
<br>
where XX, YY are adjusted to try and reduce AFS problems ( 0.5 ? --<br>
this will slow things down but...)<br>
<br>
<br>
2010/7/28 Marcos Veríssimo Alves &lt;<a href="mailto:marcos.verissimo.alves@gmail.com">marcos.verissimo.alves@gmail.com</a>&gt;:<br>
<div><div></div><div class="h5">&gt; Hi all,<br>
&gt; I have managed to run Wien2k in our cluster, with k-point parallelization.<br>
&gt; However, it looks like our NFS system (which is actually an AFS one) is<br>
&gt; still a bit unstable, since the cluster has been upgraded and re-assembled<br>
&gt; very recently. Problem is, the sysadmins have gone on vacations, so I&#39;ll<br>
&gt; have to find a way of getting around this the best I can until the beginning<br>
&gt; of next month.<br>
&gt; My current problem is that looks like some nodes of our cluster have been<br>
&gt; losing connection with the AFS server intermittently, and from what I see<br>
&gt; (please correct me if I&#39;m wrong) all the writing is done over the network to<br>
&gt; the home directory. So, during the writing of the energy_up files, if the<br>
&gt; connection is lost then lapw2 will crash. Indeed, one of the instances of<br>
&gt; lapw1 resulted in an energyup file, in the end, with 0 size. This in turn<br>
&gt; made lapw2 crash, and this has happened overnight.<br>
&gt; My question is, I would like to make a small (I guess) change in the<br>
&gt; scripts, wherever needed. Instead of writing some files (only the ones that<br>
&gt; are critical for the execution of the next code) to the home, which would be<br>
&gt; done over AFS, they would be done in the scratch directory, which is local.<br>
&gt; Then, at the end of the execution, they would be copied to the home<br>
&gt; directory, possibly with a check on the success of the operation. I don&#39;t<br>
&gt; know if this would be better, but at least the problems with network load<br>
&gt; would be much more punctual, and it could also be more prone to error<br>
&gt; control.<br>
&gt; Since I do not have much knowledge of csh programming (I&#39;m mostly a bash<br>
&gt; guy) and the Wien2k scripts are pretty complex beasts to which I am not very<br>
&gt; acquainted, could you give your opinions on the feasibility of my<br>
&gt; suggestions, and if they are not too complex to implement, possible changes<br>
&gt; and/or places to be changed in the scripts?<br>
&gt; Best regards,<br>
&gt; Marcos<br>
</div></div><div><div></div><div class="h5">&gt; _______________________________________________<br>
&gt; Wien mailing list<br>
&gt; <a href="mailto:Wien@zeus.theochem.tuwien.ac.at">Wien@zeus.theochem.tuwien.ac.at</a><br>
&gt; <a href="http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien" target="_blank">http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien</a><br>
&gt;<br>
&gt;<br>
<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: <a href="http://www.numis.northwestern.edu" target="_blank">www.numis.northwestern.edu</a><br>
Chair, Commission on Electron Crystallography of IUCR<br>
<a href="http://www.numis.northwestern.edu/" target="_blank">www.numis.northwestern.edu/</a><br>
Electron crystallography is the branch of science that uses electron<br>
scattering and imaging to study the structure of matter.<br>
_______________________________________________<br>
Wien mailing list<br>
<a href="mailto:Wien@zeus.theochem.tuwien.ac.at">Wien@zeus.theochem.tuwien.ac.at</a><br>
<a href="http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien" target="_blank">http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien</a><br>
</div></div></blockquote></div><br></div>