PaperlayerView exact revision on arXiv

Source-linked AI summary

GPUPhysBench: Benchmarking Coding Agents for Correct and Efficient GPU Physics Simulation

Yuchen Sun, Jinjin He, Sinan Wang, Bo Zhu

arXiv:2609.35639v1cs.DCcs.AI

TL;DR

Physical simulation coding requires accurate, efficient GPU implementations, yet existing evaluations do not jointly test numerical correctness and speed on these workloads. GPUPhysBench evaluates coding agents on 50 simulation tasks against expert references. The two strongest systems pass every task, but performance remains behind the references on most tasks.

  • Problem

    Existing benchmarks provide limited coverage of GPU physical simulation, where evaluation must assess both numerical correctness and execution speed amid irregular computation.

    Source: §1 · p. 1

  • Method

    GPUPhysBench evaluates coding agents on 50 fluid, solid, and granular simulation tasks using fixed budgets, numerical checks, and expert reference implementations.

    Source: §1 · p. 2

  • Results

    The two strongest systems pass all 50 tasks, yet Opus reaches fast0.9 on only 22% of tasks.

    Source: §4.2 · p. 6

  • Takeaways & Limitations

    Generated-code analysis highlights numerical algorithm selection, data organization, and coordination across kernels as important performance factors.

    Source: §5 · p. 9

    Submissions must use FP32 computation and storage, while hidden tests vary data but keep problem size fixed.

    Source: §3.2 · p. 4

Abstract

from arXiv · show

Writing fast GPU code for physical simulation is difficult: implementations must preserve numerical accuracy while handling irregular data access, synchronization, and iterative solvers. We introduce GPUPhysBench, a benchmark of 50 tasks testing whether coding agents can meet these demands. Tasks cover fluids, deformable solids, and granular materials, from individual simulation operators to complete simulators. Agents write, compile, test, and optimize GPU code with access to a NVIDIA GPU under fixed time budgets. We report pass rates and runtime performance relative to expert-optimized reference implementations. In a single-attempt evaluation of six frontier model-harness pairs, the two strongest pass all 50 tasks, but even the fastest reaches at least 0.9 the reference speed on only 22% of them, and no submission is more than 5% faster than the reference. The largest gaps arise in collision detection, constraint solving, and iterative solvers. GPUPhysBench brings physical simulation workloads to coding-agent evaluation, testing both the ability to implement numerical methods correctly and the ability to make them run efficiently.

1 INTRODUCTION

GPU physics simulation needs optimized CUDA implementations that preserve numerical accuracy, but existing evaluations do not cover the combined demands of irregular GPU workloads and numerical reasoning. GPUPhysBench addresses this gap with 50 tasks and controlled, tool-using agent evaluation against expert references.

Motivation

  • Physical simulation also supplies scalable, controllable physically plausible interaction data for world models and embodied intelligence, where real-world collection is costly and slow.This demand increases the value of automating GPU implementation while retaining accuracy and efficiency.Source: §1 · p. 1

Research gap

  • Existing benchmarks separate simulation correctness from efficient GPU coding and omit the irregular access patterns and numerical reasoning required by physics simulators.Simulation bottlenecks include neighbor search, atomic contention, and load imbalance; solver runtime also depends on algorithm and preconditioner choices.Source: §1 · p. 1
  • Most existing evaluations do not test agents’ extended workflows of planning, editing, compiling, diagnosing failures, and improving code.A controlled setting must preserve agent autonomy while standardizing resource budgets and hardware access.Source: §1 · pp. 1–2

Benchmark contribution

  • GPUPhysBench introduces 50 tasks across fluids, deformable solids, and granular materials, with expert-validated references and fixed budgets in an isolated agent sandbox.It measures pass rates and runtime against expert implementations while capturing long-horizon, tool-using optimization.Source: §1 · p. 2

2 RELATED WORK

Prior benchmark work evaluates GPU-kernel performance and scientific-code correctness, while agentic systems increasingly use iterative feedback to develop code. These lines of work provide context for GPUPhysBench’s focus on physical simulation workloads.

GPU Kernel Generation

LLMs for Scientific Computing

  • Scientific-code benchmarks include research coding problems and CFD or PDE solvers evaluated for accuracy and efficiency.Other agentic systems generate and refine PDE solvers, automate OpenFOAM workflows, or address neighboring tasks such as PDE control and reduced-order modeling.Source: §2 · p. 2

3 BENCHMARK

GPUPhysBench covers 50 established simulation tasks across fluids, deformable solids, and granular materials, spanning isolated operators and full simulators. Agents implement specified CUDA computations in a controlled environment, and submissions are checked, audited, and measured against references.

3.1 TASK DESIGN AND COVERAGE

  • The 50 tasks cover established methods across fluid dynamics, deformable solids, and granular materials, and include both isolated operators and integrated simulation computations.Tasks span stencils, iterative solves, atomic scatter and gather, irregular neighborhoods, constraint projection, and collision processing; full-simulator tasks require multiple stages to work together.Source: §3.1 · p. 2, Figure 1 · p. 3

3.2 TASK SPECIFICATION

  • Agents implement specified CUDA computations under numerical requirements, using a GPU workspace while references and correctness evaluators remain withheld.Prompts specify the method, discretization, boundary conditions, and convergence criteria where applicable; the objective is to minimize GPU execution time while satisfying the specification.Source: §3.2 · pp. 3–4

3.3 ANTI-CHEATING

  • Isolation, static checks, and post-run audits enforce access, interface, build, allocation, and execution rules; any audited violation counts as failure.The harness rebuilds submissions in a clean directory with protected starter-code sections, driver, and evaluator.Source: §3.3 · p. 5

3.4 METRICS

  • Correctness measures tasks passing numerical checks on public and hidden inputs, while pass rate additionally requires passing anti-cheating audits.The metrics are computed across all benchmark tasks using each attempt’s final submission.Source: §3.4 · p. 5
  • fast_p measures the fraction of tasks that pass and exceed a speedup threshold, with failed submissions retained in the denominator.The benchmark reports p values of 0.5, 0.9, and 1.05; the last threshold counts implementations more than 5% faster than the reference.Source: §3.4 · p. 5

4 EXPERIMENTS

GPUPhysBench evaluates coding-agent systems on numerical correctness and execution speed against expert implementations. Correctness is near-saturated for the strongest systems, while performance remains well below reference speed on most tasks, especially in complex workloads.

4.1 SETUP

  • Six model-harness pairs are compared with expert implementations for correctness, pass rate, and runtime, using one attempt per task under fixed evaluation conditions.The evaluation uses a single NVIDIA GeForce RTX 4090; systems receive one attempt per task.Source: §4 · p. 5, §4.1 · p. 6, §4.2 · p. 6

4.2 MAIN RESULT

  • Opus and GPT pass all 50 tasks, but Opus reaches fast0.9 on only 22%, and no single-attempt submission exceeds 5% faster than the reference.Opus is faster than GPT on 38 tasks; 17 of Opus’s 50 passing submissions take at least twice as long as the reference.Source: §4.2 · p. 6

4.3 PERFORMANCE BY TASK CATEGORY

  • Category-level speed is computed over each system’s passing tasks, and the strongest performance concentrates in regular local computations rather than complex workloads.Geometric-query and collision-detection tasks are slowest on average, followed by global solves and position constraint solving; all speedups above 1× are below 0.3% and do not establish an advantage.Source: §4.3 · p. 7, Figure 4 · p. 8
  • Near-reference performance is concentrated in regular grid and lattice tasks, while advection and Cahn–Hilliard updates show larger gaps and more variation.In third-order advection, Opus combines velocity components in one kernel, whereas GPT uses separate component kernels.Source: §4.3 · p. 7
  • In PIC/FLIP P2G, Opus reaches 0.556× reference speed versus Gemini’s 0.134× by packing particles into spatial tiles and accumulating in shared memory.The reference also aggregates contributions by cell, so grouping cost and accumulation granularity remain optimization challenges.Source: §4.3 · p. 7
  • For local interaction updates, Opus approaches reference speed on explicit FEM and closely matches it on DEM contact, where contiguous spatial-grid traversal differs from GPT’s hash-bucket search.The comparison points to neighbor-search organization and candidate access as important beyond the local update arithmetic.Source: §4.3 · p. 8
  • Standalone PBF reaches 0.815× reference speed for Opus, but every system remains below 0.3× on the standalone spring-based XPBD solve.For the Dirichlet Poisson solve, Jacobi-preconditioned Opus and Gemini reach 0.049× and 0.036×, while multigrid-preconditioned GPT, GLM, and DeepSeek reach 0.241×, 0.248×, and 0.303×.Source: §4.3 · pp. 8–9

4.4 ABLATION STUDY

  • Longer budgets raise Opus’s fast0.5 from 54% to 76%, while three attempts raise its fast0.9 from 22% to 36%; GPT’s fast0.9 rises from 16% to 18%.At 1.5× budget, two Opus submissions exceed reference speed by more than 5%; across three attempts, only one run does so, on DEM at 1.13×.Source: §4.4 · p. 9, Table 2 · p. 9

5 CONCLUSION

GPUPhysBench evaluates whether coding agents can implement physical simulation methods correctly and efficiently, finding that the two strongest systems pass all 50 tasks while substantial speed gaps remain.

5 CONCLUSION

  • The two strongest frontier agents pass all 50 tasks, but substantial performance gaps remain, especially in collision detection, constraint solving, and iterative solvers.Generated-code analysis and development traces highlight numerical algorithm selection, data organization, and coordination across kernels as important factors.Source: §5 · p. 9
  • GPUPhysBench evaluates 50 physical simulation tasks, from individual operators to complete simulation steps, using numerical checks and expert reference implementations.It measures both implementation correctness and execution efficiency.Source: §5 · p. 9
  • The findings motivate agents that reason jointly about numerical methods and GPU execution, with GPUPhysBench serving as a testbed for automated implementation of efficient physical simulators.Source: §5 · p. 9

AI USE STATEMENT

Generative AI tools assisted with benchmark construction and paper writing; human experts optimized the reference implementations, and the authors reviewed the AI-assisted work and take responsibility for it.

AI USE STATEMENT

  • Generative AI tools assisted in constructing the benchmark, drafting sections, and polishing the paper’s writing.Source: AI USE STATEMENT · p. 10
  • Claude Fable translated upstream simulation code into CUDA, after which human experts rewrote and optimized the reference implementations.Source: AI USE STATEMENT · p. 10
  • The authors reviewed all AI-assisted work, including tasks, results, and text, and take full responsibility for the paper’s content.Source: AI USE STATEMENT · p. 10

A EXAMPLE TASK PROMPT AND STARTER CODE

The appendix uses a Neumann Poisson GPU task to illustrate GPUPhysBench’s task specification, CUDA starter interface, drivers, and fixed execution requirements, including an FP32 preconditioned Conjugate Gradient solve completed in timed compute(). It also describes submission-audit procedures and outlines detailed outcomes reported later.

Neumann Poisson Prompt

  • The example asks for a fast, general-purpose FP32 CUDA preconditioned Conjugate Gradient solver exposed to Python through pybind11 and compiled with xmake.The implementation must not be tailored to the sample input.Source: Neumann Poisson Prompt · p. 14

2. Implementation and interface

  • The fixed Python interface uploads inputs in input(), times compute() within exec(), and copies results back in output(), so the task requires algorithmic work to occur in compute().The starter-code instructions prohibit modifying those methods, the destructor, error helper, bindings, or members set by input().Source: §2 · p. 14, Timer Auditor Prompt · p. 22

Neumann Poisson Prompt (continued)

  • The harness rebuilds the extension from the source and xmake.lua in a clean directory, restores fixed code, and times compute() on a fresh process.Compilation flags may change, but build scripts and fixed interface components must remain intact.Source: Neumann Poisson Prompt (continued) · p. 15
  • The agent implements allocate(), compute(), and release(); only compute() performs the solve, while allocation is limited to permitted setup without reading input data.Input-dependent storage must instead be allocated in timed compute() or bounded during allocate().Source: Neumann Poisson Prompt (continued) · p. 15

A.2 INITIAL CUDA CODE

  • The starter defines a cell-centered 3D Poisson system with FP32 coefficient and right-hand-side arrays, a Boolean active-cell mask, and symmetric axis-neighbor couplings.Inactive cells contribute no equation, and missing boundary couplings are absent from the system.Source: §A.2 · p. 16
  • The Neumann system is singular with a constant null space, so the compatible right-hand side and solution must be handled with the output normalized to zero active-cell mean.The output must also be zero at inactive cells.Source: §A.2 · pp. 16–17

A EXAMPLE TASK PROMPT AND STARTER CODE

  • The fixed exec() scaffold measures compute() with CUDA events and synchronizes before stopping the timer, so all GPU work issued by the solve is timed.The task description also reproduces the complete prompt and initial CUDA source, including interface documentation, implementation hooks, timing scaffold, and bindings.Source: A EXAMPLE TASK PROMPT AND STARTER CODE · p. 14, §A.2 · pp. 16, 18

A.2 INITIAL CUDA CODE

  • The starter module exposes a preconditioned conjugate-gradient solver for a Poisson-type system, returning a zero-mean active-cell solution and GPU time measured around compute().Its output is copied to a NumPy array with non-DoF cells set to zero.Source: §A.2 · p. 19

A.3 PYTHON DRIVER

  • The public driver tests a 256^3 Poisson-Neumann system with a cylinder radius of 0.18 grid widths and tolerance 10^-6, timing the fastest of five calls after three warm-ups.A hidden driver changes the seed and cylinder radius to 0.21; correctness also requires a true relative residual below tolerance, near-zero active-cell mean, and exactly zero inactive cells.Source: §A.3 · p. 20

B AUDITOR

  • The audit combines mechanical interface and API checks with two read-only LLM reviews, and a run passes only when static, network, parallel-agent, and timing checks all pass.The LLM reviews use Claude-Opus-5; audit findings must cite logs or source lines, and numerical correctness is evaluated separately.Source: B AUDITOR · p. 21

Transcript Auditor Prompt

  • The transcript auditor checks whether an agent accessed the network or used overlapping parallel agents, requiring evidence from transcript events and line numbers.The harness omits the parallel-agent question when its tool-name scan finds no possible agent-starting calls.Source: Transcript Auditor Prompt · p. 21, B AUDITOR · p. 21

Timer Auditor Prompt

  • The timer auditor checks whether any algorithmic work occurs outside compute(), including input-dependent preparation or work reused across calls.Initialization, layout conversion, and preparation must run inside compute() on every call; allocation, synchronization, and device-buffer copies are allowed there.Source: B AUDITOR · p. 21, Timer Auditor Prompt · p. 22
  • All reported audit failures were deterministic HARNESS MODIFIED findings, while LLM audits found no timing, network-access, or parallel-agent violations.The deterministic failures involved changes to protected interface code or build configuration beyond permitted compilation flags.Source: Timer Auditor Prompt · p. 22

C DETAILED RESULTS

  • The detailed-results section reports per-task outcomes, repeated-run variation, family-weighted scores, development cost, and numerical-check pass or fail margins.The supplied passage identifies these reporting categories but does not provide their values.Source: C DETAILED RESULTS · p. 23

C.1 PER-TASK RESULTS

All six systems pass 21 of 50 tasks, but speed remains uneven: performance is strongest on a small set of tasks and weakest on iterative, irregular, or candidate-search workloads. Run-to-run variation is small for Opus and GPT, while task-family weighting and development-time results reveal further differences across systems.

C.1 PER-TASK RESULTS

  • No system reaches 0.5× reference speed on 16 tasks, mostly those involving iterative solvers, irregular contact or constraint processing, or data-dependent candidate search.The best speedup reaches at least 0.95× on nine tasks, and submissions exceeding the reference do so by at most 0.2%.Source: §C.1 · p. 23

C.2 RUN-TO-RUN VARIATION

  • Across three runs, Opus reaches fast0.5 of 64%–66% and GPT 38%–42%; their geometric-mean speedups are 0.52–0.53 and 0.29–0.33, respectively.Within-system variation is small; only the second Opus run on dem exceeds the reference by more than 5%, at 1.13×.Source: §C.2 · p. 23, Table 4 · p. 25

C.3 FAMILY-BALANCED SCORES

  • Family-weighted fast0.5 preserves the system ordering, with Opus at 65% and GPT at 35%; family-weighted fast0.9 is 8% for every system except Opus.Near-variant tasks are grouped into 37 equally weighted families.Source: §C.3 · p. 23, Table 5 · p. 25

C.4 DEVELOPMENT TIME AND TOKEN USAGE

  • Opus, GPT, Gemini, and DeepSeek finish every task before the deadline, while Qwen reaches the deadline on 19 tasks and uses a median 92% of its budget.GLM reaches the deadline on four tasks; Gemini produces the fewest output tokens and finishes fastest.Source: §C.4 · p. 23

C.5 CORRECTNESS MARGINS

The correctness checks separate most passing submissions from failing ones, but residual-based checks behave differently because solvers stop near their required threshold. Hidden inputs rejected no submission that passed public inputs in these runs, while some failures produced no output to evaluate.

Correctness margins

  • Figure 5 plots each output-producing submission’s worst error-to-tolerance ratio across checks on both input sets, with comparison checks distinguished from residual checks.A ratio below 1 passes; the figure’s shaded band spans the largest passing and smallest failing ratios and contains no submission.Source: §C.5 · p. 25, Figure 5 · p. 26

Comparison-based checks

  • For comparison-based checks, all 234 correct submissions fall below tolerance and all 27 failures exceed it; no submission lies between 0.6× and 2.2× tolerance.The correct submissions have median ratio 0.027 and maximum 0.60; 25 failures exceed tolerance by more than 100×.Source: §C.5 · p. 25

Residual-based checks

  • Passing residual-based submissions cluster just below the threshold, with median ratio 0.73, because iterative solvers stop once they meet the criterion.The five failing submissions exceed the required residual by at least 5 × 10^4; further iterations can increase the margin at a speed cost.Source: §C.5 · pp. 25–26

Public and hidden inputs

  • No submission passes checks on public inputs while failing them on hidden inputs in these runs; hidden inputs remain a safeguard against tailoring to public examples.Source: §C.5 · p. 26

Failures without output

  • Eleven failing submissions produce no output to check: eight cannot be rebuilt, one fails at runtime, and two produce non-finite values.Of the eight unrebuildable submissions, six do not compile and two removed fixed skeleton sections needed for restoration.Source: §C.5 · p. 26

C.6 VALIDATION OF THE TOLERANCES

Tolerance validation compares correct implementation variation with plausible implementation errors. Correct variants remain below about 0.6 of tolerance, while every planted bug exceeds it, though a few mutants lie relatively close to the threshold.

Known-correct variants

  • Disabling fused multiply-add contraction leaves all 45 comparison-based tasks passing, with median ratio 0.012 and maximum 0.18; residual-based tasks score 0.30–0.62.For residual checks, these ratios reflect where the solver stopped rather than a difference from the reference.Source: §C.6 · p. 27

Plausible implementation errors

  • All 36 plausible single-edit mutants fail, with median ratio about 1.6 × 10^3; 26 exceed tolerance by more than 100×.Mutants cover omissions, sign flips, boundary mistakes, stage-order or in-place updates, and wrong coefficients or stopping criteria.Source: §C.6 · p. 27

Closest mutants

  • Four mutants come within 10× of tolerance: the mc_r stopping-criterion mutant scores 1.07 on public and 3.4 on hidden inputs, while the pic_flip wrong-sign mutant scores 1.7.Source: §C.6 · p. 27
  • The ccd_ee mutant that stops bisection after 15 rather than 30 steps scores 6.0, while the xpbd in-place-update mutant scores 8.7.Source: §C.6 · p. 27

Submissions nearest the threshold

  • The two mc_r submissions nearest the threshold are correct: the reference’s prescribed 10^-4 residual creates a floor, and tighter reference solves widen the margin.Against a reference solved to 10^-6, the submissions score 0.18 and 0.29; re-solving one gives 0.001 of tolerance.Source: §C.6 · p. 27
  • The closest self_collision_xpbd failure has a real bug: hashed cell lookup can visit a bucket twice and record some contact pairs twice.Across the validation experiments, every planted bug exceeds tolerance, while correct variation stays below about 0.6 of tolerance.Source: §C.6 · p. 28

D CASE STUDIES OF GENERATED IMPLEMENTATIONS

The case studies compare generated implementations with expert references on particle-to-grid accumulation and a global Poisson solve. They show that reducing memory traffic or synchronization alone does not close performance gaps when aggregation strategy or solver convergence remains inferior.

D CASE STUDIES OF GENERATED IMPLEMENTATIONS

D.1 PIC/FLIP PARTICLE-TO-GRID TRANSFER: ORGANIZING ACCUMULATION

  • Gemini sorts particles by grid-cell ID but still gathers indirectly and performs global atomics for every particle-node contribution.Opus groups particles into tiles and accumulates in shared memory, reducing global atomic traffic, but still uses shared-memory atomics within each tile.Source: §D.1 · p. 29
  • For PIC/FLIP particle-to-grid transfer, Opus reaches 0.556× reference speed and Gemini 0.134×; the reference aggregates each cell’s contributions in registers before shared-memory merging.The case transfers each particle’s mass and momentum contributions to eight neighboring nodes per velocity component.Source: §D.1 · p. 29

D.2 DIRICHLET POISSON SOLVE: ITERATION COST AND SOLVER CHOICE

  • For the 256^3 Dirichlet Poisson solve, Gemini’s Jacobi-preconditioned CG uses separate kernels and transfers two scalar reductions to the host in a typical iteration.Opus uses symmetric scaling and fused kernels, keeping CG coefficients on-device and checking convergence every ten iterations.Source: §D.2 · pp. 29–30
  • The final Poisson implementations achieve 0.049× reference speed for Opus and 0.036× for Gemini, despite Opus reducing memory passes and host synchronization.Both retain diagonal preconditioning, whereas the expert reference uses multigrid-preconditioned CG.Source: §D.2 · p. 30

E.1 TASK LIST

GPUPhysBench spans established simulation methods across fluids, solids, and granular materials, with task inputs and correctness checks designed for reliable evaluation. Comparisons show the structured-grid poisson_dirichlet reference substantially outperforms AMGX on its specified solve.

E.1 TASK LIST

  • The 50 tasks cover fluid, deformable-solid, and granular simulation methods, from local operations to global solves and coupled pipelines.They include Eulerian and particle-grid fluids, PBF and LBM, plus mass-spring, FEM, MPM, XPBD, CCD, and DEM methods.Source: §E.1 · p. 31, Table 8 · pp. 31–33

E.2 TASK INPUTS AND CORRECTNESS CHECKS

  • Hidden inputs keep problem sizes comparable while changing data, with altered geometry on 16 tasks and solver coefficients on four.Correctness checks and absolute tolerances are specified task by task; most hidden inputs use different random seeds or initial conditions.Source: §E.2 · p. 33, Table 9 · pp. 34–37

F COMPARISON WITH GPU LIBRARIES

  • Reference and GPU-library timings use public inputs on an RTX 4090, with GPU time reported as the best of five runs after three warm-ups.References use the same fresh-solver-per-call timing procedure.Source: F COMPARISON WITH GPU LIBRARIES · p. 38

F.1 POISSON SOLVE WITH DIRICHLET BOUNDARIES VERSUS AMGX

  • 9.0× faster than the best AMGX configuration, the poisson_dirichlet reference exploits structured-grid methods for the specified Poisson solve.It uses geometric coarsening, red-black Gauss–Seidel smoothing, stencil storage, and fused kernels; the comparison measures task specialization, not a shortcoming of AMGX.Source: Table 10 · p. 38, §F.1 · p. 38

F.2 SIMULATION STEPS VERSUS WARP AND TAICHI

Across the compared simulation steps, GPUPhysBench references run 2.6–7.0× faster than the Warp and Taichi ports, with output differences below 5 × 10^-7. The speed gap is associated with how memory access and accumulation are organized, rather than arithmetic.

F.2 SIMULATION STEPS VERSUS WARP AND TAICHI

  • 2.6–7.0× faster than the Warp and Taichi ports, the references preserve outputs to relative difference below 5 × 10^-7.The comparison covers MPM, DEM, and explicit FEM; the Taichi FEM step includes rest-state computation required by the task.Source: §F.2 · p. 38, Table 11 · p. 38
  • The performance difference lies in memory access and accumulation: references spatially sort work, accumulate within shared memory, and make neighbor reads cache-friendly.The references counting-sort MPM particles and DEM grains, bin FEM tetrahedra spatially, and use task-specific storage and computation choices.Source: §F.2 · pp. 38–39

G SIMULATIONS BUILT ON REFERENCE IMPLEMENTATIONS

GPUPhysBench reference implementations can be advanced over multiple timesteps to produce full simulations. The examples span fluid flows, impacts, deformable solids, and cloth contact.

G SIMULATIONS BUILT ON REFERENCE IMPLEMENTATIONS

  • The six simulations advance complete reference steps over many timesteps; scene setups provide ingredients outside each task’s one-step specification.Examples include gravity, boundaries, scene-object contact, and material plasticity; Figure 6 shows four representative frames per row.Source: G SIMULATIONS BUILT ON REFERENCE… · p. 40, Figure 6 · p. 41
  • The other rows show colliding vortex rings breaking into small-scale vortices, a jelly cube bouncing after impact, a snowball compacting and shattering, and cloth folding over a sphere.The scenes use mc_r, fem_explicit, mpm_explicit, and xpbd reference steps, respectively.Source: G SIMULATIONS BUILT ON REFERENCE… · p. 40
  • The water-drop example models a 25.2-million-particle impact whose collapsing cavity drives a Worthington jet.The impact forms a crown splash and cavity.Source: G SIMULATIONS BUILT ON REFERENCE… · p. 40
  • The cylinder-flow example sheds alternating vortex rows at Reynolds number 1000, with a Strouhal number of 0.197, close to the experimental value of about 0.2.The flow uses a 512 × 256 × 128 grid.Source: G SIMULATIONS BUILT ON REFERENCE… · p. 40

Related papers

Loading 2609.35639v1…