CVF RANDOM_NUMBER converges to 1

[bradlepc]

We're seeing strange behavior using CVF 6.6C in which the RANDOM_NUMBER function eventually converges to a number very close to 1. The problem appears to go away if RANDOM_SEED is called at the beginning of the program. However, I find nothing in the f90 standard that says this is a requirement, so I think the "fix" may just be fortuitous. Google turns up a few other mentions of this behavior, but no answers. Comments?

Pete

[bradlepc]

Are you getting a random distribution? Any thoughts on what could so precisely step on the random seed through two different programs and two versions of the compiler? Also, just a reminder that we have to have /threads and /libs:dll for the behavior to occur which sounds like a clue.

Just to keep context, this is part of a larger stability problem that we're trying to resolve on Windows. I know it could well be in the code, and all the usual "it runs on they other guy's platform" data points apply. I'm suspicious of some kind of C library mismatch effect, but not sure what RANDOM_NUMBER does under the hood.

Pete

[Steven_L_Intel1]

I know that the implementation has special code when /threads is used so that it synchronizes access to the seed. I'll have to study this more. I didn't ask for more than a few numbers, but it looked to me that, once the call to MPI_INIT was done, that RANDOM_NUMBER behaved normally. It might do something different in an application actually making more MPI calls.

This will take a while, but I am not going to drop it... Please file an Intel Premier Support request on this and ask that it be assigned to Steve Lionel. Thanks.

[jimdempseyatthecove]

Pete,

In the IVF documentaton under SEED you will see the caution

"This routine is not thread-safe"

There is no similar caution under RANDOM_NUMBER (or RANDOM_SEED).

Therefore it is unknown if RANDOM_NUMBER is thread-safe. I would suspect if you cannot set the seed then it is questionable if RANDOM_NUMBER is thread-safe. It may work thread-safe in some implimentations and may not in others

Additionaly, it is ambiguous as what you would expect from multiple threads calling on RANDOM_NUMBER. i.e.

Do all threads use a commonglobal seed pair with the call to RANDOM_NUMBER being interlocked properly?

or

Does each thread use a thread-dependent global seed pair with the call to RANDOM_NUMBER insensitive to simulteaneous access?

Due to the lack of documentation regarding thread-safe and the ambiguity listed above. It would be wise for you to construct a subroutine containing critical section that uses RANDOM_SEED in a manner that produces the desired results (all threads share the seeds or all threads use independent seeds).

Jim Dempsey

[bradlepc]

Jim,

Thanks. As I tried to make clear before, there is only one FORTRAN thread of execution in the process.

Steve, I'll put in a Premier as requested. Thanks,

Pete