#15 Code in violation of the Fortran standard for fixed format sources.

[Kurt Lust]

Line 1208 of Source/ffdreiding in the version 8.2.0 download or line 1214 in that file as I find it currently in the Code section on this SourceForge site (and which I have attached). is 74 characters long which violates the Fortran standard for fixed file format (72 characters).

A compiler with a Fortran-aware preprocessor (I had it with the Intel compiler) will neglect the characters at position 73 and 74, even in the preprocessor phase. Hence this will generate one or two error messages during compilation (one because the closing ) is missing and possibly another one that it doesn't know the symbol TOR_STYLE_DREIDIN without the G either). A pure C preprocessor (which I think is the case with gfortran) might replace TOR_STYLE_DREIDING with 15, thus shortening the line to within the 72 character limit which may be while the code compiled during development.

I do realise that many Fortran compilers have an option to tell the compiler to accept longer lines. However, that isn't guaranteed to work either as you add the options for the Fortran compiler to the link line which uses the C compiler. If that compiler does not recognize that option, it may produce an error and the code may fail to link.

In my case (Intel compilers and MPI) I did manage to solve the problem using a flag to the Fortran compiler. Intel has multiple options. Some caused a failure as the option was not understood by the C compiler, but there is one that kind of made it through the C compiler also (hopefully without side effects, I'm only compiling this for a user of our system so I cannot test this).

The most robust solution would be to simply make sure all non-comment lines stay within the 72-character limit . I am not sure if there are such lines in other files also; I didn't try to patch and recompile until I had found all too long lines. An alternative solution would be to not use the Fortran flags while linking but the C flags and document that the user should specify an option for the Fortran compiler to allow for longer lines in fixed format sources, though there is no guarantee that every compiler will have such an option as the standard does not require it.

[Marcus Martin]

Thanks for that bug report. Other people had similar issues lately so I had already been working on a fix. The configure file was modified to work better with Intel compilers and I also fixed that mistake where I went over the line limit with the preprocessor options.

Version 8.2.1 is now available and should resolve your problems. If you see anything else please let me know. I do not have a machine setup with the combination of operating system and compiler that is giving folks trouble (seems like Redhat-Intel is finding these problems and I use Ubuntu-GNU for development) so I need the feedback to know for sure if my fixes resolved the problem entirely.

thanks,

Marcus

[Kurt Lust]

Sorry for not answering sooner. The mail from SourceForge landed in my spam folder.

I tested 8.2.1. There is one problem remaining: Source/schedule.F line 277 where the closing paranthese is in column 73.

Since you are so responsive and take bug reports serious, I decided to invest some more time into it. I modified that file (split the line) and I can confirm that after that change it compiled on both a CentOS/RHEL 8 and CentOS/RHEL 7 system with the Intel 2020 compilers (using the original release on the CentOS 8 system and the update 2 release on the CentOS 7 system, but that was only because that is the release that we currently use on those systems). I didn't try all examples, but I did test one of them which produced results that to me seem correct. I compiled both with and without --enable-mpi but did not yet test the MPI version. I leave that to our user who is just starting so it may take a while before he even tries. (I am only a system support person on our site.)

[Marcus Martin]

Bug fix for this issue addressed in version 8.2.2.