PhiFlow: A Differentiable PDE Toolkit That Runs on NumPy, PyTorch, Jax and TensorFlow
A differentiable PDE solving framework for machine learning
At a glance
- What is it?
- PhiFlow is a Python simulation toolkit whose selling point is that the same solver code executes on four backends and stays differentiable end to end. It is a research instrument, not a production CFD package, and the README leaves several operational questions open.
- Who is it for?
- Adopt PhiFlow if your work needs gradients to flow through a fluid or field simulation into a learned model, and you are comfortable reading example notebooks rather than a formal reference. Do not adopt it if you need a validated production CFD solver, a stable plugin API, or a documented deprecation policy.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 61 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap PhiFlow fills: gradients through a solver, not around it
Most simulation code is written to produce a trajectory and stop. If you want to train a model that controls, initializes or corrects a physical system, you need derivatives of the simulation output with respect to its inputs, and classical CFD codes do not provide them. PhiFlow is built for that case. The README describes it as an open-source simulation toolkit built for optimization and machine learning applications, and states that close integration with machine learning frameworks lets it use their automatic differentiation functionality, making it easy to build end-to-end differentiable functions involving both learning models and physics simulations. The intended user is a researcher who already writes PyTorch or Jax and wants a fluid or field solver that participates in the same autodiff graph. It is not aimed at an engineer who wants a mesh generator and a turbulence model to hand off to a cluster job.
One solver, four backends, three discretization families
The architectural decision that defines PhiFlow is backend abstraction. The README says the toolkit is written mostly in Python and can be used with NumPy, PyTorch, Jax or TensorFlow. The same simulation code is therefore portable across tensor libraries, and the choice of backend determines whether gradients are available at all: NumPy provides none, while the other three supply autodiff. The repository is not limited to one kind of discretization. The README organizes examples into three groups. Grids cover incompressible flow cases such as a lid-driven cavity, Taylor-Green vortex, smoke plume, wake flow and a multi-grid fluid example, plus scalar problems including Burgers' equation, reaction-diffusion, waves and heat flow. Mesh examples include a backward-facing step, heat flow, mesh construction and a cylinder wake built with GMsh, which indicates a finite-volume path on unstructured meshes. Particles cover SPH, FLIP, streamlines and terrain. Backend portability and discretization breadth are separate claims, and the example listing is the only evidence the README offers for the second one.
Getting it installed and selecting a backend
The package is published on PyPI as phiflow, which is the name to use in a pip command. The README does not print an install line in the material available here, but the PyPI badges for Python versions and licence point at that distribution name, and the Colab badge links to a Fluids tutorial notebook under docs/Fluids_Tutorial.ipynb. The practical question after installation is which tensor library is present, because PhiFlow delegates numerical work to it. Installing phiflow without PyTorch, Jax or TensorFlow leaves you with the NumPy path, which the README lists first but which cannot supply gradients. A Colab notebook is the lowest-friction way to see the API in use, and the tutorial notebook is the one the README itself promotes. What the README does not give is a configuration reference: there is no documented list of config keys, no environment variables, and no statement about how a default backend is chosen or overridden. I cannot confirm from this material how backend selection is expressed in code, so treat that as the first thing to establish from the documentation site rather than from the README.
Where the documentation stops
The README is a gallery. Its dominant content is a set of linked example pages with figures, organized by solver family, and the prose sections are short. There is a documentation site at tum-pbs.github.io/PhiFlow, referenced throughout the example links, but the README itself does not describe the numerical schemes, the time integration, the pressure solve, or the accuracy of any of the listed cases. For a framework whose value proposition is correctness of gradients through a PDE solve, that is a real gap. A user evaluating it cannot tell from this material whether a given solver is first or second order in space, what boundary condition types exist, or how the differentiable path handles the linear solves that incompressible flow requires. The example pages may answer those questions; the README does not. Budget time for reading source and examples, not just documentation.
The wrong tool for production simulation and for non-Python pipelines
Two boundaries are visible in the material. First, PhiFlow is a Python framework with a machine learning orientation, so a team that needs a validated solver with a support contract, certification evidence or a long-term API guarantee is looking at the wrong project. The README makes no accuracy or validation claims, and the example list is a demonstration set rather than a verification suite. Second, the reliance on Python tensor libraries means the deployment story is whatever those libraries offer. If your production constraint is a C++ or Fortran solver embedded in an existing simulation codebase, adopting PhiFlow means introducing a Python and autodiff dependency into a pipeline that was not built for it. A third limitation is version churn: releases 3.2.0, 3.3.0 and 3.4.0 landed between December 2024 and August 2025, roughly every few months. That cadence is normal for research software but it means pinning a version in any long-running experiment, and the material gives no deprecation policy to plan against.
How it differs from a conventional CFD solver
The natural comparison is with an established open-source CFD package such as OpenFOAM. The difference is not accuracy or mesh handling; it is what the software is optimized to produce. OpenFOAM is built to advance a discretized flow field forward in time on large meshes, with a mature case-setup format and a long history of validation, and it has no autodiff path through the solve. PhiFlow is built so that the solve itself is a node in a gradient graph, which is why it offers four tensor backends and why its examples include optimization-flavored cases such as moving obstacles and variable boundaries. If your question is how a shape performs in a flow, either tool can answer it. If your question is what shape minimizes drag, and you want that answer from a gradient rather than a parameter sweep, OpenFOAM gives you the sweep and PhiFlow gives you the derivative. That is the whole trade: you accept a younger, less documented solver in exchange for differentiability.
Maintenance burden and licence terms
PhiFlow is MIT licensed according to the repository metadata and the licence badge in the README, which is permissive and permits commercial use and modification provided the copyright notice and permission notice are retained. That is a summary of the licence identifier, not legal advice; read the LICENSE file in the repository before shipping anything. The maintenance picture is active: the default branch is master, the last push recorded is 2026-07-16, and three minor releases appeared within about eight months. For a research group this is healthy. For a product team it means the upgrade cost is real, because a minor version bump in a framework that wraps four tensor libraries can change behaviour when any of those libraries changes. Pinning phiflow to a specific version alongside pinned tensor library versions is the only way to make an experiment reproducible, and the material does not indicate that the project publishes a compatibility matrix for backend versions.
Editorial conclusion
Adopt PhiFlow if your work needs gradients to flow through a fluid or field simulation into a learned model, and you are comfortable reading example notebooks rather than a formal reference. Do not adopt it if you need a validated production CFD solver, a stable plugin API, or a documented deprecation policy. Before committing, install phiflow and confirm which backend you can actually run on your hardware, check whether the example you intend to copy uses the grid, mesh or particle solver, and read the licence file in the repository rather than relying on the badge, since MIT terms govern redistribution of anything you build on top of it.
Community notes