EWC Compute Adds Flow360: GPU-Native CFD via Flexcompute
Engineering World Company · Platform Build Series, No. 3
Post 1 introduced EWC Compute. Post 2 covered the full architecture and build plan. This is a focused update on a specific integration decision made this week.
Those who follow this publication will recognise Flexcompute. We covered their Tidy3D FDTD solver in the photonics context — it is the simulation engine behind the Precision with Light platform. This week, a second Flexcompute product enters the picture for EWC Compute: Flow360, their GPU-native CFD solver.
The integration is now in the codebase. Here is what it means and why it was the right call.
What Flow360 is
Flow360 is a computational fluid dynamics solver built natively for GPU execution. It solves the fully compressible Navier-Stokes equations — covering subsonic through supersonic and hypersonic regimes — with a physics model set that includes SA and k-ω SST turbulence, scale-resolving DDES and ZDES, conjugate heat transfer for coupled fluid-solid thermal analysis, rotor and propeller modelling via actuator disk and blade element methods, and Ffowcs Williams-Hawkings aeroacoustics for far-field noise prediction.
The customer list includes Joby Aviation, Beta Technologies, Electra Aero, Northrop Grumman, NIO, and Robinson Helicopter — the aerospace and advanced air mobility sector, which is exactly the engineering vertical where serious external aerodynamics simulation is a core workflow requirement.
The performance claim Flexcompute makes — 100× faster than traditional CPU-based CFD, with the ability to scale across hundreds of GPUs instantly — is consistent with what GPU-accelerated solvers have demonstrated across the board since NVIDIA’s CUDA-X infrastructure matured. It is not a marketing outlier; it reflects what happens when a solver is designed for GPU execution from the start rather than ported from a CPU codebase.
Why it changes Phase 2 timing
The practical reason for choosing Flow360 as the first active Sim Bridge adapter in EWC Compute is architectural rather than just technical.
COMSOL Multiphysics and Ansys Fluent — both in the EWC Compute roadmap — require local solver installation, licence files, and environment setup before a single job can be dispatched. That infrastructure overhead is real and it pushes the first working end-to-end simulation run into the second half of Phase 2 at best.
Flow360 requires pip install flow360 and one API key. Authentication is via FLOW360_APIKEY in the environment file. There is no local installation, no licence server, no hardware dependency. The solver runs on Flexcompute’s GPU cloud infrastructure.
This means the first end-to-end CFD run through EWC Compute — engineer uploads geometry, selects a Sim Template with principled_solve mode, dispatches to Flow360, results come back — can happen on day one of Phase 2, before any other solver infrastructure is provisioned.
The Flexcompute relationship more broadly
Flow360 is not an isolated integration. Flexcompute’s product portfolio maps across the full EWC Compute simulation domain coverage:
Flow360 covers computational fluid dynamics and conjugate heat transfer. Tidy3D covers optical and photonic simulation. Their RF product covers electromagnetics. GeometryAI — automated geometry preprocessing — is directly relevant to the Digital Twin Engine’s CAD upload pipeline. AutoInsight, their AI-driven aerodynamic optimisation product, is the solver-side complement to PhysicsNeMo’s generative mode: it will become the Phase 3 backend for generative ai_mode in the CFD domain.
The relationship is not competitive. Flexcompute is a simulation specialist building best-in-class physics solvers. EWC Compute is a platform orchestration layer building the unified interface, the AI assistant, the twin management, and the KPI monitoring above those solvers. The distinction is the same as the one between a database engine and an application that uses it. The value to engineers comes from having both.
For EWC Compute users who also run photonic simulation workflows, the commercial simplification is concrete: a single Flexcompute account and a single API key cover both Flow360 (CFD) and Tidy3D (optical). No separate procurement for each domain.
What was committed to the repository
SolverAdapter abstract interface — four async methods: dispatch, poll_status, fetch_results, cancel. The Flow360 Python SDK is synchronous, so every SDK call runs in a thread executor to keep the FastAPI async event loop unblocked.
The adapter handles turbulence model selection (SA through iLES), freestream condition configuration (Mach, Reynolds, angle of attack), conjugate heat transfer, rotor geometry, and output field selection. It maps Flow360’s case status strings to EWC Compute’s SimRunStatus enum. Results come back as scalar aerodynamic coefficients (CL, CD, CM) with convergence history and download URLs for surface and volumetric field data.
ADR-006 — “Flow360 as primary CFD solver and Flexcompute integration strategy” — (ADRs stands for Architecture Decision Records) records the reasoning. It covers the technical rationale, the strategic framing of the Flexcompute relationship, the full product-to-domain mapping, and the note on AutoInsight as the Phase 3 generative mode backend.
flow360 is now in requirements.txt alongside tidy3d, both in the Flexcompute suite block with phase annotations.
What comes next
Phase 0 closure is this week — five small infrastructure fixes that make the skeleton genuinely runnable end to end. Then Phase 1 begins: the Physical AI Assistant, which is three files and one Atlas Vector Search configuration (MongoDB) away from a working engineering copilot.
The Digital Twin Engine post — covering OpenUSD, the three fidelity levels, and why CAD-native surrogate inference changes the meshing problem — is next in the series. That post covers the most technically ambitious pillar and the one most directly enabled by the Flexcompute geometry and surrogate infrastructure.
EWC Compute — Engineering World Company GitHub: github.com/EWC-Compute-Platform Next in this series: Post 4 — The Digital Twin Engine: OpenUSD, physics parameterisation, and why CAD-native surrogate inference changes the meshing problem
Engineering World Company covers the methods, tools, and decisions behind modern computational engineering — and builds the platform to make them accessible.