Skip to content

GSoC 2022 Project ideas

Jump to bottom Edit New page
Milan Curcic edited this page Mar 11, 2022 · 33 revisions

Introduction

Welcome to the Fortran-Lang ideas page for contributors applying for Google Summer of Code (GSoC). If you are interested in applying for GSoC, see the Contributor Instructions for more information on how to apply.

The list here is based on priorities identified by Fortran-Lang contributors and should inform you about the state and direction of each project. If you are interested in an idea on this page, please contact us on our Discourse to ask any questions and get the latest information about the project idea. Please read the existing discussion(s) in any linked issues.

The project ideas on this page are grouped by the repository. Please familiarize yourself with each repository before exploring the ideas here.

We are not limited to the project ideas listed on this page. If you have your own project idea that is not listed here, let us know.

Contacts for prospective mentors: Mentors list

Fortran Package Manager (fpm)

Version constraint resolution

The current decentralized package system in fpm allows dependencies to be fetched via a git repository URL. As part of this, a git tag or commit can be given to require a specific version of a dependency. There is however no way of specifying version compatibility requirements (e.g. >= 1.0.0, <2.0.0) and no way to resolve such requirements across a dependency tree.

This project will involve:

  • Defining a manifest syntax for version compatibility matching
  • Implementing support in fpm for solving a set of version compatibility constraints

A possible approach would be to interface with an existing satisfiability solver such as:

  • libsolv: interface via iso_c_binding as a separate fpm package

See also: existing options for version matching syntax:

Expected outcomes: Implemented a working version constraint mechanism in fpm

Skills preferred: Fortran programming, experience with one or more build systems

Difficulty: intermediate, 350 hours

Mentors: Brad Richardson (@everythingfunctional), Sebastian Ehlert (@awvwgk)

Local package repository

Fpm currently supports decentralized package dependencies whereby dependencies are specified without a central registry. A long-term goal for Fortran-Lang is to host a community-supported registry of fpm packages and for fpm to support interfacing with this and other registries to simplify dependency management.

This project idea aims to accomplish a major step towards a central package registry by implementing support in fpm for a locally hosted package registry. In particular, this project will entail:

  • Defining the manifest syntax to use dependencies from a registry
  • Implementing support for looking up and loading a (local) registry
  • Allowing fpm to manage a local registry by fetching it from a remote registry

Related issues:

  • fpm#321: Implement support for a local registry
  • fpm#35: Full package registry

See also:

Expected outcomes: Implemented a repository of fpm packages as a service

Skills preferred: Fortran programming, experience using fpm and one or more package managers

Difficulty: intermediate, 350 hours

Mentors: Laurence Kedward (@lkedward), Brad Richardson (@everythingfunctional), Milan Curcic (@milancurcic)

fpm-ize the Fortran ecosystem

Research the Fortran library and application ecosystem (on GitHub and beyond) and collaborate with package maintainers on making their package fpm-compatible. In this project, the contributor and mentor would research and identify a limited number of Fortran packages that would be feasible to make compatible with fpm, and that would have a relatively high impact. This project will focus on social aspects of open source and allow the contributor to build their skills around interacting with other open-source projects and communities.

Expected outcomes: Few or more large Fortran packages have been brought to the fpm ecosystem

Skills preferred: Fortran programming

Difficulty: easy, 175 hours

Mentors: Milan Curcic (@milancurcic)

Preprocessor support

Adding support for both built-in compiler preprocessors and external third-party preprocessors is important for fpm due to the additional flexibility they provide when building complex packages. In particular, the Fortran-lang stdlib project exploits the powerful fypp preprocessor for code generation and we intend for stdlib to eventually be compatible as an fpm package.

This project will require:

  • Implementing a manifest syntax for defining preprocessor variables in a preprocessor-independent manner
  • Passing defined preprocessor variables to built-in preprocessors if necessary
  • Defining a manifest syntax for specifying a third-party preprocessor and the corresponding file suffixes
  • Modifying fpm to optionally invoke a third-party preprocessor before compiling sources

Third-party preprocessors should be specified on a per-project basis, i.e. multiple preprocessors might be required, and fpm should be able to report useful errors for missing third-party preprocessors.

Related issues:

  • fpm#78: support for third-party preprocessors (e.g. fypp)
  • fpm#308: Fortran-based smart code generation in fpm

Expected outcomes: fpm has a working preprocessing capability

Skills preferred: Fortran, C, or Python programming, experience using one or more preprocessors

Difficulty: easy, 175 hours

Mentors: Laurence Kedward (@lkedward), Milan Curcic (@milancurcic), Jeremie Vandenplas (@jvdp1)

Extended Testing Support

The aim of this project is to create a manifest specification to provide defaults to executable targets in fpm projects. Information can be passed as environment variables, command-line arguments or as a runner. Desired features include:

  • Programs should have a way to find resources of which the relative position within the project source directory is known.
  • The current binary directory to access other targets within a project.
  • Default runners like mpirun/cafrun or scripts from test frameworks should be usable to launch programs.
  • A general syntax to define environment variables and command-line arguments should be defined.

Some features should be implemented directly in fpm, while more elaborated functionality could be implemented in a separate fpm package as an official Fortran-lang fpm package.

Related issues:

Related discussions:

  • fpm#328: Example which requires external data

Expected outcomes: fpm has broader and deeper testing functionality

Skills preferred: Fortran programming and writing unit tests

Difficulty: easy, 175 hours

Mentors: Sebastian Ehlert (@awvwgk), Brad Richardson (@everythingfunctional)

Source Code Distribution with Foreign Build Systems

The aim of this project is to enable fpm to create source code distributions of itself that can be bootstrapped without fpm. Desired features include:

  • Allow fpm to generate source code distributions with non-fpm build systems.
  • Generated source code distribution should allow to build fpm project without fpm, git or internet access.
  • Potential third-party build systems are CMake and Meson.
  • Allow easier distribution and packaging of fpm via various packaging ecosystems.

Related issues:

  • fpm#69: Have CMake and Make backends
  • fpm#70: Have a Conda backend

Expected outcomes: fpm can generate source code distributions of packages that can be build using CMake and/or Meson.

Skills preferred: Fortran programming, experience using one or more build systems

Difficulty: intermediate, 175 hours

Mentors: Sebastian Ehlert (@awvwgk), Laurence Kedward (@lkedward)

Standard Conformance Suite

Fortran compilers' support for ISO Fortran standards generally lag the publication of the standard by several years or longer. Fortran consultants Ian Chivers and Jane Sleightholme periodically publish a paper containing a table detailing the standard features supported by 10 compilers. Gathering the tabulated data requires a considerable amount of effort on the part of the authors and the compiler developers. The chosen venue for publishing the table also puts it behind a paywall: access requires a subscription to ACM SIGPLAN Fortran Forum. The project will automate the generation of the table, make it more detailed and empower the community to contribute to by submitting small tests to an open-source conformance test suite.

Prior work:

Expected outcomes: A comprehensive test suite that generates a report of standard conformance for any Fortran compiler. The suite is not expected to be 100% complete by the end of the project, but should be significant in terms of standard coverage.

Skills preferred: Fortran programming, experience reading and interpreting the Fortran Standard, and writing tests

Difficulty: advanced, 350 hours

Mentors: Damian Rouson (@rouson), Arjen Markus (@arjenmarkus), Ondřej Čertík (@certik)

Support for C++

Enabling fpm to compile C++ projects would make a whole number of projects available in the Fortran ecosystems, most importantly the LFortran compiler and its AST parser. This requires fpm to handle C++ headers and modules (source scanner) and being able to link Fortran and C++ correctly into executables.

Expected outcomes: fpm integrates with a C++ compiler and successfully builds a C++ package.

Skills preferred: Fortran and C++ programming

Difficulty: easy, 175 hours

Mentors: Sebastian Ehlert (@awvwgk), Ivan Pribec (@ivan-pi)

Tree shaking

Building a large dependency (such as stdlib, for example) is both slow and increases the size of the produced object and executable binaries. "Tree shaking" is an optimization technique commonly used in the JavaScript ecosystem. It allows a build system to exclude unused modules and procedures from dependencies. For example, if a small fpm project uses only optval() from stdlib_optval, fpm should only need to build stdlib_optval and stdlib_kinds (dependency of stdlib_optval). While initially perhaps negligible, this problem will become more apparent as the fpm ecosystem grows and more large packages become fpm-compatible.

Expected outcomes: fpm successfully builds subsections of package dependencies.

Skills preferred: Fortran programming

Difficulty: intermediate, 350 hours

Mentors: Laurence Kedward (@lkedward), Sebastian Ehlert (@awvwgk)

Parallel builds

Currently, fpm builds Fortran packages serially: one file at a time. Because fpm is written in Fortran, however, independent branches of the file dependency tree could be built parallel using Fortran's native parallel programming features, which are usually referred to as Coarray Fortran. The International Fortran Conference 2021 keynote address presented a mock demonstration how the use of the Framework for Extensible Asynchronous Task Scheduling (FEATS) could be applied to parallelize the fpm build process based on traversing a dependency tree encapsulated in a Directed Acyclic Graph (DAG) bobject.

Expected outcomes: fpm successfully executes packages build processes in parallel

Skills preferred: Fortran programming and parallel programming

Difficulty: advanced, 350 hours

Mentors: Damian Rouson @rouson Brad Richardson @everythingfunctional

Fortran Standard Library (stdlib)

OS integration: File system

Currently, file system operations such as listing contents of directories, traversing directories, and similar, are restricted to 3rd party libraries and compiler extensions that are platform-specific and not portable. This project will entail designing and implementing a cross-platform solution for file system operations.

Related issues:

  • stdlib#201: File system operations
  • stdlib#220: API for file system operations, directory manipulation

WIP implementation:

Expected outcomes: Implemented an stdlib module that provides cross-platform file-system utilities

Skills preferred: Fortran and C programming, experience using Linux, macOS, and Windows

Difficulty: intermediate, 350 hours

Mentors: Arjen Markus (@arjenmarkus), Milan Curcic (@milancurcic)

OS integration: Subprocesses

Cross-platform solution to abstract POSIX and Windows API for creating subprocesses.

Related issues:

Discourse thread:

Difficulty: intermediate, 350 hours

Mentors: Sebastian Ehlert (@awvwgk)

Sparse matrices

Implementing a standardized API for procedures to handle (COO and CSR) sparse matrices. Both non-OO low-level API and OO API should be implemented.

Related issue:

WIP implementation:

Expected outcomes: Implemented sparse matrix functionality in the stdlib_linalg module

Skills preferred: Fortran programming, understanding of linear algebra

Difficulty: advanced, 350 hours

Mentors: Ondřej Čertík (@certik), Ivan Pribec (@ivan-pi), Jeremie Vandenplas (@jvdp1)

LFortran (lfortran)

Compile stdlib, fpm, and other Fortran-lang projects

In this project, the student would work on implementing LFortran features toward successfully compiling stdlib, fpm, and other Fortran-lang projects.

The project can be any one of the following,

  1. Compile with --symtab-only mode (Recommended for 18 hours/week sized projects)
  2. Compile with normal lfortran i.e., without using any extra flags - stdlib already compiles with --symtab-only mode (though stdlib/tests don't work as of now but other than that everything works). For compiling without any flags, the work is in progress. This gist contains instructions to find out the current state. You can do something similar for fpm and other Fortran-lang projects. Note that, it would be good to use a specific commit of stdlib, fpm through out the project, instead of always using the master/main branches. (Recommended for 36 hours/week sized projects. For stdlib we will consider 18 hours/week sized projects because, --symtab-only mode is already working to a great extent).
  3. Adding support to LLVM backend for stdlib - This cannot be done without significantly making progress on second idea (i.e., the above point). So, it is recommended for 36 hours/week sized projects.

Expected outcomes: LFortran can build stdlib and fpm.

Skills preferred: Fortran and C++ programming

Difficulty: intermediate, 350 hours

Mentors - Gagandeep Singh (Gitlab - @czgdp18071)

Allow running Fortran in the browser

This project would entail working with LFortran, LLVM, Emscripten, and Webassembly to allow running Fortran in the browser.

  • use LLVM and Emscripten to compile Fortran code to Webassembly
  • create custom Webassembly backend for LFortran and compile LFortran itself to Webassembly

Relevant issues:

Expected outcomes: LFortran can compile Fortran code, as well as bootstrap itself, to Weabassembly.

Skills preferred: Fortran and C++ programming

Difficulty: intermediate, 350 hours

Mentors - Ondřej Čertík

Compiling SciPy with LFortran

Compile all Fortran files in SciPy with LFortran. This project involves making improvements to the fixed form parser in LFortran if needed and then mainly implementing the rest of the semantics that is needed to compile the Fortran files with LFortran.

Being able to compile SciPy with LFortran would make a huge impact on both LFortran and SciPy.

Expected outcomes: LFortran can compile all Fortran code in SciPy.

Skills preferred: Fortran and C++ programming

Difficulty: intermediate, 350 hours

Mentors - Ondřej Čertík

Parser + ASR (for F2PY)

Enhance the frontend parser to allow for more generic extensions and keywords. In particular, parsing the pyf or signature file format consumed by F2PY. This would mean that SciPy can be directly transformed to the ASR representation without a fixed form parser.

This also involves adding nodes to the ASR itself.

Difficulty: intermediate, 350 hours

Expected outcomes: LFortran's ASR is improved such that it can parse the pyf format consumed by F2PY.

Skills preferred: Fortran and C++ programming

Mentors: Rohit Goswami (@HaoZeke)

Language Server

This project would be used to first serialize the ASR and then use it within a language server.

Expected outcomes: LFortran can be used as a Fortran language server that can be used in other software such as source code editors and IDEs.

Skills preferred: Fortran and C++ programming

Difficulty: intermediate, 350 hours

Mentors: Ondřej Čertík (@certik)

Other

Coarray Fortran Framework of Efficient Interfaces to Network Environments (Caffeine)

This project would add support for grouping images (parallel processes) into teams that allow submodes to execute independently. Caffeine 0.1.0 uses the GASNet-EX networking middleware software as a back end for supporting most of the non-coarray parallel features of Fortran 2018 except for the intrinsic derived team_type and related features. Work is underway to support the coarray features that most applications will need for expressing custom parallel algorithms. The teams feature set is the one significant non-coarray parallel group of features not yet implemented in Caffeine.

Expected outcomes: Caffeine can be used to create images groups in execution parallel programs

Skills preferred: Fortran and C programming

Difficulty: intermediate, 175 hours

Mentors: Damian Rouson (@rouson)

Port fortran-lang.org to Sphinx

This project would involve porting the Fortran-lang website from the current framework (Jekyll) to Sphinx+Myst parser for internationalization support and ease of maintenance.

Expected outcomes: fortran-lang.org website and its content is completely ported to Sphinx and provides internationalization support.

Skills preferred: Experience using Sphinx or other docs generators, CSS

Difficulty: intermediate, 350 hours

Mentors: Sebastian Ehlert (@awvwgk)

Build or embed online playground for fortran-lang.org

An online (in-browser) Fortran playground on the landing page of fortran-lang.org would allow visitors to try out Fortran immediately, without having to install the compiler locally. There are different possible approaches:

  • Send source code to a server that compiles and runs the code and returns the output
  • Compile and run a subset of Fortran in the browser via Webassembly and Emscripten
  • Embed a reduced version of an LFortran Jupyter notebook
  • Embed an existing playground like Repl.it or Compiler Explorer

Expected outcomes: fortran-lang.org landing page has a working interactive playground.

Skills preferred: HTML, CSS, JavaScript

Difficulty: intermediate, 175 hours

Mentors: Milan Curcic (@milancurcic)

Get fortran-lang/minpack to be used in SciPy

fortran-lang/minpack #14

The participant would work with Fortran-lang and SciPy teams toward implementing fortran-lang/minpack in SciPy.

Expected outcomes: fortran-lang/minpack is incorporated into SciPy.

Skills preferred: Fortran-C interop, Python

Difficulty: easy, 175 hours

Mentors: Sebastian Ehlert (@awvwgk)

Add a custom footer
Add a custom sidebar
Clone this wiki locally