# Research articles using Fortran **URL:** \ **Category:** Uncategorized\ **Created:** [April 24, 2021, 2:33pm UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran/1101 "2021-04-24T14:33:03Z")\ **Posts on this page:** 20\ **Page:** 5
**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\ **Post date:** [January 22, 2023, 12:20pm UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran/1101/81 "2023-01-22T12:20:05Z")
Yagi, Y., Okuwaki, R., Enescu, B. _et al._ [Irregular rupture process of the 2022 Taitung, Taiwan, earthquake sequence](https://www.nature.com/articles/s41598-023-27384-y). _Sci Rep_ **13** , 1107 (2023) > We used [FPSPACK](https://www.sciencedirect.com/science/article/pii/S0098300403000967) to handle the focal mechanism obtained in the inversion. ---
**Author:** ![jacobwilliams](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jacobwilliams/32/10_2.png) [@jacobwilliams](https://fortran-lang.discourse.group/u/jacobwilliams)\ **Post date:** [January 22, 2023, 5:11pm UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran/1101/82 "2023-01-22T17:11:07Z")
H. J. Macpherson, Cosmological distances with general-relativistic ray tracing: framework and comparison to cosmographic predictions [arXiv:2209.06775](https://arxiv.org/abs/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](https://github.com/jacobwilliams/bspline-fortran) library, which provides one to six dimensional B-spline interpolation on a regular grid. ---
**Author:** ![vmagnin](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/vmagnin/32/28_2.png) [@vmagnin](https://fortran-lang.discourse.group/u/vmagnin)\ **Post date:** [January 30, 2023, 9:31am UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran/1101/83 "2023-01-30T09:31:29Z")
> 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 > **[MSG: A software package for interpolating stellar spectra in pre-calculated...](https://joss.theoj.org/papers/10.21105/joss.04602)** > > Townsend et al., (2023). MSG: A software package for interpolating stellar spectra in pre-calculated grids. Journal of Open Source Software, 8(81), 4602, https://doi.org/10.21105/joss.04602 ---
**Author:** ![vmagnin](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/vmagnin/32/28_2.png) [@vmagnin](https://fortran-lang.discourse.group/u/vmagnin)\ **Post date:** [January 30, 2023, 9:32am UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran/1101/84 "2023-01-30T09:32:57Z")
56 JOSS papers with the “Fortran” tag: [https://joss.theoj.org/papers/in/Fortran](https://joss.theoj.org/papers/in/Fortran) ---
**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\ **Post date:** [February 5, 2023, 9:08pm UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran/1101/85 "2023-02-05T21:08:33Z")
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”](https://joss.theoj.org/papers/in/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](https://en.wikipedia.org/wiki/Ousterhout%27s_dichotomy))? Btw, Rich Townsend has a number of interesting codes, including an implementation of the `iso_varying_string` module: [mad star - Download Stuff](http://user.astro.wisc.edu/~townsend/static.php?ref=download) ---
**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\ **Post date:** [February 6, 2023, 1:58am UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran/1101/86 "2023-02-06T01:58:10Z")
> [@ivanpribec](#): > > 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”](https://joss.theoj.org/papers/in/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](https://en.wikipedia.org/wiki/Ousterhout%27s_dichotomy))? > > Btw, Rich Townsend has a number of interesting codes, including an implementation of the `iso_varying_string` module: [mad star - Download Stuff](http://user.astro.wisc.edu/~townsend/static.php?ref=download) 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 😖 ---
**Author:** ![hkvzjal](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/hkvzjal/32/3055_2.png) [@hkvzjal](https://fortran-lang.discourse.group/u/hkvzjal)\ **Post date:** [March 10, 2023, 1:57pm UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran/1101/87 "2023-03-10T13:57:01Z")
Just stumbled on this very nice work : [https://arxiv.org/pdf/2303.03398.pdf](https://arxiv.org/pdf/2303.03398.pdf) “Acceleration of a production Solar MHD code with Fortran standard parallelism: From OpenACC to ‘do concurrent’” ---
**Author:** ![R\_cubed](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/r_cubed/32/263_2.png) [@R\_cubed](https://fortran-lang.discourse.group/u/R_cubed)\ **Post date:** [March 10, 2023, 5:07pm UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran/1101/88 "2023-03-10T17:07:47Z")
> [@FortranFan](#): > > 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 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. > **[GitHub - Time0o/CPPBind: Automatically Generate Language Bindings to C++...](https://github.com/Time0o/CPPBind/)** > > Automatically Generate Language Bindings to C++ Programs With Clang's LibTooling - GitHub - Time0o/CPPBind: Automatically Generate Language Bindings to C++ Programs With Clang's LibTooling ---
**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\ **Post date:** [March 10, 2023, 8:22pm UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran/1101/89 "2023-03-10T20:22:54Z")
> [@R\_cubed](#): > > This strikes me as an issue of libraries, not something that needs to be addressed in the standard … @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. ---
**Author:** ![R\_cubed](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/r_cubed/32/263_2.png) [@R\_cubed](https://fortran-lang.discourse.group/u/R_cubed)\ **Post date:** [March 11, 2023, 6:32pm UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran/1101/90 "2023-03-11T18:32:26Z")
> [@FortranFan](#): > > the problem I mentioned also considered the aspect it’s simply too difficult or tedious to develop functional and performant libraries in Fortran 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++. ---
**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\ **Post date:** [March 11, 2023, 8:41pm UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran/1101/91 "2023-03-11T20:41:54Z")
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**](https://en.wikipedia.org/wiki/RTFM), [**RTFM**](https://en.wikipedia.org/wiki/RTFM) - few of them have the time for that. ---
**Author:** ![vmagnin](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/vmagnin/32/28_2.png) [@vmagnin](https://fortran-lang.discourse.group/u/vmagnin)\ **Post date:** [March 20, 2023, 3:32pm UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran/1101/92 "2023-03-20T15:32:43Z")
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** ---
**Author:** ![snano](https://avatars.discourse-cdn.com/v4/letter/s/fbc32d/32.png) [@snano](https://fortran-lang.discourse.group/u/snano)\ **Post date:** [March 22, 2023, 12:52am UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran/1101/93 "2023-03-22T00:52:54Z")
From this article([Large-Scale direct numerical simulations of turbulence using GPUs and modern Fortran.](https://journals.sagepub.com/doi/full/10.1177/10943420231158616)): > 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](https://journals.sagepub.com/doi/full/10.1177/10943420231158616#bibr40-10943420231158616)). 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. ---
**Author:** ![lmiq](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/lmiq/32/555_2.png) [@lmiq](https://fortran-lang.discourse.group/u/lmiq)\ **Post date:** [March 22, 2023, 12:28pm UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran/1101/94 "2023-03-22T12:28:04Z")
> [@snano](#): > > are by default not aliased What does this mean exactly? Isn’t this aliasing? ```auto 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: ```auto % ./test 2 2 2 ``` This is the kind of thing maybe only rust doesn’t let you: ```rust 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: ```auto 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 ``` ---
**Author:** ![everythingfunctional](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/everythingfunctional/32/176_2.png) [@everythingfunctional](https://fortran-lang.discourse.group/u/everythingfunctional)\ **Post date:** [March 22, 2023, 2:17pm UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran/1101/95 "2023-03-22T14:17:06Z")
> [@lmiq](#): > > Isn’t this aliasing? > > ```auto > 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 > > ``` 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. ```auto 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 ``` ---
**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\ **Post date:** [March 22, 2023, 3:43pm UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran/1101/96 "2023-03-22T15:43:58Z")
> [@everythingfunctional](#): > > 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. 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. ---
**Author:** ![vmagnin](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/vmagnin/32/28_2.png) [@vmagnin](https://fortran-lang.discourse.group/u/vmagnin)\ **Post date:** [March 23, 2023, 10:28am UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran/1101/97 "2023-03-23T10:28:00Z")
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. > **[Benchmarking Fortran DO CONCURRENT on CPUs and GPUs Using BabelStream](https://ieeexplore.ieee.org/document/10024026/)** > > 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,... ---
**Author:** ![snano](https://avatars.discourse-cdn.com/v4/letter/s/fbc32d/32.png) [@snano](https://fortran-lang.discourse.group/u/snano)\ **Post date:** [March 23, 2023, 1:34pm UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran/1101/98 "2023-03-23T13:34:04Z")
Further following this article ( [Benchmarking Fortran DO CONCURRENT on CPUs and GPUs Using BabelStream](https://ieeexplore.ieee.org/document/10024026/)): 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. ---
**Author:** ![everythingfunctional](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/everythingfunctional/32/176_2.png) [@everythingfunctional](https://fortran-lang.discourse.group/u/everythingfunctional)\ **Post date:** [March 23, 2023, 2:49pm UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran/1101/99 "2023-03-23T14:49:57Z")
He is doing yeoman work here and I thank him for it, but I must say Jeff has a knack for being pointedly opinionated: > [@snano](#): > > _only uninspired compiler developers._ > [@snano](#): > > **surely due to lack of priority rather than difficulty** ---
**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\ **Post date:** [March 23, 2023, 4:25pm UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran/1101/100 "2023-03-23T16:25:58Z")
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. . [Previous page](https://fortran-lang.discourse.group/t/research-articles-using-fortran/1101.md?page=4) [Next page](https://fortran-lang.discourse.group/t/research-articles-using-fortran/1101.md?page=6)