VA Dynamics
About the project
VA-Dynamics, developed by VA-Design, is a GPU-native CFD project focused on building a local-first simulation stack for high-fidelity external aerodynamics for motorsport and aerospace-style use, without the usual long runtimes, fragmented toolchains, and slow iteration loops. The objective is not only to compute flow fields, but to compress the full time-to-decision cycle so engineers can test ideas more often, validate changes faster, and carry momentum through an entire development programme instead of waiting on the next run.
VA-Dynamics is built around two tightly integrated parts that are designed as one product pipeline rather than separate utilities. The first is VA-Dynamics, the main desktop application written in C++ that manages models, cases, domain settings, and solver orchestration while providing the working environment through navigation menus, a real-time viewport, live logs, and the explorer and properties panels. The second is VAWindSimSolver, shortened to VAWSS, a CUDA-accelerated solver designed to run purely on the client GPU so simulations execute locally with a workflow that stays fast, repeatable, and engineering-focused.
The Main Application handles the entire “Vendor” of the CFD loop, including case setup, model preparation, domain configuration, and run management. VAWSS handles the “compute half” of the loop, iterating the solution in the background while returning not just final results but the supporting outputs an engineer needs to trust a run, including coefficients, values, and history data that can be graphed and compared inside the application.
Mission and vision
Our mission is to build a fully GPU-native CFD solver that supports accelerated aerodynamic iteration while staying grounded in real physics, an engineering tool designed for decisions, not visuals-first output. This means performance is treated as a product feature only when it is paired with numerical discipline, predictable convergence behaviour, and transparent run reporting that makes results defensible.
We are also building the surrounding workflow so CFD becomes more approachable and practical for both companies and individual engineers. The aim is to keep case setup, models, meshing, boundary conditions, solver settings, and outputs in one place, shorten turnaround time by designing the solver for GPU-parallel execution from the start, and reduce dependency on external compute, queues, and specialist infrastructure by keeping the default path local.
The long-term vision is to bridge academic-level simulation intent with real-world usability. That means fewer steps between geometry and validated coefficients, fewer places where a run can silently fail, and a workflow that encourages iteration rather than punishing it.
Technical approach
VA-Dynamics is designed as a GPU-first stack end-to-end, not a CPU solver with some GPU acceleration. The focus is to keep the core numerical workload on the GPU, including pressure–velocity coupling and the heavy sparse linear algebra that typically dominates runtime, so performance scales with modern GPU capability rather than being bottlenecked by CPU execution patterns and serial memory hierarchies.
The solver is engineered around GPU-resident field data and parallel kernel execution across the domain. CFD operations are naturally repetitive across very large numbers of cells and faces, which makes the workload well suited to GPU execution when the data layout and solver structure are designed for predictable memory access, minimal thread divergence, and controlled synchronisation. The intent is to avoid round-trips that move large field arrays back and forth and to keep runtime dominated by GPU compute rather than glue code and transfer overhead.
The numerical approach prioritises robustness first. A fast solver that converges only on idealised cases is not useful in engineering. VAWSS is therefore designed around stable iteration loops, clear convergence criteria, explicit residual reporting, and predictable failure handling when a case is invalid. The application side supports this by enforcing clean run staging and by surfacing pre-run warnings so the user is not forced into trial-and-error cycles that waste time.
Three core processes
VA-Dynamics is structured around three stages that mirror how the solver needs to be prepared, executed, and validated. These stages are not marketing labels; they define how state is controlled and how repeatability is maintained across runs.
Pre-solver
The pre-solver stage is owned by the Main Application and exists to make execution reliable. This is where the full user environment is established and stabilised before a run starts, including viewport rendering, navigation, live logging, the explorer and properties panels, and the run management system that controls solver execution cleanly in the background.
During this stage, users import and preview 3D models, apply preparation steps where required, and configure the case that defines the simulation domain and environment. The case is treated as a first-class object because it is the contract between the application and the solver. Configuration is kept explicit and traceable so that staged runs are reproducible and so that changes between iterations can be understood and audited.
When the user starts a simulation, the application stages the selected case into a universal transient run folder that is accessible to the solver. This staging step snapshots the inputs into a controlled run package, reduces hidden state, prevents cross-case contamination, and makes runs easier to reproduce. It also makes debugging and regression checking practical because the run begins from a known input snapshot and produces a clearly defined output package.
Solver
VAWindSimSolver, shortened to VAWSS, is the computational core of the project. It iterates, defines, and refines the simulation in the background while returning coefficients, values, and history data that the application can plot and compare. VAWSS is built around Nvidia CUDA to use the massively parallel nature of GPUs as the primary execution platform rather than relying on CPU-first solver patterns and then attempting to accelerate a few operations.
The intended outcome is a high-throughput iteration environment with GPU-resident field data, memory allocation strategies that suit repeated numerical passes, and solver schemes shaped for GPU execution. The aim is not merely to run faster, but to change how the tool is used by making iteration cycles short enough that engineers can explore more design variants and converge on better solutions within the same timeframe.
Performance targets depend on case complexity and hardware, but the architectural intent is consistent: reduce the time cost of iteration blocks substantially. An internal target direction is to move typical external-aero iteration runs that would traditionally take many minutes for around a thousand iterations into a much shorter window on suitable GPUs, enabling rapid prototyping and tighter design feedback loops without relying on external compute queues.
Post-solver
Once simulations are finished, the solver returns the run package back to the main application with structured outputs. Results include JSON files containing run metadata and coefficients, and VTK files containing field and surface data suitable for inspection and post-processing.
The application then shifts into analysis and comparison mode. CPU-side processing is used for presentation, plotting, rendering overlays, and managing comparisons rather than for the heavy numerical solve. This includes pressure mapping onto the model within the rendered viewport, graphs driven by solver history data, and access to raw values for verification and export. The purpose of post-solver is to make validation quick and defensible so changes can be judged with both visual evidence and measurable outputs before committing to real-world testing.
Core solver direction: VAWSS
Flow regimes
VAWSS targets incompressible flow support as the primary path for external aerodynamics. Compressible support is planned where required by operating regime, structured to fit the same GPU-native pipeline so capability expands without breaking the execution model or forcing a different workflow.
Physics models
Laminar and turbulent capability are treated as first-class requirements from the outset. Turbulence modelling is approached as practical engineering functionality rather than an optional add-on, because real aerodynamic use cases depend on it for credible surface pressure behaviour and force prediction.
Numerics and stability
The solver loop is designed as a GPU-native iteration process with robust convergence behaviour and predictable failure handling when a case is invalid. Pressure–velocity coupling and sparse linear algebra are engineered for GPU throughput through GPU-friendly formats and solver strategies rather than CPU-shaped data layouts, with run health reporting designed to make convergence quality visible rather than implied.
Performance strategy
Throughput is driven by parallel kernels, GPU-resident field data, and memory access patterns designed to be GPU-efficient. The pipeline is designed to minimise synchronisation and round-trips so runtime is dominated by GPU work rather than orchestration overhead.
Why this is a step-change and what is actually revolutionary
Iteration speed is not only about raw FLOPS. It is about removing friction and bottlenecks across the entire loop from setup, to run, to diagnosis, to adjustment, to re-run, to comparison. VA-Dynamics is built around shrinking that loop by combining a solver that runs GPU-only on local hardware, a case-driven workflow that is fast to repeat and hard to break, and outputs that translate directly into aerodynamic decisions through coefficients, forces, moments, convergence evidence, and field views.
This changes the engineering behaviour of the tool. When the cost of a run falls, engineers iterate more, test more boundaries, and converge on better solutions faster. Instead of CFD being a periodic checkpoint, it becomes an active design instrument.
VA-Dynamics workflow
VA-Dynamics is not just a launcher. It is designed to make solver runs repeatable, inspectable, and cleanly staged, with foreground visualisation and background management treated as part of the engineering workflow rather than separate utilities.
The application provides a fixed workspace layout with a viewport for render and preview, an explorer for workspace and case navigation, a properties system for case and solver configuration, and a solver console for logs, warnings, and run status. This fixed structure reduces cognitive load and keeps the workflow predictable as projects scale in complexity.
Cases are stored in their own folders and persist as readable JSON so configuration remains transparent, versionable, and easy to track across iterations. This enables practical comparison between runs because the “why” of a difference is discoverable through the case definition, not buried in hidden state.
Run control is built around clean staging. File Run Solver stages exactly one selected case into a transient run area as a controlled run snapshot. This reduces hidden state, avoids cross-case contamination, and makes runs easier to reproduce. Outputs and exports are written back as organised run artefacts, with mesh and results in VTK for inspection and post-processing, alongside JSON results for coefficients and run metadata, so comparisons across runs remain straightforward and auditable.
Outputs engineering-first
VA-Dynamics is designed to produce the metrics required to iterate aero, not just visually appealing flow images. Loads and coefficients are treated as primary outputs because they are the bridge between flow behaviour and design decisions. The system is built to return aerodynamic loads such as drag, lift, and side force, alongside moments in yaw, pitch, and roll, with coefficient reporting such as Cd, Cl, and Cm expanding as the model set develops.
Field and surface outputs are produced for inspection and validation, including pressure mapping and Cp-style behaviour on the model surface, and the underlying flow fields required for diagnosis and comparison. Derived diagnostics are supported where they are meaningful to the active physics model set, with emphasis on outputs that help explain why a design performs the way it does rather than only showing that it does.
Run quality and solver health reporting is considered as important as the final numbers. Residual history and convergence reporting are used to make solution quality visible, alongside iteration and timestep statistics, warnings for stability or boundary-condition issues, and clear failure messages when a case is invalid. The goal is to provide fast answers with accountability, where a result is always paired with the evidence needed to trust it.
Aspects
Architecture
VAWSS is a GPU-native solver engine focused on keeping the numerical workload on the GPU, including the expensive parts of the solve that dominate runtime. The desktop application is designed around case management, controlled run staging, and results inspection so the workflow remains repeatable under real iteration pressure and does not degrade into manual file handling.
Data and interoperability
Case definitions are stored as JSON for transparency and version control, enabling review, audit, and run-to-run traceability. Results export to VTK for standard visualisation and downstream analysis, while JSON outputs capture coefficients and run summaries in a form suitable for plotting, comparison, and reporting.
Local execution
The system is designed to run on the user’s machine without relying on server queues or external infrastructure as the default path. This supports rapid iteration and reduces operational friction while keeping runs structured enough that outputs can be integrated into professional pipelines when required.
Functionality
VA-Dynamics supports end-to-end CFD iteration inside one environment. Users create and organise simulation cases, attach geometry, define domains and environments, configure meshing and boundary conditions, set solver parameters, then run one selected case through a controlled staging workflow that snapshots inputs into a transient run package.
During execution, the solver console provides live logs, warnings, and run status, enabling the user to see what the solver is doing rather than waiting for a silent completion. When complete, results return to the case as structured JSON and VTK outputs so the user can inspect pressure mapping on the model, review coefficients and histories, compare runs cleanly, and make the next design decision with evidence rather than guesswork.
The workflow is designed for iteration. That means runs are structured, comparisons are straightforward, and the cause of performance changes is traceable through explicit case configuration and consistent output packaging.
Features
Current implemented foundation
VA-Dynamics provides a fixed workspace layout with viewport, explorer, properties, and solver console, a cases workspace with editable properties, JSON-based case persistence, and an export workflow producing VTK outputs and structured run artefacts per case folder. The run workflow stages a single selected case into a transient run area before execution, creating a clean run snapshot and a reproducible execution state.
In active development
Development is focused on GPU-only solver execution integrated tightly with the run workflow, laminar and turbulence capability treated as a first-class path, robust convergence reporting through residual histories and run summaries, coefficient reporting exported alongside field outputs, and stronger invalid case detection so problems are flagged before a run starts rather than after it fails.
Planned expansion
The roadmap includes broader regime support where required, including compressible paths when the operating regime demands it, additional diagnostics and aero-specific reporting to speed up decision-making, and more post-processing and comparison tools focused on iteration, including baselines, run-to-run deltas, and regression checking.
Looking forward
VA-Dynamics is being built around one goal: drastically reducing time-to-decision in aerodynamics. That means a solver designed for GPU-native performance and stability, an application workflow designed for repeatability and clarity, and outputs designed for engineering iteration.
The intended result is a CFD stack that supports faster development cycles, stronger design confidence, and a workflow that scales from individual creators to professional teams without forcing a different process at each step. The long-term direction is a tool where CFD is no longer a slow checkpoint, but a continuous part of design development, with local execution and decision-ready outputs driving faster, better engineering.