Fortran Problems when averaging a value

[jbenet]

Hi,
I am running a fortran 90 program and I have some problems when getting an average. It happens that at some point the value of suma2 is not updated, even when the value of the term s(fixed2(j))/real(nfixed) is not zero. Below is the output of fort.32. The problem dissapears when suma2 is declared as real(8), could anyone please tell me the reason?

Thank you very much

real :: suma2

10 do i = 1, ncycle

  call   mc_swap_thermo(n1,nsites,s,sorted,beta,lambda,seed,neigh,iacc,fixed1,fixed2,nfixed,sblock,sfixed,switch_thermo)

  do j = 1, nfixed

    suma2 = suma2 + s(fixed2(j))/real(nfixed)
    write(32,*) suma2, s(fixed2(j)), s(fixed2(j))/real(nfixed)

  end do
 
  steps=steps+1

end do 

   262144.000       0.00000000       0.00000000  
   262144.000      0.139704779       1.16420649E-02
   262144.000       0.00000000       0.00000000  
   262144.000      0.139704779       1.16420649E-02
   262144.000       0.00000000       0.00000000  
   262144.000      0.139704779       1.16420649E-02
   262144.000       0.00000000       0.00000000  
   262144.000      0.139704779       1.16420649E-02
   262144.000      0.139704779       1.16420649E-02

 

[jedishrfu]

I think the real(8) increases the precision to double ie 64-bit precision whereas the real or real(4) is only 32-bit precision.

 

[Mark44]

Hi,
I am running a fortran 90 program and I have some problems when getting an average. It happens that at some point the value of suma2 is not updated, even when the value of the term s(fixed2(j))/real(nfixed) is not zero. Below is the output of fort.32. The problem dissapears when suma2 is declared as real(8), could anyone please tell me the reason?

Thank you very much

real :: suma2

10 do i = 1, ncycle

call mc_swap_thermo(n1,nsites,s,sorted,beta,lambda,seed,neigh,iacc,fixed1,fixed2,nfixed,sblock,sfixed,switch_thermo)

do j = 1, nfixed

suma2 = suma2 + s(fixed2(j))/real(nfixed)
write(32,*) suma2, s(fixed2(j)), s(fixed2(j))/real(nfixed)

end do

steps=steps+1

end do

262144.000 0.00000000 0.00000000
262144.000 0.139704779 1.16420649E-02
262144.000 0.00000000 0.00000000
262144.000 0.139704779 1.16420649E-02
262144.000 0.00000000 0.00000000
262144.000 0.139704779 1.16420649E-02
262144.000 0.00000000 0.00000000
262144.000 0.139704779 1.16420649E-02
262144.000 0.139704779 1.16420649E-02

What you're encountering is the difference in precision between real (4 bytes) and real(8) (8 bytes). With 4-byte reals, you have only about 7 digits of precision. When you add .0116 to 262144.00, the change is too small to affect the larger number. Changing to 8-byte reals gives you precision out to 12 or 13 places, if I'm remembering correctly.

 

[DrClaude]

Changing to 8-byte reals gives you precision out to 12 or 13 places, if I'm remembering correctly.

real*8 is the same as double in C, so the machine epsilon is 2⁻⁵² ≈ 2.22e-16, giving 15 to 16 decimal places.

 

[jbenet]

Ok, I understand now. Thank you very much