0

The following Fortran code is compiled using intel visual Fortran compiler and run on Mac and Windows systems, respectively. On Mac, The generated two files are different as expected. However, on Windows, the two files are the same. I don't know what's wrong.

program main
  implicit none
  integer :: n1 = 2, n2 = 10
  integer :: j,k
  real(8) :: u_random(10)
  
  !generating random numbers
  open(11,file='random.dat',form='unformatted')
  do j = 1, n1
    call random_seed()
    do k = 1, n2
      call random_number(u_random(k))
    enddo
    write(11) u_random
  enddo
  close(11)
  
  !write random numbers to files
  open(11,file='random.dat',form='unformatted')
  !first 10 numbers
  read(11) u_random
  open(12,file='check1.txt')
  do k = 1, n2
    write(12,*) u_random(k)
  enddo
  close(12)
  !next 10 numbers
  read(11) u_random
  open(12,file='check2.txt')
  do k = 1, n2
    write(12,*) u_random(k)
  enddo
  close(12)

  close(11)
end
S.C. Zheng
  • 51
  • 6
  • 2
    Calling `random_seed` twice may reset the random number sequence to start at the same point. If you omit the call to `random_seed` do you get what you expect? – Ian Bush Jul 09 '21 at 09:50
  • 2
    Also note `real( 8 )` is not good practice. It is not portable, may not be supported by your compiler, and if it is it might not do what you expect. See https://stackoverflow.com/questions/838310/fortran-90-kind-parameter - nowadays I would recommend the `iso_fortran_env` route mentioned in the comments – Ian Bush Jul 09 '21 at 09:51
  • 2
    Also `random_number` is an elemental routine - you can just supply it with an array and it will fill it with random numbers, no need to loop – Ian Bush Jul 09 '21 at 09:52
  • There is a chance that the written value and then read back value isn't binary identical to the original value. So read back into a a new array and compare with the original value and check (the sizes in this example are small enough to temporary store all values in memory). – albert Jul 09 '21 at 10:12
  • @IanBush I always thought 'random_seed' was mandatory. You are right, (1) the code gives correct results when 'call random_seed()' is omitted **or** placed outside the first loop. (2) the second loop is not necessary. However, I am still wondering why the original code can run correctly on MacOS. – S.C. Zheng Jul 09 '21 at 14:34
  • 2
    What random seed with no arguments does is I think implementation dependent (but I really should check). If I'm right it could give a different seed every time, or it could give the same seed. It's up to the compiler developer. Both behaviours are correct, – Ian Bush Jul 09 '21 at 15:00
  • @albert By omitting the 'call random_seed()' or putting it outside the first loop, the results are correct. Also, I write the original values, which are the same as the values in check1.txt and check2.txt. Therefore, the problem in your answer does not exist. – S.C. Zheng Jul 09 '21 at 15:30
  • Could have been a problem. I looked at the standard and her is says (for random_seed()): `If no argument is present, the processor assigns a processor-dependent value to the seed.`, it also states `Restart or query the pseudorandom number generator`. It indicates, a bit to me that each call of `random_seed()` might start with the same seed, but I'm not sure. Maybe you could see what the value is of the used seed after each call of `random_seed()` (with `random_seed(get=seed1)` and see whether they are identical – albert Jul 09 '21 at 16:09
  • 1
    @IanBush, you are correct that `random_seed()` is implementation dependent. gfortran prior to some version (likely 9.x series) would reseed to the same sequence of random numbers. At some point, `random_seed()` was changed to reseed with a new set of seeds, and thus, a different set of random numbers are produced. I believe Intel always has the latter behavior. Also, this deficiency in the Fortran standard was the motivation for the new `random_init()` intrinsic subroutine. – steve Jul 09 '21 at 17:04

0 Answers0