<div dir="ltr">Most common problem is use of the wrong version of blacs -- which the Intel link advisor will provide information about.<div><br></div><div>I have very, very rarely seen anything beyond a wrong version of blacs.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 10, 2016 at 6:27 PM, Gavin Abo <span dir="ltr"><<a href="mailto:gsabo@crimson.ua.edu" target="_blank">gsabo@crimson.ua.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div bgcolor="#FFFFFF" text="#000000">
<div>From the backtrace, it does look like it crashed in libmpi.so.1, which I believe is an Open MPI library.  I don't know if it will solve the problem or not, but I would try a different Open MPI version or recompile Open MPI (while
 tweaking the configuration options [ <a href="https://software.intel.com/en-us/articles/performance-tools-for-software-developers-building-open-mpi-with-the-intel-compilers" target="_blank">
https://software.intel.com/en-us/articles/performance-tools-for-software-developers-building-open-mpi-with-the-intel-compilers</a> ]).<br>
<br>
composer_xe_2015.3.187 => ifort version 15.0.3 [ <a href="https://software.intel.com/en-us/articles/intel-compiler-and-composer-update-version-numbers-to-compiler-version-number-mapping" target="_blank">
https://software.intel.com/en-us/articles/intel-compiler-and-composer-update-version-numbers-to-compiler-version-number-mapping</a> ]<br>
<br>
In the post at the following link on the Intel forum it looks like openmpi-1.10.1rc2 (or newer) was recommended for ifort 15.0 (or newer) to resolve a Fortran run-time library (RTL) issue:<br>
<br>
<a href="https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/564266" target="_blank">https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/564266</a><br>
<br>
On 1/10/2016 3:42 PM, Hu, Wenhao wrote:<br>
</div>
<blockquote type="cite">
<div><br>
</div>
<div>(I accidentally replied with a wrong title. To ensure consistency, I send this post again. Maybe the mail list manager can delete the wrong post for me^)</div>
<div><br>
</div>
Hi, Peter:<br>
<br>
Thank you very much for your reply. By following your suggestion, I unified the version of all the library to be compiled or consistent with intel composer xe 2015 (MKL, fftw, openmpi etc.) and recompiled wien2k. The version of my openmpi is 1.6.5. However,
 I still get the same problem. Except for the message I posted earlier, I also have the following backtrace information of the process:<br>
<br>
lapw1c_mpi:14596 terminated with signal 11 at PC=2ab4dac4df79 SP=7fff78b8e310.  Backtrace:<br>
<br>
lapw1c_mpi:14597 terminated with signal 11 at PC=2b847d2a1f79 SP=7fff8ef89690.  Backtrace:<br>
/opt/openmpi-intel-composer_xe_2015.3.187/1.6.5/lib/libmpi.so.1(MPI_Comm_size+0x59)[0x2ab4dac4df79]<br>
/opt/openmpi-intel-composer_xe_2015.3.187/1.6.5/lib/libmpi.so.1(MPI_Comm_size+0x59)[0x2b847d2a1f79]<br>
/Users/wenhhu/wien2k14/lapw1c_mpi(blacs_pinfo_+0x92)[0x49cf02]<br>
/Users/wenhhu/wien2k14/lapw1c_mpi(blacs_pinfo_+0x92)[0x49cf02]<br>
/opt/intel/composer_xe_2015.3.187/mkl/lib/intel64/libmkl_scalapack_lp64.so(sl_init_+0x21)[0x2b8478d2e171]<br>
/opt/intel/composer_xe_2015.3.187/mkl/lib/intel64/libmkl_scalapack_lp64.so(sl_init_+0x21)[0x2ab4d66da171]<br>
/Users/wenhhu/wien2k14/lapw1c_mpi(parallel_mp_init_parallel_+0x63)[0x463cd3]<br>
/Users/wenhhu/wien2k14/lapw1c_mpi(parallel_mp_init_parallel_+0x63)[0x463cd3]<br>
/Users/wenhhu/wien2k14/lapw1c_mpi(gtfnam_+0x22)[0x426372]<br>
/Users/wenhhu/wien2k14/lapw1c_mpi(MAIN__+0x6c)[0x4493dc]<br>
/Users/wenhhu/wien2k14/lapw1c_mpi(main+0x2e)[0x40d19e]<br>
/Users/wenhhu/wien2k14/lapw1c_mpi(gtfnam_+0x22)[0x426372]<br>
/Users/wenhhu/wien2k14/lapw1c_mpi(MAIN__+0x6c)[0x4493dc]<br>
/Users/wenhhu/wien2k14/lapw1c_mpi(main+0x2e)[0x40d19e]<br>
/lib64/libc.so.6(__libc_start_main+0xfd)[0x339101ed5d]<br>
/Users/wenhhu/wien2k14/lapw1c_mpi[0x40d0a9]<br>
/lib64/libc.so.6(__libc_start_main+0xfd)[0x339101ed5d]<br>
/Users/wenhhu/wien2k14/lapw1c_mpi[0x40d0a9]<br>
<br>
Do you think it’s still the problem of my MKL or there’re some other issues I miss?<br>
<br>
Best,<br>
Wenhao<br>
<br>
<br>
<br>
<blockquote type="cite">a) Clearly, for a nanowire simulation the mpi-parallelization is best. Unfortunately, on some clusters mpi is not set-up properly, or users do not use the proper mkl-libraries for hthe particular mpi. Please use the Intel link-library
 advisor, as was mentioned in previous posts. The mkl-scalapack will NOT work unless you use proper version of the blacs_lp64 library.<br>
b) As a short term solution you should:<br>
<br>
i) Use a parallelization with OMP_NUM_THREAD=2. This speeds up the calculation by nearly a factor of 2 and uses 2 cores in a single lapw1 without memory increase. ii) Reduce the number of k-points. I'm pretty sure you can reduce it to 2-4 for scf and structure
 optimization. This will save memory due to fewer k-parallel jobs. iii) During structure optimization you will end up with very small Si-H and C-H distances. So I'd reduce the H sphere right now to about 0.6, but keep Si and C large (for C use around 1.2).
 With such a setup, a preliminary structure optimization can be done with RKMAX=2.0, which should later be checked with 2.5 and 3.0 iv) Use iterative diagonalization ! After the first cycle, this will speed-up the scf by a factor of 5 !! v) And of course, reconsider
 the size of your "vacuum", i.e. the seperation of your wires. "Vacuum" is VERY expensive in terms of memory and one should not set it too large without test. Optimize your wire with small a,b; then increase the vacuum later on (x supercell) and check if forces
 appear again and distances, ban structure, ... change.<br>
<br>
<blockquote type="cite">Am 09.01.2016 um 22:07 schrieb Hu, Wenhao:<br>
<br>
Hi, Marks and Peter:<br>
<br>
Thank you for your suggestions. About your reply, I have several<br>
follow-up questions. Actually, I’m using a intermediate cluster in my<br>
university, which has 16 cores and 64 GB memory on standard nodes. The<br>
calculation I’m doing is k-point but not MPI parallelized. From the :RKM<br>
flag I posted in my first email, I estimate that the matrix size I need<br>
for a Rkmax=5+ will be at least 40000. In my current calculation, the<br>
lapw1 program will occupy as large as 3GB on each slot (1 k point/slot).<br>
So I estimate the memory for each slot will be at least 12 GB. I have 8<br>
k points so that 96 GB memory will be required at least (if my<br>
estimation is correct). Considering the current computation resources I<br>
have, this is way too memory demanding. On our clusters, there’s a 4 GB<br>
memory limit for each slot on standard node. Although I can submit<br>
request for high memory node, but their usages are very competitive<br>
among cluster users. Do you have any suggestions on accomplishing this<br>
calculation within the limitation of my cluster?<br>
<br>
About the details of my calculation, the material I'm looking at is a<br>
hydrogen terminated silicon carbide with 56 atoms. A 1x1x14 k-mesh is<br>
picked for k-point sampling. The radius of 1.2 is achieved from<br>
setrmt_lapw actually. Indeed, the radius of hydrogen is too large and<br>
I’m adjusting its radius during the progress of optimization all the<br>
time. The reason why I have such a huge matrix is mainly due to size of<br>
my unit cell. I’m using large unit cell to isolate the coupling between<br>
neighboring nanowire.<br>
<br>
Except for the above questions, I also met some problems in mpi<br>
calculation. By following Marks’ suggestion on parallel calculation, I<br>
want to test the efficiency of mpi calculation since I only used k-point<br>
parallelized calculation before. The MPI installed on my cluster is<br>
openmpi. In the output file, I get the following error:<br>
<br>
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------<br>
 LAPW0 END<br>
<br>
lapw1c_mpi:19058 terminated with signal 11 at PC=2b56d9118f79<br>
SP=7fffc23d6890.  Backtrace:<br>
...<br>
mpirun has exited due to process rank 14 with PID 19061 on<br>
node neon-compute-2-25.local exiting improperly. There are two reasons<br>
this could occur:<br>
<br>
1. this process did not call "init" before exiting, but others in<br>
the job did. This can cause a job to hang indefinitely while it waits<br>
for all processes to call "init". By rule, if one process calls "init",<br>
then ALL processes must call "init" prior to termination.<br>
<br>
2. this process called "init", but exited without calling "finalize".<br>
By rule, all processes that call "init" MUST call "finalize" prior to<br>
exiting or it will be considered an "abnormal termination"<br>
<br>
This may have caused other processes in the application to be<br>
terminated by signals sent by mpirun (as reported here).<br>
--------------------------------------------------------------------------<br>
Uni_+6%.scf1up_1: No such file or directory.<br>
grep: *scf1up*: No such file or directory<br>
<br>
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------<br>
<br>
The job script I’m using is:<br>
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------<br>
!/bin/csh -f<br>
# -S /bin/sh<br>
#<br>
#$ -N uni_6<br>
#$ -q MF<br>
#$ -m be<br>
#$ -M wenhao...@<a href="http://uiowa.edu" target="_blank">uiowa.edu</a> <<br>
<a href="mailto:wenhao...@" target="_blank">mailto:wenhao...@</a><a href="http://uiowa.edu" target="_blank">uiowa.edu</a><br>
<blockquote type="cite"><br>
</blockquote>
#$ -pe smp 16<br>
#$ -cwd<br>
#$ -j y<br>
<br>
cp $PE_HOSTFILE hostfile<br>
echo "PE_HOSTFILE:"<br>
echo $PE_HOSTFILE<br>
rm .machines<br>
echo granularity:1 >>.machines<br>
while read hostname slot useless; do<br>
    i=0<br>
    l0=$hostname<br>
    while [ $i -lt $slot ]; do<br>
        echo 1:$hostname:2 >>.machines<br>
        let i=i+2<br>
    done<br>
done<hostfile<br>
<br>
echo lapw0:$l0:16 >>.machines<br>
<br>
runsp_lapw -p -min -ec 0.0001 -cc 0.001 -fc 0.5<br>
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------<br>
<br>
Is there any mistake I made or something missing in my script?<br>
<br>
Thank your very much for your help.<br>
<br>
Wenhao<br>
<br>
<br>
<blockquote type="cite">I do not know many compounds, for which an RMT=1.2 bohr for H makes<br>
any sense (maybe LiH). Use setrmt and follow the suggestion. Usually,<br>
H spheres of CH or OH bonds should be less than 0.6 bohr.<br>
Experimental H-position are often very unreliable.<br>
How many k-points ? Often 1 k-point is enough for 50+ atoms (at least<br>
at the beginning), in particular when you ahve an insulator.<br>
Otherwise, follow the suggestions of L.Marks about parallelization.<br>
<br>
<br>
Am 08.01.2016 um 07:28 schrieb Hu, Wenhao:<br>
<br>
Hi, all:<br>
<br>
I have some confusions on the Rkm in calculations with 50+ atoms. In<br>
my wien2k,<br>
the NATMAX and NUME are set to 15000 and 1700. With the highest NE<br>
and NAT, the<br>
Rkmax can only be as large as 2.05, which is much lower than the<br>
suggested<br>
value in FAQ page of WIEN2K (the smallest atom in my case is a H atom<br>
with<br>
radius of 1.2). By checking the :RKM flag in case.scf, I have the<br>
following<br>
information:<br>
<br>
:RKM  : MATRIX SIZE 11292LOs: 979  RKM= 2.05  WEIGHT= 1.00  PGR:<br>
<br>
With such a matrix size, the single cycle can take as long as two and<br>
half<br>
hours. Although I can increase the NATMAX and NUME to raise Rkmax, the<br>
calculation will be way slower, which will make the optimization<br>
calculation<br>
almost impossible. Before making convergence test on Rkmax, can<br>
anyone tell me<br>
whether such a Rkmax is a reasonable value?<br>
<br>
If any further information is needed, please let me know. Thanks in<br>
advance.<br>
<br>
Best,<br>
Wenhao<br>
</blockquote>
_______________________________________________<br>
Wien mailing list<br>
<a href="mailto:Wien@zeus.theochem.tuwien.ac.at" target="_blank">Wien@zeus.theochem.tuwien.ac.at</a> <<br>
<a href="mailto:Wien@zeus.theochem.tuwien.ac.at" target="_blank">mailto:Wien@zeus.theochem.tuwien.ac.at</a><br>
<blockquote type="cite"><br>
</blockquote>
<br>
<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>
<br>
<br>
SEARCH the MAILING-LIST at:<br>
<br>
<br>
<a href="http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html" target="_blank">http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html</a><br>
</blockquote>
<br>
<br>
--<br>
--------------------------------------------------------------------------<br>
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna<br>
Phone: +43-1-58801-165300             FAX: +43-1-58801-165982<br>
Email: bl...@<a href="http://theochem.tuwien.ac.at" target="_blank">theochem.tuwien.ac.at</a> <<br>
<a href="http://theochem.tuwien.ac.at" target="_blank">http://theochem.tuwien.ac.at</a><br>
<blockquote type="cite"><br>
</blockquote>
WIEN2k:<br>
<br>
<a href="http://www.wien2k.at" target="_blank">http://www.wien2k.at</a><br>
<br>
<br>
WWW:<br>
<br>
<a href="http://www.imc.tuwien.ac.at/staff/tc_group_e.php" target="_blank">http://www.imc.tuwien.ac.at/staff/tc_group_e.php</a><br>
</blockquote>
</blockquote>
</div>

</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Professor Laurence Marks<br>Department of Materials Science and Engineering<br>Northwestern University<br><a href="http://www.numis.northwestern.edu" target="_blank">www.numis.northwestern.edu</a><div>Corrosion in 4D: <a href="http://MURI4D.numis.northwestern.edu" target="_blank">MURI4D.numis.northwestern.edu</a><br>Co-Editor, Acta Cryst A<br>"Research is to see what everybody else has seen, and to think what nobody else has thought"<br>Albert Szent-Gyorgi</div></div></div>
</div>