Skip to content

Firedrake meeting 2026 06 16

Jump to bottom
Pablo Brubeck edited this page Jun 16, 2026 · 24 revisions

Date and time 2026-06-16 1600 UTC+1

Action Items

  1. Pick Chair and Minuter (LC to pick)
  2. ALL: (ongoing) triage the open issues and confirm if they are indeed still open (and perhaps provide labels)
  3. ALL: do things with SV's branches
  4. DH: Email to Andreas to have 2 (+ others!!!) loopy PRs merged TODO: FIND OUT WHICH PRS THESE ARE
  5. DH: Talk to GregVernon about PR#2116.
  6. JHC: New manual release

Agenda

Present:

Apologies: JHC

LC/DH: Need someone to cover on 29th/30th June

We have a summer student starting and we're both away for these days - can CW/JHC meet and help her get set up with Firedrake.

SG: PRs

pyadjoint #248 + firedrake #5168: fixes the SingleMemoryStorageSchedule clearing bugs from #211 and #260 by keeping checkpoints until a reverse pass revises the adjoint dependencies. The red CI isn't from this PR; it's the pre-existing #257 breakage where the is_control guard stops controls being cleared, so the firedrake test helpers need to skip controls (folding into #5168).

Discussion Points from SiaG: Adjoint taping issues, appctx and projection

  • Stale appctx during adjoint replay. When an annotated NLVS carries an appctx, the replay machinery deep-copies the form coefficients but leaves the appctx pointing at the originals, so a preconditioner like MassInvPC sees end-of-run values on replay. Real case is a fieldsplit Stokes Schur complement where the viscosity is orders of magnitude off and the pressure solve diverges. There are two PRs because the code exists in two forms: #5171 fixes the legacy cloning path on release and is the actual bug fix, #5170 reinstates the same fix against Josh's nlvs-hessian-fix (#4638) which retires the methods #5171 patches, and also covers the TLM path. Connor's alternative on #5171 is to teach the linear solver path to accept appctx so the pop and the default_appctx fallback become unnecessary. Want to settle: minimal contained fix into release now versus holding for the linear-solver change, and how #5170 folds into #4638. And generally for Josh/Angus/... to be aware of this issue.

  • Projection annotation. Several distinct faults. Solver parameters passed to project were never recorded on the block, so replay and adjoint silently used the global defaults (#5172, fixed by #5175). Direct Projector(...).project() is not taped at all (#5176). There are two forward paths (same-space assigns, cross-space solves) and three entry points. #5175 is a contained record-the-parameters fix that works but cannot capture slate inverse or constant_jacobian and does nothing for #5176. Question is whether to redesign around a block that holds the Projector (like SupermeshProjectBlock), which reshapes the same blocks/solving.py Josh's #4638 rewrites, so it wants building on top of that refactor.

PB: Change default model for DirichletBC

https://github.com/firedrakeproject/firedrake/issues/5177

The current default (restrict=False, pre_apply_bcs=True) poses the problem on the full space, and the BCs are directly imposed on the initial guess so there's no need to update them. However, the method is flawed:

a. Assumes that SNES updates satisfy homogeneous BCs, but sometimes the PC might couple BCs with the interior (e.g. GAMG does not solve the identity block on the BC rows exactly), and this spoils the BC values, without the possiblity of correcting them.

b. It can silently lead to bad initial guesses with sharp gradients that cause NaN in the first residual. (E.g. for Navier-Stokes on a lid-driven cavity, an initial guess u=0 will not be respected, hence the initial Jacobian is not Stokes.)

The proposal to set pre_apply_bcs=restrict=False as default, which does not suffer from either a and b. If we want to be able to restrict, the other method that we should keep is pre_apply_bcs=restrict=True, which only suffers from b, as b is inherent to restrict=True (we cannot set restrict=True with pre_apply_bcs=False because restrict is unable to update the BC values).

PB: Interpolation into EnrichedElement

We should let Gusto people know, as they have been unable to do interpolation into RTCF elements.

DG: Review changes to ReducedFunctional and discuss integrating TAO solver with EnsembleReducedFunctional

Merge PRs

Date of next meeting

1600 UTC+0100 2026-06-23

Home

Installation

Firedrake governance

Other pages

Clone this wiki locally