# Research articles using Fortran, 2025 on **URL:** \ **Category:** Announcements\ **Created:** [January 14, 2025, 2:08am UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran-2025-on/9070 "2025-01-14T02:08:00Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\ **Post date:** [January 14, 2025, 2:08am UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran-2025-on/9070/1 "2025-01-14T02:08:01Z")
The earlier [thread](https://fortran-lang.discourse.group/t/research-articles-using-fortran/1101) became long, so I am starting a new one. #### [Dual Numbers for Arbitrary Order Automatic Differentiation](https://arxiv.org/abs/2501.04159) by [F. Peñuñuri](https://arxiv.org/search/math?searchtype=author&query=Pe%C3%B1u%C3%B1uri,+F), [K. B. Cantún-Avila](https://arxiv.org/search/math?searchtype=author&query=Cant%C3%BAn-Avila,+K+B), [R. Peón-Escalante](https://arxiv.org/search/math?searchtype=author&query=Pe%C3%B3n-Escalante,+R) arXiv 7 Jan 2025 > Dual numbers are a well-known tool for computing derivatives of functions. While the theoretical framework for calculating derivatives of arbitrary order is well established, practical implementations remain less developed. One notable implementation is available in the Julia programming language where dual numbers are designed to be nested, enabling the computation of derivatives to arbitrary order. However, this approach has a significant drawback as it struggles with scalability for high-order derivatives. The nested structure quickly consumes memory, making it challenging to compute derivatives of higher orders. In this study, we introduce DNAOAD, a Fortran-based implementation of automatic differentiation capable of handling derivatives of arbitrary order using dual numbers. This implementation employs a direct approach to represent dual numbers without relying on recursive or nested structures. As a result, DNAOAD facilitates the efficient computation of derivatives of very high orders while addressing the memory limitations of existing methods. > **[GitHub - fpenunuri/DNAOAD: Fortran implementation of dual numbers for...](https://github.com/fpenunuri/DNAOAD)** > > Fortran implementation of dual numbers for arbitrary order automatic differentiation ---
**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\ **Post date:** [February 14, 2025, 11:13pm UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran-2025-on/9070/2 "2025-02-14T23:13:11Z")
[Native Fortran Implementation of TensorFlow-Trained Deep and Bayesian Neural Networks](https://arxiv.org/abs/2502.06853) by Aidan Furlong, Xingang Zhao, Bob Salko, Xu Wu arXiv 7 Feb 2025 > Over the past decade, the investigation of machine learning (ML) within the field of nuclear engineering has grown significantly. With many approaches reaching maturity, the next phase of investigation will determine the feasibility and usefulness of ML model implementation in a production setting. Several of the codes used for reactor design and assessment are primarily written in the Fortran language, which is not immediately compatible with TensorFlow-trained ML models. This study presents a framework for implementing deep neural networks (DNNs) and Bayesian neural networks (BNNs) in Fortran, allowing for native execution without TensorFlow’s C API, Python runtime, or ONNX conversion. Designed for ease of use and computational efficiency, the framework can be implemented in any Fortran code, supporting iterative solvers and UQ via ensembles or BNNs. Verification was performed using a two-input, one-output test case composed of a noisy sinusoid to compare Fortran-based predictions to those from TensorFlow. The DNN predictions showed negligible differences and achieved a 19.6x speedup, whereas the BNN predictions exhibited minor disagreement, plausibly due to differences in random number generation. An 8.0x speedup was noted for BNN inference. The approach was then further verified on a nuclear-relevant problem predicting critical heat flux (CHF), which demonstrated similar behavior along with significant computational gains. Discussion regarding the framework’s successful integration into the CTF thermal-hydraulics code is also included, outlining its practical usefulness. Overall, this framework was shown to be effective at implementing both DNN and BNN model inference within Fortran, allowing for the continued study of ML-based methods in real-world nuclear applications. Related projects: > **[GitHub - ajfurlong/fortran\_dnn\_from\_tf: Barebones method of implementing a pre-trained DNN...](https://github.com/ajfurlong/fortran_dnn_from_tf)** > > Barebones method of implementing a pre-trained DNN from TensorFlow in a Fortran script. > **[GitHub - ajfurlong/fortran\_bayesian\_nn\_from\_tf: Pre-Trained TensorFlow Bayesian Neural Networks in...](https://github.com/ajfurlong/fortran_bayesian_nn_from_tf)** > > Pre-Trained TensorFlow Bayesian Neural Networks in Fortran ---
**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\ **Post date:** [February 15, 2025, 12:52am UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran-2025-on/9070/3 "2025-02-15T00:52:03Z")
[Teaching An Old Dog New Tricks: Porting Legacy Code to Heterogeneous Compute Architectures With Automated Code Translation](https://www.arxiv.org/abs/2502.05279) by Nicolas Nytko, Andrew Reisner, J. David Moulton, Luke N. Olson, and Matthew West arXiv 7 Feb 2025 > Legacy codes are in ubiquitous use in scientific simulations; they are well-tested and there is significant time investment in their use. However, one challenge is the adoption of new, sometimes incompatible computing paradigms, such as GPU hardware. In this paper, we explore using automated code translation to enable execution of legacy multigrid solver code on GPUs without significant time investment and while avoiding intrusive changes to the codebase. We developed a thin, reusable translation layer that parses Fortran 2003 at compile time, interfacing with the existing library Loopy to transpile to C++/GPU code, which is then managed by a custom MPI runtime system that we created. With this low-effort approach, we are able to achieve a payoff of an approximately 2-3x speedup over a full CPU socket, and 6x in multi-node settings. The original Fortran/C++/C code is > **[GitHub - cedar-framework/cedar: A robust, variational multigrid library...](https://github.com/cedar-framework/cedar)** > > A robust, variational multigrid library implementing BoxMG on large scale parallel systems. and a tool used is > **[GitHub - inducer/loopy: A code generator for array-based code on CPUs and...](https://github.com/inducer/loopy)** > > A code generator for array-based code on CPUs and GPUs ---
**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\ **Post date:** [February 17, 2025, 9:09pm UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran-2025-on/9070/4 "2025-02-17T21:09:23Z")
[Seamless acceleration of Fortran intrinsics via AMD AI engines](https://arxiv.org/abs/2502.10254) by Nick Brown and Gabriel Rodríguez Canal arXiv 14 Feb 2025 > A major challenge that the HPC community faces is how to continue delivering the performance demanded by scientific programmers, whilst meeting an increased emphasis on sustainable operations. Specialised architectures, such as FPGAs and AMD’s AI Engines (AIEs), have been demonstrated to provide significant energy efficiency advantages, however a major challenge is that to most effectively program these architectures requires significant expertise and investment of time which is a major blocker. > Fortran in the lingua franca of scientific computing, and in this paper we explore automatically accelerating Fortran intrinsics via the AIEs in AMD’s Ryzen AI CPU. Leveraging the open source Flang compiler and MLIR ecosystem, we describe an approach that lowers the MLIR linear algebra dialect to AMD’s AIE dialects, and demonstrate that for suitable workloads the AIEs can provide significant performance advantages over the CPU without any code modifications required by the programmer. Looking at Table 4, large speedups using a Neural Processing Unit (NPU) instead of a CPU are possible for `matmul` for the int32, bfloat16, and float32 types. ---
**Author:** ![shahmoradi](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/shahmoradi/32/3151_2.png) [@shahmoradi](https://fortran-lang.discourse.group/u/shahmoradi)\ **Post date:** [February 18, 2025, 5:55pm UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran-2025-on/9070/5 "2025-02-18T17:55:19Z")
[A parallel texture-based region-growing algorithm implemented in OpenMP](https://www.nature.com/articles/s41598-025-89960-8) ---
**Author:** ![Shahid](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/shahid/32/3672_2.png) [@Shahid](https://fortran-lang.discourse.group/u/Shahid)\ **Post date:** [February 25, 2025, 3:08pm UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran-2025-on/9070/6 "2025-02-25T15:08:44Z")
[High performance additive manufacturing phase field simulation: Fortran Do Concurrent vs OpenMP - ScienceDirect](https://www.sciencedirect.com/science/article/pii/S0927025625001314?dgcid=author) Standard language parallelism is an alternate way to achieve the parallel performance of the code without using external application processing interface (API). In this work, we present the Fortran Do Concurrent standard language parallel feature for additive manufacturing. We developed an open-source AMSimulator application and have implemented OpenMP and Fortran Do Concurrent in the phase field simulation. Performance has been measured across various platforms like Windows 10 and Linux and open-source compilers with Intel and NVIDIA. We found that using standard language parallel features, the same performance can be achieved without the need of external API. This high-performance approach is useful for code development and portability across various platforms. **Related GitHub** [GitHub - Shahid718/AMSimulator: The repository compares Do Concurrent with OpenMP’s performance for additive manufacturing using the phase field approach. The app is developed with the Fortran programming language.](https://github.com/Shahid718/AMSimulator/tree/main) ---
**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\ **Post date:** [March 3, 2025, 3:00pm UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran-2025-on/9070/7 "2025-03-03T15:00:08Z")
[Accelerating the Dutch Atmospheric Large-Eddy Simulation (DALES) model with OpenACC](https://arxiv.org/abs/2502.20412) by Lucas Esclapez, Laurent Soucasse, Caspar Jungbacker, Fredrik Jansson, Stephan R. de Roode, Pedro Costa @pcosta, Gijs van den Oord, and Alessio Sclocco arXiv 21 Feb 2025 > This paper presents the GPU porting through OpenACC directives of the > Dutch Atmospheric Large-Eddy Simulation (DALES) application, a > high-resolution atmospheric model. The code is written in Fortran~90 > and features parallel (distributed) execution through spatial domain > decomposition. We assess the performance of the GPU offloading, > comparing the time-to-solution on regular and accelerated HPC nodes. > %comparing the computational time between distributed and accelerated > nodes. A weak scaling analysis is conducted and portability across > NVIDIA A100 and H100 hardware %and AMD hardware is discussed. Finally, > we show how targeted kernels can benefit from further optimization > with Kernel Tuner, a GPU kernels auto-tuning package. DALES is on [GitHub](https://github.com/dalesteam/dales). ---
**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\ **Post date:** [April 1, 2025, 5:44pm UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran-2025-on/9070/8 "2025-04-01T17:44:18Z")
[Caffeine: A parallel runtime library for supporting modern Fortran compilers](https://joss.theoj.org/papers/10.21105/joss.07895) by Dan Bonachea, Katherine Rasmussen, Brad Richardson, and Damian Rouson _Journal of Open Source Software_, 29 March 2025 > The Coarray Fortran domain-specific language pioneered a parallel programming approach > designed as a syntactically small extension to Fortran 95 (Numrich & Reid, 1998). Fortran > 2008 incorporated Coarray Fortran features, including multi-image execution, synchronization > statements, coarrays, and more. Fortran 2018 greatly expanded this feature set to include > such concepts as teams (groupings) of images, events (counting semaphores), collective > subroutines and failed-image detection (fault tolerance). Fortran 2023 provided additional, > minor multi-image extensions, including notified remote data access (Fortran Standards > Committee JTC1/SC22/WG5, Nov 2023). > Caffeine’s initial target compilers include LLVM flang and LFortran, both of which have no > existing multi-image parallel runtime and thus will need one to reach full compliance with the > 2008, 2018, or 2023 versions of the Fortran standard. The Caffeine project team has submitted \> the PRIF specification as a pull request on the llvm-project git repository and through private correspondence have confirmed the lead LFortran developer’s interest in adopting PRIF when LFortran begins work on enabling multi-image execution. ---
**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\ **Post date:** [April 1, 2025, 11:45pm UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran-2025-on/9070/9 "2025-04-01T23:45:26Z")
[Pyrometheus: Symbolic abstractions for XPU and automatically differentiated computation of combustion kinetics and thermodynamics](https://arxiv.org/abs/2503.24286) by Esteban Cisneros-Garibay, Henry Le Berre, Spencer H. Bryngelson, and Jonathan B. Freund arXiv 31 Mar 2025 > The software package Pyrometheus is introduced as an implementation of these abstractions and their transformations for combustion thermochemistry. The formulation facilitates code generation from the symbolic representation of a specific thermochemical mechanism in multiple target languages, including Python, C++, and Fortran. > **[GitHub - pyrometheus/pyrometheus: Code generation for thermochemistry](https://github.com/pyrometheus/pyrometheus)** > > Code generation for thermochemistry ---
**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:** [April 27, 2025, 4:17pm UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran-2025-on/9070/10 "2025-04-27T16:17:20Z")
Trim, S. J., & Spiteri, R. J. (2024). Algorithm 1054: ellipFor, a Fortran software library for Legendre elliptic integrals and Jacobi elliptic functions with generalized input arguments. _ACM Transactions on Mathematical Software_ . [https://doi.org/10.1145/3709136](https://doi.org/10.1145/3709136) > Legendre elliptic integrals and Jacobi elliptic functions arise in multiple applications within the physical sciences, including oscillations, celestial mechanics, and geodynamics. In this study, we describe the Fortran library ellipFor capable of evaluating the following for generalized input values: (1) the complete Legendre elliptic integrals of the first and second kinds, (2) the incomplete Legendre elliptic integrals of the first and second kinds, and (3) the principal Jacobi elliptic functions. Our software builds upon previously developed Fortran routines, which were designed with restrictions on input parameters that may be limiting in applications. Our routines apply multiple transformations to allow for more general input values, such as elliptic moduli greater than unity for points 1–3, arbitrary real Jacobi amplitudes for points 1–2, and complex first arguments for point 3. In addition, our routines are thread-safe, allowing for parallel computations. Our routines were compared with values from the computer algebra system SageMath over a wide range of input parameters. Values from ellipFor and SageMath agreed to within tolerances commensurate with the limitations of floating-point arithmetic used for the elliptic integrals and Jacobi elliptic functions listed in points 1, 2, and 3 above for generalized input arguments. ---
**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\ **Post date:** [April 27, 2025, 7:29pm UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran-2025-on/9070/11 "2025-04-27T19:29:25Z")
An associated repo is > **[GitHub - seantrim/ellipFor: Fortran software for the evaluation of Legendre...](https://github.com/seantrim/ellipFor)** > > Fortran software for the evaluation of Legendre elliptic integrals and Jacobi elliptic functions for generalized input parameters. ---
**Author:** ![rgba](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/rgba/32/2115_2.png) [@rgba](https://fortran-lang.discourse.group/u/rgba)\ **Post date:** [June 3, 2025, 11:30pm UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran-2025-on/9070/12 "2025-06-03T23:30:42Z")
Today we have finally announced on the arxiv the updated version of EDIpack, a Lanczos based solver for quantum impurity models, at the earth of dynamical mean field theory and other quantum embedding descriptions of strongly correlated materials. > **[A flexible and interoperable high-performance Lanczos-based solver for...](https://arxiv.org/abs/2506.01363)** > > EDIpack is a flexible, high-performance numerical library using Lanczos-based exact diagonalization to solve generic quantum impurity problems, such as those introduced in Dynamical Mean-Field Theory to describe extended strongly correlated... Put all the scientific of the new features aside, one significant improvement has been to fully leverage on Fortran-C interoperability to make the library callable from C++, Python and Julia, with a unique reliable strategy. So far, we focused on explicit and ready-to-go interfaces with two major DMFT community packages, namely the [TRIQS](https://triqs.github.io/triqs/latest/) framework and the [w2dynamics](https://github.com/w2dynamics/w2dynamics) code, as they are expected to provide the most obvious flow of potentially new users of our library. Yet, I have plans on exploring in depth the possibilities of full interoperability with Julia, as DMFT, besides an impurity solver, relies crucially on good optimization routines (the ‘fit of the bath’ step in the self-constistent algorithm). So leveraging on established, state of the art, optimization libraries in the Julia ecosystem could really make for unprecedented improvements in out workflow. Not to speak about autodifferentiation capabilities or other unforseen interactions with their growing and very active ecosystem. I’m glad we finally made this big step forward! ---
**Author:** ![shahmoradi](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/shahmoradi/32/3151_2.png) [@shahmoradi](https://fortran-lang.discourse.group/u/shahmoradi)\ **Post date:** [June 9, 2025, 3:35pm UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran-2025-on/9070/14 "2025-06-09T15:35:28Z")
> **[GPU acceleration of non-equilibrium Green's function calculation using...](https://arxiv.org/abs/2505.19467)** > > The numerical solution of the Kadanoff-Baym nonlinear integro-differential equations, which yields the non-equilibrium Green's functions (NEGFs) of quantum many-body systems, poses significant computational challenges due to its high computational... ---
**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\ **Post date:** [June 11, 2025, 4:42pm UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran-2025-on/9070/15 "2025-06-11T16:42:01Z")
[Automatically parallelizing batch inference on deep neural networks using Fiats and Fortran 2023 `do concurrent`](https://escholarship.org/uc/item/5z08n75q) (2025) by Rouson, Damian Bai, Zhe Bonachea, Dan Ergawy, Kareem Gutmann, Ethan Klemm, Michael Rasmussen, Katherine Richardson, Brad Shende, Sameer Torres, David Zhang, Yunhao Lawrence Berkeley Lab Publications > Abstract > This paper introduces novel programming strategies that leverage features of the Fortran 2023 standard of the International Standards Organization (ISO) to automatically parallelize computations on deep neural networks. The paper focuses on the interplay of object-oriented, parallel, and functional programming paradigms in the Fiats deep learning library. We demonstrate how several infrequently used language features play a role in enabling efficient, parallel execution. Specifically, the ability to explicitly declare that a procedure is pure facilitates inference in the context of the language’s loop-parallelism construct `do concurrent`. Also, explicitly prohibiting the overriding of a parent type’s type-bound procedures eliminates the need for dynamic dispatch in performance-critical code. Finally, this paper uses batch inference calculations on a neural network surrogate for atmospheric aerosol dynamics to demonstrate that LLVM Flang compiler’s automatic parallelization of `do concurrent` achieves roughly the same performance and scalability as achieved by OpenMP compiler directives. We also demonstrate that double-precision inference costs 37–72% longer runtime than default-real precision with most values in the range 57-60%. ---
**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\ **Post date:** [June 11, 2025, 5:16pm UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran-2025-on/9070/16 "2025-06-11T17:16:37Z")
[A near-real-time data-assimilative model of the solar corona](https://www.science.org/doi/10.1126/science.adq0872) by Cooper Downs, Jon A. Linker, Ronald M. Caplan, Emily I. Mason, Pete Riley, Ryder Davidson, Andres Reyes, Erika Palmerio, Roberto Lionello, James Turtle, Michal Ben-Nun, Miko M. Stulajter, Viacheslav S. Titov, Tibor Török, Lisa A. Upton, Raphael Attie, Bibhuti K. Jha, Charles N. Arge, Carl J. Henney, Gherardo Valori, Hanna Strecker, Daniele Calchetti, Dietmar Germerott, Johann Hirzberger, David Orozco Suárez, Julian Blanco Rodríguez, Sami K. Solanki, Xin Cheng, Sizhe Wu Science 10 Jun 2025 > Abstract > The Sun’s corona is its tenuous outer atmosphere of hot plasma, which is difficult to observe. Most models of the corona extrapolate its magnetic field from that measured on the photosphere (the Sun’s optical surface) over a full 27-day solar rotational period, providing a time-stationary approximation. We present a model of the corona that evolves continuously in time, by assimilating photospheric magnetic field observations as they become available. This approach reproduces dynamical features that do not appear in time-stationary models. We used the model to predict coronal structure during the total solar eclipse of 8 April 2024 near the maximum of the solar activity cycle. There is better agreement between the model predictions and eclipse observations in coronal regions located above recently assimilated photospheric data. Code is at [Zenodo](https://zenodo.org/records/14889337). Image from [X/Twitter](https://x.com/sumseq/status/1932567175979806761): ![image](https://global.discourse-cdn.com/free1/uploads/fortran_lang/original/2X/9/9e4f96e8b7b6a361b3b3a8b3fc11feab3a912ead.jpeg) ---
**Author:** ![shahmoradi](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/shahmoradi/32/3151_2.png) [@shahmoradi](https://fortran-lang.discourse.group/u/shahmoradi)\ **Post date:** [July 9, 2025, 5:45pm UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran-2025-on/9070/17 "2025-07-09T17:45:54Z")
> **[evortran: a modern Fortran package for genetic algorithms with applications...](https://arxiv.org/abs/2507.06082v1)** > > evortran is a modern Fortran library designed for high-performance genetic algorithms and evolutionary optimization. evortran can be used to tackle a wide range of problems in high-energy physics and beyond, such as derivative-free parameter... ---
**Author:** ![urbanjost](https://avatars.discourse-cdn.com/v4/letter/u/0ea827/32.png) [@urbanjost](https://fortran-lang.discourse.group/u/urbanjost)\ **Post date:** [July 9, 2025, 7:33pm UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran-2025-on/9070/18 "2025-07-09T19:33:59Z")
Modern algorithms expressed in modern parallel object-oriented Fortran with a clear user interface, incorporating fpm packages and builds with fpm and leverages other modern open-source Fortran packages. What is not to like? ---
**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:** [July 22, 2025, 12:50am UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran-2025-on/9070/19 "2025-07-22T00:50:40Z")
> **[Handling discontinuities in numerical ODE methods for Lagrangian oceanography](https://egusphere.copernicus.org/preprints/2025/egusphere-2025-2109/)** > > Abstract. In Lagrangian oceanography, numerical methods for Ordinary Differential Equations (ODEs) are used to model particle transport. In many common applications, the velocity field driving the particle transport is provided as output from ocean... Uses [bspline-fortran](https://github.com/jacobwilliams/bspline-fortran) library. ---
**Author:** ![shahmoradi](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/shahmoradi/32/3151_2.png) [@shahmoradi](https://fortran-lang.discourse.group/u/shahmoradi)\ **Post date:** [April 7, 2026, 7:40pm UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran-2025-on/9070/20 "2026-04-07T19:40:17Z")
[Python-Assisted Development of High-Performance Fortran Codes: A Hybrid Methodology Integrating Symbolic Mathematics and Large Language Models](https://www.mdpi.com/2079-3197/14/4/86) ---
**Author:** ![fxm](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/fxm/32/5726_2.png) [@fxm](https://fortran-lang.discourse.group/u/fxm)\ **Post date:** [April 7, 2026, 9:30pm UTC](https://fortran-lang.discourse.group/t/research-articles-using-fortran-2025-on/9070/21 "2026-04-07T21:30:07Z")
[Modeling the Transport and Dispersion of Volcanic Co-PDC Ash Clouds Using NAME: An Evaluation of Source Geometry and Mass Eruption Rate](https://agupubs.onlinelibrary.wiley.com/doi/10.1029/2025JD044031) The MetOffice’s dispersion model NAME is written in modern Fortran. [Next page](https://fortran-lang.discourse.group/t/research-articles-using-fortran-2025-on/9070.md?page=2)