vector position problem -- allocation problem?

[diedro]

hi everyone,

in this moment many strange things are happening to me so problebli I do not get up something about fortran. See my two file in the attachment.

There is a small difference between them. In sph_std_mvA I have two do-enddo, in sph_std_mvB I add another do-endo to compute the final results outside the main do-enddo.

I think that are the same thing. Howevere the program gives me not exact results in the second case. I got for exmple NaN in the second case when I print some of them.

I am very confused. I hope I haven't done some stupid erros bu I do n ot think so.

Please help me, I need this for work.

Thanks again

[mecej4]

You have not posted the source code for modules COMMONVARS and MD_KERNEL, without which we cannot compile your two programs.

[diedro]

hi, I poste a all code if this could help. reallu really thanks

[diedro]

hi, I spend all the week-end. I really do not know what I can do. I pud also some modules and interfaces but I get the same different results. is It a compiler problem?

[mecej4]

diedro wrote:

hi,
I spend all the week-end. I really do not know what I can do. I pud also some modules and interfaces but I get the same different results.
is It a compiler problem?

So far you have not posted a complete set of source files that one can compile to view the reported problem. The archive "test1.zip" is incomplete. For example, none of the .F90 files in it declare the derived type LNODEInt. My suggestion is that you create a new directory, place source and data files in it, and try to build the application from scratch. Doing so will make it evident when missing modules are being used or variable types are undefined.

[diedro]

dear mecej4, really thanks for your help. Here I post the new forder. I hone nothing is missing now. I have just read your post: http://software.intel.com/en-us/forums/topic/270147 do you think that could it be the same problem? As I told you just moving !VF(1,ip) = VF(1,ip) + dt*dvv(1,ip) !VF(2,ip) = VF(2,ip) + dt*dvv(2,ip) in or outside the do-end (in sph_std_mv) change all the things.

[mecej4]

diedro wrote:

I have just read your post:
http://software.intel.com/en-us/forums/topic/270147

do you think that could it be the same problem?

That optimizer bug was fixed a long time ago, and I do not think that it has any relevance to the present thread.

As I told you just moving

!VF(1,ip) = VF(1,ip) + dt*dvv(1,ip)
!VF(2,ip) = VF(2,ip) + dt*dvv(2,ip)

in or outside the do-end (in sph_std_mv) change all the things.

There are places in KERNEL.F90 where you add 1.0E-16 to a REAL*4 variable such as qij and compare the result to qij. This will fail to do what you expect in many cases. If qij is larger than, for example, 2e-7 in absolute value, in REAL*4 arithmetic qij + 1e-16 is no different from qij. With npt of the order of 1000 or more, an expected relative error of 1e-7 in single-precision, the expected error in the sum of array elements over the range 1:npt is about 1e-4. That is, no more than three significant digits should be expected to agree when the same sum is computed in two different ways, as in sph_std_mv.f90. In summary, the discrepancies are attributable to insufficient precision in the calculations. Careful study is needed to decide whether REAL*4 is adequate for your computations.

[diedro]

hi, really thanks for your help. I do not think that precision is the problem. I compile all in double precision as: [php] ifort -r8 *.f90 -lmkl_blas95_lp64 -lmkl_lapack95_lp64 -mkl=sequential -CB [/php] am I wrong? what should i do if I am wrong. thanks, really thanks

[diedro]

hi, I have tried also: [php] ifort -r8 *.f90 -lmkl_blas95_lp64 -lmkl_lapack95_lp64 -mkl=sequential -CB -O0 [/php] to swich off the optimazier and also: [php] ifort -r16 *.f90 -lmkl_blas95_lp64 -lmkl_lapack95_lp64 -mkl=sequential -CB -O0 [/php] but both of them fail, I have the same problem

[mecej4]

Your program does not need anything from MKL. Even when compiled with GFortran with -fdefault-real-8, the results change slightly (the fifth significant digit and beyond) when the two statements are moved to their own DO loop, as you described earlier. Therefore, the issue is one of loss of precision. I think that you should look at the algorithm used and why it is numerically sensitive, rather than suspect compiler bugs or try different optimization options. There are some places where you raise negative numbers to real powers. You could probably avoid problems with this by replacing exponents such as 2.d0 and 3.d0 by their corresponding integer values.

[mecej4]

Upon looking at your sph_std_mv.f90 more carefully than I did before, I notice that assigning VF(:,ip) inside the first double loop and assigning VF in its own loop are not equivalent. This is because VF(:,jp) is used in the right-side expression for computing drho inside the inner loop. For values of jp < ip, this results in the latest values of VF(:,jp) being used if VF is updated in the outer loop, whereas using a separate loop for updating VF causes drho to be computed using the values of VF as they were when SPH_STD_MV was called. I do not know which of these is correct for your problem domain, but it is worth putting some thought into this question.

[diedro]

hi mecej4, you are mu lifesaver. Really really thanks. The correct is the second one. Moreover is correct also the first suggestion. I have to be very careful with stability problem. I really do not know what I can say, you spend time looking to my code and help me a lot. Thanks again thanks