Week 11: Backend Abstraction and PR Submission

This week was all about refactoring. Based on continued feedback from my mentor, I reworked how the PETSc backend plugs into the HEOM solver — moving from ad-hoc if/else branching to a proper backend abstraction layer.

Backend Abstraction Layer

The biggest change was introducing HEOMBackend, a base class that defines the interface any computational backend needs to implement. The existing CSR code path is now wrapped in CSRHEOMBackend, and the PETSc path lives in PETScHEOMBackend. Both register themselves into a shared backend registry on HEOMSolver.

The key methods in the interface are:

• get_local_labels() — which ADO labels this MPI rank should handle
• add_op(row_he, col_he, op) — insert a block operator into the RHS matrix
• finalize() — assemble the matrix and wrap it for the solver
• configure_solver() — set up the integrator
• steady_state() — compute the steady state
• prepare_state() / restore_state() — convert between QuTiP objects and backend vectors

This means bofin_solvers.py no longer needs to know anything about PETSc specifically. The RHS construction loop just calls backend.get_local_labels(), backend.add_op(), and backend.finalize(), and the right thing happens regardless of whether you’re on CSR or PETSc.

Integrator Cleanup

I also cleaned up IntegratorPETSc. The main improvement was switching to PETSc’s native computeRHSFunctionLinear and computeRHSJacobianConstant instead of a Python callback for the RHS. This avoids Python overhead during time-stepping entirely — PETSc handles the matrix-vector multiply at the C level.

Test Updates

On the testing side, I added tests for the backend registry mechanism (making sure backends register correctly, invalid names raise errors, etc.) and for edge cases like restore_state when ADO data isn’t available (which happens with store_ados=False on the PETSc backend).

The existing PETSc correctness tests — trajectory matching, fidelity, steady state, trace/hermiticity checks — all still pass after the refactor.

PR Submitted

With the refactoring done, the draft PR is now in a much cleaner state. The separation between solver logic and backend implementation should make it easier to review and maintain going forward.

Next Steps

• Address any further review comments on the PR
• Documentation and cleanup for the final GSoC submission