topic Re: Read statements changed in latest intel release in Intel® Fortran Compiler

Read statements changed in latest intel release

Bowman__Eric — Thu, 03 Mar 2022 23:16:00 GMT

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

Re: Read statements changed in latest intel release

mecej4 — Fri, 04 Mar 2022 03:43:18 GMT

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?

Re: Read statements changed in latest intel release

Bowman__Eric — Fri, 04 Mar 2022 16:25:05 GMT

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.

Re: Read statements changed in latest intel release

Bowman__Eric — Fri, 04 Mar 2022 16:29:05 GMT

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

Re: Read statements changed in latest intel release

Bowman__Eric — Fri, 04 Mar 2022 17:02:14 GMT

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

Re: Read statements changed in latest intel release

mecej4 — Fri, 04 Mar 2022 17:05:22 GMT

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.

Re: Read statements changed in latest intel release

JohnNichols — Sat, 05 Mar 2022 00:08:11 GMT

! 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.

Re: Read statements changed in latest intel release

mecej4 — Sat, 05 Mar 2022 00:42:37 GMT

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.

Re: Read statements changed in latest intel release

JohnNichols — Sat, 05 Mar 2022 02:20:03 GMT

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.

Re: Read statements changed in latest intel release

Bowman__Eric — Thu, 10 Mar 2022 14:08:01 GMT

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

Re: Read statements changed in latest intel release

Bowman__Eric — Thu, 10 Mar 2022 15:07:06 GMT

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?

Re: Read statements changed in latest intel release

Steve_Lionel — Thu, 10 Mar 2022 20:57:06 GMT

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 :

Re: Read statements changed in latest intel release

Bowman__Eric — Thu, 10 Mar 2022 22:13:11 GMT

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.

Re: Read statements changed in latest intel release

mecej4 — Fri, 11 Mar 2022 01:58:56 GMT

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.

Re: Read statements changed in latest intel release

cryptogram — Fri, 11 Mar 2022 13:41:02 GMT

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.

Re: Read statements changed in latest intel release

mecej4 — Fri, 11 Mar 2022 14:15:40 GMT

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.

Re: Read statements changed in latest intel release

Bowman__Eric — Fri, 11 Mar 2022 17:59:25 GMT

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.

Re: Read statements changed in latest intel release

Bowman__Eric — Fri, 11 Mar 2022 18:03:48 GMT

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.

Re: Read statements changed in latest intel release

Bowman__Eric — Fri, 11 Mar 2022 18:29:04 GMT

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.

Re: Read statements changed in latest intel release

Bowman__Eric — Fri, 11 Mar 2022 18:50:56 GMT

The issue was the extra space in the input file.

Thanks for all your help.

Eric