https://github.com/scipy/scipy/issues/13222#issuecomment-2308814020
This has been discussed at length also on Fortran Discourse:
Since it is a long thread, I will link to a direct answer from one of the SciPy maintainers, why preserving the existing fixed-form Fortran code is non-desirable: The difficulties of using Fortran in SciPy - #54 by ev-br
I can certainly agree the style of these existing legacy codes can be hard to comprehend (even for Fortran programmers). There are other issues too like static variables (save
), API’s relying on named user procedures instead of procedure arguments (callbacks), and a bunch of wrapper idiosyncrasies which get in the way of sane software engineering.
The next issue SciPy faced is due to build woes, such as:
- lack of native Fortran compiler on Windows (if I remember correctly using
gfortran
via Cygwin or MinGW is problematic, because of incompatibilities in the underlying C libraries when the Python interpreter is compiled with MVSC) - issues on MacOS (and more recently also Windows) with Aarch64 processors, where Fortran compilers still aren’t as mature (although it is getting better)
A good write-up can be found here: The 'eu' in eucatastrophe – Why SciPy builds for Python 3.12 on Windows are a minor miracle | Labs
There is also a related thread at the Scientific Python Discourse, discussing new Fortran libraries/components:
Thanks for the information.
I didn’t know that Fortran compilers on Windows and MacOS are issues. I guess that is one of the motivations for them for porting old Fortran code to C, like quadpack
, even though there is a modern implementation like GitHub - jacobwilliams/quadpack: Modern Fortran QUADPACK Library for 1D numerical quadrature
It is bit of disappointing that efforts for these fundamental libraries are distributed in different languages, and hard to be merged.
The top post is from August 2024, an old post. We discussed this in many threads with the SciPy maintainers. Let’s just say that they are not very excited users of Fortran, and so it’s best if they can switch to technologies that they are excited about, and everybody will be happier in the end.
I recommend the Fortran community focuses on projects with excited users that want to use Fortran. We follow the same with LFortran, on our frontpage we say “… and users enthusiastically participate in bug reporting and fixing”. It’s just a temporary solution until our tools mature on all platforms, probably still 2-3 years. Eventually we’ll get to a phase that we have rock solid tools on all platforms and there will be no technical reason why Fortran couldn’t be used.
Hopefully the interactive capabilities of LFortran will be the impetus for some folks to consider Fortran over Python but that’s going to be a steep hill to climb. Python has a large head start in perceived ease of use and shallower learning curve (although I think both of those points are debatable), an enormous catalog of libraries for just about any task, and tooling. However, a bullet-proof interactive Fortran just might attract enough developers to cut into Python’s wealth of libraries (which for me is really the only reason to use it). Still a tall order but “if you build it, they will come”.
Python might have large adoption, but as an astrophysicist, for me Fortran still is not dead. With the explosion of new tools, as well as interaction with the language similar to Python thanks to tools such as lfortran
and fpm
, in fields like material science or astrophysics we still have a good chance.
Before I started collecting Fortran codes for my list I knew it was heavily used in quantum chemistry/electronic structure and numerical weather prediction, but I did not realize how many codes in astrophysics, CFD, and earth science/geophysics were out there.
Yes, electronic structure, CFD, astrophysics and geophysics are historically as well as today still strongholds of Fortran. Also continuum mechanics. We should make it strong in machine learning (AI).
This would be great, but NVFORTRAN is the only compiler that makes this really a possibility as far as I’m aware. Maybe AOCC Flang supports some directives for targeted offloading, but I’m not sure. OpenMP in theory should allow GPU offload as well, but that’s not really intrinsic to the language.
I can say that there is a strong need in the industry for the capability to integrate/embed CFD Fortran codes with AI.
I agree. There has been a growing interest in the CFD community in applying AI (neural nets mostly) in CFD simulations. Jan Hesthaven who is a pioneer in spectral methods and his coworkers have published several recent papers applying AI to CFD. Applying AI across a wide spectrum of scientific computing is becoming an increasingly important area of research.
Rust capability to program CUDA/AMD is limited, to say the least. Definitely not the root of the problem at all
Currently yes. But multiple new compilers are working on GPU support.
Why do we need GPU support in every compiler. Regarding C/C++/NVCC, the “offloading” means each *.cu file gets split by NVIDIA Toolkit app (forgot the exact name) , the device code goes to NVCC, the host code goes to g++ (or whatever host compiler), and then the object files are linked together. Luckily for Fortraners , they have NVFortran. Am I missing something?
-
In the already niche Fortran world, the 2 most popular compilers are gfortran and ifort, nvfortran might be 3rd lagging behind by several yards. ifx tries to force its way up because intel simply dropped support of ifort. My personal experience, ifx is not ready for prime time, it gives too many surprises… it promises GPU offloading capabilities… if you have an intel gpu, I wonder how many people do actually? Compared to having an nvidia gpu.
-
Nvfortran cannot be used under Windows >> in industry Windows support is not a commodity, it is a necessity, so if one cannot compile/debug natively on Windows it is an issue. Since gnu/intel compilers have enable this since long, they have been adopted widely.
-
Nvfortran supports Fortran 2003 and some bits of 2008, but incomplete.
You missed my point. NVCC isn’t C++ (even if it aligns with C++17 features). It’s a proprietary compiler for CUDA. Normally you use NVCC with another host compilers (gcc,g++, icc etc). I suspect this is the case with NVFortran - it isn’t standard Fortran, though it retains Fortran-like syntax. I believe you need it only for CUDA code, which is very specific anyway due to architectural considerations.
I most probably did, if you tell me there is some easy way of mixing compilers in order to enable gpu offloading and not losing one hairs in the process, I’m all ears (eyes, should I say)… Joke aside, I have actually read the following material with a lot of attention:
- Accelerating Fortran codes: A method for integrating Coarray Fortran with CUDA Fortran and OpenMP - ScienceDirect
- blog/Dealing_with_imperfect_Fortran_compilers.md at main · jeffhammond/blog · GitHub + blog/Dealing_with_imperfect_Fortran_compilers_2.md at main · jeffhammond/blog · GitHub
This is not for your average Fortran programmer who’s main interest is on physics/engineering.
My feeling is that as long as some of the major compilers do not enable offloading across vendor architectures in a seamless manner (even without top-notch performance) GPU programming will not permeate the Fortran community.
Oh, there is also gcc that has some support Offloading - GCC Wiki …
I guess this discussion deserves its own thread because it will certainly drift from OPs subject.
I am very interested in this subject and would support a fresh thread, should I start it?
For sure you can mix code compiled with nvfortran and another Fortran compiler (ifx, gfortran…). But then you are basically limited to a basic ABI (say the C ABI): you cannot pass assumed shape arrays, allocatable arrays, pointers, etc…, you cannot use modules across the 2 compilers… Passing derived types is possible if they have the bind(C) attribute. So, yes, but with significant restrictions.
C compilers have this thing about providing their own stddef.h
and then using whatever headers lie in the standard include paths (e.g., /usr/include
).
Fortran compilers on the other hand, went their separate ways some 40+ years ago and mixing stuff is now problematic —as @PierU mentioned, only the “Companion Processor” has that level of compatibility.