Fortran-lang.org promotes Fortran as a modern language, which it is. But it's also an old language with a rich history that some site visitors may be interested in. At the top, along with the sections

Learn
Compilers
Community
Packages
News

should there be a link to a History page with relevant information? There is a history from IBM. Other links are at the Fortran Wiki history page, but I would excise the gloomy introduction!

@vmagnin brought my attention to the fact there are numerous Fortran projects still hosted on SourceForge: https://sourceforge.net/directory/language:fortran/?q=fortran

Some might still be useful and could be added to the package index, or we could try and notify their owners.

SIAM (Society for Industrial and Applied Mathematics) has a 1.5-minute video Math in Our Lives mentioning mathematical models of climate change, motors (automotives and aeronautics), and cancer treatment. The code shown at the end is not Fortran (is it C++?). SIAM has a YouTube channel.

Videos of Fortran programmers discussing their work could be of interest.

In the tutorial there are lines of code such as

  print *,A(i,1:m)
  mat(:,:) = 0.0

that could be written

  print *,A(i,:)
  mat = 0.0

I would either show the shorter syntax or show both versions and explain that they are equivalent. I would not want new Fortran programmers to get in the habit of using array sections when they can use refer to the whole array. I have read in the past about compilers that do not optimize x(:,:) as well as x. Maybe that has been fixed.

Here is the list of all Fortran compilers:

https://fortran-lang.org/compilers/

For now I just copied the text from their official websites. We should now contact each vendor and see if they would prefer to change the text that appears at the webpage for their compiler. Perhaps they would like to stress that they have free versions for open source, or such.

We should limit the text to 100 words, to be fair to everyone. Currently all the texts at the webpage fit into 100 words and that seems like the right size to give enough background for each compiler but not be too long.

Following up on Ondřej's suggestion from June's monthly call (see https://fortran-lang.discourse.group/t/fortran-monthly-call-june-2021/1334/14) we want put together a long-term mission statement for Fortran and where we want to be in three years from now.

The actual mission statement can be created collectively in the fortran-lang.org wiki here.

EU Regional School 2021 Part 1 with Steve Lionel. Modern Fortran: Features for High-Performance Computing

Recommended Videos from iRASPA Molecular Simulations

The packaging guidelines state:

https://github.com/fortran-lang/fortran-lang.org/blob/0013186256ed68901b883984731ee1e66e489642/PACKAGES.md#L55

But there is no PR template available for this purpose.

Additional context
Discussion regarding this line in fortran-lang/fortran-lang.org#26 (comment)

The compiler listings should be more specific about which platforms are supported by which compilers. Some are listed, but some are not clear.

As discussed on fortran-lang mailing list

Assign: Williams

#69

We can discuss what needs to be done here.

See #69

What prompted me to open this: https://twitter.com/asmeurer/status/1334423581837561856

When putting together the first version of the website back in April, I wanted and tried to include an example Fortran code snippet. However, at the time, I struggled with my HTML and CSS to make it look pretty so in interest of time I dropped it and moved on. Then I forgot about it.

First question is, should the landing page have an example code syntax, nicely styled, syntax-colored, some minimal but real-world example? The purpose is to show what Fortran looks and feels like, on a first impression to a newcomer to the language.

Second, if the answer is yes (and I think so), can you please think of and propose some example snippets that you think would be good for this? Then we can all discuss them and choose our favorite.

Third, are you interested in making this happen? It should be a relatively low-hanging fruit, with I think a high ROI. It would probably require basic-to-intermediate HTML+CSS skills and a basic sense of good design.

Here are examples for inspiration, some pretty, some not so pretty:

• Python
• Go
• Nim
• Elixir
• Ruby
• Haskell

1. Would it be possible to display packages (e.g., in https://fortran-lang.org/packages/scientific) more uniformly? At the moment those that are developed on GitHub have much more information available than those that are based on other websites, which may give the impression that non-GitHub packages a less active. Would it be possible to display the same information for those developed on GitLab?

2. Would it be possible to give more information (ideally in the submission documentation) about how the version information works? Its purpose is not very clear at the moment. Is that the version that package rapporteurs will be checking? Do other versions need to meet the criteria too? Are there any plans to create version-based links (so the version string must match a tag in the repository)?

Thank you.

I've found a few more Fortran packages I will try to add one by one:

• Fortran processing library: http://www.biosfera.dea.ufv.br/fpl/index.html
• 2DECOMP & FFT: https://github.com/numericalalgorithmsgroup/2decomp_fft
• SLICOT: http://slicot.org/
• FORTRAN Routines for Spectral methods: https://cdm.unimore.it/home/matematica/funaro.daniele/rout.htm
• NUFFT: https://cims.nyu.edu/cmcl/nufft/nufft.html.bak
• FFTLog: https://jila.colorado.edu/~ajsh/FFTLog/
• P3DFFT: https://www.p3dfft.net/
• Parallel FFT Package: https://cs.sandia.gov/~sjplimp/docs/fft/README.html
• fftMPI: https://fftmpi.sandia.gov/
• CSLib: https://github.com/lammps/cslib
• Quadratures for elastostatic Green's functions on flat triangles: https://cims.nyu.edu/cmcl/quadratures/quadratures.html
• Quadratures for smooth functions in two and three dimensions: https://cims.nyu.edu/cmcl/quadratures/quadratures.html
• FMMLIB2D: https://cims.nyu.edu/cmcl/fmm2dlib/fmm2dlib.html
• OpenFFT: http://www.openmx-square.org/openfft/
• libcerf: https://jugit.fz-juelich.de/mlz/libcerf
• PROPACK: http://sun.stanford.edu/~rmunk/PROPACK/
• FATODE: https://github.com/ComputationalScienceLaboratory/FATODE
• HEALPix: https://healpix.jpl.nasa.gov/
• auto-07p: https://github.com/auto-07p/auto-07p
• AxiSEM: http://seis.earth.ox.ac.uk/axisem/
• SeisSol: https://github.com/SeisSol/SeisSol
• APES: https://apes.osdn.io/ (has 5 independent? sub-components)
• codelib: http://elib.zib.de/pub/elib/codelib/en/
• NewtonLib: http://elib.zib.de/pub/elib/codelib/NewtonLib/index.html
• Expokit: https://www.maths.uq.edu.au/expokit/
• pencil-code: https://github.com/pencil-code/pencil-code
• SALMON2: https://github.com/SALMON-TDDFT/SALMON2
• RAMSES: https://www.ics.uzh.ch/~teyssier/ramses/RAMSES.html
• GENE: http://genecode.org/
• PICLAS: https://github.com/piclas-framework/piclas
• OceanWave3D: https://github.com/lppferreira/OceanWave3D-Fortran90

Tracking issue for creating a minibook on language intercompatibility of Fortran with Python.

This is a non-comprehensive list of method to interface Fortran and Python, feel free to edit this list:

• ctypes: dynamic loader for C libraries
• cffi: Python wrapper generator for C
• SWIG: Python wrapper generator for C
• numpy.f2py: wrapper generator for Fortran
• cython: compiler for Python C-extensions
• fwrap: wrapper generator for Fortran
• forpy: bindings to CPython
• f90wrap: wrapper generator for Fortran
• fmodpy: wrapper generator for Fortran
• F2x: template-based wrapper
• Forthon: wrapper generator for Fortran
• gfort2py

Aspects to cover:

• ease of use, constraints (bind(C) requirement, derived type support, finalization, ...)
• memory management, function callbacks
• build system integration (compiling of extension modules, distribution, ...)
• stability (frequent tool chain changes), portability (platforms, Python implementations), runtime overhead
• integration with OpenMP, MPI, CAF (mpi4py, ...)

It was discussed at the October 2020 Fortran call to add a section to our website about autodiff, similar to https://www.juliadiff.org/, that would list all the libraries and tools for automatic differentiation and we would keep it up to date as we develop such tools more.

Looking for example at quantum-chemistry packages, I don't see how they are sorted. If the ordering is by stars, that should be mentioned somewhere.

Because of how central publishing is to the progress in science and academia, the website should include a section where it highlights new publications that build upon the good work of this fortran community. Whether for papers that specifically cite usage of packages from the package repository or papers that build upon fortran code, showcasing such work would be good both for authors and good for the fortran community.

I mentioned my Fortran code on GitHub repo (call it FCoG) on Fortran Discourse in June, which now has 800+ entries, and @awvwgk asked, "How do you feel about contributing this list to the package index or have a separate package page at fortran-lang.org to host this information?" I am happy to collaborate but am unsure in what form. The readme.md page does link to the fortran-lang package index, and FCoG has the unlicense license, so it can be copied. A place where FCoG could use help is classification. The "physics" category is too broad, and some codes in it could be moved to categories such as condensed matter or plasma physics. The "earth science" category is also large and heterogeneous.

I think the emphasis of the flang package list is high-quality open source code that people can use in their own projects. Listed GitHub projects should have 5 stars. Although FCoG has numerical methods categories listing many of the same codes, it also has lots of specialized codes for astrophysics, earth science, and quantum chemistry and electronic structure. I will list a repo on FCoG even if it has few stars, if it looks like a "production code". I created FCoG partly to document what Fortran is being used for.

Possibly the section "What is Fortran used for?" section could link to FCoG. Or at the bottom of the packages page, after "See here for how to get your project listed", the sentence "Another categorized list is Fortran Code on GitHub" could be added.

The chapter Type Casting in Callbacks needs some work.

1. No links to external gists or pastebin entries, the document must be self-contained
2. Generally more text actually explaining what is going on in the sections
3. Better flow of explanation rather than multiple example

The Develop tools section says "You can also help make Fortran better by contributing to its suite of tools, such as Standard Library, Package Manager, or this website." The gfortran, lfortran and I think flang compilers are open-source projects that accept the contributions of volunteers. Why not mention them?

The Write Fortran Software section says "Or just write Fortran software for your research, business, or schoolwork. You can learn how to get started here." Writing code for your own use is fine but does not by itself benefit the Fortran community. Maybe add "and share your code on sites such as GitHub" to the end of the first sentence?

Participants in Fortran-related GSoC projects have not only improved Fortran but earned some money and gained experience that they can put on their resumes. Mention this when GSoC next has openings?

Let's discuss what should the fortran-lang newsletters be and how we should work on them.

I posted an example newsletter in fortran-lang/fortran-lang.org#2 yesterday. You can see the post here and the source file here. With Jekyll, like with most popular static site generators, you write posts in plain markdown, with html for any extras.

Topics

First, what topics/news should be covered by the newsletter. Here's my idea:

• Events: conferences, meetups, and similar. These could be either announcements for upcoming events or briefings/reports from events that happened. They should be related to Fortran. A NumPy or weather prediction conference is probably off-topic. Fortran or HPC meetings are on topic.
• Updates from J3 and WG5 meetings and developments of the language. Highlight proposals discussed. Like what @certik has been posting directly in issues in j3-fortran/fortran_proposals.
• Fortran compiler releases
• New development in fortran-lang projects: For example, highlighting new modules or functions in stdlib, or new fpm capability.
• New packages available in the fpm registry.
• Last but not least, new Fortran releases (202x, 202y...). This one's pretty obvious. :)
• Anything else?

What I think should be off-topic and omitted in newsletters:

• Personal (non-community) Fortran projects, except listing them when they're added to the fpm registry.
• News not directly about Fortran but that could be interesting to Fortran developers. Stuff about other languages etc.

Format

I think we could have two kinds of newsletters:

• Off-schedule, topic-specific. This kind of newsletter covers only one item that is noteworthy. Examples: Fortran meetings, language releases, perhaps even compiler releases.
• Monthly, recurring. This kind of newsletter comes out periodically at the beginning of each month, summarizing the Fortran development and news from the previous month. It's formatted more as a summary rather than an in-depth coverage of a topic, so it can include on-topic odds and ends.

How should we work on it

Here's what I propose:

• Anybody can open a PR for a newsletter
• Must assign a reviewer/editor. Can assign more than one if desired, ideally not too many. You don't want to have to wait for 5 people to review if you want timely news to go out.
• Of course, anybody can comment. If somebody thinks a PR doesn't make appropriate newsletter, they should say so.
• For a monthly recurring newsletter, I suggest we open a draft PR at the beginning of each month, and we work on it as the month goes and new stuff happens. At the end of the month, we clean it up and merge.

Obviously, my PR fortran-lang/fortran-lang.org#2 was not an example of this workflow. I just wanted to get something up quickly to use as an example.

We can automate posting of new newsletters to the @fortranlang Twitter using this. For people who use RSS readers, we have a feed on the website.

What do you think? @certik @jvdp1 @ivan-pi @everythingfunctional @jacobwilliams @marshallward @zbeekman

Modern Fortran in Science and Technology could be added to the Online Courses section. I skimmed it, and it seems pretty thorough.

The Operators and Control Flow section presents the do while loop with the example

  integer :: i
  i = 1
  do while (i < 11)
    print *, i
    i = i + 1
  end do
  ! Here i = 11

but the infinite do loop can emulate this behavior and is more general, since you can test the condition anywhere in the loop. In my codes I use do loops with indices and infinite do loops with exits, but not do while (although there is nothing wrong with it). So I suggest that the infinite do loop be presented in addition to or instead of do while. The equivalent to the code above would be

  integer :: i
  i = 1
  do
    if (i > 10) exit
    print *, i
    i = i + 1
  end do
  ! Here i = 11
  print*,i
  end

The code uses the one-line-if, which I suggested mentioning in another issue.

The sentence "The do loop has an integer counter variable which is used to track which iteration of the loop is currently executing." should be qualified by putting "usually" or "typically" before "has", since infinite do loops do not have integer counters.

I understand that the Fortran-lang tutorial is short and selective in what it covers. However, reading the Derived types section, I think there is a jump in level starting with "Derived types in detail", which covers features from Fortran 2003+ (bind, extends, abstract) that I consider advanced. I would first discuss basic usage of derived types that existed in Fortran 95, such as
(1) printing a derived type
(2) using derived types as procedure arguments and function results
(3) using arrays of derived types. In particular, the simple way that you can refer to the components of an array of derived types is a strength of Fortran. For example, given

type, public :: date_mdy 
   integer :: month, day, year
end type date_mdy
type(date_mdy) :: dates(100)

you can refer to all the months, days, and years with dates%month, dates%day, dates%year.

After this basic usage of derived types one could discuss operator overloading. Given a date derived type it is natural to define operators such as == and >. Examples could be given of how to do this.

If desired, I could write a section with a module defining a date derived type and a program using it.

Looking at

I think there are still many multi-word tags that need to be hyphenated. I assume hash-table, linked-list, and dynamic-array are multi-word tags.

I read the page on the style guide and found this curious text:

Indentation

Use a consistent indentation to make your code readable. The amount of indentation is a matter of preference, the most common choices are two, three or four spaces.

Comparison to Other Languages

On the other hand, in most of the rest of the programming world, ...

The first sentence of "Comparison to Other Languages" feels to me as if it refers to preceding text that has disappeared. What is the first hand? Whatever it is, the short text on the indentation is not related to it. This requires some editing.

I suggest that we have to have and maintain our own benchmarks and have a dedicated section for it.

As an example, the Julia page has benchmarks against Fortran, but unfortunately they do not enable all optimization flags in gfortran, and when I pointed that to them, they said that they do not want to do that because they have different priorities in what they want to benchmark: JuliaLang/julia#24568, which is fine, they have the right to do that. But it is then misleading to users when they think that Fortran is not that fast.

To fix that, we have to maintain our own benchmarks, and test them with several Fortran compilers, and ensure that all optimization options are enabled. And we should benchmark against other languages.

This will also provide motivation for Fortran compiler vendors to speed up some of these benchmarks if Fortran is not the fastest.

Here are some ideas for benchmarks to include:

• https://julialang.org/benchmarks/
• https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/fortran.html
• https://github.com/ParRes/Kernels
  ...

Originally from proposed by @certik here.

Document on fortran-lang.org how to get started on each platform using Conda in 5 minutes. Conda is nice because it does not require root access and installs locally, in a non-invasive manner. And the usage from the user perspective is almost identical on all platforms.

Looking for example at quantum-chemistry packages, I don't see how they are sorted. If the ordering is by stars, that should be mentioned somewhere.

Fortran's one-line-if is convenient and concise, and I think it should be used when possible in the tutorial.

At https://fortran-lang.org/learn/quickstart/operators_control_flow , after showing

  if (angle < 90.0) then
    print *, 'Angle is acute'
  end if

I think it should be added that the following is equivalent:

if (angle < 90.0) print *, 'Angle is acute'

Then the one-line-if should be used in later examples:

  integer :: i
  do i=1, 100
    if (i > 10) then
      exit ! Stop printing numbers
    end if
    print *, i
  end do

  integer :: i
  do i=1,10
    if (mod(i,2) == 0) then
       cycle  ! Don't print even numbers
    end if
    print *, i
  end do

  integer :: i,j
  outer_loop: do i=1,10
    inner_loop: do j=1,10
      if ((j+i) > 10) then  ! Print only pairs of i and j that add up to 10
         cycle outer_loop  ! Go to the next iteration of the outer loop
      end if
      print *, 'I=', i, ' J=', j, ' Sum=', j+i
    end do inner_loop
  end do outer_loop

What should the learning page and tutorial look like?

What should they cover?

How should they be organized?

Let's discuss.

Follow up from fortran-lang/fortran-lang.org#5 .

The chapter about File Input/Output needs some work.

1. clearer recommendation on best practice
2. better explanation of the modifiers used with open, close, ...
3. separate discussion of inquire

We discussed website tutorials on our June 19 call and we tentatively agreed to organize the mini-books that teach the language itself around topics, rather than skill level. Each mini-book would then cover the topic with increasing skill level, starting from the most basic concepts and building toward more advanced.

This is specific to the mini-books that teach the language itself. We'd still have other mini-books that cover other topics like building programs, best practices, Rosetta code and similar.

On the call a few people suggested that we discuss what should be the topics to cover. I think we should aim to define topics that are mostly complementary, have little overlap between each other (but it's impossible to completely avoid overlap). Here are the topics that I think would work well:

• Built-in types and operators
• Control flow
• Procedures
• Modules
• Arrays
• Strings
• Derived types
• I/O
• OOP
• Parallel programming
• C-interop

As an example of building skill level within a topic, mini-book on parallel programming would cover all parallel concepts, from basic to advanced: Images, synchronization, coarrays, collectives, teams, events, and perhaps even some example parallel algorithms.

In this approach, a user of any skill level who wants to learn or refresh memory on any aspect of the language, knows where to look for it because the mini-books are organized by topic. Once in the mini-book, they can skip forward to more advanced aspects of a topic if needed.

How this all evolves exactly in practice, I don't know. Perhaps @LKedward will have some ideas. Perhaps we just expand the sections in the existing Quickstart until they become complete enough to warrant transitioning them into a dedicated mini-book.

What do you think?

Some of the compiler descriptions read like advertising copy, because they were taken from advertising. For example,

"Absoft
Our compilers build faster code more efficiently than ever before."

The "our" should be reworded since the fortran-lang site is not owned by a vendor.

The Lahey description has two exclamation points that don't below in a vendor-neutral site.

"The Cray Compiling Environment (CCE) is the cornerstone innovation of Cray’s adaptive computing paradigm." This is MBA-speak that conveys nothing to me.

In general, vendors will try to summarize the special features of their compilers in a few sentences, and such descriptions can be informative, but I think fortran-lang should tone them down a little.

I am to this day struggling how to deal with strings in modern Fortran. I would be happy to contribute a tutorial, once I learn what the best practice is.

Function accepting a string

integer function f(s)
character(*), intent(in) :: s
f = len(s)
end function

Note: the first argument in character(...) is len, so the above is equivalent to character(len=*). I think it is ok to not specify len, as things are shorter then.

Subroutine returning a string

subroutine f(s)
character(:), allocatable, intent(out) :: s
s = "Some text"
end subroutine

Note: This automatically allocate the LHS, so s will get allocated to the length of the string, no white space padding.

Question 1

In fpm, the following code:

subroutine cmd_build()
type(string_t), allocatable :: files(:)
character(:), allocatable :: basename, pkg_name, linking
integer :: i, n    
print *, "# Building project"
call list_files("src", files)
linking = ""
do i = 1, size(files)
    if (str_ends_with(files(i)%s, ".f90")) then
        n = len(files(i)%s)
        basename = files(i)%s(1:n-4)
        call run("gfortran -c src/" // basename // ".f90 -o " // basename // ".o")    
        linking = linking // " " // basename // ".o"
    end if    
end do
call run("gfortran -c app/main.f90 -o main.o")
call package_name(pkg_name)
call run("gfortran main.o " // linking // " -o " // pkg_name)
end subroutine

Gives a warning:

# gfortran (for build/gfortran_debug/fpm/fpm.o build/gfortran_debug/fpm/fpm.mod)
src/fpm.f90:163:0:

 linking = ""
 
Warning: ‘.linking’ may be used uninitialized in this function [-Wmaybe-uninitialized]

What am I doing wrong? How do I initialize an empty string?

Question 2

How do you return a string from a function as a return value?

I will probably have more questions. These are the most pressing.

So far we've only posted newsletters. However, it'd be of great value to establish a process for members of the community to publish Fortran-related blog posts. This would be good case for people who don't have their own blog, or people who want a wider audience than their own blog, or for any article that is especially relevant for readers of fortran-lang.org.

Ondrej and I discussed this via email some time ago, and came up with a first stab of criteria and process. Here they are:

Criteria:

1. Relevant: The article should be about Fortran, or at least interesting to Fortran programmers.
2. Original: The article should not have been published elsewhere, but adaptation from GitHub, Discourse, or Twitter threads is fine.
3. High quality: The article provides meaningful and useful information, does not advertise a product or service, and is generally aligned with the Fortran-lang community.

Point 3 is especially subjective and difficult to quantify, so review will be important.

Process:

1. The Author opens an issue to propose an article, with a tentative title and short description.
2. If there are thumbs ups / go aheads at step 1, open a PR with the article, and request 3 reviewers.
3. Reviewers review and approve the article. Once published, it's distributed on usual channels (Discourse, mailing list, Twitter)

We'll discuss this on the call this week.

It would be nice to have a chart with a list of platforms (operating system and hardware) and which compilers run in them. Some common platforms are
(1) Windows x86
(2) Windows Subsystem for Linux
(3) Linux x86
(4) Apple on Intel
(5) Apple Silicon

and others could list more.

For (1) I know from personal experience that gfortran, Intel, and g95, Lahey/Fujitsu Fortran 95, and Salford work, and there are other compilers. For (2) I have used gfortran and flang/clang 7.0.1. (This flang is not mature. I've read that there is a distinct "classic flang".)

In another issue the question of providing objective information about compilers was discussed. At least the existence of compilers for platforms can be summarized objectively.

In both fortran-lang/fortran-lang.org#99 and fortran-lang/fortran-lang.org#96 the code style is mentioned. Should we use the same code style as for stdlib?

I think there is a general interest in having a good Fortran specific introduction to commonly used build systems. The target audience has already intermediate or advance knowledge of Fortran, but maybe little to no knowledge of the respective build tools.

I listed the ones I know about for quick reference:

• fpm (discussion: fortran-lang/fpm#302)
• make (introduction: fortran-lang/fortran-lang.org#156, dependencies: fortran-lang/fortran-lang.org#160)
• CMake
• meson
• autotools
• scons
• waf
• FoBiS
• foray

Let me know if there should be something added to this list.

The criteria to recommend a build system could be:

• accessibility (available platforms, setup prerequisites, open source)
• user friendliness (learning curve, documentation in general, Fortran support)
• functionality (dependencies, cross compiling, speed)
• adaption in the community

Looking at the images at the bottom of a course "High Performance Computing in the Physical Sciences" page https://home.chpc.utah.edu/~thorne/computing.html suggests to me that such images and movies could be a nice addition to the main fortran-lang page. Maybe Milan Curcic can provide an image or movie from a weather simulation?

The chapter Element-wise Operations needs some work.

1. more explanation between code examples
2. better examples for usage of elemental
3. drawbacks of elemental procedures

The chapter Multidimensional Arrays should explain performance implications by the choice of indexing.

I suggest that a chapter on error handling be added. In a Fortran Discourse thread a few approaches were listed and evaluated.

We should add a new category:

• Codes that contain some Fortran code, but Fortran is not the primary development language (either has never been, or is not anymore) as judged from the latest commits in the last few years. It does not matter in terms of lines if the Fortran code is a majority or minority.

What this category will show is what projects depend on Fortran, even if only as "clients". All those projects will benefit from any improvement we will do for the Fortran ecosystem, even if indirectly.

Here I found libraries that fit exactly into this category:

• https://github.com/scipy/scipy
• https://github.com/xianyi/OpenBLAS

And I think many of these fit there also (they all have Fortran code inside, but I suspect Fortran is not the primary development language):

• https://github.com/keflavich/plfit
• https://github.com/kthyng/tracpy
• https://github.com/dfm/python-fsps
• https://github.com/sonofeft/RocketCEA
• https://github.com/pvthinker/Fluid2d
• https://github.com/stfc/PSyclone
• https://github.com/mancellin/capytaine

I am sure there are many more such projects.

At https://fortran-lang.org/learn/os_setup/install_gfortran , I think it's fine to keep equation.com as the 1st method to install gfortran on Windows, since it is simple and fast to install. I suggest adding MSYS2 as method fortran-lang/fortran-lang.org#4. I just tried it on Windows 10, and it works fine after following the instructions. Once installed, gfortran --version says GNU Fortran (Rev9, Built by MSYS2 project) 10.2.0 . It takes longer to install than the equation.com compiler binary but comes with more stuff, such as python. A list of MSYS2 packages is here.

In (fortran-lang/fortran-lang.org#313) I made suggestions about grammar and spelling and later made a pull request, which was accepted. I also made suggestions about content, which I will repeat here, since that issue was closed:

For naming conventions, I suggest that short, especially one-letter variable names for integers and reals follow Fortran's implicit typing rules, although one should use implicit none. A variable i should be an integer and x should be a real, for example.

A naming convention I would suggest is to use consistent names for integer variables in a do loop. For example, to loop over days of data,

do iday=1,ndays
   ...
end do

Also, it is common for an integer variable starting with n to denote a loop bound or array dimension and for a variable starting with i to be a loop variable. So one would not write

do nday=1,idays
   ...
end do

At https://fortran-lang.org/learn/best_practices/modules_programs use, only is done for imports, which I agree with, but it should be explained that this reduces name clashes and helps the reader understand where imported entities are coming from.

The code examples use argument intent, but is there a place where that is explicitly suggested and justified?

Why use Roman numerals instead of the usual Arabic digits in https://fortran-lang.org/learn/best_practices/type_casting ?

A naming convention I suggest is that local variables that shadow optional variables have similar names, possibly appending "_". For example,

subroutine sub(a,b)
real, intent(in) :: a
real, intent(in), optional :: b
real :: b_
if (present(b)) then
   b_ = b
else
   b_ = default_value
end if
! remaining code uses b_, not b
end subroutine sub

It may not hurt to state the obvious -- a "best practice" is to use free source form. Free source form code should use the .f90 suffix, not .f95 or .f03 etc., because .f90 stands for free source form, not for compliance to the Fortran 90 standard. I believe @certik supports .f for free source form, but since 99% of .f Fortran code uses fixed source form, I think that causes confusion.

Currently all the packages in https://fortran-lang.org/packages/ have OSI approved open source licenses. See also https://github.com/fortran-lang/fortran-lang.org/blob/master/PACKAGES.md#package-criteria which has the same criterion (OSI approved license).

We should add a new section "other", or "commercial" or "not open source" that would list packages that have non OSI approved license. Some examples:

• MUMPS (#259)
• VASP
• the NAG Fortran Library
• Numerical Recipes (in Fortran)
• perhaps packages like ANSYS, NASTRAN, ...
• Original Matlab: https://fortran-lang.discourse.group/t/compiling-the-original-matlab/1074
• ...

I believe there are quite a few codes out there where you have to request permission to access, but are written in Fortran. We can list all those.

As I mentioned on Fortran Discourse, Microsoft has recently upgraded WSL 2 so that you can run Linux GUI programs, including text editors. Currently fortran-lang says "All of the above approaches provide access to common shells such as bash and development tools including GNU coreutils, Make, CMake, autotools, git, grep, sed, awk, ssh, etc."

In the description of WSL I suggest adding the text "With Windows Subsystem for Linux GUI one can run text editors and other graphical programs."

I could submit a PR but my last trivial one is still pending ...