Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Known issues when moving a code from matlab to fortran

Erez_K_1
Beginner
362 Views

Hello,

I am working on transferring a code from matlab to fortran.

Finally my code is compiling, but the distribution function I want to get out of it is not coming out correctly.

I would't want to bother someone with reviewing my whole code but I wanted to see if anyone has good advice regarding issues I should look at. 

I have noticed that when I size a matrix that I know should be an 20x16 (in matlab), in fortran I get the size to be 320.

Any ideas?

Thanks,

Erez

 

 

0 Kudos
7 Replies
Steven_L_Intel1
Employee
362 Views

20x16 is 320. It's not at all evident what problem you're seeing. You should add some debugging code to verify that Matlab is sending you the values you expect and check intermediate computation.

0 Kudos
Erez_K_1
Beginner
362 Views

Sounds good. Done and done.

At the moment it seems that my issue is accuracy. So I am trying to take my code to real*16. My main issue is that I have some values that are used both for indexing and computation. When I went to real*8 i used dble() on them. I look at the user guide and thought that qext() or qextd() would solve my issue but it seems that they both don't work on my compiler.

Is that a known issue? if so what should I do?

Thanks so much!

Erez

0 Kudos
Johannes_Rieke
New Contributor III
362 Views

Hi Erez,

I assume you like to translate a prototype Matlab code into a native Fortran code. So, you're not trying to interoperate between both languages, are you?

If you translate the code, arrays should be of the same sytax and shape (both have 1 as start index, both are column orderd as far as I know).

If you think you need quadruple precision and have to change the kind from integer to 128 bit real (or 16 byte -> in many compiles real kind 16), you can still use the real function, but with the optional second argument (compare Intel Fortran Compiler help for real function).

program real128_conversion
  use ISO_FORTRAN_ENV, only : rk => real128, ik => int64
    implicit none

    ! Variables
    integer(ik) :: i_in
    real(rk)    :: r_out

    ! Body of real128_conversion
    print *, 'Hello World'
    
    i_in = 8
    r_out = real(i_in,rk)
    
    write(*,'("Real kind is: ",i8)') kind(r_out)
    write(*,'(E32.26)') r_out

end program real128_conversion

 

However, I assume that you do not need quadruple precision, but that there is a translation issue somewhere in the Fortran code.

Best regards, Johannes

ps. don't forget to use always 'implicit none'!

0 Kudos
Johannes_Rieke
New Contributor III
362 Views

Hi Erez,

me again, I read your other thread (https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/623458) and I'm not sure whether you aware of the precision issues one can get into while programming in Fortran. In the book you cited there should be a chapter which describes the precision model of Fortran and in the web there are many examples for best practise (e.g. https://software.intel.com/en-us/articles/understanding-floating-point-value-with-intel-fortran-compiler).

The default in Fortran is single precision in real variables and constants, which can but should not be changed by compiler settings (do not do this unless it is legacy code). I prefer to use the intrisic iso_fortran_env module and redifine the real 64bit kind to rk. A double precision number constant is written 3.141527_rk therefore. Mixing up double, single or even quadruple can cause a lot of problems especially in interative solvers.

Good luck, Johannes

0 Kudos
Steven_L_Intel1
Employee
362 Views

Is it "accuracy" you're having issues with or "reproducibility"? That is, are you looking for bit-for-bit same answers as some other program or tool? If so, you may need to reset your expectations. Changing from single to double to quad precision probably won't help you, especially if the input values are good to only a few digits, and performance will suffer.

If the answers are WAY off, then you'll need further debugging to see why and where the answers start to diverge.

0 Kudos
Erez_K_1
Beginner
362 Views

Johannes, 

I am not trying to interoperate between them. Just take a working code  in Matlab (which takes about 3 days to run for a low resolution  grid)  and rewrite the entire thing on Fortran. 

I will read through the posts and chapter you suggested. Thank you. 

 

Steve,

I am not looking for  bit to bit answer, but possibly an answer which matches  to 4-6 significant figures. I hope this is possible. 

When i changed from single to double my results improved significantly but it could be that quad will not solve the issue. although I do have numbers in the 1.3456e-13 range.

Il go into debugging it a bit more and see what I can do. 

Thanks you so much!

Best,

Erez

 

0 Kudos
Johannes_Rieke
New Contributor III
362 Views

Hi Erez,

as far as I know Matlab uses only double precision (64bit) floating point models at maximum precision. If that is your reference, it makes in my opinion no sense to switch to quad precision in Fortran. What compiler settings do you use? I work in "debug" mode in most performance restricitive and hopefully most precise settings (/fp:strict and /Qfp-speculation=strict) and compare these results against the "release" version of my program with higher optimizations turned on. In most cases I can use /fp:source and /Qfp-speculation=safe without an impact on results and good complience to analytical results.

Have you tried changing the compiler settings?

Maybe you find these links helpful:

http://sc13.supercomputing.org/sites/default/files/WorkshopsArchive/track127.html

https://software.intel.com/sites/default/files/managed/9d/20/FP_Consistency_300715.pdf

 

Best regards, Johannes

0 Kudos
Reply