I have created a GitHub repo https://github.com/Beliavsky/Fortran-code-on-GitHub/blob/main/README.md that lists 400+ Fortran codes by category, either by task, such as numerical integration, or domain, such as astrophysics. I will continue to update it.Please make suggestions for additions by creating an issue at the repo.
Another repo https://github.com/Beliavsky/Fortran-related-books lists books with Fortran code, other than textbooks.
A third repo https://github.com/Beliavsky/Burkardt-Fortran-90 categorizes the many Fortran codes of John Burkardt at https://people.sc.fsu.edu/~jburkardt/f_src/f_src.html
On Thursday, July 8, 2021 at 8:16:52 AM UTC-4, Beliavsky wrote:it. Please make suggestions for additions by creating an issue at the repo.
I have created a GitHub repo https://github.com/Beliavsky/Fortran-code-on-GitHub/blob/main/README.md that lists 400+ Fortran codes by category, either by task, such as numerical integration, or domain, such as astrophysics. I will continue to update
Another repo https://github.com/Beliavsky/Fortran-related-books lists books with Fortran code, other than textbooks.
A third repo https://github.com/Beliavsky/Burkardt-Fortran-90 categorizes the many Fortran codes of John Burkardt at https://people.sc.fsu.edu/~jburkardt/f_src/f_src.htmlKudos on the great effort, such initiatives are of tremendous help to boost the "ecosystem" around Fortran. Thank you.
I have created a GitHub repo https://github.com/Beliavsky/Fortran-code-on-GitHub/blob/main/README.md that lists 400+ Fortran codes by category, either by task, such as numerical integration, or domain, such as astrophysics. I will continue to update it.Please make suggestions for additions by creating an issue at the repo.
Another repo https://github.com/Beliavsky/Fortran-related-books lists books with Fortran code, other than textbooks.
A third repo https://github.com/Beliavsky/Burkardt-Fortran-90 categorizes the many Fortran codes of John Burkardt at https://people.sc.fsu.edu/~jburkardt/f_src/f_src.html
On 7/8/2021 7:16 AM, Beliavsky wrote:it. Please make suggestions for additions by creating an issue at the repo.
I have created a GitHub repo https://github.com/Beliavsky/Fortran-code-on-GitHub/blob/main/README.md that lists 400+ Fortran codes by category, either by task, such as numerical integration, or domain, such as astrophysics. I will continue to update
Not sure the purpose other than a list but RSICC Radiation Safety
Information Computer Center at ORNL is the repository of almost all the shielding and other reactor codes in use or past use in the non-defense-specific nuclear power field.
I have created a GitHub repo https://github.com/Beliavsky/Fortran-code-on-GitHub/blob/main/README.md that lists 400+ Fortran codes by category, either by task, such as numerical integration, or domain, such as astrophysics. I will continue to update it.Please make suggestions for additions by creating an issue at the repo.
Another repo https://github.com/Beliavsky/Fortran-related-books lists books with Fortran code, other than textbooks.
A third repo https://github.com/Beliavsky/Burkardt-Fortran-90 categorizes the many Fortran codes of John Burkardt at https://people.sc.fsu.edu/~jburkardt/f_src/f_src.html
dpb <none@none.net> schrieb:it. Please make suggestions for additions by creating an issue at the repo.
On 7/8/2021 7:16 AM, Beliavsky wrote:
I have created a GitHub repo https://github.com/Beliavsky/Fortran-code-on-GitHub/blob/main/README.md that lists 400+ Fortran codes by category, either by task, such as numerical integration, or domain, such as astrophysics. I will continue to update
Not sure the purpose other than a list but RSICC Radiation Safety
Information Computer Center at ORNL is the repository of almost all the
shielding and other reactor codes in use or past use in the
non-defense-specific nuclear power field.
Seems to be somewhat restricted... when I click on any link below
https://www.ornl.gov/project/radiation-safety-information-computational-center-rsicc
I get "You are not authorized to access this page."
A suggestion for your "interoperability" section: the Forpy package (for Fortran-Python interop), developed by Elias Rabel:
https://github.com/ylikx/forpy
On 7/9/2021 1:19 AM, Thomas Koenig wrote:it. Please make suggestions for additions by creating an issue at the repo. >>>>
dpb <none@none.net> schrieb:
On 7/8/2021 7:16 AM, Beliavsky wrote:
I have created a GitHub repo https://github.com/Beliavsky/Fortran-code-on-GitHub/blob/main/README.md that lists 400+ Fortran codes by category, either by task, such as numerical integration, or domain, such as astrophysics. I will continue to update
Not sure the purpose other than a list but RSICC Radiation Safety
Information Computer Center at ORNL is the repository of almost all the
shielding and other reactor codes in use or past use in the
non-defense-specific nuclear power field.
Seems to be somewhat restricted... when I click on any link below
https://www.ornl.gov/project/radiation-safety-information-computational-center-rsicc
I get "You are not authorized to access this page."
Oh. The actual RSICC portal is at
<https://rsicc.ornl.gov/Default.aspx>
I have created a GitHub repo https://github.com/Beliavsky/Fortran-code-on-GitHub/blob/main/README.md that lists 400+ Fortran codes by category, either by task, such as numerical integration, or domain, such as astrophysics. I will continue to update it.Please make suggestions for additions by creating an issue at the repo.
Another repo https://github.com/Beliavsky/Fortran-related-books lists books with Fortran code, other than textbooks.
A third repo https://github.com/Beliavsky/Burkardt-Fortran-90 categorizes the many Fortran codes of John Burkardt at https://people.sc.fsu.edu/~jburkardt/f_src/f_src.html
dpb <none@none.net> schrieb:update it. Please make suggestions for additions by creating an issue at the repo.
On 7/9/2021 1:19 AM, Thomas Koenig wrote:
dpb <none@none.net> schrieb:
On 7/8/2021 7:16 AM, Beliavsky wrote:
I have created a GitHub repo https://github.com/Beliavsky/Fortran-code-on-GitHub/blob/main/README.md that lists 400+ Fortran codes by category, either by task, such as numerical integration, or domain, such as astrophysics. I will continue to
Not sure the purpose other than a list but RSICC Radiation Safety
Information Computer Center at ORNL is the repository of almost all the >>>> shielding and other reactor codes in use or past use in the
non-defense-specific nuclear power field.
Seems to be somewhat restricted... when I click on any link below
https://www.ornl.gov/project/radiation-safety-information-computational-center-rsicc
I get "You are not authorized to access this page."
Oh. The actual RSICC portal is at
<https://rsicc.ornl.gov/Default.aspx>
Interesting, thanks!
I don't work in nuclear engineering myself, but I know somebody
who does, and I will forward this.
Oh. The actual RSICC portal is atThanks, I added RSICC to the Fortran Wiki software repositories page http://fortranwiki.org/fortran/show/Software+repositories . There probably many scientific and engineering disciplines with their own repositories of codes, some of which are in Fortran.
<https://rsicc.ornl.gov/Default.aspx>
--
On 7/9/2021 7:48 AM, Thomas Koenig wrote:
dpb <none@none.net> schrieb:
On 7/9/2021 1:19 AM, Thomas Koenig wrote:
dpb <none@none.net> schrieb:
On 7/8/2021 7:16 AM, Beliavsky wrote:
I have created a GitHub repo
https://github.com/Beliavsky/Fortran-code-on-GitHub/blob/main/README.md >>>>>> that lists 400+ Fortran codes by category, either by task, such as >>>>>> numerical integration, or domain, such as astrophysics. I will
continue to update it. Please make suggestions for additions by
creating an issue at the repo.
Not sure the purpose other than a list but RSICC Radiation Safety
Information Computer Center at ORNL is the repository of almost all
the
shielding and other reactor codes in use or past use in the
non-defense-specific nuclear power field.
Seems to be somewhat restricted... when I click on any link below
https://www.ornl.gov/project/radiation-safety-information-computational-center-rsicc
I get "You are not authorized to access this page."
Oh. The actual RSICC portal is at
<https://rsicc.ornl.gov/Default.aspx>
Interesting, thanks!
I don't work in nuclear engineering myself, but I know somebody
who does, and I will forward this.
It is a gold mine if one is in the area, indeed...
In professional life while still in the vendor fold before migrating to independent consulting role I was in the reactor physics side and there
was another group that did the stuff that required all the shielding calculations so I'm not all that familiar with those -- and it's been so
long now that I don't know what are the current codes still in use for
core design and fuel cycle analyses, etc., that was what I did. The big tool then was still PDQ-07/HARMONY (again, a proprietary version of) and
the internally-developed code used to generate few-group nuclear cross sections for input to those from the detailed multi-group ENDF tables.
That code was also FORTRAN + (originally Philco) assembly; it was
totally rewritten (my first major introduction to writing code) when
moved to the CDC machines.
There's another whole arena of reactor transient analyses for LOCA (loss
of coolant analysis) that was the holy grail of the safety analysis section. RELAP was the tool then; we ported it to the PC environment in
the days of the x386 by using a multiprocessor coprocessor board running
two 68332s with a FORTRAN compiler by a now defunct outfit whose name
now escapes me. We used this as the simulator in conjunction with the
real Foxboro IA control system hardware in doing the first NRC-accepted conversion from fully analog to a hybrid analog-digital control system
on a US PWR, replacing the feedwater control subsystem that had become obsolete and repair parts difficult to procure.
Eventually, the NRC left the dark ages and allowed modernized control
systems overall, but it was another 5 years or so after that before the
first transition in an operating US plant occurred.
Geezer tales aside, if one wants to add to the list of codes that were written in FORTRAN in all or in major part, there's a humongous list,
the majority of which I would think were/are.
What's happened in the last 20 years in the transition to the desktop/workstation I really don't know; I migrated totally away from
the large code environment to embedded systems and then instrumentation
and controls for the fossil utilites and other things by then...
I did do a few other pieces for ORNLL/NASA of some thermodynamics
simulations of heat exchangers and the like to modify them to account
for redesigns for the shuttle and some other experimental work in the
90s; those also were derived from original ORNL work in FORTRAN. Not surprising, I didn't find them in the RSICC archives; I don't know where
they might be, but I know that ORNL group also had a "veritable
plethora" of both production-type as well as research-level FORTRAN
codes for thermal analyses totally unrelated to anything nuclear.
Then, of course, there iss the highly classified defense related side of things that is its own private world. It was all FORTRAN originally,
too. I never did code development on that side; only peripheral
facilities work associated with the operations ends of things.
--
I'm eagerly anticipating some of the newer mini and micro/modular systems...and of course, fusion...before I die...:)
There's another whole arena of reactor transient analyses for LOCA (loss
of coolant analysis) that was the holy grail of the safety analysis section. RELAP was the tool then; we ported it to the PC environment in
the days of the x386 by using a multiprocessor coprocessor board running
two 68332s with a FORTRAN compiler by a now defunct outfit whose name
now escapes me. ...
I can't let that episode pass without at least one war story -- those
old enough to remember the CDC recall it was a 60 bit word as opposed to 32/64 and all that entails.
In addition, the CDC compilers decoded only the lower 18 bits of
integers for array address indexing wise; the wise guys who wrote RELAP
thus used those same variables for other purposes simultaneously by
storing other control and logic variables in the upper 32 bits.
Owing to this, masking/shifting with intrinsics in line ended up being a major performance bottleneck; eventually the compiler vendor made a
similar patch to the compiler for us.
IBM S/360 uses 24 bit addresses, and OS/360 uses the high byte often for other uses, especially in system control blocks. For S/370, LCM and STCM were added to allow load/store of some of the bytes of a register
(as selected by mask bits), with the primary use being addresses.
This, then, complicated the change to 31 bit addressing. Hardware still knows how to do operations ignoring the high byte. Also, many control
blocks have to be below 16M, and the system knows how to make that
work.
Not so many years later, the Apple Macintosh, using the 68000 processor
again with 24 bit addressing, again used the high bytes for other uses.
On Friday, July 9, 2021 at 10:54:48 AM UTC-7, dpb wrote:.
(snip)
I can't let that episode pass without at least one war story -- those
old enough to remember the CDC recall it was a 60 bit word as opposed to 32/64 and all that entails.
In addition, the CDC compilers decoded only the lower 18 bits ofIs this a software operation, or what the hardware did?
integers for array address indexing wise; the wise guys who wrote RELAP thus used those same variables for other purposes simultaneously by
storing other control and logic variables in the upper 32 bits.
Owing to this, masking/shifting with intrinsics in line ended up being a major performance bottleneck; eventually the compiler vendor made a
similar patch to the compiler for us.
IBM S/360 uses 24 bit addresses, and OS/360 uses the high byte often for other uses, especially in system control blocks. For S/370, LCM and STCM.
were added to allow load/store of some of the bytes of a register
(as selected by mask bits), with the primary use being addresses.
This, then, complicated the change to 31 bit addressing. Hardware still
knows how to do operations ignoring the high byte. Also, many control
blocks have to be below 16M, and the system knows how to make that
work.
Not so many years later, the Apple Macintosh, using the 68000 processor
again with 24 bit addressing, again used the high bytes for other uses. Though not quite as much as IBM, but it still took some time to get
older programs using them out. Not quite as deep into the OS, though,
as memory costs were less than in S/360 days.
I don't know of any OS/360 Fortran programs that used high bits of indexing that would be ignored by the hardware, but it should have been possible.
I suspect that there are more stories out there. Thanks for that one, though.
On Friday, July 9, 2021 at 10:54:48 AM UTC-7, dpb wrote:
(snip)
I can't let that episode pass without at least one war story -- those
old enough to remember the CDC recall it was a 60 bit word as opposed to
32/64 and all that entails.
In addition, the CDC compilers decoded only the lower 18 bits of
integers for array address indexing wise; the wise guys who wrote RELAP
thus used those same variables for other purposes simultaneously by
storing other control and logic variables in the upper 32 bits.
Is this a software operation, or what the hardware did?
On 7/9/2021 8:56 PM, gah4 wrote:
On Friday, July 9, 2021 at 10:54:48 AM UTC-7, dpb wrote:
In addition, the CDC compilers decoded only the lower 18 bits of
integers for array address indexing wise; the wise guys who wrote RELAP
thus used those same variables for other purposes simultaneously by
storing other control and logic variables in the upper 32 bits.
Is this a software operation, or what the hardware did?
I am not positive -- but I think it was just inherent in the compiler
that the variable as part of an indexing expression was silently masked whereas if fetched and stored the full integer value was retrieved (as
it was either way in the compiler running the coprocessor code, of
course, the cause of the problems).
The INEL guys had had packed program control data in the upper end --
since the code that used those was only needed on input/output
processing the overhead of the explicit bit-munging to get those values wasn't significant in overall run time.
Not so, of course, when the same variables were then used as the
indexing variables inside the bowels of the numerical iterations for the solution during the transient simulation...
When we were able to get the compiler vendor to make the change in their compiler to also use do that in generating the array addressing code instructions, its performance also soared in comparison to using the
explicit intrinsics that it didn't inline initially.
I still cannot recall the name of that little outfit out of California, though...they didn't make it when the PC soon evolved to the 286/386
machines and the compute power matched/exceeded the coprocessor
solutions at far less expense.
On 7/9/2021 8:47 AM, dpb wrote:.
...
There's another whole arena of reactor transient analyses for LOCA (loss
of coolant analysis) that was the holy grail of the safety analysis section. RELAP was the tool then; we ported it to the PC environment in
the days of the x386 by using a multiprocessor coprocessor board running two 68332s with a FORTRAN compiler by a now defunct outfit whose name
now escapes me. ...
I can't let that episode pass without at least one war story -- those
old enough to remember the CDC recall it was a 60 bit word as opposed to 32/64 and all that entails.
In addition, the CDC compilers decoded only the lower 18 bits of
integers for array address indexing wise;
the wise guys who wrote RELAP
thus used those same variables for other purposes simultaneously by
storing other control and logic variables in the upper 32 bits.
Owing to this, masking/shifting with intrinsics in line ended up being a major performance bottleneck; eventually the compiler vendor made a
similar patch to the compiler for us.
On Monday, July 12, 2021 at 7:19:00 AM UTC-7, dpb wrote:
On 7/9/2021 8:56 PM, gah4 wrote:
On Friday, July 9, 2021 at 10:54:48 AM UTC-7, dpb wrote:
(snip)
In addition, the CDC compilers decoded only the lower 18 bits of
integers for array address indexing wise; the wise guys who wrote RELAP >>>> thus used those same variables for other purposes simultaneously by
storing other control and logic variables in the upper 32 bits.
Is this a software operation, or what the hardware did?
I am not positive -- but I think it was just inherent in the compiler
that the variable as part of an indexing expression was silently masked
whereas if fetched and stored the full integer value was retrieved (as
it was either way in the compiler running the coprocessor code, of
course, the cause of the problems).
OK, it seems that addresses, and address arithmetic are done
in 18 bit address registers:
https://en.wikipedia.org/wiki/CDC_6600#Central_Processor_(CP)
(see the figure on the right)
So yes, indexing will be done in 18 bits, and ignore the rest.
...The INEL guys had had packed program control data in the upper end --
since the code that used those was only needed on input/output
processing the overhead of the explicit bit-munging to get those values
wasn't significant in overall run time.
Not so, of course, when the same variables were then used as the
indexing variables inside the bowels of the numerical iterations for the
solution during the transient simulation...
When we were able to get the compiler vendor to make the change in their
compiler to also use do that in generating the array addressing code
instructions, its performance also soared in comparison to using the
explicit intrinsics that it didn't inline initially.
I still cannot recall the name of that little outfit out of California,
though...they didn't make it when the PC soon evolved to the 286/386
machines and the compute power matched/exceeded the coprocessor
solutions at far less expense.
I remember FPS, Floating Point Systems, which made coprocessors
that could be used with VAX and some minicomputers of the time.
It seems that FPS was in Oregon, though.
I still cannot recall the name of that little outfit out of California,I remember FPS, Floating Point Systems, which made coprocessors
though...they didn't make it when the PC soon evolved to the 286/386
machines and the compute power matched/exceeded the coprocessor
solutions at far less expense.
that could be used with VAX and some minicomputers of the time.
It seems that FPS was in Oregon, though.
I used FPS attached processors all through the 1980s
You programmed them in assembler and fortran, both of which
were cross compilers than ran on a VAX front-end machine.
On 7/12/21 6:18 PM, gah4 wrote:
I still cannot recall the name of that little outfit out of California,I remember FPS, Floating Point Systems, which made coprocessors
though...they didn't make it when the PC soon evolved to the 286/386
machines and the compute power matched/exceeded the coprocessor
solutions at far less expense.
that could be used with VAX and some minicomputers of the time.
It seems that FPS was in Oregon, though.
I used FPS attached processors all through the 1980s. It was not PCs
that doomed them, but rather the rise of the cheap, unix based, RISC machines, which I also used during that time. Especially in the early
80s, they were very cost effective in delivering floating point
operations. You programmed them in assembler and fortran, both of which
were cross compilers than ran on a VAX front-end machine.
https://doi.org/10.1002/qua.560240865
$.02 -Ron Shepard
Not sure the purpose other than a list but RSICC Radiation Safety
Information Computer Center at ORNL is the repository of almost all the shielding and other reactor codes in use or past use in the non-defense-specific nuclear power field.
On 7/13/2021 11:40 AM, Ron Shepard wrote:...
On 7/12/21 6:18 PM, gah4 wrote:
...I used FPS attached processors all through the 1980s. It was not PCs
that doomed them, but rather the rise of the cheap, unix based, RISC
machines, which I also used during that time. Especially in the early
80s, they were very cost effective in delivering floating point
operations. You programmed them in assembler and fortran, both of
which were cross compilers than ran on a VAX front-end machine.
https://doi.org/10.1002/qua.560240865
$.02 -Ron Shepard
Yeah, but those were a whole different class than the one/ones we were
using that were just plug-ins into a PC that are talking about here.
I've gargled some, but found no references to anything similar to these
-- the last ones I recall were based on the i960 RISC processor as they
had passed Motorola by...on reflection I don't know what became of that system; I suppose at some point it was just pitched as obsolete or maybe
it was delivered with the systej, I just can't recall for sure.
About then is when my consulting clientele base begin to change markedly
and kinda' left that chapter behind and onto other areas with far fewer regulatory hassles.
On Thursday, July 8, 2021 at 5:19:47 PM UTC-7, dpb wrote:
(snip)
Not sure the purpose other than a list but RSICC Radiation Safety Information Computer Center at ORNL is the repository of almost all the shielding and other reactor codes in use or past use in the non-defense-specific nuclear power field.I tried looking there, but didn't see any code at all. Maybe I looked in the wrong place, though. Is there a link to any Fortran programs there?
On 7/13/2021 2:50 PM, dpb wrote:
On 7/13/2021 11:40 AM, Ron Shepard wrote:...
On 7/12/21 6:18 PM, gah4 wrote:
...I used FPS attached processors all through the 1980s. It was not PCs
that doomed them, but rather the rise of the cheap, unix based, RISC
machines, which I also used during that time. Especially in the early
80s, they were very cost effective in delivering floating point
operations. You programmed them in assembler and fortran, both of
which were cross compilers than ran on a VAX front-end machine.
https://doi.org/10.1002/qua.560240865
$.02 -Ron Shepard
Yeah, but those were a whole different class than the one/ones we were
using that were just plug-ins into a PC that are talking about here.
I've gargled some, but found no references to anything similar to these
-- the last ones I recall were based on the i960 RISC processor as they
had passed Motorola by...on reflection I don't know what became of that system; I suppose at some point it was just pitched as obsolete or maybe
it was delivered with the systej, I just can't recall for sure.
On Thursday, July 8, 2021 at 5:19:47 PM UTC-7, dpb wrote:
(snip)
Not sure the purpose other than a list but RSICC Radiation Safety
Information Computer Center at ORNL is the repository of almost all the
shielding and other reactor codes in use or past use in the
non-defense-specific nuclear power field.
I tried looking there, but didn't see any code at all. Maybe I looked in the wrong place, though. Is there a link to any Fortran programs there?
On 7/13/21 6:28 PM, dpb wrote:
On 7/13/2021 2:50 PM, dpb wrote:
On 7/13/2021 11:40 AM, Ron Shepard wrote:...
On 7/12/21 6:18 PM, gah4 wrote:
...I used FPS attached processors all through the 1980s. It was not PCs
that doomed them, but rather the rise of the cheap, unix based, RISC
machines, which I also used during that time. Especially in the
early 80s, they were very cost effective in delivering floating
point operations. You programmed them in assembler and fortran, both
of which were cross compilers than ran on a VAX front-end machine.
https://doi.org/10.1002/qua.560240865
$.02 -Ron Shepard
Yeah, but those were a whole different class than the one/ones we
were using that were just plug-ins into a PC that are talking about
here.
I've gargled some, but found no references to anything similar to
these -- the last ones I recall were based on the i960 RISC processor
as they had passed Motorola by...on reflection I don't know what
became of that system; I suppose at some point it was just pitched as
obsolete or maybe it was delivered with the systej, I just can't
recall for sure.
I used an Alliant fx2800 parallel machine which was also based on the
Intel i960 RISC cpu. This was in the late 1980s and early 1990s. The
fortran compiler supported both shared-memory and distributed-memory programming models, and it incorporated many f90 features (e.g.
allocatable arrays) even before the final f90 approval. That was a nice machine to use, nice programming environment, and nice performance. I
thought the i960 cpu had a lot of potential. It was possible to build anything from PC class machines to mid-level parallel machines (ours had
16 cpus), to massive supercomputers (which at that time would have been
about 1000 cpus). That would have been an ideal situation for program development. However, for some reason the chip was not successful in the market, while the lower-performing 286/386/486 etc. line did survive. It would take another decade, the early 2000s, before these cpus caught up
with the performance of the i960. Without further development of the
i960 line, and probably other contributing reasons, Alliant closed its
doors in 1992.
$.02 -Ron Shepard
On 7/14/2021 12:43 AM, Ron Shepard wrote:
On 7/13/21 6:28 PM, dpb wrote:
On 7/13/2021 2:50 PM, dpb wrote:
On 7/13/2021 11:40 AM, Ron Shepard wrote:...
On 7/12/21 6:18 PM, gah4 wrote:
...I used FPS attached processors all through the 1980s. It was not PCs >>>> that doomed them, but rather the rise of the cheap, unix based, RISC >>>> machines, which I also used during that time. Especially in the
early 80s, they were very cost effective in delivering floating
point operations. You programmed them in assembler and fortran, both >>>> of which were cross compilers than ran on a VAX front-end machine.
https://doi.org/10.1002/qua.560240865
$.02 -Ron Shepard
Yeah, but those were a whole different class than the one/ones we
were using that were just plug-ins into a PC that are talking about
here.
I've gargled some, but found no references to anything similar to
these -- the last ones I recall were based on the i960 RISC processor
as they had passed Motorola by...on reflection I don't know what
became of that system; I suppose at some point it was just pitched as
obsolete or maybe it was delivered with the systej, I just can't
recall for sure.
I used an Alliant fx2800 parallel machine which was also based on the Intel i960 RISC cpu. This was in the late 1980s and early 1990s. The fortran compiler supported both shared-memory and distributed-memory programming models, and it incorporated many f90 features (e.g. allocatable arrays) even before the final f90 approval. That was a nice machine to use, nice programming environment, and nice performance. I thought the i960 cpu had a lot of potential. It was possible to build anything from PC class machines to mid-level parallel machines (ours had 16 cpus), to massive supercomputers (which at that time would have been about 1000 cpus). That would have been an ideal situation for program development. However, for some reason the chip was not successful in the market, while the lower-performing 286/386/486 etc. line did survive. It would take another decade, the early 2000s, before these cpus caught up with the performance of the i960. Without further development of the
i960 line, and probably other contributing reasons, Alliant closed its doors in 1992.
$.02 -Ron ShepardIndeed, and unfortunately for "real" computing, the open PC platform and price drove the mass market when IBM picked Intel '86 the others were doomed.
The above would, indeed, have been a marvelous development system; the coprocessor board we had for this specific project was "only" the M68020/68881; iirc there wasn't yet the cross-compiler for the i860 yet
at the time we needed it for our project.
It was a F77 compiler but was all that was needed to port the RELAP code developed with FTN/FTN4. I don't recall any real hassles in the
conversion (other than having to go to DP of course)* other than the
issue with the 60-bit integer and high-order storage as outlined before.
We took the expedient of simply using the native 32-bit integer
elsewhere as being sufficient to hold all actual values used otherwise
which turned out to be adequate for our purposes.
(*) Which leads to another war story -- we had a summer student at the
time and gave him the task of making the global substitution (before SELECTEDxxx of course) and he made the rookie mistake of submitting a
TECO batch command to do a global substitution that turned out to be
quite painful as he also didn't make a backup copy of the source code
files before submitting the job. It ran overnight on the DEC 10 before
they finally killed it, but it destroyed most of the previous work done before having done...
--Ron's experience with an Alliant fx2800 parallel machine is very interesting. If only I knew!
On Thursday, July 15, 2021 at 12:41:00 AM UTC+10, dpb wrote:[...]
Ron's experience with an Alliant fx2800 parallel machine is very interesting. If only I knew!private companies struggled in early 90's)
In early 90's price was a big consideration and my experience was that Apollo/Sparc workstations were too expensive for individual use so most of us used individual pc and 32-bit Lahey / Salford Fortran when the Vax / Pr1me multi-users shut down. (many
After the Vax / Pr1me experience, IBM and other large systems were so unfriendly, we didn't complain.
Ron, how reliable was the Alliant Fortran compiler that supported both shared-memory and distributed-memory programming models ? That suspicion would have made it hard to get funding when workstations were seen as the more expensive way forward.
Looking back, they were incredibly slow and the memory bandwidth would have been a challenge for shared-memory.
The low cost of pc's in the 90's caused the demise of many other hardware alternatives that could have been.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 159 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 98:59:25 |
| Calls: | 3,209 |
| Files: | 10,563 |
| Messages: | 3,009,783 |