🔬 physics

Mosaic: A Benchmark Suite for Differentiable Physics Solvers

Het artikel introduceert Mosaic, een open-source benchmarking-framework dat de evaluatie van differentieerbare PDE-solvers standaardiseert door deze te verpakken als gecontaineriseerde componenten, waarbij significante variaties in computationele kosten, numerieke conditionering en compatibiliteit over 14 solvers worden onthuld, terwijl wordt aangetoond dat alle gradiënt-producerende solvers convergeren naar vergelijkbare optima.

Oorspronkelijke auteurs: Andrin Rehmann, Heiko Zimmermann, Dion Häfner

Gepubliceerd 2026-06-29

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Andrin Rehmann, Heiko Zimmermann, Dion Häfner

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een chef bent die een nieuw recept probeert uit te vinden. Je hebt een keuken vol verschillende ovens (de physics solvers). Sommige zijn hypermoderne slimme ovens, andere zijn ouderwetse gasfornuizen en weer andere zijn luxe convectie-units. Ze bakken allemaal brood, maar ze doen dat op heel verschillende manieren.

Stel je nu voor dat je een robotarm wilt gebruiken om het recept automatisch aan te passen. Om dit te doen, moet de robot precies weten hoe het veranderen van de temperatuur of de hoeveelheid bloem de uiteindelijke smaak verandert. In de wereld van natuurkundige simulaties wordt deze "smaakfeedback" een gradiënt genoemd.

Lange tijd hadden wetenschappers deze ovens wel, maar niemand wist welke oven de robot de meest nauwkeurige feedback zou geven, hoeveel elektriciteit het zou kosten om die feedback te krijgen, of de oven zelfs zou ontploffen als je hem de verkeerde vraag stelde.

Maak kennis met "Mosaic."

Beschouw Mosaic als een universele testkeuken. De onderzoekers hebben een gestandaardiseerde opstelling gebouwd waarin ze 14 verschillende "ovens" (computerprogramma's die natuurkundige vergelijkingen oplossen) naast elkaar kunnen testen. Ze hebben elke oven in een speciale doos geplaatst (een Tesseract), zodat de robotarm exact dezelfde vraag op exact dezelfde manier kan stellen, ongeacht in welke taal de oven is gebouwd (Python, Julia, C++) of hoe deze intern werkt.

Dit is wat zij ontdekten toen ze begonnen met bakken:

1. De "Feedback" varieert enorm

Net zoals sommige ovens 5 minuten nodig hebben om voor te verwarmen en andere 30 minuten, varieert de kosten van het verkrijgen van die "smaakfeedback" (de gradiënt) enorm.

De Snelheidsduivels: Sommige moderne ovens (zoals die gebouwd op JAX of PyTorch) kunnen de feedback bijna direct geven, met bijna geen extra inspanning. Het is alsof je een slimme oven hebt die je de temperatuur vertelt op het moment dat je de deur opent.
De Zwaargewichten: Andere ovens (zoals OpenFOAM of deal.II) zijn krachtig, maar vereisen een enorme hoeveelheid handwerk om die feedback te krijgen. Het is alsof je handmatig de hitte moet meten met een thermometer voor elke enkele graad verandering. De onderzoekers ontdekten dat voor sommige van deze ovens het schrijven van de code om de feedback te krijgen, honderden of zelfs duizenden extra regels code kostte.

2. De "Stabiliteits"-valstrik

Sommige ovens zijn geweldig voor het bakken van een simpel brood (een glad, eenvoudig natuurkundig probleem), maar als je een complexe soufflé probeert te bakken (een chaotisch stromingsprobleem), kunnen ze instorten.

Het artikel stelde vast dat voor bepaalde taken, zoals het optimaliseren van de vorm van een cilinder om de weerstand in water te verminderen, de helft van de ovens helemaal niet gebruikt kon worden. Ze waren structureel incompatibel. Het is alsof je een broodrooster probeert te gebruiken om een cake te bakken; de machine is simpelweg niet gebouwd voor die vorm van een probleem.
Zelfs onder de ovens die wel konden werken, waren sommigen "instabiel". Als je hen vroeg om een lange periode te simuleren, werden de getallen zo rommelig (een wiskundig concept genaamd ill-conditioning) dat de robotarm in cirkels begon te draaien, niet in staat om de beste oplossing te vinden.

3. De "Perfecte" Oven bestaat niet

De grootste verrassing? Nauwkeurigheid was niet het hoofdpunt.
De meeste ovens, zodra ze er daadwerkelijk in slaagden feedback te geven, waren verrassend nauwkeurig. Als ze niet crashten, vonden ze meestal dezelfde "perfecte receptuur" (de optimale oplossing).

De echte knelpunten waren niet dat de wiskunde fout was; het was dat het geheugen op was (de oven werd te heet), de opstelling te moeilijk te configureren was, of de kosten te hoog waren.
Het is alsof je 10 chefs hebt die allemaal een perfect biefstuk kunnen bereiden. Het probleem is niet dat ze niet kunnen koken; het probleem is dat drie van hen een keuken van $10.000 nodig hebben, één van hen 24 uur voorbereidingstijd nodig heeft, en één weigert te koken tenzij je hem een specifiek type mes geeft.

4. De "Negatieve Controle" (De Simpele Test)

Om er zeker van te zijn dat ze de ovens testten en niet de ingrediënten, begonnen ze met een zeer eenvoudige taak: het verhitten van een platte metalen plaat. Dit is de "negatieve controle."

Bij deze eenvoudige taak produceerde elke enkele oven die het kon uitvoeren, exact hetzelfde perfecte resultaat. Dit bewees dat de verschillen die ze zagen bij de complexe taken niet kwamen doordat de wiskunde kapot was; het was omdat de complexe taken de specifieke zwakheden van het ontwerp van elke oven blootlegden.

De Kern van het Verhaal

Het artikel introduceert Mosaic niet als een nieuwe manier om natuurkundige problemen op te lossen, maar als een gestandaardiseerd menu voor onderzoekers.

Vóór Mosaic was het kiezen van een solver als het gokken welke oven je moest kopen op basis van het woord van een verkoper.
Met Mosaic kun je op het menu kijken en zien: "Als ik deze specifieke taak moet doen, is Oven A 200 keer sneller dan Oven B, maar handelt Oven B mijn specifieke vorm beter af."

De onderzoekers concluderen dat voor veel problemen de "beste" solver niet degene is met de meest nauwkeurige wiskunde, maar degene die past bij jouw specifieke beperkingen (zoals geheugenlimieten of opsteltijd) zonder te crashen. Ze hebben al hun "keukengereedschap" en "menu's" open-source gemaakt, zodat iedereen hun eigen ovens aan de testkeuken kan toevoegen en kan zien hoe ze scoren.

Technische Samenvatting: Mosaic: Een Benchmark-suite voor Differentiabele Physics Solvers

Probleemstelling

Hoewel differentiabele partiële differentiaalvergelijking (PDE) solvers steeds vaker worden gepresenteerd als technologieën die solver-in-the-loop machine learning, gradiëntgebaseerde optimale controle en inverse problemen mogelijk maken, blijven de praktische kosten voor het verkrijgen van correcte en bruikbare gradiënten opaak. Het landschap van differentiabele solvers is gefragmenteerd over talen, automatic differentiation (AD) frameworks en numerieke methoden. Praktijkgebruikers worden geconfronteerd met aanzienlijke onzekerheid met betrekking tot:

Integratie-inspanning: De variërende expertise die vereist is om solvers te integreren, variërend van kant-en-klare applicaties tot low-level kernel toolkits.
Gradiëntkwaliteit: Het gebrek aan systematische metingen over gradiëntnauwkeurigheid, numerieke conditionering en stabiliteit.
Structurele Compatibiliteit: Solver-specifieke beperkingen (bijv. alleen periodieke randvoorwaarden, incompatibele penaliseringsschema's) die vaak pas aan het licht komen na een aanzienlijke commitment aan een specifieke stack.

Huidige benchmarks richten zich ofwel op de forward-nauwkeurigheid van neurale surrogaten (bijv. APEBench, PDEBench), of vergelijken AD-backends binnen een enkel framework (bijv. PhiFlow), maar falen in het systematisch meten van gradiënteigenschappen over onafhankelijke solver-implementaties heen.

Methodologie

De auteurs introduceren Mosaic, een uitbreidbare benchmarking-framework ontworpen om de toegang tot solver-gradiënten te standaardiseren en cross-solver vergelijking mogelijk te maken. De methodologie rust op drie kernartefacten:

Containerized Solver Interface (Tesseract):
- Solvers worden verpakt als Docker-containers (Tessera) die een uniforme API exposeren, ongeacht de taal of AD-strategie.
- De interface definieert twee entry points: apply(inputs) → outputs (forward pass) en vector_jacobian_product(inputs, cotangents) → vjp (reverse-mode gradiënt).
- Deze abstractie maakt het mogelijk om solvers te wisselen via configuratiestrings zonder de evaluatiecode te herschrijven. Alleen forward-solvers (bijv. OpenFOAM, deal.II) worden automatisch ingekapseld om finite-difference gradiënten als referentiebaseline te bieden.
Benchmark Taken:
- Vier fysieke domeinen worden geëvalueerd, gerangschikt op moeilijkheidsgraad:
  - Warmteoverdracht (H): Conductiviteitsinversie (Negatieve controle; gladde fysica isoleert AD-bugs).
  - Structurele Mechanica (S): Compliance minimalisatie via SIMP-topologieoptimalisatie.
  - 2D Fluïda (F2): Drag minimalisatie via inflow optimalisatie rond een cilinder (Niet-periodiek, obstakel-rijk).
  - 3D Fluïda (F3): Initial condition recovery in een periodieke Taylor-Green vortex box.
- Taken zijn ontworpen als standalone optimalisatieproblemen zonder geleerde componenten, wat ervoor zorgt dat fouten kunnen worden toegeschreven aan het gradiëntmechanisme van de solver in plaats aan modelbenaderingsfouten.
Evaluatieprotocol:
- Gradiëntnauwkeurigheid: Gemeten via cosine similarity en relatieve $\ell_2$ -fout tegen centrale finite differences bij optimale perturbatiegroottes.
- Conditionering: Geanalyseerd via het enkelvoudige waarde spectrum van de Jacobian.
- Prestaties: Wall-clock tijd voor forward en VJP passes, geheugengebruik en de VJP/forward kostenratio.
- Optimalisatie Convergentie: Vaste iteratiebudgetten met Adam en L-BFGS optimizers om convergentie naar het globale optimum te meten.

De suite bevat 14 solver backends die uiteenlopende AD-strategieën (source transformation, tape-based adjoints, hand-derived adjoints) en numerieke methoden (finite difference, finite volume, finite elements, lattice Boltzmann, spectral) beslaan.

Belangrijkste Resultaten

De evaluatie van 14 solvers over de vier domeinen onthult verschillende cruciale bevindingen:

Gradiëntnauwkeurigheid vs. Conditionering: Alle differentiabele solvers die gradiënten produceren, bereiken een hoge nauwkeurigheid (cosine similarity > 0.999) ten opzichte van finite differences. Echter, de Jacobian conditionering varieert met ordes van grootte. Projectie-gebaseerde solvers vertonen een steile spectrale verval (slechte conditionering) vergeleken met lattice Boltzmann of spectrale methoden, wat de stabiliteit van second-order optimizers beïnvloedt.
Computationele Kosten: Er is een variatie van een orde van grootte in computationele kosten. Source-transformation AD (bijv. JAX-gebaseerde solvers) behoudt een bijna constante VJP/forward ratio, terwijl tape-based adjoints (bijv. FEniCS, Firedrake) steiler schalen met de probleemgrootte.
Structurele Incompatibiliteit: Bij de meest complexe taak (2D drag minimalisatie met obstakels) kon slechts 3 van de 7 fluïda backends het probleem representeren vanwege incompatibiliteiten in randvoorwaarden of penaliseringsschema's. Deze "attritie" vindt plaats nog voordat de gradiëntkwaliteit een factor wordt.
Optimalisatie Uitkomsten: Ondanks enorme verschillen in conditionering en kosten, convergeren alle succesvol draaiende solvers naar vergelijkbare optima op goed geconditioneerde problemen (Heat, Structural). Op de 3D IC recovery taak presteert L-BFGS met solenoidal projectie significant beter dan Adam en unprojected L-BFGS, waarbij de initial condition error wordt teruggebracht van >40% naar <0.5%.
Implementatie-inspanning: De integratiecomplexiteit varieert enorm. Solvers gebouwd op moderne AD-frameworks (JAX, PyTorch) vereisen vaak nul extra regels code voor gradiënten, terwijl low-level kernel toolkits (bijv. NVIDIA Warp) honderden specifieke regels voor de adjoint implementatie vereisen.

Betekenis en Claims

Het artikel positioneert Mosaic niet als een bron van nieuwe empirische resultaten voor een enkele solver, maar als infrastructuur die de drempel voor differentiabele physics onderzoek verlaagt, analoog aan OpenAI Gym voor reinforcement learning.

Standaardisatie: Mosaic biedt de eerste gestandaardiseerde interface om gradiënten van onafhankelijke solver-implementaties te ontsluiten, te vergelijken en te vertrouwen.
Praktijkbegeleiding: De benchmark brengt praktische barrières aan het licht (geheugenlimieten, numerieke stabiliteit, setup compatibiliteit) die kritischer zijn dan louter de ruwe gradiëntnauwkeurigheid alleen. Het suggereert dat voor goed geconditioneerde problemen de snelste solver met de laagste integratie-inspanning de optimale keuze is.
Community Extensibiliteit: Het framework is open-source en ontworpen om te evolueren. Het stelt onderzoekers in staat om failure modes te testen voordat ze zich vastleggen op een specifieke solver stack, en maakt de constructie van solver-in-the-loop pipelines mogelijk op basis van een uniforme interface.
Validatie van AD: De resultaten valideren dat hoewel hand-derived adjoints sneller kunnen zijn, reverse-mode AD via moderne frameworks de beste balans biedt tussen inspanning en capaciteit, waarbij voldoende nauwkeurigheid wordt geboden voor optimalisatie tegen een fractie van de implementatiekosten.

De auteurs concluderen dat hoewel de gradiëntkwaliteit over het algemeen voldoende is, de keuze van de solver backend een beslissende factor is in het succes of falen van gradiënt-gebaseerde workflows, primair door structurele compatibiliteit en numerieke conditionering in plaats van de correctheid van de gradiënt zelf.