FortranCon 2021 is the second edition of the International Conference targeting the development and usage of the Fortran programming language and will take place on September 23-24, 2021.
In recent years Fortran has seen a series of new standards, improving the language in regards to object-oriented, parallel and general-purpose programming. This has spurred the development of several new projects written in and for Fortran, helping the Fortran programmers - in particular, the scientific community - to modernize their code and make it more maintainable.
With this conference, we intend to bring together active Fortran project developers from all fields: library and tool developers as well as people using Fortran to develop scientific applications, to share their experience and exchange ideas.
For the 2021 edition, the conference is supported both by the University of Zurich and members of the BCS Fortran Specialist group from the UK.
For the Keynote talk we are happy to welcome Dr Damian Rouson, Group Lead for the Computer Languages and Systems Software (CLaSS) Group at Berkeley Lab.
The FortranCon 2021 is organized in two full days with session timings to accommodate attendance from both Europe and the Americas. Anyone interested is kindly requested to register for the event. The registration is free of charge. Please register until September 15th, 2021. Participants will virtually attend the meeting (due to Covid-19 situation). If you wish to attend in person then please contact us as places will be limited and so we can inform you of restrictions with physical events.
Update: Instructions on how to connect to the event will be only sent to registered persons. Please contact the Steering Committee Members if you have not received them yet.
A Call-for-Abstracts is also open for people who would like to present at the conference. The official language is English. We have 2 tracks: Presentations (25 + 5 minutes discussion) and Communications (15 + 5 minutes discussion). They will be reviewed by a Scientific Committee.
The submission must consist of a title (max 10 words) and an abstract (max 200 words). Furthermore, it is required to specify if you apply for a 15 or 25 minutes slot. You should submit a talk about anything you think is worth sharing with the Fortran Community. However, we are happy to host talks on other topics that can inspire us. Speakers will be requested to describe their experience, the implemented techniques, and the eventual new developments.
Unless explicitly requested by the speaker, all presentations will be recorded and made available through the FortranCon channel.
Submissions will be selected by review from the Scientific Committee via a voting process, members of the committee will not be able to review or score their own submissions or any submission where there may be a conflict of interest. As per the 2020 conference there will be two calls (see deadlines) operating on a first-come, first-served basis between the two calls should there be slots left following the first call.
Registration (free of charge): September 15th, 2021.
First Call-for-Abstract: August 1st, 2021 (decisions sent by August 20th, 2021).
Second Call-for-Abstract: September
1st 4th (deadline extended), 2021 (decisions sent by September 13th, 2021).
We gratefully acknowledge the funding of this event by the UZH Graduate Campus via its GRC Grant.
Most, if not all, programs that perform numerical computations of some kind or other need to deal with
the units of measure in which their variables are expressed. Many solutions for the general problem
have been proposed, but the problem is more difficult than it looks at first sight. For instance,
should a program be able to handle different units (cm versus inch) automatically? Is it possible
to check the dimensional consistency of a formula without have the programmer detailing everything?
How to deal with similar formulae that can be applied to different quantities, like an interpolation routine?
Are dimensions and units beyond the Système International supported? In this presentation we
attempt to give insight in the various aspects and what existing and proposed solutions can and cannot do.
Compile-time evaluation offers significant advantages during optimization and debugging. It promotes transparency and brings a code closer to functional paradigm. Unfortunately, Fortran does not support compile time evaluation of user defined functions. Nevertheless, it includes two features which salvage such undertakings: a vast library of intrinsic functions and default constructors. The intrinsic functions can be composited to an arbitrary degree and made to act upon default constructors. This allows one to accomplish surprisingly complex computations at compile time. Chief example to be discussed in this presentation is evaluation of arbitrary degree Lagrange polynomials and their derivatives using an ingenious combination of SUM, PRODUCT, SPREAD and RESHAPE functions. Admittedly, the implementation will be admonished as a crazy contrivance once Fortran starts supporting compile-time evaluation of user defined functions. However, it is interesting in its own right to explore the limits and possibility of the approach within the framework of the current standard.
Practitioners in the field of hydrometallurgy need computational models that
help to plan, optimize and troubleshoot the operation. Most of these models are
mass balance based and can be simply formulated in a spreadsheet application.
However, more detailed models that deal with such processes as heap or dump
leaching require solution of numerous coupled partial differential equations.
Two particular issues arise with the practical use of these models. First, there
are typically many input parameters. Secondly, these models are required to deliver simulation results in less than a minute on a typical desktop PC.
Fortran has a long history of being used in engineering applications. There
exists a large collection of libraries for various purposes. Although they are
commonly implemented using FORTRAN77 standard, backward compatibility of the
modern Fortran makes it easy to use them in a new code. Furthermore, its
object-oriented and functional programming capabilities help to build modular
and easy-to-maintain applications. Finally, C-interoperability enables the use
of tools such as Python or spreadsheet applications for pre- and
This case study demonstrates how Fortran is used to model liquid flow in heap
leaching operation and how it integrates with a spreadsheet application.
In this talk, I will present my personal experience in developing packages for molecular dynamics simulations in Fortran and in Julia, in particular codes for the calculation of many-body interactions. I will discuss what are the advantages, facilities, and disadvantages of the Julia language and its set of development tools, compared to the current Fortran development process.The main disadvantages of the Julia language will also be discussed, and I will illustrate the possibility of code migration between the two languages. I am the lead developer of the widely used (Fortran) Packmol code for generating initial configuration for molecular dynamics simulations, and have been adventuring myself in Julia for about two years, having developed the ComplexMixtures.jl package for the analysis of the structure of solutions, which include the CellListMap.jl generic package for pairwise n-body interaction calculations. (github: https://github.com/m3g)
I will present an overview of the methods we use to generate bit-reproducible
solutions of the Modular Ocean Model (MOM), a Fortran-based model widely used
in weather and climate simulations. I will briefly describe the overall
structure of the solvers as well as its verification and regression test
suites. This is followed by a discussion of the more novel testing methods of
dimensional and rotational invariance.
Dimensional verification is based on power-of-two rescalings of the model
parameters. The dimensions generally correspond to physical units, such as
length and time, although there may be multiples scales of each instance.
The rotational verification is used ensure the invariance of the numerical
solvers. We apply an "index rotation" to the model inputs, parameters, and
coordinates, so that the fields are rotated in memory while retaining their
These methods have proven capable of detecting subtle errors in complex
numerical expressions, and further validate Fortran as a platform for producing
robust bit-reproducible solutions in forecasting and academic research.
This talk will describe our experience porting the bottleneck kernels of NWChem's CCSD(T) code. With the NVIDIA HPC Fortran compiler, we are able to run completely standard Fortran code on A100 GPUs, with respectable performance, relative to the expert-optimized GPU implementation based on CUTENSOR. The same code runs well on a range of CPUs. We will explain how to optimize DO CONCURRENT for GPU and CPU architectures using different variants of standard parallelism. We will also show how the NVIDIA HPC Fortran compiler supports high-performance GPU implementations of linear algebra intrinsics, using a CUTENSOR back-end.
Although Fortran has evolved into a modern, multi-paradigm programming language, the research literature on Fortran more thoroughly addresses some paradigms, such as object-oriented and parallel programming, than others, such as functional programming and programming by contract. This talk will present new patterns for expressing concepts from these less-studied paradigms and will illuminate the subtle
interplay between each of the aforementioned paradigms. The talk will demonstrate how error termination, a parallel execution concept, combines with object-orientated programming (OOP) to facilitate contract enforcement in pure procedures, a functional programming concept. The talk will highlight how user-defined operator semantics nudge the programmer toward writing purely functional expressions suitable for asynchronous parallelization, vectorization, or offloading to accelerators. The talk will also describe how OOP supports asynchrony through the event_type derived type. The talk will conclude with thoughts on intersectionality from a social science perspective, describing the experience of someone from an underdog community striving to teach an underdog language new tricks.
We are developing a modern open-source Fortran compiler called LFortran. This compiler enables the interactive execution of code in environments like Jupyter, enabling exploratory workflows in Fortran (like Python, MATLAB or Julia). Besides interactive use, LFortran can also generate binaries. A live demo of the compiler with a Jupyter notebook will be shown. The compiler is written in C++ for robustness and speed. It parses Fortran code to an Abstract Syntax Tree (AST) and transforms it to an Abstract Semantic Representation (ASR). LFortran includes several backends that transform the ASR to machine code via LLVM, x86, or C++ implementations. More backends are planned. Our compiler has been designed to be modular so that the AST and ASR can be used independently, which is an important feature for supporting an ecosystem of tools that otherwise would be hard with a monolithic compiler design. Any Fortran 2018 code can now be parsed into the AST, with smaller subset to ASR and an even smaller subset to LLVM and machine code. We are now working on extending the subset of code that can be compiled. The goal is to be Fortran 2018 compliant.
Over the last decade, efficient and portable GPU programming has become a necessary evil for applications expecting to run efficiently on modern supercomputers.
The Heterogeneous-compute Interface for Portability (HIP) is a C++ Runtime API and kernel language that allows developers to create portable applications for AMD and NVIDIA GPUs from single source code.
HIPFort exposes the HIP APIs to Fortran applications via standard ISO_C_BINDING interfaces. The APIs also include interfaces to vendor-specific, highly optimized libraries for dense and sparse linear algebra, FFTs, and machine learning routines.
In this talk, current and future implementations of HIPFort will be discussed, with a particular focus on the pros and cons of the various Fortran/C interoperability features introduced over the years by the Fortran standards.
The SPACE (System Power Analysis for Capability Evaluation) Fortran program developed at NASA Glenn Research Center has enabled power generation predictions and energy balance analyses for spacecraft electrical power systems (EPS) since 1988. SPACE was originally designed to analyze the EPS of the Space Station Freedom and continues to support certifications for visiting vehicles and extravehicular activities on the International Space Station today. Another version of SPACE currently supports design and mission planning operations for the Orion and Gateway vehicles as part of NASA’s Artemis program. In total, over 50 engineers have contributed to the development and use of SPACE on various platforms throughout its history. Ongoing code modernization efforts aim to generalize the program for use with different vehicles and configurations. While SPACE team analysts currently interact with the program via the command line, future development work also includes the creation of a graphical user interface for use by flight operations personnel. The SPACE code thus has a long legacy in spacecraft EPS analysis and will continue to play a critical role in future human spaceflight missions by leveraging the computational power of Fortran.
In this presentation the implementation adopted on existing Fortran code used across different platforms (Windows/Linux), for the calculation of Ship motions based on potential theory, to achieve hybrid parallelization (MPI and OMP) will be discussed. Main points of attention when developing code (MPI shared memory, OMP private data, sp/dp precision, compilers, etc.) as well as user definition of optimal settings for the parallel execution, which depend on hardware and the problem under study, will be addressed. Finally, the importance of additional topics like handling of large temporary files (fort, hdf5), run-time memory consumption checks and language limitations will be presented.
f2py is the gold standard for interfacing Fortran and Python. The most famous downstream consumer of the generated wrappers is undoubtedly the
scipy ecosystem. Crucially,
f2py is not a compiler, and generates a best effort set of wrappers, aided by special comment lines. One of the key inter-operable approaches to compilation of the subsequent wrappers relies on
numpy.distutils. Given the planned obsolescence of this module; we discuss the methology by which the build phase can be split into a two phase process and document better the
pyf enhancements made to facilitate callbacks. A brief outline of test suites and documentation within the
numpy ecosystem and proposed enhancement proposals will be discussed as well. We lay out the roadmap towards
f2py remaining relevant beyond
f77 by implementing derived types and newer features like parallelism with co-arrays. Playing to its strengths as a code-enhancer and leveraging the flexibility of not being constrained by the actual compilation process allows for the reimagining of
f2py as a tool and library.
In the modern software development approach, it is often advocated that test automation should be implemented in the regular workflow. The test automation aims to simplify the software development by replacing the repetitive tasks into a framework that would compare the actual with the predicted outcomes.
One way to guarantee that new implementations in legacy code would not change past behavior is by the test automation implementation; it would catch changes in the code that alters the results from functions and routines.
The Brazilian Electrical Energy Center Research (Cepel) develops a suite of commercial software for power system analysis, coded in Fortran and C++, that requires a lot of testing for publishing newer versions of the software. The AnaTest framework was an internal solution developed to provide a tool for test automation that works for both legacy Fortran and modern C++ code and in Windows and Linux environments.
The AnaTest framework illustrates how test automation can be implemented in legacy code, with high benefits and low cost. It will also be used as a showcase to motivate the community into adopting test automation for a safer and faster production of Fortran software development, addressing unit testing and black-box testing approaches.
Starting in Fortran 2008, Fortran supports two forms of parallelism: loop-level parallelism using DO CONCURRENT and coarse-grain parallelism using
coarrays, which is form of PGAS. This talk will describe a third form of parallelism and argue that it should be supported by the Fortran language. The third form of parallelism is shared-memory task parallelism, which supports a range of use cases not easily covered by either of the current forms of parallelism in Fortran. We will describe what these language features might look like and how they can be implemented, based on our experience with OpenMP tasks and OpenACC async, among other things.
Automated testing is a well established best practice in software development, so you are writing test suites for your Fortran projects right? But how useful is your test suite after you have finished writing it? Does it help you to pinpoint the source of bugs? Does it help you to make changes to functionality, or get in the way? Would a new developer find it useful for getting their bearings in your project? Can you tell which requirement a given test is meant to verify?
Experience in the nuclear power industry, with its emphasis on quality assurance and high standards for verification, provides motivation to always have satisfactory answers to these questions. This presentation provides guidance for writing a well organized suite of tests that leads to positive answers to the previous questions. The primary lesson is that a test suite organized as an executable verification of the requirements of the project provides long term value in the form of easier on-boarding for new team members and increased developer productivity during maintenance activities. Examples and demonstrations are provided using the Vegetables Unit Testing Framework, which has been designed to aid in writing test suites of the form described above.
A new community of developers has formed to unite Fortran users and modernize the Fortran ecosystem.
In this presentation, we describe the high-level features of Fortran that continue to make it a good choice for scientists and engineers in the 21st century. We also outline ongoing community efforts including the development of a Fortran standard library and package manager, the fostering of a friendly and welcoming online community, improved compiler support, and language feature development.
The lessons learned are common across contemporary programming languages and help reduce the learning curve and increase adoption of Fortran.
LFortran has a Bison based parser implemented in the parser.yy file that can parse most of Fortran source code. The main objective of my GSoC project was to make sure that all the grammar rules defined are exposed to AST (Abstract Syntax Tree) level i.e., one has to systematically go over the parser file and make sure AST is always generated for all the grammar rules defined, resulting in Completion of the AST generation. AST.asdl contains a list of AST nodes that have already been implemented, this project aims at adding the missing node into the AST.asdl.
The steps for implementation are:
Add missing AST nodes.
Define macros, use them in the parser file to expose these nodes to the AST level.
Add tests to make sure things work as expected.
fmt sub-command(format) is used to convert AST back to Fortran source code. There were certain issues related to
parser, this project solved those issues. As a result, LFortran would be able to convert every grammar rule defined into AST for further manipulation and if required back to Fortran source code.
In my Google Summer of Code, 2021 with LFortran under the umbrella of NumFOCUS, I worked on adding semantic and LLVM backend support for arrays and allocatables as per Fortran standards. Specifically, the project resulted in addition of support for array declaration, operations on arrays (slicing, unary and binary operations), allocatable arrays, automatic deallocation, passing arrays to subroutines and functions. At the LLVM level, structures have been used as descriptors to store the necessary information related to an array such as the pointer to the data, offset and dimensions’ lower and upper bounds. Operations on arrays are converted to
do loops while storing the intermediate results in compiler generated variables. Memory for allocatable arrays is reserved in heap using
malloc and freed using
free in C runtime library. Automatic deallocation is achieved by freeing memory of those allocatable arrays in a particular scope which haven’t been manually deallocated by the user. We pass pointers to array descriptors (for arrays on heap) and pointers to data (for arrays on stack) in functions and subroutines. In this talk, I would be covering each of these topics in detail with some examples of internal representations (ASR, LLVM) generated by LFortran.
The Fortran standard is a rather imposing document; though with F2018 at around 600 pages it is significantly lighter than its C++ counterpart. The standard itself is rarely cited as a beginner resource, with a cottage industry of books designed to shed light on the dry prose and foreboding technical rigor. However, with LFortran, particularly viewed through the lens of the Abstract Semantic Representation (ASR) of any Fortran code, the standard suddenly gains clarity and rigor. Being as it is a Fortran-first representation, unlike GCC's internal representations (parse trees and lowered GIMPLE) or opaque (proprietary) middle-layers of NAG/Intel; the ASR is meant to concretely represent the syntax in a way to make the Standard seem eminently rational. Implementing the intrinsic functions and standard computing models become pleasant C++ puzzles instead of pidgin nightmares of progressively lower representations. In this presentation, I will discuss the process of implementing Standard intrinsic functions, the lifeline of any applied physical science researcher. LFortran allows for further flexibility at runtime, which will come up briefly, but most of the focus for this short talk will be on the compile time evaluation of intrinsic functions and future directions.
The Fortran standard library (stdlib) is now well into its second year of development. In this past year, stdlib has grown not only in its functionality but in its contributor base, with most of the new development coming from new contributors, including two Google Summer of Code students. Stdlib provides new functionality for working with bit sets, logging, quadrature, sorting, strings, and more. In addition to new capabilities in stdlib itself, there have also been several technical improvements to the documentation and build system. The full API documentation is generated by the FORD tool and hosted online at the fortran-lang website. Furthermore, Github's Continuous Integration pipeline is used to ensure cross-platform support by building stdlib and running its test suite on every pull request. There has also been progress toward supporting the Fortran Package Manager (fpm) both for building stdlib as a standalone library and for incorporating stdlib as a dependency in fpm projects. These enhancements bring stdlib closer to its goal of being a featureful and easy-to-use library for general and widespread use.
To provide better support for strings, the Fortran Standard Library (stdlib) introduces stdlib_string_type, stdlib_strings and stdlib_stringlist module.
Since the start of the project, several string inquiry and manipulation procedures like pad, find, replace-all, etc have been added, adhering to the philosophy of unifying the community and providing simple and intuitive abstraction to the users.
Every type of usage from common ones like reversing a string to peculiar ones like finding n-th non-overlapping substring are developed in close collaboration with the community.
Flexible high-level procedures like slice cater to every possible need while low-level APIs like count are optimized to readily build upon (as stand-alone or in combination with other provided APIs) to meet any specific requirement of a user.
All procedures work with deferred-length intrinsic character as smoothly as with string-type. This allows for a seamless integration of stdlib's string processing with the existing projects. Moreover, APIs being backward compatible will continue to serve old projects even with their latest versions.
A language-specific package manager is an important element to build an efficient ecosystem of libraries and projects. Fortran has long missed a dedicated package manager, making the user experience of practitioners cumbersome. With the Fortran package manager (fpm) we are addressing these needs creating a reliable and productive tool that makes building applications and using libraries intuitive. Fpm takes care of fetching and building all transitive dependencies used to build the main project making especially easy to reuse other projects. As a cross-platform reproducable development and production environment fpm simplifies the difficulties in building, running, testing, and installing Fortran-centric projects. Support for all major Fortran compilers and platforms is available.
Fpm is written in Fortran and built with itself, making it easy to bootstrap and install fpm on any platform with a Fortran compiler. The positive effect of a Fortran implementation is the easy accessibility of the codebase, which enables the community to contribute back and improve fpm further. While fpm is relatively new and still rapidly developing, it already found adoption even for large-scale projects today. Features to incorporate build requirements emerging from developing parallel applications or integrations with GUI environments are planned or under active development.
The Fortran Package Manager (fpm) aims to be a Fortran-specific build system to simplify compiling Fortran code and using third-party dependencies.
Fpm is currently in alpha development status and supports a wide range of features.
Recent work, undertaken as part of the Google Summer of Code programme, has implemented the syntax and logic required to provide fine-grain control of compiler flags by package maintainers.
Specifying compiler flags for fpm projects is a complex problem due the existence of multiple Fortran compilers, each with their own set of flags.
Moveover, package maintainers often need to specify different flags for a variety of build profiles, such as ‘debug’ and ‘release’, as well as across a variety of target operating systems.
What is more, some packages require specific compiler flags other than the default ones built into fpm and complex projects with various package dependencies might need specific flags for each package, therefore a priority system for compiler profiles was designed and implemented.
In this presentation, detail is given on the new functionality for specifying compiler flags in fpm including: the syntax for the manifest file; the behaviour for package dependencies; and common use-case examples.