Problems when averaging a value

  • #1
2
0
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
Code:
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
 
Last edited by a moderator:

Answers and Replies

  • #2
12,222
5,923
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.
 
  • Like
Likes jbenet
  • #3
34,299
5,936
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.
 
  • Like
Likes jbenet
  • #4
DrClaude
Mentor
7,506
3,786
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−52 ≈ 2.22e-16, giving 15 to 16 decimal places.
 
  • Like
Likes jbenet and Mark44
  • #5
2
0
Ok, I understand now. Thank you very much
 

Related Threads on Problems when averaging a value

Replies
2
Views
2K
Replies
5
Views
2K
Replies
8
Views
2K
Replies
1
Views
2K
Replies
3
Views
9K
Replies
4
Views
3K
  • Last Post
Replies
5
Views
4K
Top