Re: [Wien] hmsec.F:(.text+0x3057): undefined reference to `pzheevr_'

[Dr. K. C. Bhamu]

Dear Gavin

Thanks for you detailed advice. Unfortunetly is could not solve the issue,

What I did is I added  "-pthread" to linker's option and I do not see any
warning/error message.
Hope it should be fine.


regards
Bhamu






On Fri, Sep 29, 2017 at 7:13 AM, Gavin Abo  wrote:

> composer_xe_2013.1.117 => This is update 1 of the 2013 composer xe [
> https://software.intel.com/en-us/articles/intel-fortran-
> composer-xe-2013-release-notes ].
> The MKL 11.0 update 2 release notes [ https://software.intel.com/en-
> us/articles/intel-mkl-110-release-notes ] has:
>
> ScaLAPACK
>
> Updated version to 2.0.2. New functions introduced include:
>
> P?SYEVR/P?HEEVR: MRRR (Multiple Relatively Robust Representations)
> algorithm
>
> This seems to indicate that your ifort/mkl version is barely too old.  It
> looks like update 2 of the 2013 composer xe or a newer version of the
> ifort/mkl is needed to be able to use the pzheevr function [
> http://scc.ustc.edu.cn/zlsc/tc4600/intel/2015.1.133/mkl/
> mklman/GUID-B5DEF9B1-C3B5-4D24-A776-744D282039CA.htm ].
>
> Please note: There are cases, where the old Scalapack diagonalization
> fails." => This strongly suggests that the best solution is to upgrade to a
> newer version of the Intel Fortran compiler and mkl.
>
> If you compare hmsec.F from WIEN2k 14 and 16.1 (using a program like
> WinMerge [ http://winmerge.org/ ]), you can clearly see that you most
> likely should not use the 14 version of the file in 16.1.
>
> The hmsec.F that is in the hmsec.F.gz file is the replacement file for
> WIEN2k 16.1, which is in Prof. Blaha's post at:
>
> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg15213.html
>
> This file seems to be identical to the one in WIEN2k 17.1  So, you could
> also instead copy the file from WIEN2k 17.1 to 16.1, or better yet should
> be to just use WIEN2k 17.1
>
> As was previously described, the -Dold_scalapack has to be added to the
> parallel options (FPOPT) in 16.1 with the replacement file or in 17.1 if a
> ifort/mkl version  2013.1.117 or older is used.
>
> On 9/28/2017 2:25 PM, Dr. K. C. Bhamu wrote:
>
> A temperately solution what I see is:
>
> If I copy below files/modules from Wien2k_14 (not from Wien2k_16) into
> respective SRC dir and compiles I see not error or warning.
>
> Could you please confirm whether this is fine or I should not do this? If
> I should avoid this then I am waiting for your advice for a possible
> solution.
>
> *lapw1*:
>
>
> seclr4.* .
>
> lapw1_mpi
>
>
> *lapwso:*
>
> hmsec.* .
>
> lapwso_mpi
>
>
> Regards
> Bhamu
>
>
>
> On Thu, Sep 28, 2017 at 11:08 PM, Dr. K. C. Bhamu 
> wrote:
>
>> Dear Prof. Peter,
>> Below warning message is already mentioned in the mailing list some time
>> ago and I tried all possibilities but I could not fix it.
>>
>> In one of the link you advised :
>>
>> "The attached hmsec.F for lapwso contains the old and new Scalapack
>> routines.
>>
>> Add -Dold_scalapack to the parallel compiler options.
>>
>> Please note: There are cases, where the old Scalapack diagonalization
>> fails."
>>
>>
>>
>>
>>
>> hmsec.o: In function `hmsec_':
>> hmsec.F:(.text+0x3057): undefined reference to `pzheevr_'
>> hmsec.F:(.text+0x37b0): undefined reference to `pzheevr_'
>>
>>
>> Its Intel Xeon Phi coprocessors based cluster and mkl is
>> composer_xe_2013.1.117 with mpiifort and miicc
>>
>>
>> Could you please tell me how to overcome below issue?
>>
>> Kind regards
>> Bhamu
>>
>
> ___
> Wien mailing list
> Wien@zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
> SEARCH the MAILING-LIST at:  http://www.mail-archive.com/
> wien@zeus.theochem.tuwien.ac.at/index.html
>
>
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] LAPW2: semicore band-ranges too large

[Luis Ogando]

Dear Prof. Blaha,

   Thank you again !
   I have 3 k-points and each k-point gives rise to an MPI calculation with
9 processors. I believe that LAPW1 results are written in case.scf1_1,
case.scf1_2 and case.scf1_3 for each k-point and after each iteration,
these files are added to case.scf and "cleaned".
   For some reason, only the Gamma point results are present in case.scf.
Anyway, I could notice that  the lowest Gamma eigenvalues have an abrupt
change in the last iteration what probably caused the calculation
interruption (iqtlsave=1).
   I will increase the effective RKmax to 3.0, following your
recommendation and hoping that this can solve the problem.
   Thank you for your help.
   All the best,
   Luis


2017-09-28 9:42 GMT-03:00 Peter Blaha :

> For sure the effective RKmax=2.37 is too small.
>
> You will have to go mpi-parallel.
>
> Otherwise, check your eigenvalues at the different k-points.
>
> With only C,N,H you can identify each eigenvalue and of course the low
> lying eigenvalues should change very little for different k-points ...
>
> On 09/27/2017 08:18 PM, Luis Ogando wrote:
>
>> Dear Prof. Blaha,
>>
>>Thank you very much for your help !
>>Do not worry ! I removed only the l=0 lo orbitals for C. The   "
>> 0   -0.70  0.002 CONT 1   " lines were preserved.
>>Yes, I used RKmax=3.0 , but it was reduced to  RKM= 2.37  due to
>> NMATMAX. Do you believe that this can be related to the "effective"
>> RKmax value ? I can increase NMATMAX, recompile LAPW1 and try again, but
>> I would like your opinion before starting such a time consuming
>> calculation.
>>During optimization, when Gamma was the only k-point, I tested the
>> basis size through an SCF cycle (MSR1) with an intermediary structure
>> *and iqtlsave = 1.* In that case, the effective RKmax was 2.38 and the
>> calculation converged without a problem, but the RMT's were smaller than
>> now (0.98 (C), 1.18 (N) and 0.64 (H)).
>>Is there any other parameter that you would like to know ?
>>Thank you again.
>>All the best,
>>  Luis
>>
>> 2017-09-27 1:49 GMT-03:00 Peter Blaha > >:
>>
>>
>> As I said, iqtlsave should ONLY be used in very special cases (high
>> pressure). It usually is a hint for ghostbands and one should not
>> switch it of.
>>
>> I don't think the problems come from a not optimized structure,
>> except when the positions would be extremely wrong.
>>
>> The RMTs are probably ok.
>>
>> When I say, you should remove the lo for C, l=0, I meant to remove
>> the line with l=0 and 0.30 as energy parameter, but keep the line
>> with -0.7xx.
>>
>> PS: I hope you reduced RKMax to 3 (or for the beginning to save time
>> during crude position optimization even 2.75)
>>
>> Am 26.09.2017 um 19:31 schrieb Luis Ogando:
>>
>> Dear Prof. Blaha,
>>
>> Thank you very much for your response !
>> The molecule has 100 atoms and the only symmetry operation
>> is identity. You can imagine the computation time required for
>> optimization. I turned "iqtlsave" off during optimization in
>> order to avoid interruption due to fortuitous atom displacement.
>> Anyway, after getting the relaxed structure, I turned it on
>> again (and got the problem).
>> The RMT's I am using are 1.25 (C), 1.24 (N) and 0.67 (H).
>> These values were suggested by init_lapw.
>> As you previewed, l=0 local orbitals for C are problematic
>> and I removed them during optimization. I also removed the l=0
>> local orbitals for N and kept the same basis set for the next
>> calculations, with the optimized structure.
>> I believe that it is important to say that I got the error
>> message on the SCF cycle number 25 after energy convergence on
>> cycle 23 (-ec 0.0001 -cc 0.0001). During optimization I used
>> "-ec 0.001 -cc 0.001 -fc 1.0"  . Do you believe that the problem
>> can be related to a "non" fully relaxed structure ?
>> Thank you again !
>> All the best,
>>  Luis
>>
>>
>> 2017-09-25 16:57 GMT-03:00 Peter Blaha
>> > 
>> >
>> >>:
>>
>> Yes, worry !!
>>
>> Why did you change iqtlsave in the first place ? It is not
>> sace and
>> ment only for special cases like very large pressure.
>>
>> I guess you had spurious ghost bands and most likely the
>> problems
>> come form the small C sphere and the l=0 LO on Carbon.
>> Remove the C l=0 local orbital.
>>
>>
>> Am 25.09.2017 um 20:56 schrieb Luis Ogando:
>>
>> Dear Wien2k community,
>>
>> 

Re: [Wien] hmsec.F:(.text+0x3057): undefined reference to `pzheevr_'

[Gavin Abo]

I'm able to reproduce your new compile.msg errors below from hmsec.F in 
WIEN2k 17.1 with the -Dold_scalapack switch.


This seems to be because the & (continue line feed) symbol is missing on 
line 723 and 756. There also might be too many spaces in line 724.


Try placing that attached patch file (hmsec.patch) into the SRC_lapwso 
directory of WIEN2k 17.1, then while in that directory in a terminal run:


patch -b hmsec.F hmsec.patch

Then, do a recompile in siteconfig, it should remove those errors.

Note: I get some other errors (from 'parallel_mp_init_parallel_') after 
those, but hopefully it is just on my system only as my blacs for 
parallel is apparently not currently setup correctly.


SRC_lapwso/compile.msg:
...
mpiifort -O1 -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML 
-Dold_scalapack -traceback -assume buffered_io 
-I/opt/intel/composer_xe_2013.1.117/mkl/include -DParallel -c hmsec.F
hmsec.F(723): error #5082: Syntax error, found END-OF-STATEMENT when 
expecting one of: ( * ) :: ,   
  ...

   abstol,neig,pNZ_vec,en,porfac,vec,1,1,DESC_vec,
--^
hmsec.F(724): error #5276: Unbalanced parentheses
   pWORK1,ipLWORK, pRWORK1, ipLRWORK,pIWORK1,ipLIWORK, 
pIFAIL,pICLUSTR,pGAP,INFO)

---^
hmsec.F(756): error #5082: Syntax error, found END-OF-STATEMENT when 
expecting one of: ( * ) :: ,   
  ...

 abstol,neig,pNZ_vec,en,porfac,vec,1,1,DESC_vec,
^
hmsec.F(757): error #5276: Unbalanced parentheses
pWORK,pLWORK,pRWORK,pLRWORK,pIWORK,pLIWORK,pIFAIL,pICLUSTR,pGAP,INFO)
-^
...

On 9/29/2017 4:29 AM, Dr. K. C. Bhamu wrote:

Dear Gavin

Thanks for you detailed advice. Unfortunetly is could not solve the issue,

What I did is I added  "-pthread" to linker's option and I do not see 
any warning/error message.

Hope it should be fine.


regards
Bhamu
723,724c723,724
abstol,neig,pNZ_vec,en,porfac,vec,1,1,DESC_vec, &
>pWORK1,ipLWORK, pRWORK1, 
> ipLRWORK,pIWORK1,ipLIWORK,pIFAIL,pICLUSTR,pGAP,INFO)
756c756
<  abstol,neig,pNZ_vec,en,porfac,vec,1,1,DESC_vec,
---
>  abstol,neig,pNZ_vec,en,porfac,vec,1,1,DESC_vec, &
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

[Wien] DOS

[delamora]

I calculated ZnO in the Zinc blende structure
FCC
A=B=C=4.6A
Zn: 0,0,0
O: 1/4,1/4,1/4
And when I am calculating DOS I get a plot that stops at 3eV which is in the gap
In case.in1c I increased the bottom numbers:
"de" 1.5 => 15.5
"nband" 20 => 30
and I do not see any improvement in the DOS plot

Pablo

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] DOS

[Yundi Quan]

Hi,

You might want to increase the emax in case.int file.

Hope this helps.




On Fri, Sep 29, 2017 at 10:34 PM, delamora  wrote:

> I calculated ZnO in the Zinc blende structure
> FCC
> A=B=C=4.6A
> Zn: 0,0,0
> O: 1/4,1/4,1/4
> And when I am calculating DOS I get a plot that stops at 3eV which is in
> the gap
> In case.in1c I increased the bottom numbers:
> "de" 1.5 => 15.5
> "nband" 20 => 30
> and I do not see any improvement in the DOS plot
>
> Pablo
>
>
> ___
> Wien mailing list
> Wien@zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
> SEARCH the MAILING-LIST at:  http://www.mail-archive.com/
> wien@zeus.theochem.tuwien.ac.at/index.html
>
>
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html