Solved: Re: READ command with IOSTAT does not capture end of file and returns error instead

Feng__Jesse · ‎09-28-2023

I have two workstations running two versions of Intel Fortran, one with:

And the second one:

The following read code works in the second version but does not work in the first version:

SUBROUTINE READSEC()

IMPLICIT NONE
CHARACTER(LEN=100) :: CURRENTLINE
INTEGER,PARAMETER :: FID=15,NVAR=10
INTEGER :: I,J,IOS,NHEADER,NPHSEC
LOGICAL :: READHEADER

READHEADER=.TRUE.

OPEN(UNIT=FID,FILE = TRIM(WORK_DIR) // FNSEC, IOSTAT=IOS,ACTION='READ')
!DETERMINE LENGTH OF HEADER AND NUMBER OF SECTIONS IN FILE
NHEADER=0
NSEC=0

DO
   
   IF(READHEADER)THEN
      READ(FID,'(A)', IOSTAT=IOS) CURRENTLINE
   ELSE
      READ(FID,*, IOSTAT=IOS)
   ENDIF
   
   IF ( IOS .GT. 0 )THEN
      !ERROR STOP "ERROR OPENING FILE *.SEC"
      CALL STDB_ABQERR(-3,"ERROR OPENING FILE: "// TRIM(WORK_DIR) // FNSEC ,(/INTEGER::/),(/REAL::/),(/CHARACTER(8)::/))
   ELSEIF(IOS .LT. 0 )THEN
      EXIT !END OF FILE
   ELSE
      IF(READHEADER)THEN
         NHEADER=NHEADER+1
      ELSE
         NSEC=NSEC+1
      ENDIF
	    
      IF(CURRENTLINE.EQ.'*DEFINE SECTIONS')READHEADER=.FALSE.
   ENDIF
ENDDO

ENDSUBROUTINE

This is the first part of this read subroutine. The purpose is to determine the total number of data lines in the file for reading later.

Specifically, in first workstation with 2021.10.0, the code successfully reads all the lines in the attached file, New01.SEC (I changed the extension from sec to txt to upload), then when it returns back to line 21, instead of canceling the read operation and set IOS to -1 for end of file, it just attempts to read the line normally and fails with an end-of-file error instead. Again, this does not happen in the second workstation with 2021.4.0.

I tried many ways to debug this but I cannot figure out why. The compilation flags used for this code are also attached. Can anyone else replicate this? Any suggestion on how to figure out the source of this issue would be much appreciated!

mnolaya · ‎10-02-2023

UPDATE

I managed to resolve the issue, but I'm not sure I can explain the reasoning for it on any deep level. Took me a while to get there as I had to dig up the old installer for OneAPI back to 2021.4: Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.4.0 Build 20210910_000000.

Because I reverted back to 2021.4, I could no longer integrate with VS2022, meaning I also had to revert back to VS2017 or 2019. Unfortunately, this came with its own issues -- the 2021.4 installer would crash due to some issue with a DLL file that came with VS2022 as discussed on Intel's known issues pages here and on the forums here.

Ultimately, the solutions provided in the above links didn't work for me. What did however was first uninstalling VS2022, then repairing my 2019 installation. Then, I went ahead and tried to install 2021.4 with no crashes and integration with VS2019 confirmed.

I don't know if the problem was the compiler version or with VS2022, as I could not integrate the two to test and confirm. However, if you have the ability to do this, I would consider it a possible solution to explore @Feng__Jesse. Good luck. I'll check back in on this thread in case you have questions.

@andrew_4619to answer your question about build command & runtime libraries -- I'm pretty much a novice at a lot of what VS offers as well as the terminology. I attached an example of the output from building one of the static libs, which uses the same commands and options as all of my static libs in the overall solution. Let me know if there's anything that seems out of place.

View solution in original post

andrew_4619 · ‎09-28-2023

program readsec

IMPLICIT NONE
CHARACTER(LEN=100) :: CURRENTLINE
INTEGER,PARAMETER :: FID=15,NVAR=10
INTEGER :: I,J,IOS,NHEADER,NPHSEC
integer :: nsec
LOGICAL :: READHEADER

READHEADER=.TRUE.

OPEN(UNIT=FID,FILE = 'New01.txt', IOSTAT=IOS,ACTION='READ')
!DETERMINE LENGTH OF HEADER AND NUMBER OF SECTIONS IN FILE
NHEADER=0
NSEC=0

DO
   IF(READHEADER)THEN
      READ(FID,'(A)', IOSTAT=IOS) CURRENTLINE
   ELSE
      READ(FID,*, IOSTAT=IOS)
   ENDIF
   IF ( IOS .GT. 0 )THEN
      !ERROR STOP "ERROR OPENING FILE *.SEC"
      !CALL STDB_ABQERR(-3,"ERROR OPENING FILE: "// TRIM(WORK_DIR) // FNSEC ,(/INTEGER::/),(/REAL::/),(/CHARACTER(8)::/))
      write(*,*) 'CALL STDB_ABQERR'
   ELSEIF(IOS .LT. 0 )THEN
      EXIT !END OF FILE
   ELSE
      IF(READHEADER)THEN
         NHEADER=NHEADER+1
      ELSE
         NSEC=NSEC+1
      ENDIF
      IF(CURRENTLINE.EQ.'*DEFINE SECTIONS')READHEADER=.FALSE.
   ENDIF
ENDDO
write(*,*) 'nheader',nheader
write(*,*) 'nsec',nsec
write(*,*) 'ios',ios
if( IS_IOSTAT_END(ios) ) write(*,*) 'EOF'
if( IS_IOSTAT_EOR(ios) ) write(*,*) 'EOR'
END program

I made your snipped into something that could be compiled and run and added some diagnostics info at the end.

I downloaded your text file and used Intel® Fortran Compiler Classic for applications running on Intel(R) 64, version 2021.10.0 Package ID: w_oneAPI_2023.2.0.49496. The output is below which is what I expected and seems consistent with the file which has 609 lines with the *defsec on line 7.

 nheader           7
 nsec         602
 ios          -1
 EOF

Feng__Jesse · ‎09-28-2023

Hmm essentially you cannot replicate my issue. It is not related to the compiler version. And the compilation flag is fully defined. Do you have any suggestions on what I can check to see why this is happening on the workstation?

andrew_4619 · ‎09-28-2023

Well compiler options is a possibility I used my default options. I would run my exact test case with your options just to check.

mnolaya · ‎10-02-2023

Hey @Feng__Jesse, I'm having a similar issue. It looks like subroutine readsec is being used with Abaqus? I have a similar subroutine that parses a file containing tabulated text data.

Recently, after upgrading my OneAPI version, I get the forrtl: severe (24): end-of-file during read error due to iostat not correctly returning -1 at end-of-file. As I was trying to debug the problem, I decided to try writing a small program outside of Abaqus and compile/build a .exe with ifort directly. I used the exact same code as I would within my Abaqus subroutines and read in the same text file I normally would for an analysis. This time, no error, and at end-of-file, iostat was equal to -1 as expected.

This is making me think it could have something to do with some compatibility between Abaqus and the compiler itself? What version of Abaqus are you running? I'm on Abaqus 2023 and the compiler version is Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.10.0 Build 20230609_000000 (same as yours).

Feng__Jesse · ‎10-02-2023

That seems like a strange symtom in terms of Abaqus compatibility. But yes this is happening while running via Abaqus umat. I have Abaqus 2019 on the workstation. This sheds a new light and I can look at Abaqus environmental files to see if any issues there. I can also install a different version of Abaqus.

andrew_4619 · ‎10-02-2023

The bit I don't understand is why you get "forrtl: severe (24): end-of-file during read " as the read has IOSTAT? Does SUBROUTINE READSEC get built as a DLL? There may be some runtime system problems from different versions.

mnolaya · ‎10-02-2023

That's where I am confused as well. Personally, my subroutine exists within a module which is built as a part of a static library. To test, I instead placed directly into the UMAT which Abaqus compiles/links and still received the same error. I did not have this problem until I upgraded from the 2021 to the latest 2023 version of OneAPI.

andrew_4619 · ‎10-02-2023

What is the build command used? And specifically what runtime library options are used?

Feng__Jesse · ‎10-02-2023

The compiler options are attached in the post. The libraries I am not too certain. I didn't find a command that would list the libraries, do you have the procedure to retrieve that information?

mnolaya · ‎10-02-2023

UPDATE

I managed to resolve the issue, but I'm not sure I can explain the reasoning for it on any deep level. Took me a while to get there as I had to dig up the old installer for OneAPI back to 2021.4: Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.4.0 Build 20210910_000000.

Because I reverted back to 2021.4, I could no longer integrate with VS2022, meaning I also had to revert back to VS2017 or 2019. Unfortunately, this came with its own issues -- the 2021.4 installer would crash due to some issue with a DLL file that came with VS2022 as discussed on Intel's known issues pages here and on the forums here.

Ultimately, the solutions provided in the above links didn't work for me. What did however was first uninstalling VS2022, then repairing my 2019 installation. Then, I went ahead and tried to install 2021.4 with no crashes and integration with VS2019 confirmed.

I don't know if the problem was the compiler version or with VS2022, as I could not integrate the two to test and confirm. However, if you have the ability to do this, I would consider it a possible solution to explore @Feng__Jesse. Good luck. I'll check back in on this thread in case you have questions.

@andrew_4619to answer your question about build command & runtime libraries -- I'm pretty much a novice at a lot of what VS offers as well as the terminology. I attached an example of the output from building one of the static libs, which uses the same commands and options as all of my static libs in the overall solution. Let me know if there's anything that seems out of place.

Feng__Jesse · ‎10-02-2023

I am using a Linux workstation that doesn't have VS, so it is probably simpler for me. But in essence, the difference between 2021.4 and 2021.10 did cause the issue when it comes to Abaqus? You were not able to reproduce the IOSTAT issue with both versions outside of Abaqus, is that correct?

mnolaya · ‎10-02-2023

Yes, that is correct. IOSTAT issue was non-existent when running external to Abaqus with 2021.10, using the same file I had tried to use while within Abaqus. I did not check with 2021.4 since it worked within Abaqus.

Oscar8 · ‎01-24-2024

Hi Jesse,

Here recent installation with Intel 2024.0 release for Abaqus subroutine usage in VS2019 and delete and uninstall older Intel releases (2021, 2022).

Would it be possible to share the .exe files of 2021.4 intel in order to solve this problem in case you have it?

Thank you.

Best regards,
Oscar

Feng__Jesse · ‎10-02-2023

I am uninstalling 2021.10 right now. I am going to try to install the latest oneAPI and see if the issue is resolved. Otherwise, can you please share the linux installation file for 2021.4?

mnolaya · ‎10-02-2023

Unfortunately, I only have the Windows offline installer. Do you have access to the installer from your other workstation?

andrew_4619 · ‎10-02-2023

The build for the lib has \libs:dll so it has deferred dll linkage. Then your lib is linked with other Abaqus stuff you probably link objects with a different (older) Fortran runtime level. Maybe if this first step was \libs:static so the runtime was built in to your lib objects you wouldn't get that problem. But I have some knowledge gaps as I don't know the full build process with Abaqus.

AnthonyFloydCMT · ‎06-19-2024

Come here with similar symptoms in search of a solution. Abaqus, umats, and oneAPI - multiple versions over the past year including ifort 2021.12.0 downloaded earlier this week. Same sort of error generated:

forrtl: severe (268): end of record during read, unit 10, file /tmp/anthony_test_24808/fort3uWgDQ

The code works with a 2015 version of ifort - which I've recently lost access to due to a hardware failure, the disappearance of the Intel license activation servers, and the apparent lack of a way to contact the licensing department directly.

Interestingly enough, the error is not generated with Abaqus 2024 and the oneAPI compiler. Unfortunately I need to support Abaqus versions from 6.14-3 through 2024.

I see the comment about static linking of the runtime into my libraries, and I'll give that a go.