Read statements changed in latest intel release

Bowman__Eric · ‎03-03-2022

say I have the following data in a text file:

0.0 0.0 20.00 0. 1. 0. 0.

and that I read it with the following statement:

READ(1,40)PSL,RANGE,TRIM,LIST,RDCH,CHARTF,CHARTS
40 FORMAT(7F10.2)

I know that the text in the text file does not exactly match the format descriptor, but this was not a problem in previous versions of the intel fortran compiler, it would read the data in just fine. Now it won't read it in unless I reformat my input decks to explicitly match the format descriptor.

Is this a compiler setting that got changed?

I noticed that a lot of the debug compiler flags were changed....which was a big headache.

Eric

mecej4 · ‎03-03-2022

I do not see any of the behavior changes that you mention. The following program works as expected with Ifort 2021.5 /Ifx 2022.0 .

program tread
implicit none
character(70) :: line='       0.0       0.0     20.00        0.        1.        0.        0.'
real psl,range,trim,list,rdch,chartf,charts
READ(line,40)PSL,RANGE,TRIM,LIST,RDCH,CHARTF,CHARTS
40 FORMAT(7F10.2)
print '(7ES12.4)',PSL,RANGE,TRIM,LIST,RDCH,CHARTF,CHARTS
end

On input with the Fw.d format, the presence of a decimal point in the input data causes the ".d" part of the format to be overridden.

What causes you to infer that "Now it won't read it in"? Reading formatted input is such a basic part of the Fortran language that no compiler would change its basic features and rules.

Do you have tabs or other "white-space" characters in your input files?

Bowman__Eric · ‎03-04-2022

if I run the program with the above input, some of the values are read incorrectly.

If I run the program with the below input, all values are read in correctly.

0.00 0.00 20.00 0.00 1.00 0.00 0.00

I can tell because I have debugged the application with both input files.

This all worked just fine before the last update and now it does not work correctly, so intel clearly changed something.

Bowman__Eric · ‎03-04-2022

I'm working on an app that reproduces the issue.

Bowman__Eric · ‎03-04-2022

This is going to take me a while to reproduce and share without sharing proprietary info, Thanks for your help guys. my guess is I'll have something some time next week.

Eric

mecej4 · ‎03-04-2022

Please do not post data into the body of your reply, since column formatting and white space characters can become changed when you do so. If that happens, the error may not be reproducible.

Instead, zip up the program and data files and attach the zip files to your reply.

JohnNichols · ‎03-04-2022

!  Console26.f90 
!
!  FUNCTIONS:
!  Console26 - Entry point of console application.
!

!****************************************************************************
!
!  PROGRAM: Console26
!
!  PURPOSE:  Entry point for the console application.
!
!****************************************************************************

    program Console26

    implicit none
    real*8 PSL,RANGE,TRIM,LIST,RDCH,CHARTF,CHARTS

    ! Variables

    ! Body of Console26
    print *, 'Hello World'
    open(12,file="Data.in",status = "unknown")
    
    READ(12,*)PSL,RANGE,TRIM,LIST,RDCH,CHARTF,CHARTS
40 FORMAT(7F10.2)
write(*,*)PSL,RANGE,TRIM,LIST,RDCH,CHARTF,CHARTS

    end program Console26

your code and then changing to the

above code

0123456789012345678901234567890123456789012345678901234567890123456789
0.0       0.0     20.00        0.        1.        0.        0.

Your text file is simply wrong for this format, unless all I learnt about data entry is not correct.

DO 20 I=1,NT
	 READ(1,*)CHAIN(1,I),CHAIN(2,I),DESIGN(I),NCHAIN(I),IETA(I)
     1                ,IETB(I)
     1           ,IMANN(I),ILINTO(I),IMANTO(I),DIAS(I),ICOVER(I)
21       FORMAT(3F10.3,I3,F10.3)
20	CONTINUE

This code is straight out of 1986, it has not been changed, the data file looks like :

TEST1.RPT
TEST1.SER
1
TEST1.DXF
33
      .000   122.970   121.000   20    0    0    0    1    1      .000  0
    50.950   124.020   123.000   20    0    0    0    1    1      .000  0
   102.730   125.410   124.000   20    0    0    0    1    2      .000  0
   104.539   125.504      .000   21    0    0    0    0    0      .000  0
   105.553   125.080      .000   24    0    0    0    0    0      .000  0
   107.210   125.670      .000   21    0    0    0    0    0      .000  0
   108.940   125.794      .000   25    0    0    0    0    0      .000  0
   111.739   125.942      .000   25    0    0    0    0    0      .000  0
   114.438   125.884      .000   25    0    0    0    0    0      .000  0
   116.635   125.623      .000   21    0    0    0    0    0      .000  0
   162.103   126.680   126.000   20    0    0    0    1    3      .000  0
   214.489   128.590   127.000   20    0    0    0    1    4      .000  0
   264.482   131.260   130.000   20    0    0    0    1    5      .000  0
   306.002   134.527      .000   25    0    0    0    0    0      .000  0
   309.715   134.722      .000   25    0    0    0    0    0      .000  0
   312.636   134.727      .000   25    0    0    0    0    0      .000  0
   315.300   134.515   134.890   28    1    0    0    0    0   375.000  0
   317.015   135.015      .000   21    0    0    0    0    0      .000  0
   319.042   135.260   134.000   20    0    0    0    1    6      .000  0
   359.090   134.920   134.000   20    0    0    0    1    7      .000  0
   387.614   135.280   134.000   20    0    0    0    1    8      .000  0
   389.290   135.191      .000   24    0    0    0    0    0      .000  0
   390.028   135.359      .000   25    0    0    0    0    0      .000  0
   395.739   135.164      .000   25    0    0    0    0    0      .000  0
   401.535   135.649      .000   25    0    0    0    0    0      .000  0
   422.401   136.108   136.008   22    0    0    0    0    0   100.000  0
   446.452   136.649      .000   23    0    0    0    0    0      .000  0
   450.884   136.760   136.000   20    0    0    0    1    9      .000  0
   478.787   137.215      .000   30    0    0    0    0    0      .000  0
   486.550   137.294      .000    4    0    0    0    0    0      .000  0
   507.131   137.480   136.000   20    0    0    0    1   10      .000  0
   546.375   137.385      .000   30    0    0    0    0    0      .000  0
   554.701   137.290   136.000   20    0    0    0    1   11      .000  0
100.0
1000.0
200.0
120.0
2.5
10.0

This file was assembled from surveyor data files, very quickly I moved to * format as people made mistakes.

mecej4 · ‎03-04-2022

The line of data in the initial post has seven leading blanks. Without their being present, the format string will not match the data.

Every field in the data has an explicit decimal point. That suggests that the variable LIST should also be REAL or Double Precision.

JohnNichols · ‎03-04-2022

CSV is so much easier to follow. I agree on the LIST. Does it matter if they are real or real*8? They will all fit. I just changed them from 0. so I could see where they were going.

Bowman__Eric · ‎03-10-2022

Thank you for all your comments, I learn a lot every time I post on this forum. (learning by firehose really).

I know the formatting and the code are not ideal ( I Inherited them) but they have been working for almost 30 years and should continue to work the same, especially since they are fixed-format fortran.

I am not using this code moving forward except to validate that my new code produces the same results as the original code, so I cannot make any changes to it or else my test would be invalidated, I just need it to compile the same way it has been since 1996.

In other words, I'm not asking how to rewrite the code or edit the input files to make things work; I'm asking what has changed recently so that this code that worked fine recently does not work fine any more?

I have a reproduction on my end but it has proprietary code in it. I am working on removing that proprietary code so that I can share a full working reproduction here. Hopefully I'll have that done today, but I only work on this project on Thursdays so if not today next week.

I actually had it striped down to just those basic reads and writes and the problem went away, so there must be a more complex interaction going on than just those read lines.

Eric

Bowman__Eric · ‎03-10-2022

I can now reproduce the issue. If you run the program with "input1.txt" some of the values are read incorrectly. If you run the program with "input2.txt" the values are read correctly. Either input file would have read correctly up until a recent update.

Any thoughts on what has changed?

Steve_Lionel · ‎03-10-2022

I'm not seeing any difference in the output between the 19.1 compiler and the 2021.5 compiler. What is supposed to be "incorrect"?

19.1
D:\Projects\FP1_Original_Production>source.exe
 ENTER INPUT FILE NAME :  input1.txt


      GENERAL DATA
      ────────────
           MODE       NBL       INP     KWNCH    WTWNCH       PSL     RANGE
             0.        3.        1.        1.      470.      3.00      0.00
           TRIM      LIST      RDCH    CHARTF    CHARTS    CHARTO    CHARTM
           0.00      0.00      20.0        0.        0.        0.        0.
         CHARTL        NR    REGION   NPLMAX1   NPLMAX2    TIPSYM     TIPPC
             1.       10.        5.        5.        5.        1.      0.85
 ENTER INPUT FILE NAME :

D:\Projects\FP1_Original_Production>source.exe
 ENTER INPUT FILE NAME :  input2.txt


      GENERAL DATA
      ────────────
           MODE       NBL       INP     KWNCH    WTWNCH       PSL     RANGE
             0.        3.        1.        1.      470.      3.00      0.00
           TRIM      LIST      RDCH    CHARTF    CHARTS    CHARTO    CHARTM
           0.00      0.00      20.0        0.        1.        0.        0.
         CHARTL        NR    REGION   NPLMAX1   NPLMAX2    TIPSYM     TIPPC
             1.       10.        5.        5.        5.        1.      0.85
 ENTER INPUT FILE NAME :

2021.5
D:\Projects\FP1_Original_Production>source.exe
 ENTER INPUT FILE NAME :  input1.txt


      GENERAL DATA
      ────────────
           MODE       NBL       INP     KWNCH    WTWNCH       PSL     RANGE
             0.        3.        1.        1.      470.      3.00      0.00
           TRIM      LIST      RDCH    CHARTF    CHARTS    CHARTO    CHARTM
           0.00      0.00      20.0        0.        0.        0.        0.
         CHARTL        NR    REGION   NPLMAX1   NPLMAX2    TIPSYM     TIPPC
             1.       10.        5.        5.        5.        1.      0.85
 ENTER INPUT FILE NAME :

D:\Projects\FP1_Original_Production>source.exe
 ENTER INPUT FILE NAME :  input2.txt


      GENERAL DATA
      ────────────
           MODE       NBL       INP     KWNCH    WTWNCH       PSL     RANGE
             0.        3.        1.        1.      470.      3.00      0.00
           TRIM      LIST      RDCH    CHARTF    CHARTS    CHARTO    CHARTM
           0.00      0.00      20.0        0.        1.        0.        0.
         CHARTL        NR    REGION   NPLMAX1   NPLMAX2    TIPSYM     TIPPC
             1.       10.        5.        5.        5.        1.      0.85
 ENTER INPUT FILE NAME :

Bowman__Eric · ‎03-10-2022

The values printed after reading input2.txt are correct.

This code was originally written by someone who used the microsoft fortran compiler, and either of those input files would work with no difference in result. I took his source code and compiled it using the intel compiler about a year ago and got the same results as the microsoft compiler. I've recently updated to the latest oneAPI compiler and now it's not working the same as the microsoft compiler.

I'm really at a loss what could have changed between a year ago and now. I haven't touched the code.

mecej4 · ‎03-10-2022

Your program uses variables YR and DAY without type declarations, so they are treated as REAL. However, those variables are passed as arguments to GETDAT, which expects INTEGER arguments. Given such errors, the output of your program is unpredictable. In fact, compiling with the FPS4 compiler with the /4Yb option and running gives:

ENTER INPUT FILE NAME :  input1.txt

Source.for(27) : run-time error F6206: WRITE(output.txt)
- E, F, D or G edit descriptor expected for REAL

Execution traceback:
                from INPUT in Source.for(27)
                from main program in Source.for(3)

As Steve_Lionel stated, we cannot discern what is wrong in the output without your telling us. After all, running a program with different input files will generally give different output files, even when the program is error-free.

cryptogram · ‎03-11-2022

I'd guess he was expecting to CHARTS to be 1.0 in both outputs. But if you look at input1.txt carefully, you can see

why the program outputs 0

      TRIM      LIST      RDCH    CHARTF    CHARTS     CHRTO    CHARTM
        0.        0.       20.        0.         1.        0.        0.
1234567890123456789012345678901234567890123456789012345678901234567890

The numbers are read with 7F10.2 format, so I've added a line showing where each set of 10 columns starts and ends.

Starting with CHARTS, the alignment within the line is off. The decimal point for "1." is actually in the next set. This makes the

input for CHARTS as 9 blanks followed by a 1, and since there is no explicit decimal point, the implicit decimal point from F10.2 is

applied, which I believe would make the value of CHARTS equal to .01. When you print this using an f10.0 format, the output will be

0. Note that the decimal that should have the last character of CHARTS field is now the first character in the CHRTO field, which would cause additional problems if CHRTO or CHARTM was meant to be non-zero.

In the input2.txt file the same lines show this:

     TRIM      LIST      RDCH    CHARTF    CHARTS     CHRTO    CHARTM
      0.00      0.00     20.00      0.00       1.00      0.00      0.00
1234567890123456789012345678901234567890123456789012345678901234567890

The data here also doesn't quite align with the formatting. However in each of the misaligned inputs, the character bleeding over

into the next field is a 0, and the part with the decimal is still included within the 10 characters of the field, so you have an explicit decimal which overrides the implicit decimal in the F10.2 input format.

Bowman__Eric · ‎03-11-2022

Good catch, that would explain the issue and why all of the other input files without enough trailing digits have still worked for me in the past.

I'll look into it a bit and see for sure.

Bowman__Eric · ‎03-11-2022

I have declared YR, MNTH and DAY explicitly as integers to make sure that's not causing any problems and attached the revised code.

In both input files, the value of CHARTS is 1, but it is read as 0 from input1.txt. Input1.txt and Input2.txt have the same exact input values in different formats. The two different formats were read in identically by previous versions of both the microsoft and the intel compiler, but with a recent release of the intel compiler they are no longer read in the same.

mecej4 · ‎03-11-2022

Cryptogram, you have advanced one way of analyzing the problem, namely, assuming that the format string is correct and explaining how the data does not adhere to the format and how the data line gets interpreted given a fixed format string. We could follow a different path, and discuss variations of the format string and how those would affect the interpretation of a fixed data input line.

We could also take a step back, remember that a program implements ideas and algorithms, and that it is far easier to start with clearly defined ideas and expectations as to output, and then devise/modify a program to achieve the objectives. I do not understand why the OP is so reluctant to express the ideas and expectations, and instead insists that a modern compiler should mimic the behavior of an old and somewhat discredited compiler when there are errors in the program and/or in the input data.

Bowman__Eric · ‎03-11-2022

I'm sorry if I haven't been clear about my ideas and expectations, although to be fair this is the first anyone has asked.

My assigned task is to modernize a substantial FORTRAN code that has been in use for about 30 years. One of the most difficult tasks with such a modernization is to validate the results I get from the new version. I can either validate the code by comparing outputs between the two programs or by comparing the output of the original program against hand calculations or some other trusted computational method. In this case It is much easier to maintain an original copy of the code and compare the results from the new version against it.

So, while comments about formatting and coding best practices help me tremendously as I refactor and create the new version, they do not help me keep an unchanged, working copy of the original code. As far as compilers go, I didn't ask that the latest intel compiler work like the Microsoft compiler, I asked that it work the same as previous versions of the intel compiler. I had no idea the Microsoft compiler was discredited, please try to remember that if you're a black belt, I'm a snowy white belt in the world of FORTRAN. I am an experienced programmer and engineer, but know very little of FORTRAN's idiosyncrasies...and there are many of them.

In the end it looks like it might have just been a formatting error on my part anyway, I'll look into that but either way thank you all for your patience and help.

Bowman__Eric · ‎03-11-2022

The issue was the extra space in the input file.

Thanks for all your help.

Eric

mecej4 · ‎03-12-2022

@Bowman__Eric wrote: "The issue was the extra space in the input file. "

That is only one of the issues.

Intel Fortran will happily let you read formatted real data fields into integer variables, integer input fields into real variables, and so on, if you do not turn on some of the checking options. I would not be surprised if, given a variable of one type and a format specifier that is unsuitable for that type, it ignores the destination type and simply transfers the bytes. Here is a test example.

Consider the following test program.

program mismatch
implicit none
integer i
real r
character(2) :: iline = '1.', jline='123'
read(iline,'(F2.1)')i !reading real number into integer variable using F format
print '(ES10.3,4x,I10)',i,i !printing integer using ES format
read(jline,'(I3)')r  !reading integer data into real variable using I format
print '(ES10.3,4x,I10)',r,r !printing real using I format
end program

Without checking options, the output is

 1.000E+00    1065353216
 1.682E-44            12

Much higher levels of alertness and adequate checking procedures are necessary if you are going to depend on establishing reference runs based on large amounts of formatted input using fixed field widths.