Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Annonces
FPGA community forums and blogs on community.intel.com are migrating to the new Altera Community and are read-only. For urgent support needs during this transition, please visit the FPGA Design Resources page or contact an Altera Authorized Distributor.

implied loop for write

Yu__Wenbin
Débutant
7 404 Visites

I have a code to write a large array. 

WRITE(EIN,'(1X,i8,2ES20.10)') (i,coord(i,:),i=1,nnode)

it stops at i=63800. Do you know why? Thanks a lot for your help in advance!

0 Compliments
33 Réponses
andrew_4619
Contributeur émérite III
5 048 Visites

Because nnode is 63800 maybe?

Another point that it appears you have Coord(N,2) which means that in memory you have all the "X" values and then all the "Y" values which means that  the code is most likely very inefficient as you will be jumping around in memory. In Fortran  Coord(2,N) is better then the x and y for point N are next to each other,

 

0 Compliments
Yu__Wenbin
Débutant
5 048 Visites

No. nnode is much larger than 63800. Comparing to time used in other part of the code, this efficiency is not my concern.  

0 Compliments
andrew_4619
Contributeur émérite III
5 048 Visites

what do you mean by 'stops'. end of writing or program crash?

0 Compliments
Yu__Wenbin
Débutant
5 048 Visites

Just silently stops and exit. Program does not crash. Its effect is the same as if I am doing the following

do i=1,63800

WRITE(EIN,'(1X,i8,2ES20.10)') i,coord(i,:)

enddo

stop

I used both ifort Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 12.1.5.344 Build 20120612

and Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 19.0.5.281 Build 20190815.

 

0 Compliments
andrew_4619
Contributeur émérite III
5 048 Visites

does it terminate if you have an explicit do loop like in #5?  Or could you try:

WRITE(EIN,'(1X,i8,2ES20.10)',err=1234) (i,coord(i,:),i=1,nnode) 

and then have some diagnostic messages after an error jump? It may be that windows or the fortran run time is running out of some resource.

 

 

0 Compliments
Yu__Wenbin
Débutant
5 048 Visites

If I use explicit do loops, it works perfect. If you use what you suggest, it does not branch out, it still silently stops, no any diagnostic info

WRITE(EIN,'(1X,i8,2ES20.10)',err=1234,iostat=in_stat) (i,coord(i,:),i=1,nnode)
1234 write(*,*)"after error", in_stat

0 Compliments
Yu__Wenbin
Débutant
5 048 Visites

If I use explicit do loops, it works perfect. If you use what you suggest, it does not branch out, it still silently stops, no any diagnostic info

WRITE(EIN,'(1X,i8,2ES20.10)',err=1234,iostat=in_stat) (i,coord(i,:),i=1,nnode)
1234 write(*,*)"after error", in_stat

And if I forgot to tell, if I compile the code using gfortran, it works perfect. It is the ifort compiler I have problem with. I don't know whether there are some default value or some flags I should use to avoid this mistake.

 

0 Compliments
Steve_Lionel
Contributeur émérite III
5 048 Visites

You should not need any flags or settings. Please construct a small test case that demonstrates the problem.

0 Compliments
Yu__Wenbin
Débutant
5 048 Visites

I wrote a simple code main.f90, compiled used ifort -O3 main.f90

The input file is test.txt. The results can be found at fort.50. It seems that the number stops randomly on my computer. Sometimes at 64074, sometimes at 64066. Never runs successfully on my dell latitude laptop.

0 Compliments
Yu__Wenbin
Débutant
5 049 Visites

To make it simple, I change the code to generate the test.txt file. Then to read from it and write into a different file. This code works as expected if compiled using gfortran, but not ifort. I don't know why and how to fix it if I have to use ifort for compiling.

0 Compliments
andrew_4619
Contributeur émérite III
5 049 Visites
PROGRAM main
IMPLICIT NONE  
integer              :: i, nnode
REAL(8), ALLOCATABLE :: coord(:,:)

nnode = 65853
ALLOCATE( coord( nnode, 2 ) )
coord = 99.99e3

WRITE(50,'(1X,i8,2ES20.10)') ( i, coord(i,:) , i = 1, nnode )
write(*,*)"Finished successfully"
END

I reduced your code and ran it under debug with Intel(R) Visual Fortran Compiler 19.0.4.245 [IA-32]

It crashes with "Exception thrown at 0x771996CF (ntdll.dll) in readtest.exe: 0xC0000005: Access violation writing location 0x00C00FFC."

there is some variation   from run to run but approx 32229 record are written. I note you had approx 64000 records  but mine was a 32 bit build and I am guessing yours was 64 bit....

This seems to me like a compiler bug to me file a bug report..

PROGRAM main
IMPLICIT NONE  
integer              :: i, nnode
REAL(8), ALLOCATABLE :: coord(:,:)

nnode = 65853
ALLOCATE( coord( 2, nnode ) )
coord = 99.99e3

WRITE(50,'(1X,i8,2ES20.10)') ( i, coord(:,i) , i = 1, nnode )
write(*,*)"Finished successfully"
END

I will further add that with cord being address in the more sensible order it runs OK to completion. I am guessing because the non-contiguous array slice causes extra work with temporaries being created and this is where is goes wrong.

0 Compliments
Yu__Wenbin
Débutant
5 049 Visites

Thanks a lot! It is not easy for us to change the order. What flags you used to trigger it to report crash information?

0 Compliments
andrew_4619
Contributeur émérite III
5 049 Visites

/debug:full /Od  but I ran it in the debugger in Visual studio. The debugger picks up the exception. You should report this bug.

 

0 Compliments
Yu__Wenbin
Débutant
5 049 Visites

Thanks a lot Andrew. I will wait for Dr. Fortran's suggestion before I decide what to do. 

0 Compliments
GVautier
Nouveau contributeur III
5 049 Visites

This would get around the problem

WRITE(50,'(1X,i8,2ES20.10)') ( i, coord(1,i),coord(2,i) , i = 1, nnode )

 

0 Compliments
Yu__Wenbin
Débutant
5 049 Visites

Gilles, I can also use explicit loops to get around this problem without switch the orders of the index. However, in the entire code, such changes will be too many. I hope there are some flags of the compiler during compilation can help me avoid this problem. I will be surprised that such a problem has not been identified and fixed already. 

0 Compliments
Ferdinand_T_
Nouveau contributeur II
5 049 Visites

Yu, Wenbin wrote:

I hope there are some flags of the compiler during compilation can help me avoid this problem.

Have you tried the heap-arrays option?

0 Compliments
Steve_Lionel
Contributeur émérite III
5 049 Visites

The program is running out of stack, and the stack overflow is not detected (at least when I tried it). The simplest workaround is to set the project property Linker > System > Stack Reserve Size to 100000000 (100 million) . Don't go overboard with this setting as too large a value can prevent the program from running at all.

I think the issue is that coord(i,:) creates a stack temp that is not removed on each iteration through the loop. As noted already, the section you are reading into is discontiguous, so a temp is needed. I'd consider it a bug that the stack is not unwound at each iteration.

0 Compliments
Yu__Wenbin
Débutant
5 049 Visites

Dear Steve, thanks a lot for your advice. How to increase the stack reserve size through command line? I don't have the IDE. 

0 Compliments
Steve_Lionel
Contributeur émérite III
4 929 Visites

From the command line, add /link /stack:100000000 to the end of the ifort command that links the program.

0 Compliments
Répondre