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

implied loop for write

Yu__Wenbin
Beginner
3,023 Views

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 Kudos
33 Replies
andrew_4619
Honored Contributor II
2,090 Views

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 Kudos
Yu__Wenbin
Beginner
2,090 Views

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

0 Kudos
andrew_4619
Honored Contributor II
2,090 Views

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

0 Kudos
Yu__Wenbin
Beginner
2,090 Views

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 Kudos
andrew_4619
Honored Contributor II
2,090 Views

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 Kudos
Yu__Wenbin
Beginner
2,090 Views

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 Kudos
Yu__Wenbin
Beginner
2,090 Views

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 Kudos
Steve_Lionel
Honored Contributor III
2,090 Views

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

0 Kudos
Yu__Wenbin
Beginner
2,090 Views

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 Kudos
Yu__Wenbin
Beginner
2,091 Views

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 Kudos
andrew_4619
Honored Contributor II
2,091 Views
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 Kudos
Yu__Wenbin
Beginner
2,091 Views

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 Kudos
andrew_4619
Honored Contributor II
2,091 Views

/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 Kudos
Yu__Wenbin
Beginner
2,091 Views

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

0 Kudos
GVautier
New Contributor II
2,091 Views

This would get around the problem

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

 

0 Kudos
Yu__Wenbin
Beginner
2,091 Views

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 Kudos
Ferdinand_T_
New Contributor II
2,091 Views

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 Kudos
Steve_Lionel
Honored Contributor III
2,091 Views

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 Kudos
Yu__Wenbin
Beginner
2,091 Views

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 Kudos
Steve_Lionel
Honored Contributor III
1,971 Views

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

0 Kudos
Reply