Problem getting IMSL 5.0 to work with Visual Studio 2003

ssiddarth · ‎07-24-2010

I purchased this software a while ago but didn't try and seriously use it until now.

I followed the instructions to add the correct directories to the INCLUDE and LIB options.

I tried running the program imslmp.f90 included in tha validate sub-directory of the VNI IMSL directories

The program opens with these lines.

Use files

use rand_gen_int

use show_int

I added the INCLUDE 'link_f90_static.h' in the beginning of the program. However, when I tried to run the program I got the following errors

Error 1 Error: Error in opening the Library module file. [FILES] C:\\Program Files\\VNI\\CTT6.0\\examples\\IA32\\f90\\validate\\imslmp.f90

I also tried a different program and found that it did not recognize simplefunction like DLOG

Any suggestions on how I can get it to work would be greatly appreciated.

Thanks,

Siddarth

mecej4 · ‎07-25-2010

I think that

Use files

should be

!Use files

At least, in the corresponding example source file from IMSL FNL 6, that's what I see.

ssiddarth · ‎07-25-2010

Thanks for replying to my post.

I am using the IDE environment and I find an exclamation mark makes the rest of the line a comment. Maybe I need to first update my version of Visual Fortran?

ssiddarth · ‎07-25-2010

You were right! That was a comment line and it worked fine.

Now if I can only get my own program to work as well.

Thanks!

ssiddarth · ‎07-25-2010

Ok, now I tried to run my own program and here are the errrors that I got

As you can, several of the standard random number generator functions don't seem to be recognized by the compiler. The D_NORIN was my attempt at trying to make a change in the function to see if it worked.

The actual command that uses DRNNOF is

Z=CVAR(ID,J)*DRNNOF()

I was surprised to see that the DLOG function didn't work.

Any ideas on how to fix the problem?

Thanks,

Siddarth
----------------------------------------------------------

Error 1 Error: This name does not have a type, and must have an explicit type. [D_NORIN] C:\Allwork\PROJECTS\SML\FORTRAN\PROGRAMS\treesnew.f90 203

Error 2 Error: This name does not have a type, and must have an explicit type. [DRNNOF] C:\Allwork\PROJECTS\SML\FORTRAN\PROGRAMS\treesnew.f90 290

Error 3 Error: This name does not have a type, and must have an explicit type. [DRNNOF] C:\Allwork\PROJECTS\SML\FORTRAN\PROGRAMS\treesnew.f90 418

Error 4 Error: This name does not have a type, and must have an explicit type. [DRNUNF] C:\Allwork\PROJECTS\SML\FORTRAN\PROGRAMS\treesnew.f90 455

Error 6 Error: This name does not have a type, and must have an explicit type. [DLOG] C:\Allwork\PROJECTS\SML\FORTRAN\PROGRAMS\treesnew.f90 455

Steven_L_Intel1 · ‎07-25-2010

Without seeing the source, it's hard to know for sure. I will say that you should use the generic names and not the specific names such as D_NORIN and DRNUNF. You do need to add USE xxx_INT lines for the routines you are using.

I too am surprised by the DLOG and would like to see the whole source.

mecej4 · ‎07-25-2010

That statement betrays a misunderstanding of the role of the IDE. What the IDE does, among other things, is to display different elements of the source code in different colors/fonts/styles to make it easy for the reader to distinguish these elements visually. The compiler sees the same source code as the IDE, but the ASCII character set you probably used has no idea of color. Therefore:

A comment line is a comment line is a comment line ...

For a given source code, the way the compiler treats it is independent of the IDE (apart from compiler options and switches, which can be passed to the compiler either by the IDE or a command line). Many people choose not to use any IDE at all.

There are reasons to update your compiler, but the one you stated is not valid.

ssiddarth · ‎07-25-2010

Iincludedthe functions that were giving me a problem in my other program in the sample program from VNI

Strange thing is that it works fine, even though I didn't have any extra USE commands. Here's the program that worked.

I will work on the other program some more and see if it works and then post it here, if it does not.

---------------------------------------------------------------------------------

INCLUDE 'link_f90_static.h'

!Use files

use rand_gen_int

use show_int

! Declarations

real (kind(1.e0)), parameter:: zero=0.e0

real (kind(1.e0)) x(5)

REAL*8 Z

type (s_options) :: iopti(2)=s_options(0,zero)

character VERSION*48, LICENSE*48, VERML*48

external VERML, E1CHK, ERSET, N1RNOF

integer n1rnof

! Start the random number generator with a known seed.

iopti(1) = s_options(s_rand_gen_generator_seed,zero)

iopti(2) = s_options(123,zero)

call rand_gen(x, iopt=iopti)

! Verify the version of the library we are running

! by retrieving the version number via verml().

! Verify correct installation of the license number

! by retrieving the customer number via verml().

!

VERSION = VERML(1)

LICENSE = VERML(4)

WRITE(*,*) 'Library version: ', VERSION

WRITE(*,*) 'Customer number: ', LICENSE

! Get the random numbers

call rand_gen(x)

! Output the random numbers

call show(x,text=' X')

! Generate error

call erset(5, 0, 0)

call e1chk (-1234.0D0)

iopti(1) = s_options(15,zero)

call rand_gen(x, iopt=iopti)

call e1chk(296323.0d0)

write(*,*)

if (n1rnof(2) .eq. 0) then

write(*,*) "The output is correct."

else

write(*,*) "The output is not correct."

endif

do i=1,100

Z=ABS(DRNNOF())

Y=5*DRNUNF()

write(6,*) 'ZLOGZ',z, DLOG(Z)

write(6,*) 'NORIN', DNORIN(0.225D0),'UNI',Y

enddo

end

ssiddarth · ‎07-25-2010

You are right! As i said before, I did put the ! before the USE command and it worked. It was supposed to be a comment...I'm not sure how I missed that.

Thanks!

Siddarth

mecej4 · ‎07-25-2010

1. You stated: "As you can, several of the standard random number generator functions don't seem to be recognized by the compiler."

What do you mean by "standard"? The functions D_NORIN and DRNNOF that you allude to are not in any Fortran standard. If you have some local, company developed standards, we don't know about them, neither does the compiler. Any functions and subroutines that are not INTRINSIC need to be provided by you or by a third-party library, and used consistently with their definitions.

2. "I was surprised to see that the DLOG function didn't work."

The ALOG, DLOG, LOG functions have been part of Fortran for decades and they have been used in millions of programs. So, instead of making mere claims, show us an example of how they "didn't work".

We might wonder if you expect too much from a mere trancendental function. Given a double-precision argument within certain limits, DLOG will compute the logarithm of the argument. It does not, by itself, predict the weather or make music. So, what do you mean by DLOG not working? In what way did it not work?

3. "Any ideas on how to fix the problem?"

Certainly. Describe the problem logically. Show us a small working example code which we can compile, run, etc. to see if we can reproduce the problem that you describe. Don't assume that we know what you have tried and what your code contains without your having shown us. Don't advance your diagnosis before giving a description of the problem.

ssiddarth · ‎07-26-2010

Steve,

I tried including the interface names in the other program as you suggested butthat didn't help. Ialsoincluded it in the VNI sample program (which I had posted earlier) by including it thus.

INCLUDE 'link_f90_static.h'

!Use files

use rand_gen_int

use show_int

use D_RNNOF_INT

I got the error Error 1 Error: Error in opening the Library module file. [D_RNNOF_INT] C:\Program Files\VNI\CTT6.0\examples\IA32\f90\validate\imslmp.f90 7

In fact when I remove the line "use D_RNNOF_INT" this program runs okay.

Any thoughts?

Regards,

Siddarth

Steven_L_Intel1 · ‎07-26-2010

Siddarth,

Please read the IMSL documentation for the routines you use. The module name is RNNOF_INT, not D_RNNOF_INT. The module is named after the generic name, and the generic name is the only one you should reference in the function call.

ssiddarth · ‎07-27-2010

Steve,

The reason I had it that way was because the IMSL documentation (for my version) showed the F90 interface as follows.

FORTRAN 90 Interface

Generic: RNNOF ()

Specific: The specific interface names are S_RNNOF and D_RNNOF

The documentation also mentioned that one could use the specific name to avoid the restriction of not directly using the result in an expression (see below)

Comments

1. If the generic version of this function is used, the immediate result must be stored in a

variable before use in an expression. For example:

X = RNNOF()

Y = SQRT(X)

must be used rather than

Y = SQRT(RNNOF())

If this is too much of a restriction on the programmer, then the specific name can be

used without this restriction.

Therefore I thought D_RNNOF_INT should work fine.

Here's a subroutine that I am using. I tried using the generic name for the module, but I still get the following compiler error.

Error 1 Error: This name does not have a type, and must have an explicit type. [DRNNOF] C:\Allwork\PROJECTS\SML\FORTRAN\PROGRAMS\treesnew.f90 289

However, if I don't use the double precision versions (change Z=DRNNOF() to Z=RNNOF() the compiler works fine.

Any ideas on how to fix this problem?

I also tried to run the compiled programbut got a severe error......the window shut down immediately

Regards,

Siddarth

SUBROUTINE DRAWMU(MUK,TAUK,THETA)

! Modules

USE SETTINGS

USE PRIORS

!use D_RNNOF_int

USE RNNOF_INT

IMPLICIT NONE

REAL*8, INTENT(OUT) :: MUK(NP)

REAL*8, INTENT(IN) :: THETA(NTREES,NP),TAUK(NP)

REAL*8 :: POSTMEAN,POSTTAU,POSTSIGMA,SUMTHETA,Z

INTEGER :: I,ID

DO I=1,NP

SUMTHETA=0.0D0

DO ID=1,NTREES

SUMTHETA=SUMTHETA+THETA(ID,I)

ENDDO

POSTMEAN=(ETA(I)*CINV(I)+SUMTHETA*TAUK(I))/(CINV(I)+NTREES*TAUK(I))

POSTTAU= CINV(I)+TAUK(I)*NTREES

POSTSIGMA=1.0D0/DSQRT(POSTTAU)

Z=DRNNOF()

MUK(I)=POSTMEAN+POSTSIGMA*Z

ENDDO

END SUBROUTINE DRAWMU

Steven_L_Intel1 · ‎07-27-2010

You are confusing D_RNNOF with DRNNOF - they are two different routines with different interfaces (though they do the same thing.)

If you USE RNNOF_INT, call RNNOF (or D_RNNOF if you must), not DRNNOF. DRNNOF is the "Fortran 77" style routine that requires all arguments be passed in a specific order.

Again, the _INT module names are based on the generic name - here, RNNOF. There are very few cases where you would ever need to reference S_RNNOF or D_RNNOF. The text mentions passing the function name itself as an argument, not using the function result in an expression.

You have not provided a complete program so I can't help with the "shut down immediately" other than to note that if you start under the debugger and have not set a breakpoint, the program will run to completion and then exit.

ssiddarth · ‎07-27-2010

Steve,

I am a novice in using FORTRAN 90, so thanks for bearing with me. Ok, now D_RNNOF worked fine.

As for the error, I used the debugger and found that the program shut downwheneverI had theWrite (6,*) statement.The programran okaywhen I commented all of these statements out.

When I cut and paste this program into another console application, the program ran fine even with the write statements. In fact, as I mentioned before, in this, second, console application, all of the calls to DRNNOF wen through fine, even when I didn't have any of the USE *_INT comments.

In other words, all of the calls to the random numbers go throughwithout any problem.

Thanks for your help!

INCLUDE

!Use files
use rand_gen_int
use show_int
! Declarations
real (kind(1.e0)), parameter:: zero=0.e0
real (kind(1.e0)) x(5)
REAL*8 Z
type (s_options) :: iopti(2)=s_options(0,zero)
character VERSION*48, LICENSE*48, VERML*48
external VERML, E1CHK, ERSET, N1RNOF
integer n1rnof
! Start the random number generator with a known seed.
iopti(1) = s_options(s_rand_gen_generator_seed,zero)
iopti(2) = s_options(123,zero)
call rand_gen(x, iopt=iopti)
! Verify the version of the library we are running
! by retrieving the version number via verml().
! Verify correct installation of the license number
! by retrieving the customer number via verml().
!
VERSION = VERML(1)
LICENSE = VERML(4)
WRITE(*,*) 'Library version: ', VERSION
WRITE(*,*) 'Customer number: ', LICENSE
! Get the random numbers
call rand_gen(x)
! Output the random numbers
call show(x,text=' X')
! Generate error
call erset(5, 0, 0)
call e1chk (-1234.0D0)
iopti(1) = s_options(15,zero)
call rand_gen(x, iopt=iopti)
call e1chk(296323.0d0)
write(*,*)
if (n1rnof(2) .eq. 0) then
write(*,*) "The output is correct."
else
write(*,*) "The output is not correct."
endif

do i=1,100

Z=

ABS(DRNNOF())

Y=5*DRNUNF()

write(6,*) 'ZLOGZ',z, DLOG(Z)

write(6,*) 'NORIN', DNORIN(0.225D0),'UNI',Y

enddo

end

'link_f90_static.h'

Steven_L_Intel1 · ‎07-27-2010

Is there still a problem? I took the code you pasted and it builds and runs fine for me. This is the standard IMSL validation file.

ssiddarth · ‎07-27-2010

As I said this versionruns fine.

However, I don't know why, even withoutthe USE commands in there,the calls to DNNORF (and others) still go through.

Thanks

Steven_L_Intel1 · ‎07-27-2010

As I wrote above, DNNORF is a "Fortran 77" style routine and does not require a USE statement. You CAN add one, USE NUMERICAL_LIBRARIES - this will provide error checking for your arguments.

With the use of the "Fortran 90" interfaces such as D_NNORF, you may get errors as arrays are usually required to be passed as assumed-shape arrays, requiring an explicit interface.