vasp 5.2.12

Questions regarding the compilation of VASP on various platforms: hardware, compilers and libraries, etc.


Moderators: Global Moderator, Moderator

Post Reply
Message
Author
imcnab
Newbie
Newbie
Posts: 22
Joined: Thu Jul 08, 2010 10:49 pm
License Nr.: 5-531
Location: Toronto, Canada

vasp 5.2.12

#1 Post by imcnab » Tue Jul 26, 2011 7:25 pm

All help and comments most gratefully received.

I tried to build vasp 5.2.12 using the supplied make file for ibmxl fortran "makefile.ibm_hlrn"
I am working on "SciNet" TCS:
OS = AIX 5.3
IBM POWER6 nodes

I am using the version of the IBM fortran compiler, xlf which was tested in the makefile:
IBM XL Fortran for AIX, V12.1
Version: 12.01.0000.0009

The module "vdw_nl.f" will not compile.

There appears to be a problem with the way that the subroutine SPLINE is called - the compiler reports (using -qsource option):
###########################################
271 | call SPLINE(dk,phik(:,alf,bet),Nr+1,0._q,0._q,d2phik_work)
.....................a.............................................
a - "vdw_nl.f", line 271.21: 1513-061 (S) Actual argument attributes do not match those specified by an accessible explicit interface.
633 | call SPLINE(dint1, dinb, nintg, 0._q, 0._q, ders)
...................a....................................
a - "vdw_nl.f", line 633.19: 1513-061 (S) Actual argument attributes do not match those specified by an accessible explicit interface.
636 | call SPLINE(dint1, dina, nintg, 0._q, 0._q, ders)
.................a....................................
a - "vdw_nl.f", line 636.17: 1513-061 (S) Actual argument attributes do not match those specified by an accessible explicit interface.
846 | REAL(q) :: yp1,ypn,x(n),y(n),y2(n),dx
............a.................................
a - "vdw_nl.f", line 846.12: 1516-050 (S) Expression or initial value must be evaluated at compile time.
848 | REAL(q) :: p,q,sig,un,u(n)
............a.....................
a - "vdw_nl.f", line 848.12: 1516-050 (S) Expression or initial value must be evaluated at compile time.
** vdw_ll === End of Compilation 1 ===
** vdw_calc === End of Compilation 2 ===
** vdw_calc_spin === End of Compilation 3 ===
1501-511 Compilation failed for file vdw_nl.f.
############################################

This appears to be a section of code that is new since 5.2.11 - all help would be most gratefully received.

best regards... Iain McNab
Last edited by imcnab on Tue Jul 26, 2011 7:25 pm, edited 1 time in total.

alex
Hero Member
Hero Member
Posts: 583
Joined: Tue Nov 16, 2004 2:21 pm
License Nr.: 5-67
Location: Germany

vasp 5.2.12

#2 Post by alex » Wed Jul 27, 2011 12:12 pm

Hi Iain,

check if 'kind' is set properly (both in call and subroutine). Or ask the author of the makefile. He should be still out there.

Cheers,

alex
Last edited by alex on Wed Jul 27, 2011 12:12 pm, edited 1 time in total.

kelum
Newbie
Newbie
Posts: 42
Joined: Wed Jul 27, 2011 12:22 pm
Location: Vienna

vasp 5.2.12

#3 Post by kelum » Wed Jul 27, 2011 1:24 pm

Hi,
What happens is that the preprocessor in the SPLINE routine changes the name of one of the variables ("qn") to "q" for some reason which is also the kind, this causes the problems. As a workaround you can change the name of "qn" to something else in the routine (in header and 4 times in the body).
That should hopefully fix the problem.
I've checked that the results won't change when ifort is used.
Best,
j
Last edited by kelum on Wed Jul 27, 2011 1:24 pm, edited 1 time in total.

imcnab
Newbie
Newbie
Posts: 22
Joined: Thu Jul 08, 2010 10:49 pm
License Nr.: 5-531
Location: Toronto, Canada

vasp 5.2.12

#4 Post by imcnab » Wed Jul 27, 2011 10:14 pm

Dear Both,
Thanks for your help.
J, I renamed qn to qnwa (work around) as you suggested, and it compiled straight away.
You are an absolute STAR, thank you again.
Alex, as J's work around worked, I didn't check the kind statements, but my guess is you are also correct. There don't appear to be any kind statements for this subroutine.
Thanks again...
best.. Iain :)
Last edited by imcnab on Wed Jul 27, 2011 10:14 pm, edited 1 time in total.

kelum
Newbie
Newbie
Posts: 42
Joined: Wed Jul 27, 2011 12:22 pm
Location: Vienna

vasp 5.2.12

#5 Post by kelum » Wed Aug 03, 2011 2:10 pm

Hi,
I looked a bit more into it and it's basically two things:
First the preprocessor changes "qn" to "q" so that it collides with the name of the kind.
Unlike other compilers, your compiler doesn't like it but if "qn" is changed to something else it works since the names differ.
Second, the situation then corresponds to this code:

Code: Select all

!declare?q?as?integer?parameter?corresponding?to?double?precision
MODULE?prec
??INTEGER,?PARAMETER::?q?=SELECTED_REAL_KIND(10)
END?MODULE

!declare?a?subroutine?in?a?different?module?that?uses?the?prec?module
MODULE?routine
??USE?prec

??CONTAINS
????SUBROUTINE?rout
!??????USE?prec
??????real(q)?::?q
??????q?=?1.635465464654d0
??????print?*,?q,?1.635465464654d0
????END?SUBROUTINE
END?MODULE

!call?the?subroutine?from?the?main?programme
PROGRAM?test
??USE?routine
????CALL?rout
END?PROGRAM
the thing is that the ifort, pgi, and gfortran will happily compile this code while your IBM compiler (I guess) won't. Both ifort and pgi compile it also when the "USE?prec" is uncommented in the module subroutine, they only complain when the first "USE prec" is not present and the second one is.
Of course if you don't redeclare "q" you can use it inside the subroutine as constant integer equal to 8 as you'd expect.
To me allowing

Code: Select all

real(q)?::?q
looks like a compiler bug or very odd settings but if anyone has an explanation, it'd be very welcome.

The important thing is that the results are exactly the same, either if q is allowed as a local variable (and the compiler compiles the code) or if a different name is used for the variable.
Last edited by kelum on Wed Aug 03, 2011 2:10 pm, edited 1 time in total.

Post Reply