Problem with Ran() function

[michael_m2]

Hello:

I am running IVF 9.0.029. I have a program that uses the ran() function andI addedsome code to theprogram that required me to also add "use ifport" at the top.

It seems as though ifport has its own version of the ran() function (although I could not find it in the documentation, I did find its interface in the ifort.f90 file). So when I added "use ifort" the compiler "secrectly" switched the function that is called by ran() to be the one in ifport. The problem with that is two-fold.

First of all, the one in ifport seems to run considerably slower than the Intel instrinsic version. Secondly, the one in ifport seems pretty useless since it doesn't update the seedargument everytime the function is called (so it returns the same random number every time -- unless I manually updated the seed between each call).

One work-around that I have found is to specify exactly whichprocedures I want to use from ifport, instead of using the whole module (making sure not to specify ran()), by using "only". But this seems clumsy, at best. Is it, perhaps, an oversight by Intel that this ran() function was included in ifport? Are there any better work-arounds or fixes?

Thanks for your help.

[Steven_L_Intel1]

Yes, the intrinsic RAN is different from the portability library RAN. It is also a different interface. For the IFPORT RAN, see the description of RANDOM in the library reference. The problem with RAN is that there have been so many variants of it over the years, none of them standardized.

My advice is to use the standard Fortran intrinsic RANDOM_NUMBER. Our implementation of this is very good.

[michael_m2]

Thanks very much for your quick reply. I did a quick test with random_number instead of ran and it looks like it worked well.

I think it would be nice to see some type of indication in the documentation that there is a ran function in ifport (that will over-ride the intrinsic if you "use ifport"). I've spent the past 3 days trying to figure out why adding "use ifport" to the top of my program caused the run time to jump from 5 minutes to 8 hours!!! (Not to mention that the results were all messed up since the same random number ended up being chosen each time.)

Just for my own knowledge I was wondering if you have any idea why the ifport ran function is so slow? Also, how is the ifport ran function intended to be used, if you have to come up with a new seed every time you call the function? Are you supposed to use the random number generated by the previous call to cook up a new seed to use for the next call?

Thanks again.

Michael

[Steven_L_Intel1]

I doubt the performance difference is due to the other routine specifically. There is probably an effect on your program of having "wrong" random numbers generated. The ifport version of RAN seems to return the same value each time. The documentation implies that it should behave much the same as the intrinsic RAN.

Either there is something I don't understand about the ifport version of RAN, or it has a bug. I'll ask that it be looked into.

[michael_m2]

That's a good point -- that the program probably runs so much slower because of the wrong random numbers being generated. However, it still seems to me that the ifport version of ran is noticeably slower than the intrinsic ran (though nowhere near the magnitude that I said in my previous post). I have created a sample program (below) to show this.

On my machine, with the "use ifport" line commented out, the program takes about 12 seconds to run. when I put the "use ifport" line back in, it slows down to about 17 seconds. That's about a 40% increase in run time.

Also, you mentioned that "The documentation (of the ifport version of ran) implies...". Can you point me to where that documentation is?

Thanks again for all your help.

Here's my sample program:

program main!use ifportimplicit noneinteger :: iinteger :: mySeed = 33333double precision :: total = 0.0d0integer, dimension(8) :: dateTimecall date_and_time(VALUES = dateTime)write(6,'(A, I2.2, A, I2.2, A, I2.2, A, I3.3)') "Starting at: ", &
dateTime(5), ":", dateTime(6), ":", dateTime(7), ".", dateTime(8)do i = 1, 1000000000
total = total + ran(mySeed)end dowrite(6, '(F30.10)') totalcall date_and_time(VALUES = dateTime)write(6,'(A, I2.2, A, I2.2, A, I2.2, A, I3.3)') "Starting at: ", &
dateTime(5), ":", dateTime(6), ":", dateTime(7), ".", dateTime(8)
end program main

[Steven_L_Intel1]

There is definitely a bug in the ifport version of RAN. I've reported it.

As for documentation - there is a subtle reference to RAN in the description of RANDOM in the Libraries Reference. The problem is that there used to be a full description there back in the CVF days and it got removed. I'll have it readded.