Gridap.jl: finite element PDEs in Julia, written the way the maths reads

The problem: finite elements in a language where the maths is the point

Finite element discretisation is a well understood but laborious business. You choose a space, you choose a mesh, you write the weak form, you assemble, you solve, you post-process, and most of the code is bookkeeping about degrees of freedom, basis functions and cell iteration.

The languages with the best finite element tooling are often the ones where the bookkeeping is hidden behind a large framework, which is convenient until you need something the framework did not anticipate. Gridap takes the opposite position. It is a Julia package that provides a set of tools for the grid-based approximation of partial differential equations, and its claim is that the user can write the underlying weak form with a syntax almost one to one with the mathematical notation, and that Gridap generates an efficient finite element assembly loop automatically by leveraging the Julia JIT compiler.

The audience is researchers and engineers who write PDEs for a living and who care that the code in the repository matches the paper. The repository topics say the same thing: finite elements, gridap, julia, numerical methods and partial differential equations.

The licence is MIT, with a LICENSE.md at the root, the last push was on 2026-10-20, and the recent releases are v0.20.10 from 2026-09-21, v0.20.9 from 2026-08-17 and v0.20.8 from 2026-05-31. There is also a Journal of Open Source Software paper, with a DOI badge in the project description.

The scope: what discretisations and meshes it covers

The description of the library's scope is precise, and it is worth reading in full because it tells you what a project can assume.

Gridap currently supports linear and nonlinear PDE systems for scalar and vector fields, single and multi-field problems, conforming and nonconforming finite element discretizations, on structured and unstructured meshes of simplices and n-cubes. It also provides methods for time integration.

That list covers the decisions a solver author normally has to make explicitly, and it is broader than the usual Julia offering. The conforming and nonconforming distinction is the significant one, because discontinuous Galerkin methods are a different discretisation with different assembly and different boundary conditions, and a library that handles both without a second interface saves a lot of work.

The claim of extensibility is the other half. Gridap is extensible and modular: one can implement new finite element spaces, new reference elements, use external mesh generators, linear solvers and post-processing tools. That is what the plugin list is for, and it is the reason the library can stay small while covering a wide range of problems.

The examples in the project description show the range in practice, since each one is a solved PDE with a visualisation: the Poisson equation, linear elasticity, hyper-elasticity, the p-Laplacian, the Poisson equation with a discontinuous Galerkin discretisation, the Darcy equation with a Raviart-Thomas space, incompressible Navier-Stokes and isotropic damage.

The mechanism: a weak form that reads like the equation

Here is the interior penalty discontinuous Galerkin weak form for the Poisson equation as it is written in Gridap:

a(u,v) =
  ∫( ∇(v)⋅∇(u) )*dΩ +
  ∫( (γ/h)*v*u - v*(n_Γ⋅∇(u)) - (n_Γ⋅∇(v))*u )*dΓ +
  ∫(
    (γ/h)*jump(v*n_Λ)⋅jump(u*n_Λ) -
    jump(v*n_Λ)⋅mean(∇(u)) -
    mean(∇(v))⋅jump(u*n_Λ)
    )*dΛ

l(v) =
  ∫( v*f )*dΩ +
  ∫( (γ/h)*v*u - (n_Γ⋅∇(v))*u )*dΓ

The domain integral is written as ∫ and the boundary integral as ∫ over the boundary, the jumps and the mean appear as functions in the formula, and the penalty parameter γ and the cell size h are just symbols. Nothing in that code refers to a basis function, a degree of freedom or a cell index.

The multi-field case works the same way. For the Stokes equation with Neumann boundary conditions, the trial and test functions are pairs:

a((u,p),(v,q)) =
  ∫( ∇(v)⊙∇(u) - (∇⋅v)*p + q*(∇⋅u) )*dΩ

l((v,q)) =
  ∫( v⋅f + q*g )*dΩ +
  ∫( v⋅(n_Γ⋅∇u) - (n_Γ⋅v)*p )*dΓ

The dispatch on the pair type is what makes the mixed formulation work, and the boundary terms for the pressure are written in the same notation as the volume terms. The project links the complete code for both examples in its test suite, which is a useful signal: the examples are not illustrative snippets, they are tests.

The assembly loop underneath is generated from that expression by the Julia JIT compiler, which is the mechanism behind the claim of an efficient loop without a user written one.

Installing and the first call, which is where the time goes

Installation is ordinary Julia package management, because Gridap is a registered package in the official Julia package registry. You open the Julia REPL, type `]` to enter package mode, and then:

pkg> add Gridap

There is nothing to compile by hand and no system dependency to install, and that is the whole installation.

The caveat is the first call. The known issues section of the documentation records that since Julia 1.6 onwards large first call latencies of Gridap.jl have been noticed. The entry is truncated in the published description, so the details are not available there, but the shape of the problem is well known in the Julia ecosystem: the package specialises its methods on the types of the expressions it evaluates, and the first evaluation of a new combination of types has to be compiled.

That has two practical consequences. A script that solves a PDE will spend its first seconds compiling rather than solving, which is invisible in a long batch run and very visible in an interactive session. And a notebook or a REPL session that keeps a compiled method alive will be more responsive on the second problem than the first.

For a team evaluating the library, this is the single fact to test first. Write the Poisson example, time it, and time it again in the same session, before deciding anything about the API.

For learning, the project documentation points at a hands-on user guide available as a set of tutorials in a separate repository, provided as Jupyter notebooks and as HTML pages, and at two documentation builds, one for the most recently tagged version and one for the in-development version.

The plugin ecosystem, which is where the real coverage lives

The list of plugins is long and it is the best available description of what the library can actually be used for.

GridapDistributed is the distributed-memory extension, and GridapSolvers provides scalable multiphysics finite element solvers. GridapEmbedded brings embedded finite elements to Julia, and GridapP4est adds adaptive mesh refinement and coarsening with forests of trees. GridapTopOpt is a topology optimisation library, and ComodoGridap combines the Comodo.jl library with Gridap for finite element work.

Then there are the bridges to the rest of the ecosystem. GridapGmsh generates a finite element mesh with GMSH and uses it in Gridap. GridapMakie provides Makie plotting recipes, GridapPardiso plugs in the Intel Pardiso MKL direct sparse solver, and GridapPETSc brings PETSc linear and nonlinear solvers.

The pattern is instructive. Gridap itself is the discretisation layer, and anything that is a solver, a mesh generator, a plotting backend or a parallel runtime is a separate package with its own maintainers. That is a healthier arrangement than a monolith with a dozen optional dependencies, and it also means the practical question for a new user is which of these bridges you need.

The two that most often decide feasibility are GridapPETSc and GridapPardiso, because a serious PDE problem usually ends at a large sparse solve, and GridapMakie, because the post-processing step is where a lot of time goes otherwise. The plugin list also has a community page, with a Gitter room and a Slack channel in the Julia workspace.

Licence, maintenance and the limits of the design

The licence is MIT, with the licence text in a LICENSE.md file at the root, and the repository also carries a CODE_OF_CONDUCT.md, a CONTRIBUTING.md, an ADMINISTRATORS file and a NEWS.md, which is the changelog for a library that has been releasing for a long time.

The maintenance picture is healthy. The repository is not archived, the last push was on 2026-10-20, and the 0.20 series has had three releases since May 2026. The project also has a peer-reviewed publication, which is the sort of external validation that a scientific library benefits from, and separate stable and development documentation builds so that a user can read about the version they actually have.

The limits are more interesting. Gridap is a discretisation library with a mathematical API, and that API is a design commitment: the weak form is the program. If your workflow is to build the discretisation once in a general purpose framework and then reuse it across many problems, or if you want to drive the assembly loop directly, this is the wrong level of abstraction. The same goes for a project that is mostly about the linear algebra rather than the model.

There is also the compilation cost, which is a permanent property of the approach rather than a temporary inconvenience. The first call latency is the price of a library whose internal loop is generated from your expression tree, and the documentation records it as a known issue rather than a solved problem.

The judgement is straightforward. If you write PDEs and want the code to look like the mathematics, Gridap is one of the few packages that delivers that, and the plugin list means you can pair it with the solver and the visualiser you already use. Budget for the first call, and pin a version and read the matching stable documentation.

Editorial conclusion

Adopt Gridap.jl if you solve PDEs in Julia, particularly if you want the discretisation to follow the mathematics rather than the structure of a finite element library, and if you are prepared to accept a first-run compilation cost. Do not adopt it if you need a precompiled, immediately responsive environment, since the documentation itself records large first call latencies since Julia 1.6, and do not assume the plugin ecosystem covers your solver of choice without checking. Before you start, read the STABLE documentation for the version you will pin rather than the development docs, and plan for the time penalty of the first call in every session.

Frequently asked questions

Official sources

1. gridap/Gridap.jl on GitHub
2. Issues
3. License: MIT
4. README
5. Releases