vasp 5.2.12
Moderators: Global Moderator, Moderator
-
- Newbie
- Posts: 22
- Joined: Thu Jul 08, 2010 10:49 pm
- License Nr.: 5-531
- Location: Toronto, Canada
vasp 5.2.12
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
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.
-
- Hero Member
- Posts: 586
- Joined: Tue Nov 16, 2004 2:21 pm
- License Nr.: 5-67
- Location: Germany
vasp 5.2.12
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
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.
-
- Newbie
- Posts: 42
- Joined: Wed Jul 27, 2011 12:22 pm
- Location: Vienna
vasp 5.2.12
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
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.
-
- Newbie
- Posts: 22
- Joined: Thu Jul 08, 2010 10:49 pm
- License Nr.: 5-531
- Location: Toronto, Canada
vasp 5.2.12
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
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.
-
- Newbie
- Posts: 42
- Joined: Wed Jul 27, 2011 12:22 pm
- Location: Vienna
vasp 5.2.12
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:
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 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.
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
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
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.