Yagi, Y., Okuwaki, R., Enescu, B. et al. Irregular rupture process of the 2022 Taitung, Taiwan, earthquake sequence. Sci Rep 13 , 1107 (2023)
We used FPSPACK to handle the focal mechanism obtained in the inversion.
1 Like
H. J. Macpherson, Cosmological distances with general-relativistic ray tracing: framework and comparison to cosmographic predictions arXiv:2209.06775
At every step, we therefore must use spatial interpolation to calculate the simulation quantities (e.g. metric tensor, curvature) appearing on the right-hand-side of the evolution equations at the position of the light beam. For this purpose, we use the B-spline Fortran library, which provides one to six dimensional B-spline interpolation on a regular grid.
2 Likes
MSG is implemented as a software library with Python, Fortran 2008 and C bindings. These APIs each provide routines for interpolating specific intensity and flux spectra. They are underpinned by OpenMP-parallelized Fortran code that performs energy-conservative interpolatio
1 Like
56 JOSS papers with the “Fortran” tag:
https://joss.theoj.org/papers/in/Fortran
Most of the papers tagged Fortran also have a Python, C, or C++ tag. On the other hand, most of the papers with the tag “Julia” have no other tags. Is this a manifestation of what the Julia community calls the “two-language problem” (a variation of Ousterhout's dichotomy - Wikipedia)?
Btw, Rich Townsend has a number of interesting codes, including an implementation of the iso_varying_string module: mad star - Download Stuff
Practically speaking, Fortranners, particularly in industry practice of engineering (chemical, mechanical, etc ) for sure, suffer from n+1 language problem!
That is, to solve or help solve practical problems, they have to work with n other languages (C, C++, C#, Visual Basic, Python, R, MATLAB, Excel VBA, Java, and on occasion even Tcl, etc.), either to make available bindings for their Fortran libraries, or to be effective/productive with their number crunching.
The problem keeps getting worse as more languages and platforms come up or other languages evolve faster and when things with Fortran, especially the language standard, deliver too little, too late for its practitioners 
3 Likes
Just stumbled on this very nice work : https://arxiv.org/pdf/2303.03398.pdf “Acceleration of a production Solar MHD code with Fortran standard parallelism: From OpenACC to ‘do concurrent’”
1 Like
This strikes me as an issue of libraries, not something that needs to be addressed in the standard. The problem with libraries is the very tiny open source Fortran community. All languages that go against the herd deal with this.
The ISO C Bindings standardization helps, but someone who knows Fortran will inevitably have to interface with C or C++. Tutorials need to recognize this until either enough bindings are written manually, or an automation solution is developed. There are clang derived tools that might help with this. The following I played with; I could not get the practice example to work, but it did give me some ideas.
1 Like
@R_cubed , the problem I mentioned also considered the aspect it’s simply too difficult or tedious to develop functional and performant libraries in Fortran which then leads to those doing scientific and technical computing having to look elsewhere for solutions. Looking elsewhere creates the situation where many other programming languages and paradigms get into the mix - solution du jour - MATLAB/Octave; C, C++, Python, Julia, etc., to name a few. If Fortran had evolved at a bit of a faster pace, the problem would not have exacerbated as much and the scientists and the engineers could have focused on their domains instead of having to expend so much time/energy on tools.
1 Like
Could you elaborate on this? I’m most familiar with what goes on in applied stats, and cannot find a technical reason to prefer C++ over Fortran for fundamental algorithms. The main reason seems to be network effects – ie. more people “know” C++ vs. Fortran, and lots of available code already exists for C++.
Re: “Could you elaborate on this?” only a little: unless a library in question involves APIs that can be designed as external subprograms that do not require, per the Fortran standard to have explicit interfaces (even as it is always better to use explicit interfaces), the ground reality is a lot of library developers have found it very difficult to work with Fortran and the reasons are varied but they begin with the confusion around ALLOCATABLE, POINTER, TARGET attributes with arguments and on and on the issues go including mod output from the compilers and the lack of portability with such output, and derived types, and finalization, etc., etc…
Re: “… cannot find a technical reason to prefer C++ over Fortran…” my comments were not about “C++ over Fortran,” rather that quite a few circumstances have led to those doing scientific and technical computing to look elsewhere; C++ is one they consider, but quite a few people look at other options also.
Fortran is basically a half-baked product and one can argue that so is every programming language and paradigm usable for scientific and technical computing.
The fundamental difference is those who carry actual influence in the realm of Fortran (e.g., those who can actually vote/sign off on budgets and bring changes given the position they are in) pay inadequate attention to the half-baked aspects in Fortran whereas those driving other programming languages and paradigms are willing to listen and work on the areas needing improvement and support/do a lot, lot more for their practitioners.
Those doing scientific and technical computing are needing to focus and focus more and more on domain challenges e.g., work on their small bits to successfully enable the global energy industry to transition to non-fossil fuel options whereas the practice of Fortran presently turns out RTFM, RTFM - few of them have the time for that.
Karp M, Massaro D, Jansson N, et al. Large-Scale direct numerical simulations of turbulence using GPUs and modern Fortran. The International Journal of High Performance Computing Applications. 2023;0(0). doi:10.1177/10943420231158616
=> Open Access
2 Likes
From this article(Large-Scale direct numerical simulations of turbulence using GPUs and modern Fortran.):
As is clear from the description of Neko, modern Fortran (e.g. Fortran 03, 08, 18) offers similar object-oriented features to other programming languages such as C++ (Reid 2008). Most importantly, modern Fortran supports dynamic memory allocation. Other features of Fortran are the native support for the quad data-type, FP128, that all arrays are by default not aliased, pure functions, and that modern Fortran both supports older Fortran code and can interface with C-code. As Fortran is tailored to high-performance numerical computations it caters to the functionalities necessary to perform high-fidelity flow simulations.
3 Likes
What does this mean exactly? Isn’t this aliasing?
program main
integer :: x(3)
x = 1
call test(x,x)
print *, x
end program main
subroutine test(x,y)
integer :: x(3), y(3)
x = 1
y = 2
end subroutine test
compiles without errors (even with -Wall) and gives:
% ./test
2 2 2
This is the kind of thing maybe only rust doesn’t let you:
fn test(x: &mut [i64], y: &mut [i64]) {
x[1] = 1;
y[1] = 2;
}
fn main() {
let mut x: [i64; 3] = [1,1,1];
test(&mut x, &mut x);
println!("x = {}", x[1]);
}
gives:
error[E0499]: cannot borrow `x` as mutable more than once at a time
--> src/main.rs:8:18
|
8 | test(&mut x, &mut x);
| ---- ------ ^^^^^^ second mutable borrow occurs here
| | |
| | first mutable borrow occurs here
| first borrow later used by call
Yes, and that makes it invalid (I.e. not standards conforming). But, the processor (compiler) is not required to detect it, since it is not a numbered constraint or syntax rule. And since program units are often compiled independently, it may be impossible for it to actually detect at compile time, because the rule is actually a bit more subtle than just no aliasing. The existence of an alias is fine, the use of it is not. I.e.
program alias
integer :: x(3)
x = 1
call sub(x)
print *, x
contains
subroutine sub(y)
integer :: y(3)
y = 2 ! x and y are aliased here, but I only use one so it's ok
end subroutine
end program
1 Like
But what it then allows is for the processor to make certain assumptions (or not make them depending on the perspective) and which can then facilitate compiler optimizations.
J. R. Hammond, T. Deakin, J. Cownie and S. McIntosh-Smith, “Benchmarking Fortran DO CONCURRENT on CPUs and GPUs Using BabelStream,” 2022 IEEE/ACM International Workshop on Performance Modeling, Benchmarking and Simulation of High Performance Computer Systems (PMBS), Dallas, TX, USA, 2022, pp. 82-99
Abstract: Fortran DO CONCURRENT has emerged as a new way to achieve parallel execution of loops on CPUs and GPUs. This paper studies the performance portability of this construct on a range of processors and compares it with the incumbent models: OpenMP, OpenACC and CUDA. To do this study fairly, we implemented the BabelStream memory bandwidth benchmark from scratch, entirely in modern Fortran, for all of the models considered, which include Fortran DO CONCURRENT, as well as two variants of OpenACC, four variants of OpenMP (2 CPU and 2 GPU), CUDA Fortran, and both loop- and array-based references. BabelStream Fortran matches the C++ implementation as closely as possible, and can be used to make language-based comparisons. This paper represents one of the first detailed studies of the performance of Fortran support on heterogeneous architectures; we include results for AArch64 and x86_64 CPUs as well as AMD, Intel and NVIDIA GPU platforms.
3 Likes
Further following this article ( Benchmarking Fortran DO CONCURRENT on CPUs and GPUs Using BabelStream): some part of the conclusion says
Compiler support for programming models tracks applica-
tion use. Traditional OpenMP parallelism on CPUs has been
around for decades and is well-supported in all compilers.
Newer forms of parallelism, such as OpenMP taskloop and
Fortran 2023 extensions to DO CONCURRENT are not yet
implemented effectively in all compilers, and it is disappoint-
ing that, after 14 years, Fortran 2008 DO CONCURRENT fails
to fulfill its purpose as a portable parallel loop construct
supported by all compilers. However, when it is implemented
properly with parallelism, we see that it is competitive with
directive-based parallelism on all CPUs and NVIDIA GPUs.
The only platforms where there is no parallel implementation
of DoConcurrent are AMD and Intel GPUs, both of which are
relatively new to the HPC space. Thus, there are no technical
barriers to the effective implementation of CPU and GPU
parallelism in DO CONCURRENT, only uninspired compiler
developers.
Hopefully, in the future, we will see efforts in this direction.
While OpenMP workshare has been around for many
years, implementation quality varies significantly due to it
remaining a low priority for compiler developers, because
of little use in applications, which itself follows from the
lack of adoption of array expressions in Fortran codes, often
because of poor compiler implementations. Additionally, the
DOT_PRODUCT, which is almost trivial to implement, and
is equivalent to xDOT from the BLAS, is sadly inconsistent
from a performance portability perspective, surely due to
lack of priority rather than difficulty. This chicken-and-egg
problem is common in parallel computing. One potential use
of BabelStream Fortran is to allow HPC users and operators
to measure the differences between implementations, in order
to expose deficiencies in compilers, so that they might be
improved.
Agree, dot_product is not good from performance perspective.
1 Like
He is doing yeoman work here and I thank him for it, but I must say Jeff has a knack for being pointedly opinionated:
Outside of thermodynamics, everything can be “reduced” to be an “opinion”, if one were so inclined! So should authors not express them and worry about “hurt” feelings or some such!!!?
It appears the author is “calling a spade a spade”. Fortran really needs it, for it is indeed hurting terribly from entirely uninspired compiler developers and a sheer lack of priority on way too matters of importance to the language. @certik and LFortran are the one true exception. This is as close to truth as it can get. Calling that out is a really good thing, no one has a right to remain unoffended when they associate themselves with some group that is getting called out. .
1 Like