Skip to content

Fix PETSc error in mesh.adapt() with extra MeshVariables#67

Merged
lmoresi merged 1 commit intodevelopmentfrom
bugfix/fix-amr-adapt
Mar 3, 2026
Merged

Fix PETSc error in mesh.adapt() with extra MeshVariables#67
lmoresi merged 1 commit intodevelopmentfrom
bugfix/fix-amr-adapt

Conversation

@lmoresi
Copy link
Member

@lmoresi lmoresi commented Mar 3, 2026

Summary

  • Stale field_ids on old variable lvecs caused createSubDM to fail during variable reinitialization after mesh adaptation
  • Fix: destroy all old lvecs upfront before reinitializing any variable, so _setup_ds()'s internal backup/restore loop never encounters stale vectors
  • The metric field is now preserved through adaptation (it's user-created and may have external references), rather than being silently deleted

Test plan

  • Exact reproducer from issue AMR error after Stokes solve. #48 runs without PETSc errors
  • All variables (including metric) survive adaptation with correct field_ids
  • Verbose output confirms all variables reinitialize cleanly

Fixes #48

Underworld development team with AI support from Claude Code

When variables beyond the solver fields (e.g. strain rate, metric) existed
on the mesh, adapt() would trigger "Invalid field number N; not in [0, M)"
errors from PETSc. Two problems:

1. Old variable lvecs were destroyed one-at-a-time inside the reinit loop.
   When variable N's _setup_ds() ran its internal backup/restore loop over
   all mesh._vars, variables N+1, N+2 etc still held lvecs with stale
   field_ids from the pre-adaptation DM, causing createSubDM to fail.

2. The metric field was excluded from reinitialization and deleted after
   adaptation. As a user-created variable with external references, it
   should survive adaptation like any other variable.

Fix: destroy all old lvecs upfront before reinitializing any variable,
include the metric in the reinitialization set, and stop deleting it.

Fixes #48

Underworld development team with AI support from Claude Code
Copilot AI review requested due to automatic review settings March 3, 2026 03:56
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Fixes a PETSc “Invalid field number …” failure during Mesh.adapt() when additional MeshVariables exist (e.g., created after a solve), by ensuring stale vectors/field IDs cannot be used during variable reinitialization on the adapted DM. Also keeps the user-supplied metric variable registered on the mesh across adaptation.

Changes:

  • Preserve all mesh variables (including the metric field) for reinitialization after adaptation, instead of excluding/deleting the metric variable.
  • Destroy all existing variable PETSc vectors up front before any _setup_ds() calls, preventing _setup_ds()’s internal backup/restore from encountering stale field IDs (fix for #48).
Comments suppressed due to low confidence (1)

src/underworld3/discretisation/discretisation_mesh.py:3060

  • Consider adding a regression test that exercises mesh.adapt() when extra MeshVariables exist (e.g., after a Stokes solve) and verifies that adaptation completes without PETSc field-id errors and that all variables (including the metric field) remain registered with updated field_id values. This change fixes a previously reported failure mode (#48), so a targeted test would help prevent future DM/field ordering regressions (similar to existing DM rebuild regression tests).
        # Destroy ALL old vectors upfront before reinitializing any variable.
        # This is critical because _setup_ds() iterates mesh._vars to backup/restore
        # data — if some variables still hold lvecs with stale field_ids from the
        # pre-adaptation DM, createSubDM will fail on the new DM.  (Fixes #48)
        for old_var in old_vars_data.values():

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@lmoresi lmoresi merged commit 714059d into development Mar 3, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants