Seeking support for a proposed Network on Sustainable Fortran-based Software

TL;DR:

  1. We will be submitting a funding application to a UK research council to support the creation of a network focused on Sustainable Fortran-Based Science.
  2. We seek letters – from you and others – of support for such a Network and/or of participation in the Network. I can provide advice on what you might write in a letter.
  3. Please email letters directly to me (a.rainer@qub.ac.uk). Deadline: Tuesday 25 March 2025
  4. Further information on the network is provided below, and/or contact me to discuss further.
  5. Thank you!
  6. P.S. I have seen the thread on “Sustainable Computational Chemistry Software Development and Integration” and will explore that thread in more detail.

The detail:

Here’s some further detail:

  1. The aim of the Network is to engage with questions such as: What needs to happen for existing and new Fortran scientific codebases to continue to contribute to outstanding science over the coming 70 years, in the way these codebases have contributed during the past 70 years?
  2. Thus, the focus of the Network will be on the importance of Fortran to science, to complement others’ (cf. this Fortran-lang?) focus on the Fortran language itself. Clearly the two foci are (closely) connected. (Apologies if I am misrepresenting Fortran-lang!)
  3. We want to work with others and not step on each others’ toes.
  4. We want the network to remain active after the funding ends.
  5. As with our RSE’24 workshop last year, we want the network to be warmly welcoming and inclusive, e.g., of people from diverse backgrounds, the spectrum of scientific disciplines, professional roles (e.g., research software engineer, computational scientist, scientist), sectors (e.g., academe, government, industry, vendors, other?), and countries (for funding reasons, the network will be UK-based but will have an international focus, including support for international travel). ← I expect I have missed something important out of this ‘list’.
  6. We seek two kinds of letters: a) letters supporting the value of such a network, and b) letters also expressing interest in participating in the network. I can provide guidance on each.
  7. Thank you!
9 Likes

Hey @arainer,

This sounds like a good idea in principle. I think additional networks/communities that are more focused on one particular aspect (such as science) would be enriching, esp. if there’s a lot of healthy communication between communities (e.g., collating and communicating the uses, needs and challenges with Fortran specifically in the science community).

I’ve been meaning to submit a UKRI proposal on sustainable software in general (sustainability in terms of environment and development/longevity), but I think one can make a good case for a focus on Fortran in many areas of sustainability. Consequently, this peaks my interest here.

Happy to provide letters for both, though currently stretched a little thin, so I’d welcome more explanation and templates. I’m also serving on steering committees of programmes (related to supercomputing, climate/earth system modelling and AI), where I see potential benefit from such a network. Happy to also explore greater involvement in/ties to your project to also ensure its longevity (point 4).

You use “sustainable” in the sense of the ability to continue to run and develop Fortran codes that have been used for a long time. Another common meaning of “sustainable” nowadays has to do with environmental impact. There was a 2021 paper Ranking Programming Languages by Energy Efficiency by Pereira et al. in which Fortran generally had a high rank.

Thanks for your comments, @Beliavsky . You are ‘correct’ in observing that I (primarily) used “sustainable” in the sense of continuing to run and develop Fortran codebases. At least two other connotations are also relevant: your second interpretation, i.e., about programming languages being sustainable in an environmental sense (thank you for the link); and then, as a third connotation, the contribution that Fortran has made to environmental sciences, e.g., weather prediction.

That’s great, thank you @fxm ! I’ll message you direct to discuss more specific explanation and templates.

100% into this, amazing idea. Happy to provide a letter for both too.

1 Like

Thank you, @jorgeg!

1 Like

I can answer this one right away: you need to rejuvenate the language, see the efforts at fortran-lang (this Discourse, fpm, stdlib, tutorials, webpage, etc.), you need good open source compilers (GFortran, Flang, LFortran), you need good hardware support (ideally from vendors directly, as well as open source), and then you need some improvements to the language itself (probably some generics, some improvements to the GPU support, etc.). As to the codes, they can then take advantage of the above. It needs to be simple to run on all modern hardware and get high performance. (If you do not rejuvenate the language, then there is almost nothing the codes can do: the options are very limited, and migration to another language is often the best option.)

If you have another question like this one, I am happy to answer also. :slight_smile:

1 Like

Thanks, @certik, for your perspective. Part of what I am hoping the Network will do is help with some of the “hows” for the items you identify, and also help to advocate for those items. I also think there are additional challenges to address, e.g., the differences in culture between scientists (e.g., the pressure to publish which can increase technical debt) and research software engineers (the desire to minimise at least some technical debt), the time/effort needed to refactor code to be simple(r) to run on different platforms, and the policies of funding councils (e.g., the difficulty in securing funding to address some of the items you identify). Thanks again.

1 Like

@arainer, good additional points.

Yes, there is “What the problems are”, I think we already identified pretty much all of them in the above two comments.

Then “How to fix the problems”, there I think our current plan + roadmap seems the the answer for most points that I raised. Regarding the points you raised in your last comments (culture, RSE, effort and funding), we can discuss those too, I don’t know if there is much to add: yes, it’s difficult to find funding for these things. I don’t know if a council could help there by advocating. Do you think that can be effective with some funding agencies?

The last part is “Actually fix the problems we identified by doing the plan from the ‘how’ answer”. Can the council help there? We might not have the precise answers to the questions of funding, but we know very well how to do the other things, such as how to write a compiler, or a package manager. And we are doing it, but that’s where we need the most help. It’s this last part that is the most critical, i.e., “talk is cheap, show me the code”, as Linus likes to say. :slight_smile: I would be interested what your opinion is here, and if your proposal could help.

From my perspective this last point is where efforts should be directed. Unless it was not clear what should be done, but in that case I am always happy to discuss more any of the points above.

Hi @certik , here’s two responses, one in relation to funding and one in relation to the Network. I have tried to be concise…

In terms of funding, two things might interest you:

  1. We plan to request funding to support some development of tooling. This is likely to be smaller amounts funding, e.g., a set of 3 months projects. I don’t think it’s helpful to say more here because anything I say would be speculative and suppositional. If you - or for that matter anyone reading this exchange - wants to discuss specifics, they are welcome to message me direct. Also, be aware that the research council will expect the funding to be spent on a research software engineer, or equivalent, based in the UK, but that might constitute a UK-based RSE helping to develop some aspect of the Fortran technical ecosystem (e.g., tools) that benefits everyone.
  2. You and others might also be interested in a recent pre-announcement for research-software maintenance funding. Disclaimer: the following is my interpretation. The amounts available are larger, £150K - £500K (approx. $300K - $1M) for one or two year projects. As with item 1, be aware that the research council will expect the funding to be spent on a research software engineer(s), or equivalent, based in the UK, but again that might be about a UK-based RSE helping to develop Fortran tooling, or other contributions that benefit everyone - see the call. If you - or anyone else - would like to discuss this option, contact me direct. Without going in specifics here, we are considering (we’re not convinced yet) submitting an application to the call for funding in this space.

In terms of the Network:

  1. First, some context: at a one-day workshop last September, in the UK, on Fortran-based science, we hoped for about 20 participants. We actually got close to 50 participants. What came out of that workshop was: a) the recognition that the Fortran community (in the UK, at least) was invisible to itself (I realise fortran-lang is aiming to address that), b) a desire to strengthen the community, c) a desire to help develop tools, including their documentation and other support, and d) the need for education to improve software engineering practices for Fortran software engineering.
  2. The proposed Network would aim to establish a strong, active Fortran-based science community that was located in the UK (due to funding) but with an proactive international reach (we’re stronger together…). We therefore want to engage with, for example, Fortran-lang, and also others, in the UK, Europe, the US and internationally. This would directly respond to items 3a) and 3b).
  3. The network would undertake some short-term funded projects to explore and progress tooling and education. This would address items 3c) and 3d). There is a least one significant tooling project that emerged following the workshop last September, and which has seen impressive adoption in a short timeframe. The workshop can’t and shouldn’t try to take the credit for the tooling, but I suggest the workshop helped provide the motivation and encouragement for a couple of keen and capable research software engineers to create and develop that tool.
  4. The network would also undertake a mapping of the state of Fortran-based science. Amongst other benefits, I suggest that this mapping would help us provide a compelling, evidence-based response (even, perhaps, a rebuttal) to a certain, fairly-recent report that advocated moving off Fortran because of the risks of remaining with Fortran :)…

Let me know if you want/need further information.

Thanks again.

1 Like

About tooling: what ever the language, nowadays it is expected to be magic and I think it is easily the main issue for any project. More so for a fresh research project.

My 2cents through recent experience:

I was involved in a project recently and we developed a very nice modern code using old f77 ODE codes. We sort of modernized it to a degree and modified to our needs. It works great! But the experience was not Magic:

  • fpm doesn’t support dynamic libraries (yet); very important point for Python API (thanks to @septc and @PierU btw. for helping us getting the ctypes correct for our API, it was a while a go in the forum!)

  • fpm and stdlib had some issues with a project of multiple dependencies (that may have been fixed now) and we had to use hacks (I admire the work of @FedericoPerini and others with stdlib and fpm, if we started now many of the issues would not have hindered us, we’ll try again later)

  • lack of ready made modernized and packaged ODE solvers (there are some great modernization efforts by Fortran hackers, like @jacobwilliams, but it included not the one that we needed)

I think I agree with @certik that the roadmap is well set, but there is work ahead. Tooling is #1 issue. I would say that if more funding could be steered towards systematic and professional packaging/modernizing of important packages (like the work done by @FedericoPerini on blas/lapack), that would pack a high impact.

4 Likes

@eelis can you please report all the issues you found into github issues at fpm?

@FedericoPerini is planning to work on fpm in the next few months and he will fix it.

2 Likes

The open PR feat: init shared library support. by arteevraina · Pull Request #1050 · fortran-lang/fpm · GitHub … I’ve been waiting for this specific feature more than anything in fpm as it would also facilitate two actual production steps for me, one creating a Python API also using ctypes and another one for a shared Fortran library used in conjunction with an executable.

3 Likes

Thanks @arainer for the details. I think this is very helpful, I have a better idea now what you are trying to do. I think having good vision, and then investing/developing specific tools is key, and it looks like that is part of your vision. The other part is connecting people and visibility, and that is also very important.

This is indeed my experience as well:

the recognition that the Fortran community (in the UK, at least) was invisible to itself

I think any effort to connect the Fortran community is great. I think only a small subset is currently here at Discourse, and yet we have over 1,800 registered users (and only a subset of those are active). You should do a poll with your 50 participants to see how many are registered here. Then we can extrapolate that to estimate the total size of the community. It’s definitely not tiny. I am guessing maybe 1% is here, but I have no idea.

2 Likes

The Fortran, C++, and Python subreddits have 7.7K, 312K, and 1300K members.

3 Likes

Thanks, @Beliavsky , that’s a helpful cross-reference.

I can answer this one right away: you need to rejuvenate the language, see the efforts at fortran-lang (this Discourse, fpm, stdlib, tutorials, webpage, etc.), you need good open source compilers (GFortran, Flang, LFortran), you need good hardware support (ideally from vendors directly, as well as open source), and then you need some improvements to the language itself (probably some generics, some improvements to the GPU support, etc.).

I would like to add two things:

  1. Better Tooling: testing (c.f. Julia), documentation (c.f. Python with Sphinx), and maybe debugging (gdb works, but has limits)
  2. More and better libraries. Obviously a chicken and egg problem, but even the best language will not be used if everything has to be programmed from scratch.
1 Like

the FPM will help a lot with

More and better libraries. Obviously a chicken and egg problem, but even the best language will not be used if everything has to be programmed from scratch.

Since there are two issues here, not only the availability of more and better libraries but the ease of integration of these libraries in new or legacy projects. The FPM solves that by providing a nice way to compile your apps and a nice way to make them available and interfaceable. I am very happy the FPM exists and I try to use it in all the things I write nowadays alongside with CMake.

I think helping with build systems is also crucial, for packages that can’t adopt the FPM yet, for example large legacy apps that use deprecated constructs and weird flags at compile time the FPM is still not ready for these monsters.

So making sure most packages are interfaceable via a simple ExternalProjectAdd in CMake will be very nice.

Better Tooling: testing (c.f. Julia), documentation (c.f. Python with Sphinx), and maybe debugging (gdb works, but has limits)

Julia has gained popularity because of that, how easy it is to pick up and how many packages and libraries there are to do things. The packages then are also documented and well fleshed out. FPM + Forde can also help us with this, making nice docs and good dev docs. But like @certik mentioned, the main thing we need is for people to write code for either the FPM, LFortran etc. or develop tools and libraries that are generally usable by a wide community. For example, the json-fortran project is very very nice but it is not at the level of support as C++ or Python analogues. I will be having more time on my hands soon and will start here, since I believe moving towards json based input output dumping is the right chocie for my particular applications.

Then the existence of a community that is willing to cross pollinate and foster this effort is super important and being visible to one another is inspiring. The discourse, the website, the different Fortran-lang championed apps have inspired me a lot to write things in Fortran. Mostly based on the idea “I could do this in C++, I wonder how it would work in Fortran?”

Sorry I started out just typing a short response and ended up really fleshing this out. Enjoy your (day/night/evening/morning) where you might be!

6 Likes