Here is another example of a Fortran to C++ migration, this time for weather and climate modeling codes at ORNL:
I don’t know more details beyond the tweet. I offered them collaboration on the Fortran to C++ translation backend in LFortran.
That bullet point at the end seems to negate much of the benefits of the migration, though.
3 Likes
There is a Feb 2021 press release US Air Force, ORNL launch next-generation global weather forecasting system.
1 Like
It’d be great to hear more from Matt Norman about this, but without knowing more this looks like noise presented as signal.
Matt has a nice project on GitHub in which he has several Fortran, C, and C++ implementations of a toy weather model with different parallel paradigms:
However, I assume the relevant ORNL climate and weather code in question is E3SM. Its GitHub repository can show you in what language its implemented in: GitHub - E3SM-Project/E3SM: Energy Exascale Earth System Model source code. NOTE: use "maint" branches for your work. Head of master is not validated.
C++ is indexed at 3.5% (Fortran is at 86.4%), however in reality, the percentage of actual C++ code is much smaller. If you look at what source files are indexed as C++, you’ll see that most of them are Fortran .inc (include) files that are incorrectly labeled as C++ by GitHub.
I am not too familiar with E3SM, but I am doubtful that this huge project that is several years in development already, will suddenly pivot to migrate its entire codebase to C++. More likely, it will have C++ extensions to offload portions of the model to GPUs, as has been done previously with WRF and MPAS (MPAS is also an E3SM component).
A bullet point from the slide included in the linked tweet:
- Fortran is less popular overall; fewer dedicated developers
Is generally true, but absolutely false in the weather and climate fields.
So, my impression from all of this is, Matt likes C++ (and that is fine, of course), he’s done great parallel work with various architectures, and it doesn’t look like a significant production-grade weather or climate project is migrating from Fortran to C++. I’m not saying it’s impossible, it just looks highly unlikely to me.
2 Likes
In one of the replies Oliver Fuhrer wrote
DOE/ORNL is using C++ because of its templating functionality (among other). We have moved on to using Python with code generation.
This seems to be part of a general trend (also seen at large in Julia) to use meta-programming and code generation to simplify the creation of (parallel) kernels for different models/architectures.
Also the UK Met Office is working on a code generation system - PSyclone, that is used in their “next generation” LFRic weather modelling system.
This is not just due to a lack of templates in Fortran; I am aware of code generators like pystencils which create optimized C/C++ code (CUDA, OpenMP, …). Two more projects which also use code generation are (were) the ExaStencils project funded by the German research foundation, and the PyFR CFD code developed at Imperial College London.
4 Likes
Couple points:
-
Thanks for the background Milan, I was thinking you would know.
-
Milan, can you please submit E3SM to Fortran Packages - Fortran Programming Language? I didn’t find it there. If this is the only outcome of this discussion, it was worth it!
-
I don’t know if it is noise. But especially if it is noise I want to have the discussion here: it helps to see the background and points and even I learned something, and it might help people to be less inclined to do the migration, and if it is noise, we can actually help prevent the migration. And if it is not noise, then we also need to have a discussion to learn something from it.
-
Milan, from where you see it — is your opinion that codes like E3SM do not need any of our help, that they are not in any danger at all to migrate to C++? From where I see it, they absolutely are in such danger, and that is why I am starting such threads like this one: to figure out what are the motivations and do we have a plan to address all of them as fortran-lang? (Obviously we can’t fix things by tomorrow, but if we have a plan and are working on fixing those, they will be fixed in a few years.)
1 Like
Yes, I’ll submit it to the index, good idea.
No, even projects like E3SM could absolutely use our help, even if they are not (IMO) in danger at all to migrate to C++. The way I see us being able to help best is, promoting the language, improving its tooling, making it easier to use and learn, so that young scientists who join large Fortran projects can promote, improve, and grow best Fortran practices within their own teams, and so that young scientists not originally familiar with Fortran get interested and desire joining such projects.
There sure are Fortran projects that are in danger of migrating to C++. I don’t think E3SM or other production weather and climate projects are like that. More likely I expect, and it’s been common, for smaller pieces of such projects to be written in different languages and programming paradigms. This is because of the scope of the effort, which is O(100 person-years) from start to production, and because of the large body of Fortran expertise and existing code in this field. It also tremendously helps that Fortran’s design fits the problem better than any other language I know.
More likely are brand new projects being started in other languages, like CliMA in Julia. I wouldn’t be surprised another large project like that being started in Python at the high level, and a mix of Fortran, C, and/or C++ at the low level.
1 Like
(Without a background in computer science, if this is relevant for the following limited perspective), but point #3 of said tweet, the correlation of a language’s reliability to perform well, on one hand, and popularity (measured how?) and number of developers on the other hand is not obvious to me. As it addresses Fortran (or perhaps FORTRAN?), I perceive this point as a blend of myths #13–15 of Crain Dedo’s compilation.
Yes, I agree that’s how we can help: to provide the ammunition to people on those big projects that like Fortran, so there is a community that champions Fortran. That was the main thing missing in the past.
The only part where I personally take a different approach is that I personally take efforts to migrate (parts?) of such codes away from Fortran very seriously. I personally do not see that as noise, as something that can never succeed and so on. Rather, I see that as efforts of well meaning people to migrate away for good reasons (to them). And I am very much interested in investigating those reasons, and if they are valid, to fix them.
There is a lot of effort (and tax payers money) spend on such migrations, even for just parts of the code. It would be better for everybody if we improve Fortran to the level that we do not have to have such conversations and efforts and where we can simply stick to Fortran for such numerical scientific codes and everybody is happy.
3 Likes
Yes, I don’t dismiss that there is a signal overall. What I meant specifically is that the tweet you quoted, and the slide that the tweet quotes, does not point to any specific large project actually migrating. So, in my view, the messaging is disguised to present a signal out of noise, regardless of whether signal exists elsewhere or not. I don’t disagree that it does, given your experience and that I trust you on it.
1 Like
The European Centre for Medium-Range Weather Forecasts (ECMWF) maintains fckit
Fortran toolkit for interoperating Fortran with C/C++.
In addition useful algorithms from ecKit are wrapped with Fortran.
Project website and reference documentation on released versions: fcKit - fcKit - ECMWF Confluence Wiki
fctest
Unit Testing Framwork for Fortran, made easy.
- C Preprocessor Macros are used to make writing tests extremely fast
- Tests in one file are bundled in a Test Suite (Fortran Module)
- Python script generates a main program for a Test Suite
- Driven by CMake build system ( and ctest )
To use in your ecbuild project
Simply add following line to your project’s CMakeLists.txt
ecbuild_add_option( FEATURE FCTEST DEFAULT ${ENABLE_TESTS} DESCRIPTION "Fortran Unit Testing Framework" REQUIRED_PACKAGES "NAME fckit" )See src/examples folder how to add and create the unit-tests.
fckit
Various Fortran modules helpful to create mixed-language applications
- MPI
- Logging
Their atlas project depends on fckit.
Atlas is a ECMWF library for parallel data-structures supporting unstructured grids and function spaces, with the aim to investigate alternative more scalable dynamical core options for Earth System models, and to support modern interpolation and product generation software
Atlas is predominantly C++ code, with main features available to Fortran codes through a F2003 interface.
2 Likes
Hi all, finally get the time to respond here. A lot of what has been mentioned above is correct. Not sure what the main point of the discussion or thread is (seems like understanding the reasons for migrating from Fortran to C++ and finding arguments why that is not a good idea or not required). Here are my $0.02:
- The weather and climate community has lots of Fortran code and will always continue to have Fortran code.
- With HPC hardware becoming more and more diverse because the end of Moore’s law, three things are becoming an issue with Fortran: 1) vendor support for novel hardware architectures is typically earlier and better for C++ 2) Fortran itself is not sufficient and needs to be enriched with multiple flavors of directives which deteriorates maintainability and readability of the code and 3) Fortran’s procedural and explicit looping syntax is typically an overspecification of the algorithm and it’s hard to extract parallelism from the code.
- Some of these issues can be alleviated by programming languages that allow for template metaprogramming (e.g. C++) or are more dynamic (e.g. Python, Julia), since it allows to specify the algorithm on a higher-level of abstraction and e.g. leave the execution model, parallelism, data storage order, … to a hardware specific backend.
- The weather and climate community at large will probably never accept modern C++ as their main programming language (my personal opinion).
6 Likes
Here are a few E3SM articles that describe the re-write of an E3SM component–an atmospheric dynamical core (essentially, a PDE solver) and a set of physics parameterization schemes (empirical models of unresolved sub-grid processes)–from Fortran to C++ and Kokkos:
https://e3sm.org/about/organization/ngd-sub-projects/ngd-nonhydrostatic-atmosphere/
This is a significant re-write for sure, so I was wrong with my earlier assumption.
1 Like
Welcome to the forum. Based on the job market’s demands, the argument presented about Fortran’s popularity is not accurate. I attach a recent finding from a larger research project to this comment. Fortran’s presence and demand are as strong as ever it has been.
3 Likes
I am surprised not to see C and C++ on the graphic – they are commonly used in computational physics. I believe C++ dominates in high energy physics. Google searches of “computational physics C++” and “computational physics Fortran” give 2.7 and 1.4 million hits.
1 Like
It is likely that the NLP parser confuses the “C” with the character “C”. So, C/C++ should likely be there somewhere in the top-10 list. But that is not the point of this graph. It was to show that Fortran is still a dominant popular language in computational physics, more popular than the most popular language in the world, Python. So the argument that people frequently make regarding the popularity of Fortran is baseless.
It’s hard to take a graph seriously that is based on automated analysis that misses 2 of the most popular languages.
On the side note, the software used for this project is gensim. If you have questions about its reliability, please reach out to the authors.
Thank you for the feedback and welcome to the Forum. Yes, that is the aim of this discussion. We are trying to learn the reasons and improve Fortran to fix them.
I am personally not trying to find arguments why it is bad idea (from past interactions with teams who do the porting from Fortran to C++, it is usually a very good idea, for performance and other reasons, using current tooling). Rather, I am just trying to understand exactly the issues with Fortran, and work on fixing them in the long run.
2 Likes