ifort read file error and ifx internal compiler error for oneAPI 2023.0.0 for Modflow6 Software

[Scott_Boyce]

I attached a program called MODFLOW6 (mf6),

hosted at https://github.com/MODFLOW-USGS/modflow6

that does compile with ifort from oneAPI 2023.0.0 (2021.8.0 20221119), but when running the software causes read file errors that do not occur with previous versions of ifort or gfortran.

A single example is provided in the example folder to illustrate this problem. To run the example, the bash file, run_example.sh, calls the compiled executable and the appropriate input file. Note that this bash script is setup to run the mf-debug.nix, and if you want to test the release version, it will have to be modified to run mf6.nix as the program. Using older versions of ifort results in a successful completion of the program.

When the example problem is run, the following error message is triggered by the code:

#########################################################################

>>> mf6.nix  mfsim.nam

ERROR REPORT:

1. ERROR. "BEGIN" DETECTED BEFORE "END OPTIONS". "END OPTIONS" MUST BE USED
TO END OPTIONS.

UNIT ERROR REPORT:

1. ERROR OCCURRED WHILE READING FILE
'modflow6/example/mfsim.nam'

#########################################################################

which with all past versions of ifort (and all versions of gfortran) would successfully read the file and the simulation would complete successfully.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This same code also fails to compile with ifx from oneAPI 2023.0.0 (2023.0.0 20221201) with an internal compiler error. The following is the output from compiling on Lubuntu the code with the following arguments

ifx -O0 -g -debug -traceback -fpe0 -fp-model source -nologo -warn nousage -check bounds,pointers,stack,format,output_conversion,uninit -static -static-intel -qopenmp-link=static -static-libstdc++ -static-libgcc

#########################################################################

/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1f563ca]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1bef70e]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1c55e52]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1c55e26]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1b6fb6c]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1be23f6]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1c2bfc8]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1c93141]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1ca1cc5]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1ca3eed]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1ca4500]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1c2b06d]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1ca3eed]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1ca4500]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1ca13d9]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1ca3eed]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1ca4500]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1ca6a30]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1ca3eed]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1ca4500]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1ca19c2]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1ca3eed]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1ca104a]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1ca3eed]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1b44bf6]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1b445c9]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1d028ee]
/lib/x86_64-linux-gnu/libc.so.6(+0x29d90)[0x7f715789cd90]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80)[0x7f715789ce40]
/opt/intel/oneapi/compiler/2023.0.0/linux/bin-llvm/xfortcom[0x1982da9]

./src/Model/GroundWaterFlow/gwf3tvbase8.f90(373): error #5623: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error.
bndElem => this%get_pointer_to_value(node, varName)
-------------------^
compilation aborted for ./src/Model/GroundWaterFlow/gwf3tvbase8.f90 (code 3)
make[1]: *** [makefile:726: make/obj_temp/debug_ifx/gwf3tvbase8.o] Error 3

#########################################################################

I attached a zip file of the project with the main source under the src folder, a makefile for compiling in Linux, for windows a solution file located at modflow6/msvs/mf6.sln, and input files are in the example folder.

There are two makefiles, the first is the one that comes with the github repository (located at modflow6/make/makefile). The second makefile is one that I setup for posting on here (located at modflow6/makefile) for ease for the Intel engineers to compile. I will explain next how to setup the second makefile.

The added makefile (located at modflow6/makefile) has a set of variables that control how the compiled variable is made. There are comments to explain what they do, but I will give a brief explanation:

#########################################################################
# Set to "RELEASE" for -02 compilation, "DEBUG" for -O0 -g -debug -traceback compilation

# RELEASE makes "bin/mf6.nix"; and DEBUG makes "bin/mf6-debug.nix"
CONFIG := DEBUG
#
# Set to "INTEL" to indicate that oneAPI is used
COMPILER := INTEL
#
# Set to "ifort" or "ifx" to indicate the compiler command invoked
F90 := ifx
#
#
# Set to "YES" to include static flags, otherwise set to "NO"
STATIC := YES

#########################################################################

For testing on here I would compile with

F90 := ifx

and

F90 := ifort

to evaluate the two issues posted here.

If you want to adjust the specific flags used in the compiler by changing the variable:

F90FlagsIntel

which is located within in an ifeq ($(CFG), DEBUG) that sets it to values based on if CONFIG := RELEASE and CONFIG := DEBUG.

#########################################################################

These same problems occur on Windows 11 and Visual Studio 2019 for ifort and ifx.

For the case of ifx, we would like to switch to this eventually, but we need to be able to successfully compile an executable and pass all our unit tests.

Thanks all for the help and support.

[Barbara_P_Intel]

I'm investigating this.

For the runtime error:

• Can you please confirm that this app ran okay when compiled with ifort 2021.7.0?
• What is the error you get from the Fortran compiler when you run this? The message you reported comes from your app.

For the internal compiler error (ICE), I worked with it and narrowed the number of lines of code to reproduce the problem quite a bit. The issue is a compiler problem with derived types. I submitted a bug report on your behalf, CMPLRLLVM-44872. I'll let you know when it's fixed.

[Scott_Boyce]

Yes, so the software runs fine with earlier versions of ifort (such as, 2021.7) and with gfortran, but with the 2021.8 ifort version something happens when parsing the command argument flags and opening/reading the main input file (mfsim.nam).

If you run the example, with a binary compiled with an older ifort will result in a successful completion of the program, while running with 2021.8 results in the main input file failing to read part of the input file. Rather than having a fortran error occur the code is raising its own error message. I think something changed with the new release that is causing the file i/o issues in the software.

[Barbara_P_Intel]

I understand that it is the app's error message. What is the READ error that the app is handling?

[Scott_Boyce]

I think I isolated the problem for ifort (ifx still does not compile).

It is failing when using a combination of the "subroutine get_line(lun, line, iostat)" with "backspace(lun)"

when reading the first couple of input lines.

The call stack is:

subroutine simulation_cr()                                                   -> SimulationCreate.f90

subroutine read_simulation_namefile(namfile)                                 -> SimulationCreate.f90

subroutine options_create()                                                  -> SimulationCreate.f90

subroutine GetBlock(this, blockName, isFound, ierr, supportOpenClose, &
                    blockRequired, blockNameFound)                           -> InputOutput.f90

subroutine uget_block(iin, iout, ctag, ierr, isfound, lloc, line, iuext, &
                       blockRequired, supportopenclose)                      -> InputOutput.f90

subroutine u9rdcom(iin, iout, line, ierr)  -> InputOutput.f90

subroutine get_line(lun, line, iostat)     -> InputOutput.f90

I wrote up a simple example that creates this problem and attached it here.

What it does is make a file that is:

-------------------
line 1          
line    2       
line       3    
line          4 
-------------------

and then I reopen that file for read and use get_line to read the first two lines, then backspace, then get_line again.

The expected output should be "line    2" repeated twice, but instead it writes "line         3"

[Barbara_P_Intel]

Thank you for taking the time to create such a nice reproducer! I see that it is a regression. I filed another bug for you, CMPLRLIBS-34350. I'll keep you posted on its progress to fix.

[Scott_Boyce]

Great to hear about the bug fix being in the works.

I did try oneAPI 2023.1 April download but I still get the same compiler error message when compiling with ifx.

[Scott_Boyce]

Also, it does compile with ifort, but still has the same error when running the examples (reported earliar with the get_line code).

[Barbara_P_Intel]

The ICE is fixed in the compiler that will be released around mid-year 2023.

Correct. No fix yet for the get_line issue.

[Scott_Boyce]

I just wanted to follow up with the get_line issue?

Several of our partner research agencies have updated their compute clusters to oneAPI 2023 and now cannot compile the code.

Its been causing a lot of trouble getting the old compilers installed (the cluster staff wont do it).

Thanks again for fixing this.

[Barbara_P_Intel]

No fix yet for the backspace issue. I asked for an update.

[Barbara_P_Intel]

The compiler team reports that work is in progress on this issue.

[Barbara_P_Intel]

The ICE you reported is fixed in the version of ifx that is part of oneAPI HPC Toolkit 2023.2 that was recently released. Please try it!

The backspace issue works in an internal version of the compiler that will be available before the end of 2023.

[Scott_Boyce]

That is good to know, you beat me to the message.

I had just downloaded and compiled the software with IFORT and IFX, but both have the same backspace issue and was about to report that.

Thanks for moving forward an will keep an eye out for the next release with the fix.

[Barbara_P_Intel]

@Scott_Boyce, the backspace issue is fixed now, too, in the 2024.0 release of ifx and ifort.

Please try it!

[Oscar8]

Hi,

Here recent installation with Intel 2024.0 release for Abaqus usage in VS2019.

The error persists: 

forrtl: severe (24): end-of-file during read, unit -131, file D:\Repository\onebyone\originalc\code\sro_wing_fnm_disbond.info
Image                            PC                                       Routine           Line            Source
libifcoremd.dll             00007FFA090E29DE     Unknown       Unknown   Unknown
libifcoremd.dll             00007FFA09138E86     Unknown       Unknown   Unknown
standardU.dll               00007FF96C75C679     Unknown       Unknown   Unknown
standardU.dll               00007FF96C741590     Unknown       Unknown   Unknown
standardU.dll               00007FF96C737CCD     Unknown      Unknown    Unknown
ABQSMAStaCore.dll   00007FF9AEEF276A      openfs                     196    openfs.f
ABQSMAStaCore.dll   00007FF9B0CDC2C0     Unknown      Unknown    Unknown
standard.exe                00007FF691A50453      Unknown      Unknown    Unknown
standard.exe                00007FF691A4D798      Unknown      Unknown    Unknown
standard.exe                00007FF691A67768      Unknown      Unknown    Unknown
                                        00007FF691A30554      Unknown      Unknown    Unknown
Image                             PC Routine Line Source
libifcoremd.dll             00007FFA090E29DE      Unknown Unknown Unknown
libifcoremd.dll             00007FFA09138E86      Unknown Unknown Unknown
standardU.dll              00007FF96C75C679      Unknown Unknown Unknown
standardU.dll              00007FF96C741590      Unknown Unknown Unknown
standardU.dll              00007FF96C737CCD      Unknown Unknown Unknown
ABQSMAStaCore.dll  00007FF9AEEF276A      openfs 196 openfs.f
ABQSMAStaCore.dll  00007FF9B0CDC2C0      Unknown Unknown Unknown
standard.exe                00007FF691A50453      Unknown Unknown Unknown
standard.exe                00007FF691A4D798     Unknown Unknown Unknown
standard.exe                00007FF691A67768      Unknown Unknown Unknown
                                       00007FF691A30554       Unknown Unknown Unknown

------------------

In code: 

do
read(ifl, '(a)', iostat=ios) lineRaw
if (ios /= 0) exit
line = adjustl(trim(lineRaw))

if (line(1:1) == "*") then

---------------

As I read in other forum section (Solved: Re: READ command with IOSTAT does not capture end of file and returns error instead - Intel Community) , the problem is due to the intel release, Would it be possible to share the .exe file of the Intel oneApi 2021.4, so that I can solve the problem by re installing it ? I do not have that package any more.

Thank you.

Best regards, 
Oscar

[Steve_Lionel]

Actually, if you read through that entire thread, you'll see that the compiler release was not implicated, and that the actual cause of the issue was not identified. Since you have not provided a test case we can try ourselves, that does not depend on unavailable third-party software such as ABAQUS, I'm not sure what we can do for you here.

Take your code and turn it into a self-contained test, including the input file, and attach it here.