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!
链接已复制
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,
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.
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.
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
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.
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.
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.
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.