Bill Gunshannon <bill.gunshannon@gmail.com> writes:

> On 4/13/22 22:01, Rich Alderson wrote:
>> "Craig A. Berry" <craigberry@nospam.mac.com> writes:

>>> On 4/13/22 6:54 PM, Bob Gezelter wrote:

>>>> FORTRAN II (IBM 1620, circa 1960, 20K digits of storage) had full
>>>> subroutines and functions.

>>> OK. I read the Wikipedia article wrong, specifically with regard to
>>> functions and subroutines. The fact they had them doesn't mean they
>>> were used.

>>>> Admittedly, many of these codes were not written to modern engineering
>>>> standards, but one can decode them. Been there, done that (both in modern
>>>> times, and when I was an undergraduate).

>>> Right. And of course you can decode a 40,000-line program with no
>>> comments and 6-digit identifiers. But it's work. Arguably not worth
>>> the effort 10 years after they were written, much less 50.

>> FORTRAN IV was my first language, on an IBM 1401, in 1969. Functions and
>> subroutines were actively encouraged.

>> If you knew what you were talking about you might be dangerous.

> Wow, were you ever lucky. I did 1401 in 1971 and all we got was
> Autocoder. I'll bet you even had disks.

Yup, a pair of 1311s. No tape drives, though.

The system was installed at the school district offices; because it was not
utilized up to the lease minimum (IBM, after all), it was decided to offer a
half-year "Computer Math" class in all the high schools in the district. That
was in the fall semester, with linear algebra in the spring (1967 and 1968);
the class was so popular that it was offered again in spring 1969, so I got to
take it after all, at the end of my senior year.

Look at all the things which have come out of being president of the chess club
in 1968...

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

The problem is not Fortran, the problem is engineers that write code.
I suspect much of this code was not readable when it was written.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 4/14/22 15:00, Rich Alderson wrote:
> Bill Gunshannon <bill.gunshannon@gmail.com> writes:
>
>> On 4/13/22 22:01, Rich Alderson wrote:
>>> "Craig A. Berry" <craigberry@nospam.mac.com> writes:
>
>>>> On 4/13/22 6:54 PM, Bob Gezelter wrote:
>
>>>>> FORTRAN II (IBM 1620, circa 1960, 20K digits of storage) had full
>>>>> subroutines and functions.
>
>>>> OK. I read the Wikipedia article wrong, specifically with regard to
>>>> functions and subroutines. The fact they had them doesn't mean they
>>>> were used.
>
>>>>> Admittedly, many of these codes were not written to modern engineering
>>>>> standards, but one can decode them. Been there, done that (both in modern
>>>>> times, and when I was an undergraduate).
>
>>>> Right. And of course you can decode a 40,000-line program with no
>>>> comments and 6-digit identifiers. But it's work. Arguably not worth
>>>> the effort 10 years after they were written, much less 50.
>
>>> FORTRAN IV was my first language, on an IBM 1401, in 1969. Functions and
>>> subroutines were actively encouraged.
>
>>> If you knew what you were talking about you might be dangerous.
>
>> Wow, were you ever lucky. I did 1401 in 1971 and all we got was
>> Autocoder. I'll bet you even had disks.
>
> Yup, a pair of 1311s. No tape drives, though.
>
> The system was installed at the school district offices; because it was not
> utilized up to the lease minimum (IBM, after all), it was decided to offer a
> half-year "Computer Math" class in all the high schools in the district. That
> was in the fall semester, with linear algebra in the spring (1967 and 1968);
> the class was so popular that it was offered again in spring 1969, so I got to
> take it after all, at the end of my senior year.
>
> Look at all the things which have come out of being president of the chess club
> in 1968...
>

Mine (actually, the Army's) had a card reader, a card punch, a printer
and 8 tape drives. And a good time was had by all.....

Oh yeah, and an IBM Tech Rep who got rich off of that contract because
someone on the day shift couldn't keep their hands off the thermostat.

bill

On Thursday, April 14, 2022 at 2:20:01 PM UTC-7, Bill Gunshannon wrote:

(snip)

> Oh yeah, and an IBM Tech Rep who got rich off of that contract because
> someone on the day shift couldn't keep their hands off the thermostat.

I was not so many years ago, working with the IBM 360/20.

It seems that it has temperature compensation for the magnetic
core memory, so it can work in an office environment without
air conditioning.

Some of the earlier machines put the whole core memory in oil
to keep it cooled and constant temperature.

On 4/13/2022 10:02 PM, Don Baccus wrote:
> On Wednesday, April 13, 2022 at 6:49:05 PM UTC-7, Galen wrote:
>>> Fortran 66 was available for most of that period.
>>>
>>> Fortran IV is mostly the same as Fortran 66.
>>>
>>> And functions and subroutines was (per public sources - before
>>> my time) added in Fortran II in 1958.
>>>
>>> So not quite as bad.
>>>
>>> Anything text sucked big time in Fortran IV/66 but climate
>>> model should not be impacted by that.
>>>
>> It’s possible that, just as today, “seasoned” (I.e. older, perhaps set in
>> their ways) programmers in the 1960’s and 1970’s may not have used
>> new-dangled features like IF/THEN/ELSE or more modern loop constructs. And
>> may actually have liked assigned or computed GOTOs, three-branch IF, etc.
>>
>> Or they may have been constrained by out-of-date compilers on their
>> platforms.
>
> Here's a statement from NASA GISS regarding Model E. Which has been
> open source for years, now, if you want to take a look.
> Conceptually like most such models they're simple, pave the earth
> with pizza boxes stacked about 20 high these days, IIRC. The pizza
> boxes shrink and the number of them that are stacked increase as
> supercomputers increase in power, improving resolution.
> Understanding the model physics is, ummm, a tad more complex :).
> Also some of that increasing power generally is devoted to more
> complex physical modeling which works against how many more pizza
> boxes you can have in your model in reasonable time.
>
> Anyway, after a prologue pointing out that it has been around
> awhile:
>
> "While much of the subsequent reworking of the model has led to a
> reduction in these historical influences, some parts of the model
> still hark back to the days of punch cards, FORTRAN 66 and line
> printer output. A charitable interpretation would be that while
> embracing the new (FORTRAN 90/95, multi-processing, netcdf, etc.), we
> endeavour to maintain some of the more harmless GISS traditions
> (which some might call eccentricities) in a spirit of continuity with
> those who have previously worked on the model. On the other hand,
> some of those early decisions (for instance regarding diagnostics, or
> conservation properties) turned out to be very far-sighted and are a
> principle reason why the GISS series of models continue to play a
> useful and important role in the world of GCM simulations."

A quick look at a few randomly selected files from the
code at https://simplex.giss.nasa.gov/snapshots/
did not show very old code - lots of 90 and some
77 upgraded to 90.

Arne

In article <6258c4e1$0$693$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 4/13/2022 10:02 PM, Don Baccus wrote:
>> [snip]
>> "While much of the subsequent reworking of the model has led to a
>> reduction in these historical influences, some parts of the model
>> still hark back to the days of punch cards, FORTRAN 66 and line
>> printer output. A charitable interpretation would be that while
>> embracing the new (FORTRAN 90/95, multi-processing, netcdf, etc.), we
>> endeavour to maintain some of the more harmless GISS traditions
>> (which some might call eccentricities) in a spirit of continuity with
>> those who have previously worked on the model. On the other hand,
>> some of those early decisions (for instance regarding diagnostics, or
>> conservation properties) turned out to be very far-sighted and are a
>> principle reason why the GISS series of models continue to play a
>> useful and important role in the world of GCM simulations."
>
>A quick look at a few randomly selected files from the
>code at https://simplex.giss.nasa.gov/snapshots/
>did not show very old code - lots of 90 and some
>77 upgraded to 90.

Hmm, I'm not sure about that:

: chandra; pwd
/Users/cross/Downloads/modelE2_dev/model
: chandra; cloc .
613 text files.
568 unique files.
26 files ignored.

github.com/AlDanial/cloc v 1.92 T=1.67 s (340.1 files/s, 279550.2 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
Fortran 77 361 30746 86473 272461
Fortran 90 175 9720 14530 50033
C/C++ Header 11 264 0 1148
make 13 130 36 418
Korn Shell 1 31 35 128
m4 3 56 312 127
Pascal 2 1 0 120
C 2 33 27 78
-------------------------------------------------------------------------------
SUM: 568 40981 101413 324513
-------------------------------------------------------------------------------
: chandra;

I took a peak at a few files; it seems pretty archaic to me.
There's lots of C preprocessor abuse, too.

- Dan C.

On 4/15/2022 8:04 AM, Dan Cross wrote:
> In article <6258c4e1$0$693$14726298@news.sunsite.dk>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 4/13/2022 10:02 PM, Don Baccus wrote:
>>> [snip]
>>> "While much of the subsequent reworking of the model has led to a
>>> reduction in these historical influences, some parts of the model
>>> still hark back to the days of punch cards, FORTRAN 66 and line
>>> printer output. A charitable interpretation would be that while
>>> embracing the new (FORTRAN 90/95, multi-processing, netcdf, etc.), we
>>> endeavour to maintain some of the more harmless GISS traditions
>>> (which some might call eccentricities) in a spirit of continuity with
>>> those who have previously worked on the model. On the other hand,
>>> some of those early decisions (for instance regarding diagnostics, or
>>> conservation properties) turned out to be very far-sighted and are a
>>> principle reason why the GISS series of models continue to play a
>>> useful and important role in the world of GCM simulations."
>>
>> A quick look at a few randomly selected files from the
>> code at https://simplex.giss.nasa.gov/snapshots/
>> did not show very old code - lots of 90 and some
>> 77 upgraded to 90.
>
> Hmm, I'm not sure about that:
>
> : chandra; pwd
> /Users/cross/Downloads/modelE2_dev/model
> : chandra; cloc .
> 613 text files.
> 568 unique files.
> 26 files ignored.
>
> github.com/AlDanial/cloc v 1.92 T=1.67 s (340.1 files/s, 279550.2 lines/s)
> -------------------------------------------------------------------------------
> Language files blank comment code
> -------------------------------------------------------------------------------
> Fortran 77 361 30746 86473 272461
> Fortran 90 175 9720 14530 50033
> C/C++ Header 11 264 0 1148
> make 13 130 36 418
> Korn Shell 1 31 35 128
> m4 3 56 312 127
> Pascal 2 1 0 120
> C 2 33 27 78
> -------------------------------------------------------------------------------
> SUM: 568 40981 101413 324513
> -------------------------------------------------------------------------------
> : chandra;
>
> I took a peak at a few files; it seems pretty archaic to me.

If you look at the .f files that are supposedly 77 then
it really just are old fixed format - the code are full of
90 features.

Example advc1d.f - code starts in column 7, comments are
a c in column 1 - but the code would not build with 77.

Declarations like:

integer, intent(IN) :: kk

Loops like:

do k=1,kk
...
end do

Arne

In article <62596294$0$703$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 4/15/2022 8:04 AM, Dan Cross wrote:
>> In article <6258c4e1$0$693$14726298@news.sunsite.dk>,
>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 4/13/2022 10:02 PM, Don Baccus wrote:
>>>> [snip]
>>>> "While much of the subsequent reworking of the model has led to a
>>>> reduction in these historical influences, some parts of the model
>>>> still hark back to the days of punch cards, FORTRAN 66 and line
>>>> printer output. A charitable interpretation would be that while
>>>> embracing the new (FORTRAN 90/95, multi-processing, netcdf, etc.), we
>>>> endeavour to maintain some of the more harmless GISS traditions
>>>> (which some might call eccentricities) in a spirit of continuity with
>>>> those who have previously worked on the model. On the other hand,
>>>> some of those early decisions (for instance regarding diagnostics, or
>>>> conservation properties) turned out to be very far-sighted and are a
>>>> principle reason why the GISS series of models continue to play a
>>>> useful and important role in the world of GCM simulations."
>>>
>>> A quick look at a few randomly selected files from the
>>> code at https://simplex.giss.nasa.gov/snapshots/
>>> did not show very old code - lots of 90 and some
>>> 77 upgraded to 90.
>>
>> Hmm, I'm not sure about that:
>>
>> : chandra; pwd
>> /Users/cross/Downloads/modelE2_dev/model
>> : chandra; cloc .
>> 613 text files.
>> 568 unique files.
>> 26 files ignored.
>>
>> github.com/AlDanial/cloc v 1.92 T=1.67 s (340.1 files/s, 279550.2 lines/s)
>> -------------------------------------------------------------------------------
>> Language files blank comment code
>> -------------------------------------------------------------------------------
>> Fortran 77 361 30746 86473 272461
>> Fortran 90 175 9720 14530 50033
>> C/C++ Header 11 264 0 1148
>> make 13 130 36 418
>> Korn Shell 1 31 35 128
>> m4 3 56 312 127
>> Pascal 2 1 0 120
>> C 2 33 27 78
>> -------------------------------------------------------------------------------
>> SUM: 568 40981 101413 324513
>> -------------------------------------------------------------------------------
>> : chandra;
>>
>> I took a peak at a few files; it seems pretty archaic to me.
>
>If you look at the .f files that are supposedly 77 then
>it really just are old fixed format - the code are full of
>90 features.
>
>Example advc1d.f - code starts in column 7, comments are
>a c in column 1 - but the code would not build with 77.
>
>Declarations like:
>
> integer, intent(IN) :: kk

I think it's fair to say that there are some FORTRAN 90 features
thrown in, but I don't think it's fair to say that that makes it
FORTRAN 90 in anything other than a strictly technical sense.

Idly, I wonder if this is what "modernized" COBOL code bases
look like?

>Loops like:
>
> do k=1,kk
> ...
> end do

My VAX FORTRAN manual from well before 1990 shows support for
that particular construct. :-)

- Dan C.

On Friday, April 15, 2022 at 5:18:33 AM UTC-7, Arne Vajhøj wrote:
> On 4/15/2022 8:04 AM, Dan Cross wrote:
> > In article <6258c4e1$0$693$1472...@news.sunsite.dk>,
> > Arne Vajhøj <ar...@vajhoej.dk> wrote:
> >> On 4/13/2022 10:02 PM, Don Baccus wrote:
> >>> [snip]
> >>> "While much of the subsequent reworking of the model has led to a
> >>> reduction in these historical influences, some parts of the model
> >>> still hark back to the days of punch cards, FORTRAN 66 and line
> >>> printer output. A charitable interpretation would be that while
> >>> embracing the new (FORTRAN 90/95, multi-processing, netcdf, etc.), we
> >>> endeavour to maintain some of the more harmless GISS traditions
> >>> (which some might call eccentricities) in a spirit of continuity with
> >>> those who have previously worked on the model. On the other hand,
> >>> some of those early decisions (for instance regarding diagnostics, or
> >>> conservation properties) turned out to be very far-sighted and are a
> >>> principle reason why the GISS series of models continue to play a
> >>> useful and important role in the world of GCM simulations."
> >>
> >> A quick look at a few randomly selected files from the
> >> code at https://simplex.giss.nasa.gov/snapshots/
> >> did not show very old code - lots of 90 and some
> >> 77 upgraded to 90.
> >
> > Hmm, I'm not sure about that:
> >
> > : chandra; pwd
> > /Users/cross/Downloads/modelE2_dev/model
> > : chandra; cloc .
> > 613 text files.
> > 568 unique files.
> > 26 files ignored.
> >
> > github.com/AlDanial/cloc v 1.92 T=1.67 s (340.1 files/s, 279550.2 lines/s)
> > -------------------------------------------------------------------------------
> > Language files blank comment code
> > -------------------------------------------------------------------------------
> > Fortran 77 361 30746 86473 272461
> > Fortran 90 175 9720 14530 50033
> > C/C++ Header 11 264 0 1148
> > make 13 130 36 418
> > Korn Shell 1 31 35 128
> > m4 3 56 312 127
> > Pascal 2 1 0 120
> > C 2 33 27 78
> > -------------------------------------------------------------------------------
> > SUM: 568 40981 101413 324513
> > -------------------------------------------------------------------------------
> > : chandra;
> >
> > I took a peak at a few files; it seems pretty archaic to me.
> If you look at the .f files that are supposedly 77 then
> it really just are old fixed format - the code are full of
> 90 features.
>
> Example advc1d.f - code starts in column 7, comments are
> a c in column 1 - but the code would not build with 77.
>
> Declarations like:
>
> integer, intent(IN) :: kk
>
> Loops like:
>
> do k=1,kk
> ...
> end do
>
> Arne

As they said, they kept the "spirit" of some of the older code while embracing newer FORTRAN. :)

If they've been using some sort of source control software then it makes sense..

Rewriting bits to take advantage of F90 features while maintaining old-style formatting gives you meaningful diffs. If you go in to fix a bug or to improve the physics in a chunk of the code might as well take advantage of newer constructs. That chunk is going to show up in a diff whether or not you do so.

But taking advantage of the freedom to not start statements in column 7, etc, and reformatting whole files will yield diffs that essentially say "yep, the entire files are different". Not very useful for tracking the history of changes, it would for all practical purposes reset the baseline to the moment at which the file was reformatted.

Mixing styles within a single source file would just be confusing, there's something to be said for consistency.

On Friday, April 15, 2022 at 5:26:59 AM UTC-7, Dan Cross wrote:
> In article <62596294$0$703$1472...@news.sunsite.dk>,
> Arne Vajhøj <ar...@vajhoej.dk> wrote:
> >On 4/15/2022 8:04 AM, Dan Cross wrote:
> >> In article <6258c4e1$0$693$1472...@news.sunsite.dk>,
> >> Arne Vajhøj <ar...@vajhoej.dk> wrote:
> >>> On 4/13/2022 10:02 PM, Don Baccus wrote:
> >>>> [snip]
> >>>> "While much of the subsequent reworking of the model has led to a
> >>>> reduction in these historical influences, some parts of the model
> >>>> still hark back to the days of punch cards, FORTRAN 66 and line
> >>>> printer output. A charitable interpretation would be that while
> >>>> embracing the new (FORTRAN 90/95, multi-processing, netcdf, etc.), we
> >>>> endeavour to maintain some of the more harmless GISS traditions
> >>>> (which some might call eccentricities) in a spirit of continuity with
> >>>> those who have previously worked on the model. On the other hand,
> >>>> some of those early decisions (for instance regarding diagnostics, or
> >>>> conservation properties) turned out to be very far-sighted and are a
> >>>> principle reason why the GISS series of models continue to play a
> >>>> useful and important role in the world of GCM simulations."
> >>>
> >>> A quick look at a few randomly selected files from the
> >>> code at https://simplex.giss.nasa.gov/snapshots/
> >>> did not show very old code - lots of 90 and some
> >>> 77 upgraded to 90.
> >>
> >> Hmm, I'm not sure about that:
> >>
> >> : chandra; pwd
> >> /Users/cross/Downloads/modelE2_dev/model
> >> : chandra; cloc .
> >> 613 text files.
> >> 568 unique files.
> >> 26 files ignored.
> >>
> >> github.com/AlDanial/cloc v 1.92 T=1.67 s (340.1 files/s, 279550.2 lines/s)
> >> -------------------------------------------------------------------------------
> >> Language files blank comment code
> >> -------------------------------------------------------------------------------
> >> Fortran 77 361 30746 86473 272461
> >> Fortran 90 175 9720 14530 50033
> >> C/C++ Header 11 264 0 1148
> >> make 13 130 36 418
> >> Korn Shell 1 31 35 128
> >> m4 3 56 312 127
> >> Pascal 2 1 0 120
> >> C 2 33 27 78
> >> -------------------------------------------------------------------------------
> >> SUM: 568 40981 101413 324513
> >> -------------------------------------------------------------------------------
> >> : chandra;
> >>
> >> I took a peak at a few files; it seems pretty archaic to me.
> >
> >If you look at the .f files that are supposedly 77 then
> >it really just are old fixed format - the code are full of
> >90 features.
> >
> >Example advc1d.f - code starts in column 7, comments are
> >a c in column 1 - but the code would not build with 77.
> >
> >Declarations like:
> >
> > integer, intent(IN) :: kk
> I think it's fair to say that there are some FORTRAN 90 features
> thrown in, but I don't think it's fair to say that that makes it
> FORTRAN 90 in anything other than a strictly technical sense.
>
> Idly, I wonder if this is what "modernized" COBOL code bases
> look like?
> >Loops like:
> >
> > do k=1,kk
> > ...
> > end do
> My VAX FORTRAN manual from well before 1990 shows support for
> that particular construct. :-)
>
> - Dan C.
"My VAX FORTRAN manual from well before 1990 shows support for
that particular construct. :-)"

Extensions are often adopted by a standard's committee from existing implementations ...

On 4/15/2022 8:26 AM, Dan Cross wrote:
> In article <62596294$0$703$14726298@news.sunsite.dk>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 4/15/2022 8:04 AM, Dan Cross wrote:
>>> In article <6258c4e1$0$693$14726298@news.sunsite.dk>,
>>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> On 4/13/2022 10:02 PM, Don Baccus wrote:
>>>>> [snip]
>>>>> "While much of the subsequent reworking of the model has led to a
>>>>> reduction in these historical influences, some parts of the model
>>>>> still hark back to the days of punch cards, FORTRAN 66 and line
>>>>> printer output. A charitable interpretation would be that while
>>>>> embracing the new (FORTRAN 90/95, multi-processing, netcdf, etc.), we
>>>>> endeavour to maintain some of the more harmless GISS traditions
>>>>> (which some might call eccentricities) in a spirit of continuity with
>>>>> those who have previously worked on the model. On the other hand,
>>>>> some of those early decisions (for instance regarding diagnostics, or
>>>>> conservation properties) turned out to be very far-sighted and are a
>>>>> principle reason why the GISS series of models continue to play a
>>>>> useful and important role in the world of GCM simulations."
>>>>
>>>> A quick look at a few randomly selected files from the
>>>> code at https://simplex.giss.nasa.gov/snapshots/
>>>> did not show very old code - lots of 90 and some
>>>> 77 upgraded to 90.
>>>
>>> Hmm, I'm not sure about that:
>>>
>>> : chandra; pwd
>>> /Users/cross/Downloads/modelE2_dev/model
>>> : chandra; cloc .
>>> 613 text files.
>>> 568 unique files.
>>> 26 files ignored.
>>>
>>> github.com/AlDanial/cloc v 1.92 T=1.67 s (340.1 files/s, 279550.2 lines/s)
>>> -------------------------------------------------------------------------------
>>> Language files blank comment code
>>> -------------------------------------------------------------------------------
>>> Fortran 77 361 30746 86473 272461
>>> Fortran 90 175 9720 14530 50033
>>> C/C++ Header 11 264 0 1148
>>> make 13 130 36 418
>>> Korn Shell 1 31 35 128
>>> m4 3 56 312 127
>>> Pascal 2 1 0 120
>>> C 2 33 27 78
>>> -------------------------------------------------------------------------------
>>> SUM: 568 40981 101413 324513
>>> -------------------------------------------------------------------------------
>>> : chandra;
>>>
>>> I took a peak at a few files; it seems pretty archaic to me.
>>
>> If you look at the .f files that are supposedly 77 then
>> it really just are old fixed format - the code are full of
>> 90 features.
>>
>> Example advc1d.f - code starts in column 7, comments are
>> a c in column 1 - but the code would not build with 77.
>>
>> Declarations like:
>>
>> integer, intent(IN) :: kk
>
> I think it's fair to say that there are some FORTRAN 90 features
> thrown in, but I don't think it's fair to say that that makes it
> FORTRAN 90 in anything other than a strictly technical sense.

83.5

:-)

Point is that it is not 60's and 70's code using Fortran II, IV and 66.

It is 90 and 77 with 90 features mixed in.

The revision history at the bottom of advc1d.f are all from 2001-2006.

>> Loops like:
>>
>> do k=1,kk
>> ...
>> end do
>
> My VAX FORTRAN manual from well before 1990 shows support for
> that particular construct. :-)

That is how standards evolve.

If an implementation has a nice extension it gets added.

Arne

On 4/15/2022 8:32 AM, Don Baccus wrote:
> On Friday, April 15, 2022 at 5:18:33 AM UTC-7, Arne Vajhøj wrote:
>> On 4/15/2022 8:04 AM, Dan Cross wrote:
>>> I took a peak at a few files; it seems pretty archaic to me.
>> If you look at the .f files that are supposedly 77 then
>> it really just are old fixed format - the code are full of
>> 90 features.
>>
>> Example advc1d.f - code starts in column 7, comments are
>> a c in column 1 - but the code would not build with 77.
>>
>> Declarations like:
>>
>> integer, intent(IN) :: kk
>>
>> Loops like:
>>
>> do k=1,kk
>> ...
>> end do

> As they said, they kept the "spirit" of some of the older code while
> embracing newer FORTRAN. :)
>
> If they've been using some sort of source control software then it
> makes sense..
>
> Rewriting bits to take advantage of F90 features while maintaining
> old-style formatting gives you meaningful diffs. If you go in to fix a
> bug or to improve the physics in a chunk of the code might as well take
> advantage of newer constructs. That chunk is going to show up in a diff
> whether or not you do so.
>
> But taking advantage of the freedom to not start statements in column
> 7, etc, and reformatting whole files will yield diffs that
> essentially say "yep, the entire files are different". Not very
> useful for tracking the history of changes, it would for all
> practical purposes reset the baseline to the moment at which the file
> was reformatted.
>
> Mixing styles within a single source file would just be confusing,
> there's something to be said for consistency.
Of course it makes sense. Lots of places have done
something like that. And not just for Fortran.

But there is a big discrepancy between the actual code and the
early discussion we had about it here. We started talking II, IV
and 66. It it is really 77 and 90.

Arne

On Friday, April 15, 2022 at 5:40:53 AM UTC-7, Arne Vajhøj wrote:
> On 4/15/2022 8:32 AM, Don Baccus wrote:
> > On Friday, April 15, 2022 at 5:18:33 AM UTC-7, Arne Vajhøj wrote:
> >> On 4/15/2022 8:04 AM, Dan Cross wrote:
> >>> I took a peak at a few files; it seems pretty archaic to me.
> >> If you look at the .f files that are supposedly 77 then
> >> it really just are old fixed format - the code are full of
> >> 90 features.
> >>
> >> Example advc1d.f - code starts in column 7, comments are
> >> a c in column 1 - but the code would not build with 77.
> >>
> >> Declarations like:
> >>
> >> integer, intent(IN) :: kk
> >>
> >> Loops like:
> >>
> >> do k=1,kk
> >> ...
> >> end do
> > As they said, they kept the "spirit" of some of the older code while
> > embracing newer FORTRAN. :)
> >
> > If they've been using some sort of source control software then it
> > makes sense..
> >
> > Rewriting bits to take advantage of F90 features while maintaining
> > old-style formatting gives you meaningful diffs. If you go in to fix a
> > bug or to improve the physics in a chunk of the code might as well take
> > advantage of newer constructs. That chunk is going to show up in a diff
> > whether or not you do so.
> >
> > But taking advantage of the freedom to not start statements in column
> > 7, etc, and reformatting whole files will yield diffs that
> > essentially say "yep, the entire files are different". Not very
> > useful for tracking the history of changes, it would for all
> > practical purposes reset the baseline to the moment at which the file
> > was reformatted.
> >
> > Mixing styles within a single source file would just be confusing,
> > there's something to be said for consistency.
> Of course it makes sense. Lots of places have done
> something like that. And not just for Fortran.
>
> But there is a big discrepancy between the actual code and the
> early discussion we had about it here. We started talking II, IV
> and 66. It it is really 77 and 90.
>
> Arne

"But there is a big discrepancy between the actual code and the
early discussion we had about it here. We started talking II, IV
and 66. It it is really 77 and 90."

We don't know if they were talking about Model E or not, though.

On 4/15/2022 9:24 AM, Don Baccus wrote:
> On Friday, April 15, 2022 at 5:40:53 AM UTC-7, Arne Vajhøj wrote:
>> But there is a big discrepancy between the actual code and the
>> early discussion we had about it here. We started talking II, IV
>> and 66. It it is really 77 and 90.

> We don't know if they were talking about Model E or not, though.

True

Maybe there are D, C, B and A's.

Arne

On Friday, April 15, 2022 at 7:01:04 AM UTC-7, Arne Vajhøj wrote:
> On 4/15/2022 9:24 AM, Don Baccus wrote:
> > On Friday, April 15, 2022 at 5:40:53 AM UTC-7, Arne Vajhøj wrote:
> >> But there is a big discrepancy between the actual code and the
> >> early discussion we had about it here. We started talking II, IV
> >> and 66. It it is really 77 and 90.
>
> > We don't know if they were talking about Model E or not, though.
> True
>
> Maybe there are D, C, B and A's.
>
> Arne

"Maybe there are D, C, B and A's"

If you find any by those names, let me know. Perhaps they'd be written in Ada, BCPL, C, or Delphi, though.

Meanwhile, there are dozens of GCMs out there, many if not most written in FORTRAN.

NASA Model E is not the only one by any means.

For instance, the two professors are from MIT. There is a MIT general circulation model named, aptly enough, "MITgcm".

MITgcm is written in FORTRAN. So it is entirely possible that they were talking about this model, not Model E.

In article <625966c6$0$700$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 4/15/2022 8:26 AM, Dan Cross wrote:
>>[snip]
>> I think it's fair to say that there are some FORTRAN 90 features
>> thrown in, but I don't think it's fair to say that that makes it
>> FORTRAN 90 in anything other than a strictly technical sense.
>
>83.5
>
>:-)
>
>Point is that it is not 60's and 70's code using Fortran II, IV and 66.
>
>It is 90 and 77 with 90 features mixed in.
>
>The revision history at the bottom of advc1d.f are all from 2001-2006.

I think it's more likely you're seeing a single code base that's
been under more or less constant development for quite some
time, probably dating back to (at least...) the 1970s. The idea
that someone would include a revision history might be a
relatively recent introduction: consider Unix, for example; if
one looks at, say, the illumos code base one sees copyright
notices going back to the 80s on code that is known to be much
older.

Looking at this, one sees a mixture of styles and features from
several different FORTRAN versions and variants. And as has
been pointed out, this is just one GCM.

>>> Loops like:
>>>
>>> do k=1,kk
>>> ...
>>> end do
>>
>> My VAX FORTRAN manual from well before 1990 shows support for
>> that particular construct. :-)
>
>That is how standards evolve.
>
>If an implementation has a nice extension it gets added.

Of course! The point is that `END DO` does not imply FORTRAN 90
by itself.

- Dan C.

On Friday, April 15, 2022 at 5:18:33 AM UTC-7, Arne Vajhøj wrote:

(snip)

> If you look at the .f files that are supposedly 77 then
> it really just are old fixed format - the code are full of
> 90 features.

Tradition of Fortran compilers is that the .f extension is
for fixed form, and the .f90 extension free form, independent
of the actual standard that the program uses.

You can write Fortran 2018 code in fixed-form.

On 4/16/2022 5:05 PM, gah4 wrote:
> On Friday, April 15, 2022 at 5:18:33 AM UTC-7, Arne Vajhøj wrote:
>> If you look at the .f files that are supposedly 77 then
>> it really just are old fixed format - the code are full of
>> 90 features.
>
> Tradition of Fortran compilers is that the .f extension is
> for fixed form, and the .f90 extension free form, independent
> of the actual standard that the program uses.
>
> You can write Fortran 2018 code in fixed-form.

True.

s/are supposedly/could potentially be/w

Arne