Repository navigation
feat(solver): update torch-fem to 0.12.1, solve with CG+Jacobi on GPU - #187
Conversation
…on GPU - Bump torch-fem to 0.12.1. - Set BCs via SolidHeat's `temperatures` / `heat_flux`; SolidHeat no longer inherits the Mechanics `displacements` / `forces` setters, so assigning those left the load at zero. Rename the local tensors accordingly. - Drop the `sparse_solve` device monkeypatch; torch-fem now moves all solver inputs to the solve device itself. - On GPU, solve with Jacobi-preconditioned CG in torch so the forward and adjoint solves stay on the device; CPU-only hosts keep torch-fem's automatic solver choice. - Fix LD_LIBRARY_PATH to the image's Python version. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
📊 View the full benchmark resultsThe rendered docs preview has every plot for this run (forward accuracy, gradients, cost, optimization) merged with existing baseline results on Coverage: measured Status diff vs baseLegend · ✅ ok · 🟠 anom · ❌ fail · · missing · 🚫 excluded (permanent — out of score denominator) · ⚪ excluded (work-to-do) · * stale — result predates current benchmark run 0 regression(s) · 0 improvement(s) · 3 metric change(s) · 0 other transition(s) · 0 resource-frontier shift(s) · 0 new row(s) · 0 removed row(s) · score 0.93 → 0.93 📊 Metric changes
⏱ Timing (indicative — shared-runner contention)Wall-clock varies with CI-runner load, so treat these as indicative rather than controlled measurements.
Full Mosaic statusMosaic statusLegend · ✅ ok · 🟠 anom · ❌ fail · · missing · 🚫 excluded (permanent — out of score denominator) · ⚪ excluded (work-to-do) · * stale — result predates current benchmark run Each solver is run against every experiment in the suite. ok = produced valid results; fail = crashed or returned invalid data; anom = ran successfully but tripped an automated quality check (e.g. poor gradient accuracy, outlier wall-clock time, or diverged optimisation). Thresholds are defined per-problem in the problem config.
Failures & anomalies
ns-3d-grid — 16 experiment(s)
ns-grid — 20 experiment(s)
structural-mesh — 10 experiment(s)
thermal-mesh — 14 experiment(s)
|
|
The two 🟠 on torch-fem (forward/baseline, forward/source_baseline) are likely float32 rounding issues: every thermal solver casts thermal_compliance to float32 before returning it. An absolute floor in the outlier check would probably clear these (deal.II's included). |
dionhaefner
left a comment
There was a problem hiding this comment.
Will do (in a separate PR). Thanks @meyer-nils !
Summary
This updates the torch-fem thermal-mesh backend to torch-fem 0.12.1. On GPU, the linear solve now runs as Jacobi-preconditioned CG in torch, so the forward and adjoint solves stay on the device.
Type of change
For new solvers
tesseract_config.yamlhas ametadata.mosaic:block with at leastnameandbackendtesseract build mosaic/tesseracts/<domain>/<solver>succeedsmosaic run -p <domain> --suites forward -s <solver> --debugcompletesmosaic status -p <domain> -foutput pasted belowFor solver tuning
mosaic status --format jsonsnapshots comparedBenchmark label
benchmark:solver
Notes
SolidHeat'stemperatures/heat_flux.SolidHeatno longer inherits the mechanics settersdisplacements/forces, so assigning those left the applied load at zero. The local tensors are renamed to match.sparse_solvemonkeypatch removed: torch-fem now moves all solver inputs to the solve device itself.numericsmetadata is updated toCG+Jacobi.LD_LIBRARY_PATH: now points at the Python version the image actually uses.pytestpasses.mosaic run -p thermal-mesh --suites forward,gradient --debug -s torch-fempasses on GPU, and its results match the previous torch-fem version. The VJP agrees with a finite-difference check on CPU.