topic /debug:full /Od but I ran it in Intel® Fortran Compiler

implied loop for write

Yu__Wenbin — Thu, 12 Dec 2019 16:27:43 GMT

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?

andrew_4619 — Thu, 12 Dec 2019 16:36:00 GMT

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,

No. nnode is much larger than

Yu__Wenbin — Thu, 12 Dec 2019 17:38:58 GMT

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

what do you mean by 'stops'.

andrew_4619 — Thu, 12 Dec 2019 18:18:51 GMT

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

Just silently stops and exit.

Yu__Wenbin — Thu, 12 Dec 2019 20:24:29 GMT

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

andrew_4619 — Thu, 12 Dec 2019 21:52:08 GMT

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,

Yu__Wenbin — Thu, 12 Dec 2019 22:12:37 GMT

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,

Yu__Wenbin — Thu, 12 Dec 2019 22:16:28 GMT

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.

You should not need any flags

Steve_Lionel — Fri, 13 Dec 2019 00:45:47 GMT

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

I wrote a simple code main

Yu__Wenbin — Fri, 13 Dec 2019 01:52:15 GMT

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.

To make it simple, I change

Yu__Wenbin — Fri, 13 Dec 2019 15:42:25 GMT

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.

PROGRAM main

andrew_4619 — Fri, 13 Dec 2019 16:13:00 GMT

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.

Thanks a lot! It is not easy

Yu__Wenbin — Fri, 13 Dec 2019 16:31:06 GMT

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

/debug:full /Od but I ran it

andrew_4619 — Fri, 13 Dec 2019 17:08:21 GMT

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

Thanks a lot Andrew. I will

Yu__Wenbin — Fri, 13 Dec 2019 17:20:50 GMT

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

This would get around the

GVautier — Fri, 13 Dec 2019 18:45:23 GMT

This would get around the problem

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

Gilles, I can also use

Yu__Wenbin — Fri, 13 Dec 2019 19:07:11 GMT

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.

Quote:Yu, Wenbin wrote:

Ferdinand_T_ — Fri, 13 Dec 2019 19:31:38 GMT

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?

The program is running out of

Steve_Lionel — Fri, 13 Dec 2019 19:48:00 GMT

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.

Dear Steve, thanks a lot for

Yu__Wenbin — Fri, 13 Dec 2019 19:50:57 GMT

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