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

Cita:

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.

Cita:

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.
Cita:

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.

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.

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.