Suggestion: Provide pure PyTorch / torchdiffeq alternatives alongside phiflow examples
First, thank you for the PBDL book — it is one of the most comprehensive resources on physics-based deep learning available.
However, as a reader with a background in mesh-based GNNs and surrogate modeling (not fluid simulation), I found the heavy reliance on phiflow a significant barrier to understanding the core concepts.
The central idea of differentiable physics — that gradients can flow through a solver because its operations are differentiable — becomes opaque when the solver is implemented via phiflow abstractions (staggered grids, boundary condition handling, etc.). The key mechanism is buried behind domain-specific APIs rather than being visible in the computation graph.
A pure PyTorch implementation of the same advection example, for instance, would make the gradient flow completely transparent:
def advection_step(d, u, dt, dx):
u_plus = torch.clamp(u / dx, max=0)
u_minus = torch.clamp(u / dx, min=0)
d_new = d - dt * (u_plus * (torch.roll(d, -1) - d)
+ u_minus * (d - torch.roll(d, 1)))
return d_new # autograd graph built automaticallyThis also makes the ideas easier to transfer to other domains (solid mechanics, graph-based simulations, etc.) where phiflow is not applicable.
Concrete suggestion: For each notebook, consider adding a minimal pure PyTorch/torchdiffeq version alongside the phiflow version, focused on illustrating the gradient mechanism rather than simulation fidelity. This would significantly lower the barrier for readers coming from non-CFD backgrounds.
Suggestion: Provide pure PyTorch / torchdiffeq alternatives alongside phiflow examples
First, thank you for the PBDL book — it is one of the most comprehensive resources on physics-based deep learning available.
However, as a reader with a background in mesh-based GNNs and surrogate modeling (not fluid simulation), I found the heavy reliance on phiflow a significant barrier to understanding the core concepts.
The central idea of differentiable physics — that gradients can flow through a solver because its operations are differentiable — becomes opaque when the solver is implemented via phiflow abstractions (staggered grids, boundary condition handling, etc.). The key mechanism is buried behind domain-specific APIs rather than being visible in the computation graph.
A pure PyTorch implementation of the same advection example, for instance, would make the gradient flow completely transparent:
This also makes the ideas easier to transfer to other domains (solid mechanics, graph-based simulations, etc.) where phiflow is not applicable.
Concrete suggestion: For each notebook, consider adding a minimal pure PyTorch/torchdiffeq version alongside the phiflow version, focused on illustrating the gradient mechanism rather than simulation fidelity. This would significantly lower the barrier for readers coming from non-CFD backgrounds.