Fortran - KIND error?

Author

KIND error?

student

2005-06-05, 3:57 pm

while trying to compile the following source using a g95 compiler:

----------------
PROGRAM test
IMPLICIT NONE
INTEGER, PARAMETER :: real_kind = SELECTED_REAL_KIND(p=20,r=50)
REAL(KIND = real_kind), DIMENSION(33,1) :: thetasubX ,thetasubepsilon

WRITE(*,*) real_kind
end PROGRAM test
-----------------

I get the following error:
---------------------
g95 test.f90
In file test.f90:4

REAL(KIND = real_kind), DIMENSION(33,1) :: thetasubX ,thetasubepsilon
1
Error: Kind -1 not supported for type REAL at (1)
--------------------------------

Can anyone explain what this is and how this could be fixed?

Tim Prince

2005-06-05, 8:57 pm

"student" <adarsh@stat.tamu.edu> wrote in message
news:1117994540.305011.64700@g44g2000cwa.googlegroups.com...
>
> while trying to compile the following source using a g95 compiler:
>
> ----------------
> PROGRAM test
> IMPLICIT NONE
> INTEGER, PARAMETER :: real_kind = SELECTED_REAL_KIND(p=20,r=50)
> REAL(KIND = real_kind), DIMENSION(33,1) :: thetasubX ,thetasubepsilon
>
> WRITE(*,*) real_kind
> end PROGRAM test
> -----------------
>
>
> I get the following error:
> ---------------------
> g95 test.f90
> In file test.f90:4
>
> REAL(KIND = real_kind), DIMENSION(33,1) :: thetasubX ,thetasubepsilon
> 1
> Error: Kind -1 not supported for type REAL at (1)
> --------------------------------
>
> Can anyone explain what this is and how this could be fixed?
>
Presumably, selected_kind..() returns -1 when the precision you specified is
not supported. 15 is the highest commonly supported precision.

student

2005-06-05, 8:57 pm

Thanks for the reply Tim! Also, do all intrinsic functions defined for
reals support all types of reals that are being supported by the
compiler? If not, then is there any way we can avoid problems because
of this?

James Van Buskirk

2005-06-05, 8:57 pm

"student" <adarsh@stat.tamu.edu> wrote in message
news:1118004475.574817.112530@o13g2000cwo.googlegroups.com...

> Thanks for the reply Tim! Also, do all intrinsic functions defined for
> reals support all types of reals that are being supported by the
> compiler? If not, then is there any way we can avoid problems because
> of this?

Yes, but...
There are a couple of limitations:
1) There may be generic functions with no specific name, so
you can't use them as actual arguments to procedures.
2) The function CMPLX returns default complex values, even
if both inputs are double precision. For F90 code this
intrinsic should, IMO, always be supplied the optional
KIND argument as a named constant.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

John Harper

2005-06-06, 8:57 pm

In article <wEHoe.84$bv7.48@newssvr21.news.prodigy.com>,
Tim Prince <tprince@nospamcomputer.org> wrote:[color=darkred]
>
>"student" <adarsh@stat.tamu.edu> wrote in message

As Tim said, kind < 0 is the standard indication that the desired type
is not supported. For real types, it's -1 if the requested precision
isn't supported, -2 if the requested exponent range isn't, and -3 if
neither is. I use and recommend things like

INTEGER,PARAMETER:: &
DP=kind(1.d0), QP=max(DP,selected_real_kind(precision(1
.d0)*2))

so QP is quadruple precision if available, double if not. You can check
your own compiler(s) by printing precision(1._DP) and precision(1._QP).

John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045

James Van Buskirk

2005-06-07, 3:57 am

"John Harper" <harper@mcs.vuw.ac.nz> wrote in message
news:1118097396.48806@bats.mcs.vuw.ac.nz...

> INTEGER,PARAMETER:: &
> DP=kind(1.d0), QP=max(DP,selected_real_kind(precision(1
.d0)*2))

> so QP is quadruple precision if available, double if not. You can check
> your own compiler(s) by printing precision(1._DP) and precision(1._QP).

Yeah, but a couple of problems may arise:
1) The kind type parameter for quadruple precision may be
less than that for double precision, and
2) There may be an available real kind whose precision, while
greater than double precision, is less than twice as big.

I avoid problem 1) above with declarations such as may be found
in module mykinds in http://home.comcast.net/~kmbtib/conv2b.f90
(which also puts a lie to the assumption made by a non-programmer
in another thread that Fortran programmers never use any data
structures other than arrays because the above example uses
AVL trees to ride herd on the constants it is going to place in
the next generation of code.)

In practice, problem 2) above is more likely to be encountered:
looking at http://www.polyhedron.com/ I see that Salford FTN95
and N. A. Software's compiler will exhibit this problem. I
didn't put a failover for this case in my example because FTN95
didn't seem particularly close to being able to compile my code
in any case.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

Sponsored Links