Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

How to fix " forrtl: severe (24): end-of-file during read" error?

5,792 views
Skip to first unread message

nik@cabana

unread,
Jun 3, 2017, 9:15:01 PM6/3/17
to
Hello all,

I have written following two subroutines SIGINI and Read_xcsv. SIGINI subroutine is called by external program Abaqus sequentially for 164548 X 8 number of times. During each run SIGINI calls Read_xcsv subroutine which extracts data from .csv excel file which contains necessary data in 164548 X 8 number of rows. I am getting following error message:

forrtl: severe (24): end-of-file during read, unit 20, file D:\E\3D\Linear\ReducedWidth_Run_1.csv

Image PC Routine Line Source
libifcoremd.dll 0000000000E827EF Unknown Unknown Unknown
libifcoremd.dll 0000000000E7C5A3 Unknown Unknown Unknown
libifcoremd.dll 0000000000E659AF Unknown Unknown Unknown
libifcoremd.dll 0000000000DC83E8 Unknown Unknown Unknown
libifcoremd.dll 0000000000DC7022 Unknown Unknown Unknown
libifcoremd.dll 0000000000E0DAD1 Unknown Unknown Unknown
standardU.dll 000007FEF10B1379 Unknown Unknown Unknown
ABQSMAStaCore.dll 000007FED031AFAD Unknown Unknown Unknown
ABQSMAStaCore.dll 000007FED033504D Unknown Unknown Unknown
ABQSMAStaCore.dll 000007FED032CF80 Unknown Unknown Unknown
ABQSMAStaCore.dll 000007FED03292C9 Unknown Unknown Unknown
ABQSMAStaCore.dll 000007FED0311C5A Unknown Unknown Unknown
ABQSMAStaCore.dll 000007FED03102E3 Unknown Unknown Unknown
ABQSMAStaCore.dll 000007FED1035CF5 Unknown Unknown Unknown
ABQSMAStaCore.dll 000007FECFAE62BA Unknown Unknown Unknown
ABQSMAStaCore.dll 000007FED0983D6F Unknown Unknown Unknown
standard.exe 000000013FFA38C9 Unknown Unknown Unknown
standard.exe 000000013FFA153F Unknown Unknown Unknown
standard.exe 000000013FFB436A Unknown Unknown Unknown
kernel32.dll 00000000771659CD Unknown Unknown Unknown
ntdll.dll 000000007729A561 Unknown Unknown Unknown



Can anybody please tell me how to fix this error message? If I have csv file with data in just 164548 number of rows then it works fine. But when I have data in 164548 X 8 number of rows then it gives me error message.

My code for both subroutines are as follows. Any input/suggestions are appreciated.

SUBROUTINE SIGINI(SIGMA,COORDS,NTENS,NCRDS,NOEL,NPT,LAYER,
1 KSPT,LREBAR,NAMES)
C
INCLUDE 'ABA_PARAM.INC'
C
DIMENSION SIGMA(NTENS),COORDS(NCRDS)
CHARACTER NAMES(2)*80

REAL, DIMENSION(3,3) :: T,X,STRESSXYZ,STRESSRTZ
REAL :: Stress,r,c,s,ylim,sine,cosine,radius,depth,dummy1,dummy2
INTEGER :: i,j
INTEGER, parameter :: NROWS=164548, NCOLS=8
REAL :: output(1,8)
REAL, DIMENSION(1,6) :: xy

ylim=-8.701882 !6309 Size Bearing
r=SQRT(COORDS(1)**2 + COORDS(3)**2)
if (COORDS(2)>ylim) then
sine=COORDS(1)/r
cosine=COORDS(3)/r
dummy1=(36.5948*sine-COORDS(1))**2 + (COORDS(2))**2 !6309 Size Bearing
dummy2=(36.5948*cosine-COORDS(3))**2 !6309 Size Bearing
radius=SQRT(dummy1+dummy2)
depth=radius-9.0805 !6309 Size Bearing
elseif(COORDS(2)<=ylim) then
depth=34-r !6309 Size Bearing
endif

if (depth<-0.0001) then
Stress=0 !This insures residual stress in ball = 0
elseif (depth>=-0.0001 .AND. depth<=0.026) then
!Stress=(300*depth/0.026)-700
Stress=-400
elseif(depth>0.026 .AND. depth<=0.5) then
Stress=-400
elseif(depth>0.5 .AND. depth<=1) then
!Stress=(400*depth/0.265)-1154.72
Stress=800*(depth-1)
else
Stress=0
endif

STRESSXYZ(:,:)=0.0
STRESSRTZ(:,:)=0.0
STRESSRTZ(2,2)=Stress !Residual stress is applied in circumferential direction
STRESSRTZ(3,3)=Stress !Residual stress is applied in axial direction
c=COORDS(1)/r
s=COORDS(3)/r
T(:,:)=0.0
T(1,1)=c
T(1,2)=-s
T(2,1)=s
T(2,2)=c
T(3,3)=1
X(:,:)=0.0
X(1,1)=c
X(1,2)=s
X(2,1)=-s
X(2,2)=c
X(3,3)=1
STRESSXYZ=T*STRESSRTZ*X

if (COORDS(2)<=-5.426502) then
STRESSXYZ(:,:)=0
endif

if (depth>1 .AND. COORDS(2)>-5.426502) then
i=8*(NOEL-1)+NPT
CALL Read_xcsv(i,output)
xy(1,:)=output(1,3:8)
STRESSXYZ(1,1)=xy(1,1)
STRESSXYZ(2,2)=xy(1,2)
STRESSXYZ(3,3)=xy(1,3)
STRESSXYZ(1,2)=xy(1,4)
STRESSXYZ(1,3)=xy(1,5)
STRESSXYZ(2,3)=xy(1,6)
endif

SIGMA(1)=STRESSXYZ(1,1)
SIGMA(2)=STRESSXYZ(2,2)
SIGMA(3)=STRESSXYZ(3,3)
SIGMA(4)=STRESSXYZ(1,2)
SIGMA(5)=STRESSXYZ(1,3)
SIGMA(6)=STRESSXYZ(2,3)

RETURN
END

Subroutine Read_xcsv (i,xcsv)
IMPLICIT NONE
! read real numbers from CSV file
! i is used to store row number for which data needs to be extracted
integer, parameter :: iu=20, nrows = 164548, ncols = 8

real :: xcsv(1,8)
integer :: j,i, NELM, NPT, k
integer :: ios
character(len=80) :: msg

open (unit=iu,file="D:\E\3D\Linear\ReducedWidth_Run_1.csv",
+ action="read", status="old", iostat=ios,iomsg=msg)
if (ios/=0) then
print *,trim(msg)
stop
endif
k=nrows*8
sum: do j=1,k
if(j==i) then
read (iu,*) xcsv(1,:)
EXIT sum
else
read(iu,*)
endif
! read(iu,*)
!k=i-1
!if(j==k) then
!read (iu,*) xcsv(1,:)
!endif
end do sum
close (unit=iu)
END Subroutine Read_xcsv

robin....@gmail.com

unread,
Jun 3, 2017, 11:08:14 PM6/3/17
to
Check your data.

David Duffy

unread,
Jun 4, 2017, 1:19:36 AM6/4/17
to
nik@cabana <nikhil...@gmail.com> wrote:
>
> Subroutine Read_xcsv (i,xcsv)
...
> k=nrows*8
> sum: do j=1,k
> if(j==i) then
> read (iu,*) xcsv(1,:)
> EXIT sum
> else
> read(iu,*)
> endif
> end do sum
> close (unit=iu)
> END Subroutine Read_xcsv

Message sounds like k > nrecords, doesn't it?

Why not "do j=1,i-1 read(iu,*) ; read(iu,*) xcsv(1,:)"?
If you're doing it repeatedly, make an index for the
start of each line once, and open as stream.

Clive Page

unread,
Jun 4, 2017, 4:53:17 AM6/4/17
to
I've also developed software to read CSV files - my method is to open it
as an unformatted stream and read the whole thing into a character
variable. I found that CSV files vary a lot so have had to adopt a lot
of strategies to cope with all the variants. One problem is that some
end without a final end-of-line marker (CR/LF/CRLF) that Fortran
expects. This is why traditional formatted access may fail at the last
row of the table. Stream access can get around this - first use INQUIRE
to find the length of the file, then read it all in, and remember that
the last line may not end in an end-of-line marker and you are ok. I'd
be happy to post my code here, but others have done this sort of thing
before so it's hardly original.
--
Clive Page

Louis Krupp

unread,
Jun 6, 2017, 4:20:12 AM6/6/17
to
On Sun, 4 Jun 2017 09:53:15 +0100, Clive Page <use...@page2.eu> wrote:

>I've also developed software to read CSV files - my method is to open it
>as an unformatted stream and read the whole thing into a character
>variable. I found that CSV files vary a lot so have had to adopt a lot
>of strategies to cope with all the variants. One problem is that some
>end without a final end-of-line marker (CR/LF/CRLF) that Fortran
>expects. This is why traditional formatted access may fail at the last
>row of the table. Stream access can get around this - first use INQUIRE
>to find the length of the file, then read it all in, and remember that
>the last line may not end in an end-of-line marker and you are ok. I'd
>be happy to post my code here, but others have done this sort of thing
>before so it's hardly original.
>
<snip>

For the original poster (Nik): You should be able to tell if a missing
final end-of-line marker is your problem by editing the data file and
adding a blank line at the end. If the program works with no other
changes, then that was it. The easy way to work around that problem is
to add a blank line at the end whether you need to or not.

Louis

herrman...@gmail.com

unread,
Jun 6, 2017, 2:04:44 PM6/6/17
to
On Tuesday, June 6, 2017 at 1:20:12 AM UTC-7, Louis Krupp wrote:

(snip)

> For the original poster (Nik): You should be able to tell if a missing
> final end-of-line marker is your problem by editing the data file and
> adding a blank line at the end. If the program works with no other
> changes, then that was it. The easy way to work around that problem is
> to add a blank line at the end whether you need to or not.

Except that ordinary list-directed READ will read through blank
lines until it finds actual data, data that isn't compatible with
the type needed, or EOF, whichever comes first.

A few lines of the input data would make it a little easier
to figure out.

It seems that the program expects eight fields on each input
line, which may not be what the file contains, though I
didn't completely figure out what it is doing.


0 new messages