6 ms·

A modern Fortran scientific programming ecosystem

117 points by Bostonian 4y ago

syockit 4y ago
> no obsolete constructs such as gotos How do you deal with resource management? Do you create a wrapper type for those that don't have automatic destructor? (I'm surprised that stdlib doesn't provide a wrapper for files)
- milancurcic 4y ago
  If you need to clear memory in the local scope, you need to deallocate a variable explicitly. Otherwise, all Fortran variables are cleared automatically when they go out of scope. One exception are Fortran pointers (different from C pointers) which are discouraged unless really necessary. We have a discussion for a high-level wrapper for files here: https://github.com/fortran-lang/stdlib/issues/14 https://github.com/fortran-lang/stdlib/issues/14. So, it's in scope we just haven't gotten far with the design and implementation.
mkoubaa 4y ago
Good to see that the third most important scientific computing language is getting some TLC
toddm 4y ago
Really great stuff, I would love never having to interact with python ever again and this is a nice to see.
- syockit 4y ago
  At some point you'll want to do scripting to automate some stuffs so I don't think you could really fully get rid of it.
  - elashri 4y ago
    For someone who is happy that he will replace python with Fortran. I think he can replace python scripting with bash happier :)
  - toddm 4y ago
    You're right, of course. As for bash scripting, I love it and use it as much as possible. My problem with python are largely with calisthenics regarding getting all the libraries and virtual environments to play nice, and I have a particular hatred for pandas. N.B. I'm looking at all of this from the standpoint of a scientific computations guy, not as a software engineer or a "data scientist," so Fortran is in my blood.
    - klipt 4y ago
      Have you looked into Julia? It seems pretty promising for scientific computing.
      - toddm 4y ago
        No, if only because none of my employers have been using Julia - I don't tend to do a lot of coding outside of work these days so I kind of play the hand I'm dealt.
    - erremerre 4y ago
      Give a go to R. You don't need any fancy library to play with data.frames. And Rstudio makes very pleasant to work with.
      - toddm 4y ago
        Love R, it was great even 15 years ago as a start for writing an automated trading system (there were issues with memory limits and other factors that ultimately led me to switch to python). As luck would have it, I'm presently auditioning for a gig that requires a foot in R and another in python. Rstudio is really wonderful!
Koshkin 4y ago
> they are relics of the past, a reminder of what might have been if they had continued to be maintained How do you “maintain” a computational algorithm that was carefully designed and withstood the test of time over decades?
- taeric 4y ago
  This does read kind of odd. Reads as if the algorithms don't work anymore. Which... is at sharp odds for my understanding of why folks still use the basic linear algebra subprograms. If anything, my understanding is that too many of the newer languages and runtimes are made with the idea that they must have the full tooling in the language and runtime. As opposed to in the past, where many of these subprograms would be written to be called from whatever software was being written for the machines.
  - tomrod 4y ago
    I can think of a few ways: - Hardware dies, logical or physical storage needs to be reloaded - Algorithm is challenged as incorrect, needs to be tested - Underlying hardware infrastructure adjusts to 64-bit hardware, and returns different values - Intel decides to muck with the sine function near 0 (https://news.ycombinator.com/item?id=8434128 https://news.ycombinator.com/item?id=8434128, https://www.cs.earlham.edu/~dusko/cs63/fdiv.html https://www.cs.earlham.edu/~dusko/cs63/fdiv.html, https://github.com/torvalds/linux/blob/v5.9/arch/x86/kernel/fpu/bugs.c https://github.com/torvalds/linux/blob/v5.9/arch/x86/kernel/...) and so on
    - taeric 4y ago
      I don't want this to get distracted by chasing examples. If any of these are systemic, I'm curious. That said, my assertion was that evidence is the algorithms in question are still valid. Usually, they are still champions in speed. Certainly, folks have had to port and maintain the fortran compilers. Especially so to add targets. But the very stability of fortran, the language, is a big boon to those implementations not having bit rot. And while I know they could be reimplemented, in what language? And to what real advantage?
btrettel 4y ago
> [Fortran] is great for technical and numerical codes that need to run fast and are intended to be used for decades. The libraries listed above will not stop working in a few years. An extremely complicated Fortran application can be recompiled with just a Fortran compiler. You cannot say the same for anything written in the Python scientific ecosystem, which is a Frankenstein hybrid of a scripting language hacked together with a pile of C/C++/Fortran libraries compiled by somebody else. Good luck trying to run Python you write now 20 years from now (or trying to run something written 20 years ago). Fortran is a simple and stable foundation upon which to build our scientific software, Python is not. This resonates with me. A lot of the code I wrote during my PhD was Python 2. It probably wouldn't run today without a lot of work. (The easiest approach might be to start a virtual machine using a disk image of the computer I used at the time.) I could have used Python 3, but at the time I didn't pay attention to what version I was using. I also used a lot of third-party packages when I should have minimized my dependencies. I recently switched for Fortran for new scientific software largely because I expect Fortran code to last longer. I'm pretty paranoid about portability, too. I've used around 10 Fortran compilers now. I compile in standards compliance mode in most compilers. It's been interesting to see first-hand what's portable and what's not. I even got some code I've been working on recently to compile on Microsoft Fortran PowerStation 4.0 from 1995. Hopefully if it compiles on a compiler today and a compiler from 25 years ago, it'll still compile in 25 years?
- throw827474737 4y ago
  > (The easiest approach might be to start a virtual machine using a disk image of the computer I used at the time. Hm, a venv with interpreter is good enough and setup from nothing within 30 minutes still.. then if you have the right libs you are ready to go. Still doing that. Most of my (admitted, simpler) scripts from 10 years ago usually run fine without any fuzz or even with later libs - good if one embraced py3 early and isn't stuck with py2 still after EOL ;) This sure depends on libs chosen and also implementor ( yeah I also know people who claim there code breaks ever few months... I don't know why). I would claim that Fortran's stability only comes from the fact that ecosystem and libs were not really evolving anymore... you have that also in any compiled or also scripted language if you have these conditions or keep the stuff sround? In the end that's why numpy wraps Fortran libs! :D
wirrbel 4y ago
An interesting aspect about Fortran is, that it is remarkably high level even in its Fortran 77 incarnation and Fortran 2003 makes a fairly modern programming language if you don't touch the 'there be dragons' features. Of course some old code bases with lot's of gotos cryptic variable names and fixed-form code layout look a bit atrocious, but the core is fairly solid.
ar_imani 4y ago
that's great even for not-so-complicated scientific projects. keep in mind that lots of commercial software in computational engineering are rely on FORTRAN for user defined sections and tweaking. for example ABAQUS in FE analysis.
case0x00 4y ago
Modern Fortran is honestly a joy to work with. A large part of this is due to FPM; I've had a lot of problems in the past with building more complex Fortran projects (with FoBiS mainly) and dependencies have always been a bit of a hassle. Also the author of the post has worked on some really cool stuff. They work at NASA JSC and their Fortran code is being used for the Artemis I mission (https://twitter.com/DegenerateConic/status/1561531340067061762 https://twitter.com/DegenerateConic/status/15615313400670617...) which is gnarly.
rad_gruchalski 4y ago
I would like to take this opportunity and recommend the Modern Fortran book by Milan Curcic: https://www.manning.com/books/modern-fortran https://www.manning.com/books/modern-fortran.
- milancurcic 4y ago
  Thank you for sharing it!!
  - rad_gruchalski 4y ago
    Welcome. Thank you for a great catch-the-Fortran-wave book. Pun intended. Your examples are fun to follow and step out of the regular day-to-day distributed computing comfort zone. I mentioned your book in my post on Fortran: https://gruchalski.com/posts/2022-08-28-i-enjoyed-modern-fortran/ https://gruchalski.com/posts/2022-08-28-i-enjoyed-modern-for....

117 points by Bostonian 4y ago

> no obsolete constructs such as gotos How do you deal with resource management? Do you create a wrapper type for those that don't have automatic destructor? (I'm surprised that stdlib doesn't provide a wrapper for files)

milancurcic 4y ago
If you need to clear memory in the local scope, you need to deallocate a variable explicitly. Otherwise, all Fortran variables are cleared automatically when they go out of scope. One exception are Fortran pointers (different from C pointers) which are discouraged unless really necessary. We have a discussion for a high-level wrapper for files here: https://github.com/fortran-lang/stdlib/issues/14 https://github.com/fortran-lang/stdlib/issues/14. So, it's in scope we just haven't gotten far with the design and implementation.

mkoubaa 4y ago

Good to see that the third most important scientific computing language is getting some TLC

toddm 4y ago

Really great stuff, I would love never having to interact with python ever again and this is a nice to see.

syockit 4y ago
At some point you'll want to do scripting to automate some stuffs so I don't think you could really fully get rid of it.
- elashri 4y ago
  For someone who is happy that he will replace python with Fortran. I think he can replace python scripting with bash happier :)
- toddm 4y ago
  You're right, of course. As for bash scripting, I love it and use it as much as possible. My problem with python are largely with calisthenics regarding getting all the libraries and virtual environments to play nice, and I have a particular hatred for pandas. N.B. I'm looking at all of this from the standpoint of a scientific computations guy, not as a software engineer or a "data scientist," so Fortran is in my blood.
  - klipt 4y ago
    Have you looked into Julia? It seems pretty promising for scientific computing.
    - toddm 4y ago
      No, if only because none of my employers have been using Julia - I don't tend to do a lot of coding outside of work these days so I kind of play the hand I'm dealt.
  - erremerre 4y ago
    Give a go to R. You don't need any fancy library to play with data.frames. And Rstudio makes very pleasant to work with.
    - toddm 4y ago
      Love R, it was great even 15 years ago as a start for writing an automated trading system (there were issues with memory limits and other factors that ultimately led me to switch to python). As luck would have it, I'm presently auditioning for a gig that requires a foot in R and another in python. Rstudio is really wonderful!

Koshkin 4y ago

> they are relics of the past, a reminder of what might have been if they had continued to be maintained How do you “maintain” a computational algorithm that was carefully designed and withstood the test of time over decades?

taeric 4y ago
This does read kind of odd. Reads as if the algorithms don't work anymore. Which... is at sharp odds for my understanding of why folks still use the basic linear algebra subprograms. If anything, my understanding is that too many of the newer languages and runtimes are made with the idea that they must have the full tooling in the language and runtime. As opposed to in the past, where many of these subprograms would be written to be called from whatever software was being written for the machines.
- tomrod 4y ago
  I can think of a few ways: - Hardware dies, logical or physical storage needs to be reloaded - Algorithm is challenged as incorrect, needs to be tested - Underlying hardware infrastructure adjusts to 64-bit hardware, and returns different values - Intel decides to muck with the sine function near 0 (https://news.ycombinator.com/item?id=8434128 https://news.ycombinator.com/item?id=8434128, https://www.cs.earlham.edu/~dusko/cs63/fdiv.html https://www.cs.earlham.edu/~dusko/cs63/fdiv.html, https://github.com/torvalds/linux/blob/v5.9/arch/x86/kernel/fpu/bugs.c https://github.com/torvalds/linux/blob/v5.9/arch/x86/kernel/...) and so on
  - taeric 4y ago
    I don't want this to get distracted by chasing examples. If any of these are systemic, I'm curious. That said, my assertion was that evidence is the algorithms in question are still valid. Usually, they are still champions in speed. Certainly, folks have had to port and maintain the fortran compilers. Especially so to add targets. But the very stability of fortran, the language, is a big boon to those implementations not having bit rot. And while I know they could be reimplemented, in what language? And to what real advantage?

btrettel 4y ago

> [Fortran] is great for technical and numerical codes that need to run fast and are intended to be used for decades. The libraries listed above will not stop working in a few years. An extremely complicated Fortran application can be recompiled with just a Fortran compiler. You cannot say the same for anything written in the Python scientific ecosystem, which is a Frankenstein hybrid of a scripting language hacked together with a pile of C/C++/Fortran libraries compiled by somebody else. Good luck trying to run Python you write now 20 years from now (or trying to run something written 20 years ago). Fortran is a simple and stable foundation upon which to build our scientific software, Python is not. This resonates with me. A lot of the code I wrote during my PhD was Python 2. It probably wouldn't run today without a lot of work. (The easiest approach might be to start a virtual machine using a disk image of the computer I used at the time.) I could have used Python 3, but at the time I didn't pay attention to what version I was using. I also used a lot of third-party packages when I should have minimized my dependencies. I recently switched for Fortran for new scientific software largely because I expect Fortran code to last longer. I'm pretty paranoid about portability, too. I've used around 10 Fortran compilers now. I compile in standards compliance mode in most compilers. It's been interesting to see first-hand what's portable and what's not. I even got some code I've been working on recently to compile on Microsoft Fortran PowerStation 4.0 from 1995. Hopefully if it compiles on a compiler today and a compiler from 25 years ago, it'll still compile in 25 years?

throw827474737 4y ago
> (The easiest approach might be to start a virtual machine using a disk image of the computer I used at the time. Hm, a venv with interpreter is good enough and setup from nothing within 30 minutes still.. then if you have the right libs you are ready to go. Still doing that. Most of my (admitted, simpler) scripts from 10 years ago usually run fine without any fuzz or even with later libs - good if one embraced py3 early and isn't stuck with py2 still after EOL ;) This sure depends on libs chosen and also implementor ( yeah I also know people who claim there code breaks ever few months... I don't know why). I would claim that Fortran's stability only comes from the fact that ecosystem and libs were not really evolving anymore... you have that also in any compiled or also scripted language if you have these conditions or keep the stuff sround? In the end that's why numpy wraps Fortran libs! :D

wirrbel 4y ago

An interesting aspect about Fortran is, that it is remarkably high level even in its Fortran 77 incarnation and Fortran 2003 makes a fairly modern programming language if you don't touch the 'there be dragons' features. Of course some old code bases with lot's of gotos cryptic variable names and fixed-form code layout look a bit atrocious, but the core is fairly solid.

ar_imani 4y ago

that's great even for not-so-complicated scientific projects. keep in mind that lots of commercial software in computational engineering are rely on FORTRAN for user defined sections and tweaking. for example ABAQUS in FE analysis.

case0x00 4y ago

Modern Fortran is honestly a joy to work with. A large part of this is due to FPM; I've had a lot of problems in the past with building more complex Fortran projects (with FoBiS mainly) and dependencies have always been a bit of a hassle. Also the author of the post has worked on some really cool stuff. They work at NASA JSC and their Fortran code is being used for the Artemis I mission (https://twitter.com/DegenerateConic/status/1561531340067061762 https://twitter.com/DegenerateConic/status/15615313400670617...) which is gnarly.

rad_gruchalski 4y ago

I would like to take this opportunity and recommend the Modern Fortran book by Milan Curcic: https://www.manning.com/books/modern-fortran https://www.manning.com/books/modern-fortran.

milancurcic 4y ago
Thank you for sharing it!!
- rad_gruchalski 4y ago
  Welcome. Thank you for a great catch-the-Fortran-wave book. Pun intended. Your examples are fun to follow and step out of the regular day-to-day distributed computing comfort zone. I mentioned your book in my post on Fortran: https://gruchalski.com/posts/2022-08-28-i-enjoyed-modern-fortran/ https://gruchalski.com/posts/2022-08-28-i-enjoyed-modern-for....