RANDOM_NUMBER, RANDOM_SEED dependencies?

[slett]

I am observing some unexpected behavior  from RANDOM_NUMBER.   I am getting differences between sequences generated by RANDOM_NUMBER after using RANDOM_SEED to set the seed.   I am writing to see if anyone can confirm or deny that Intel RANDOM_NUMBER sequences only depend upon calls to either RANDOM_NUMBER or RANDOM_SEED, and there is no dependency,  either on other Fortran routines or C/C++/C# libraries?

Regards,

Scott

[Steven_L_Intel1]

It is not clear to me what you are doing. If you call RANDOM_SEED without any arguments, the Intel behavior is to set a "random" seed based on the date and time. However, if you are specifying seeds and are passing the correct number of seed values and the same values each time, you should get the identical sequence from RANDOM_NUMBER. There is no dependency on other libraries. You will need to first call RANDOM_SEED to get the SIZE value before allocating the seed array.

I'll comment that the "no-argument" behavior is not really defined by the standard, which is why Fortran 2015 adds a RANDOM_INIT intrinsic that lets you explicitly initialize the generator to "different" results (matching our behavior when you cal RANDOM_SEED with no arguments.)

If this doesn't explain the behavior, please provide us with a small test case and sample output showing the problem.

[slett]

Here's a code sample, 

    subroutine SetSeed( seed )
        integer(kind=4), intent(in) :: seed
        
        integer(kind=4), allocatable :: seedlist(:)        
        integer(kind=4) :: size
        
        if (CheckValues()) then
            call RANDOM_SEED(size=size)
            allocate(seedlist(size))
            seedlist(1)=seed
            seedlist(2:size)=1
            call RANDOM_SEED(put=seedlist)
            init = 1
        endif
    end subroutine SetSeed

I haven't been able to reproduce the problem with a small test case.   In subsequent calls, RANDOM_NUMBER is called with a scalar REAL(4) argument.   I am currently trying to confirm that there's not a hidden call to RANDOM_SEED elsewhere in the client's code.

[Steven_L_Intel1]

Or maybe another call to RANDOM_NUMBER. When you get a test case, let us know.

[slett]

Even a hidden call to RANDOM_NUMBER should produce the same results each time, given the same inputs (I think).  I'm certain I'll find it, and your response about dependencies helps because it eliminates at least one possible cause that would have been more difficult to find.

[Steven_L_Intel1]

Ok - I'll be interested in what you find.  We implement our own random number generator, based on an algorithm by L'Ecuyer (1990). 

[jimdempseyatthecove]

>> I am currently trying to confirm that there's not a hidden call to RANDOM_SEED elsewhere in the client's code.

You also have to confirm there isn't a hidden call to RANDOM_NUMBER (or that they haven't parallelized the code).

Jim Dempsey

[slett]

Jim, that's a good point.  I hadn't checked whether they're running multithreaded.    Having a call to RANDOM_NUMBER doesn't seem to me to introduce variability, by itself.  Running the code twice should produce the same result with the same inputs (including the seed).  However, running in parallel could potentially change the order of operations from run to run.  I'll check that as well.

Scott