Re: fortran95 error
- From: ron <jelaimartra73@xxxxxxxxx>
- Date: Mon, 03 Sep 2007 08:57:04 -0700
On Sep 3, 4:08 pm, "Dr Ivan D. Reid" <Ivan.R...@xxxxxxxxxxxx> wrote:
On Fri, 31 Aug 2007 17:28:01 +0000 (UTC), Dr Ivan D. Reid
<Ivan.R...@xxxxxxxxxxxx>
wrote in <slrnfdgjt0.65f.Ivan.R...@xxxxxxxxxxxxxxxxx>:
On Fri, 31 Aug 2007 10:01:26 -0700, ron <jelaimartr...@xxxxxxxxx>
wrote in <1188579686.746611.95...@xxxxxxxxxxxxxxxxxxxxxxxxxxx>:
I would like to seek your opinion on my program error that I stuckYou should tell us details of operating system and compiler version
right now.The
error is " attempt to call a subroutine as if it were a real (kind=1)
function"
and I dont really understand what it means since I just started to
learn it.Can
you advice me on this matter..
for best help. At a guess you are using a subroutine like:
x = subrt (y,z)
instead of
call subrt(y,z)
or perhaps you've mislabelled a function
subroutine funct(a,b)
when you meant
real function funct(a,b)
The OP sent me his programme, and while it had a number of mismatched
declarations I saw nothing that should have given the above error. He reports
back that his version now gives the results I obtained. I hope he has also
heeded my advice to use IMPLICIT NONE -- the programme was really F66 or early
F77 style, so no F95 issues at all. For the group's information, I append
my analysis of his problems:
-----------------------------------------
OK, your code has no special F95 features so I compiled it with G77
since I discovered I don't have F95 on my laptop... This meant I had to
change the 4-space line introductions in MAIN to 6 spaces.
I got these errors:
===
dipole_mom_my.f: In program `MAIN__':
dipole_mom_my.f:4: warning:
COMMON UUZM,B,A2,J,CC,AMM,DZ,DZ1,B1
^
Padding of 4 bytes required before `llp' in common block `_BLNK__' at (^) -- consider reordering members, largest-type-size first
dipole_mom_my.f: In function `funk':
dipole_mom_my.f:97: warning:
COMMON UUZM,B,A2,J,CC,AMM,DZ,DZ1,B1
^
Padding of 4 bytes required before `llp' in common block `_BLNK__' at (^) -- consider reordering members, largest-type-size first
=====
The compilers like to align things on "natural" boundaries, 4-byte
items at multiples of 4 bytes, 8-byte items at multiples of 8 bytes, etc.
For efficiency you should put, e.g. all 16-byte items before 8-byte items
before 4-byte items, etc. Strings should in general be at the end of COMMONs
or better yet in a separate COMMON of their own. You may not realise it,
but not naming your commons puts everything into the same "blank" common
block, so the COMMON statements behave as a continuation of the other.
COMMON UUZM,B,A2,J,CC,AMM,DZ,DZ1,B1
COMMON L,UL,LLP,XUL,ZM,UZM,I,II,D,ZO
There's another problem here -- you define the COMMON in three places,
but there are only two complaints! A check shows that this is because
in the two places where there is a complaint, L and LLP are defined
as REAL*8 but where there is no complaint, they are explicitly called REAL.
This means that all the items in your second COMMON line will be picked up
as different sizes and/or from different locations in the different
routines, giving garbage results.
===
dipole_mom_my.f: In subroutine `polint':
dipole_mom_my.f:116: warning:
CALL POLINT(H(J-KM),S(J-KM),K,0.0,SS,DSS)
1
dipole_mom_my.f:126: (continued):
SUBROUTINE POLINT(XA,YA,N,X,Y,DY)
2
Argument #1 (named `xa') of `polint' is one precision at (2) but is some other precision at (1) [info -f g77 M GLOBALS]
dipole_mom_my.f:116: warning:
CALL POLINT(H(J-KM),S(J-KM),K,0.0,SS,DSS)
1
dipole_mom_my.f:126: (continued):
SUBROUTINE POLINT(XA,YA,N,X,Y,DY)
2
Argument #2 (named `ya') of `polint' is one precision at (2) but is some other precision at (1) [info -f g77 M GLOBALS]
dipole_mom_my.f:116: warning:
CALL POLINT(H(J-KM),S(J-KM),K,0.0,SS,DSS)
1
dipole_mom_my.f:126: (continued):
SUBROUTINE POLINT(XA,YA,N,X,Y,DY)
2
Argument #4 (named `x') of `polint' is one precision at (2) but is some other precision at (1) [info -f g77 M GLOBALS]
dipole_mom_my.f:116: warning:
CALL POLINT(H(J-KM),S(J-KM),K,0.0,SS,DSS)
1
dipole_mom_my.f:126: (continued):
SUBROUTINE POLINT(XA,YA,N,X,Y,DY)
2
Argument #5 (named `y') of `polint' is one precision at (2) but is some other precision at (1) [info -f g77 M GLOBALS]
dipole_mom_my.f:116: warning:
CALL POLINT(H(J-KM),S(J-KM),K,0.0,SS,DSS)
1
dipole_mom_my.f:126: (continued):
SUBROUTINE POLINT(XA,YA,N,X,Y,DY)
2
Argument #6 (named `dy') of `polint' is one precision at (2) but is some other precision at (1) [info -f g77 M GLOBALS]
====
These warnings mean that you have conflicting definitions of those
5 arguments between the definition of the subroutine and where you called it.
e.g. in line 116 you have CALL POLINT(H(J-KM),S(J-KM),K,0.0,SS,DSS) where
and S are declared as arrays, SS has been passed into the subroutine and not
declared and DSS has not been declared. This means, by Fortrans implicit
naming rules, they are all default (single precision) reals. As well, 0.0
is a single-precision constant. However, in the subroutine POLINT you have
IMPLICIT REAL*8(A-H,O-Z) so that everything there is double precision,
including the function parameters.
===
dipole_mom_my.f: In subroutine `midpnt':
dipole_mom_my.f:93:
DOUBLE PRECISION FUNCTION FUNk(Z)
1
dipole_mom_my.f:167: (continued):
S=(B-A)*FUNK(0.5*(A+B))
2
Global name `funk' at (2) has different type at (1) [info -f g77 M GLOBALS]
===
Again, here you haven't declared FUNK so it takes the default
single-precision -- it should be declared REAL*8 and preferably EXTERNAL as
well.
So, what to do:
a) Put an IMPLICIT NONE statement at the start of _every_ routine, and make
an explicit declaration for all your variables, including the subroutine.
In the subroutines, explicitly declare the types of the parameters, then
remove all IMPLICIT declarations.
b) To make this easier, make a separate file, say COMMONS.INC and include
it everywhere the commons are needed. In the file, expicitly declare the
types of all the variables, and then in the COMMON statements order the
variables from largest to smallest.
e.g.:
real a2,amm,b,b1,cc,dz,dz1,uuzm
real d,ul,uzm,xul,zm
integer i,ii
complex j,zo
real*8 l,llp
common l,llp,j,zo
commona2,amm,b,b1,cc,dz,dz1,uuzm
common d,ul,uzm,xul,zm
common i,ii
Doing that, and cleaning up the type mismatches (by always promoting
the real to real*4), but not yet using IMPLICIT NONE, it compiles for me and
gives the output:
(-0.0870889202,860.523926) 1 1
(-0.0870509371,-184.406097) 1 2
(-0.0869379491,-170.381363) 1 3
Still, nothing I've done has impinged upon your originally reported error
message -- the compiler may have become confused by the other errors. Try
these fixes and see what happens.
ivan
--
Ivan Reid, School of Engineering & Design, _____________ CMS Collaboration,
Brunel University. Ivan.Reid@[brunel.ac.uk|cern.ch] Room 40-1-B12, CERN
KotPT -- "for stupidity above and beyond the call of duty".- Hide quoted text -
- Show quoted text -
Many thanks to Dr Ivan for his expertise,I manage to simulate my code
and get the result exactly the same as his.
(as per show indetails above)
ron
.
- References:
- Re: fortran95 error
- From: Dr Ivan D. Reid
- Re: fortran95 error
- Prev by Date: Re: T566
- Next by Date: pass array to subroutine
- Previous by thread: Re: fortran95 error
- Next by thread: pointers to arrays with sub references
- Index(es):
Relevant Pages
|
