Severe compiler/linker problems on macOS BigSur..11.0.1.

[metzgeriana]

For several years I have run three FORTRAN programs I had written (EWALD, CELMAP, and CNDOP) , using  the Intel compiler and run-time system on a 16-inch MacBookPro (presently MacOS Big Sur, release 11.01.1). Each program has about 6,000 lines of code, but the run time for the samples shown below should be less than 1 minute each. This year, things have gone bad. to very bad  

(1) CELMAP gave me no problems then or now.

(2) EWALD seemed to have complled and linked well, but an immediate run-time error of "input file not found" occurs every time. I sent EWALDO to a friend in Dresden, Germany: on his computer (I do not know which)  EWALD ran well and gave me a good output.

(3) I managed to work with improving CNDOP, but suddenly the output seemed to blank out matrices, and move them about, creating problem files. Transitioning from MacOS Catalina to macOS Big Sur (as has been mentioned in this forum) was not helpful. Finally "contact program support" warnings occurred, and even the command line "source /opt/intel/bin/compilervars.sh intel64" was demolished and could not be re-entered in Terminal.

I use dynamic core allocation (see source programs) but other mysterious bugs seem to exist. I am hereby sending you FORTRAN source code and input data.  HELP !!!!!

[mecej4]

Let us work with one program/input data pair at a time. Otherwise it can get very confusing for everyone concerned.

Celmap builds and runs with no error messages, as you state. There is, therefore, absolutely no reason to post that source file and the associated input data file. Remove them from the discussion.

With the next pair, Cndop and its data file, the program itself detects an error in the data, and aborts. We do not know what the input file is supposed to contain or what the program expects and how it gets processed, so we cannot help you.

For the last program, Ewald, you specified no input data file for unit-5, so the program cannot be run. If one of the other programs is expected to be run first and its output used as the input to Ewald, you have to state the details and the connections between the programs. The program attempts to read from unit number LAUXIN on line 1340, but that variable is undefined and the associated file was never opened. It appears that the source file ewald.for that you attached is an old version. The latest of the 4-digit years in the comment lines containing 'LAST CHANGE' is 1998. Your Dresden output, as well as your own output, show 2020. The implication is that the program source that you attached is not the one that produced either of the output files. This confusion needs to be removed.

I suggest that you deal with one program at a time, and keep each program and its files in a separate directory. It is not helpful to have a number of files starting with "FOR.05", etc. Give them some meaningful names instead, such as Cndop.INP, etc. That way, you will not use the input files crossed up.

As in your earlier post on the same topic, there is no evidence that the compiler or linker is doing anything wrong. Rather, there are bugs in the source code and there is unnecessary confusion -- the names of data files are confusingly similar and there is no clear indication of which program uses which files for input versus output. There is much scope for improvement here.

Two of the files that you attached, "FOR.06.DAT.txt.EWALD.from.Dresden doc.txt" and FOR.06.EWALD.TXT are byte-for-byte identical. It is odd that Ewald did not run successfully for you (you said it did not find an input file), but are we to believe that it still produced a complete output file and that output file matches the one from Dresden?

I think that the OS and compiler used are almost irrelevant. These are legacy Fortran 77 programs that read and write text files, and they should respond to testing and fixing on almost any computer with a Fortran compiler. You may want to look at this recent post regarding MacOS Big Sur not working well with older versions of Intel Fortran.

[metzgeriana]

My apologies. I appreciate your careful look at my difficulties.

Thanks to your general but helpful critique, and further work, by me all three FORTRAN programs (CELMAP, CNDOP, EWALD) now do work well. my title "Severe compiler/linker problems on macOS BigSur..11.0.1" was WRONG: the problem was with my code..... 

(1) I still have problems with my Macbook Pro: when I type in some text (say: banana) , the computer often but not always inserts the modern-day equivalent to <carriage return><several line feeds up or down>, so "banana" may end up either as "anaban" or else as "ban" with "ana" going wherever it wants to, up or down, either  in the same text or FORTRAN code , or elsewhere in some other file in the desktop. My local "apple genius" did not/could not fix it.

(2) a weird problem with THE FORTRAN code in CNDOP was that too many

(50) repetitions of (F9.4) would print only part of the line (I,II) and swallow the rest.

If only 7 repetitions was used (second line of 80 FORMAT) (that was all I needed), then all was well. 

   70       WRITE (LOUTPT,80) I,II,EL(ANII),ORB(L),(A(I,J),J=M,K)       CNI47300

    80      FORMAT(I4,I3,A4,1X,A4,50(F9.4))                                           CNI47320

    80       FORMAT(I4,I3,A4,1X,A4,7(F9.4))                                             CNI47310

For EWALD specifying the  directory (/desktop) saved everything:

OPEN (UNIT=LOUTPT,FILE='desktop/FOR.06',STATUS='REPLACE')

OPEN (UNIT=LINPUT,FILE='desktop/FOR.07',STATUS='OLD')

while omitting /desktop caused an aborted run.

Once again, thanks for looking fairly carefully at my problems.

[mecej4]

Glad to hear that you are able to get things to work better.

Regarding issue (1) (keyboard input getting changed): if you are using an editor that attempts to autofill or autocorrect input text, turn those features off. I do not have a Mac, so I cannot be more specific.

Regarding issue (2) (long lines of formatted output not coming out correctly): the default RECL value for formatted sequential output is 132 bytes. Output records that are longer than 132 characters will be folded into multiple lines. You can control the RECL value by specifying the desired value in the file OPEN statement, as you can see explained in the reference manual.

Please note that /desktop/FOR.06 and desktop/FOR.06 are quite different. There is only one /desktop (at least so for each user), but you can create as many sub-directories called "desktop" as you please. Details depends on the operating system and user permissions.