dionhaefner

We thought it would be cool to be able to run GPU workloads across process boundaries from JAX and torch. Train your torch networks through Julia, C++ solvers with adjoints, or any arcane autodiff potion you choose to concoct – now certified fresh without host round trips. Bon apetit!

No idea lol. I assume it’s possible since both Enzyme and GPU programming are pervasive in Julia. Let us know if you end up trying.

Happy to take the blame for the lack of persuasian and engagement then :) Thanks for the feedback, although I’d like to believe there’s a way to have that cake and eat it too.

Indeed, just like I let my compiler write (at least) chunks of my AD logic. Not great when the tool becomes a leaky abstraction, but overall net positive don't you think?

Not naive! The answer is yes and no.

Array layout: yes, for the simple cases this post relies on. In the demo the work arrays are literally calloc'd in a C wrapper and handed straight to the Fortran routine, and it just works. (Column-major vs. C's row-major is still on you to keep straight, of course.) This wouldn't be so easy for fancier Fortran array features — allocatables, assumed-shape (:) dummies, pointer arrays — which in general get a descriptor struct (bounds, strides, etc.) rather than a bare pointer. Flang uses those descriptors much more aggressively, but I don't know how that would manifest at the C-Fortran bridge. Would be interesting to repeat the experiment with Flang (if at all possible) and comparing the pain.

Calling convention: there are well established contracts, much older than the layout story. Fortran passes everything by reference, so a double precision :: x argument is an x* at the ABI level — which is why every argument in the C wrapper is a pointer (&n_, &k0_, ...). Combine that with C-compatible name mangling (a trailing underscore historically, controllable via LFortran/bind(C)) and Bob's your uncle. Nothing here is new, the pipeline is really just leaning on that decades-old interop contract and then letting Enzyme differentiate across the boundary.

Author here — I work on Tesseract at Pasteur Labs, and I wrote this up because the "what if this was possible" was bugging me for way too long :)

I was surprised by how well this worked, the LFortran + Enzyme stack seems to be a very clean way to get gradients through Fortran code via LLVM IR transformations. Pretty cool to see a 220-line Fortran heat solver turn into ~6,900-line reverse pass automatically if I dare say so.

Would be awesome to see this applied to a real scientific codebase, and I hope that the demo is enough to convince people that it’s worth trying.

This is a case study in making gradient-based optimization (a la gradient descent) work with tools that weren’t designed for it. The goal is optimizing rocket grid fin stiffness (8 bars, 16 angular parameters), with a pipeline that includes Ansys SpaceClaim (CAD), PyMAPDL (FEM solver), and JAX. Each step needs derivatives, which means stitching together analytical adjoints from Ansys, finite differences for mesh operations, and JAX autodiff for everything else. What makes this practical is that each component runs in its own isolated environment (Tesseract), so the Ansys tools can live on Windows with their license requirements while the optimization logic runs on Linux while still being composable for end-to-end autodiff.

The payoff is watching emergent behavior: starting from random bar positions, the optimizer discovers that orthogonal grid patterns work well, diagonal lateral bars create efficient load paths, and clustering material near the attachment points maximizes stiffness. Final result is 75% stiffer than random and 24% better than a regular grid, even after adding back symmetry constraints for manufacturing.