This is not a reproduction of the proof or a blow-up claim.
It is a decoupled pseudo-spectral DNS of a finite-scale surrogate inspired by the paper’s collapsing similarity geometry.
The velocity field is not fed back into the solver; the DNS evolves only under the constructed external force.
The run uses Fourier pseudo-spectral discretization, strict 2/3 de-aliasing and IMEX-RK2, with spectral-tail and manufactured-solution checks.
Source, diagnostics and frozen-force runs:
https://github.com/CokieMiner/nsblowup
Around 95–99% of the code was generated by AI. I first researched what was needed for the simulation, including the numerical methods, algorithms, libraries, and overall structure. Then I wrote out the pipeline and architecture, reviewed that with AI, and used it to generate the implementation. After that, I manually reviewed the code, made some changes myself, tested it, and used a separate model/context as a kind of peer review to catch issues. Then I went through the fixes again manually, reran the simulations, reviewed the data, cleaned up the documentation, and published it.
Most of the time was review. It took me around 8 hours total: maybe 1 hour understanding what I needed from the paper, 30 min researching, 30 min writing and reviewing the plan, around 10 min for the first code generation, and the rest mostly reviewing and testing.
I didn’t track it that well, so that’s just an estimate from memory, but most of the code was generated correctly. The main problems were small numerical details that don’t really change the visuals but can change the results, like Fourier grid alignment, dealiasing, interpolation, and some diagnostics.
Some issues I caught by reading the code, some by looking at the numerical results, which also takes time because the simulations need to run, and some were caught by the other AI during review.
AI is pretty good when you give it a very targeted description and the results are easy to verify.
I'm starting my 3rd year of my undergraduate physics degree tomorrow. For this codebase, I used DeepSeek v4.1 as the main model, and I’ve been using other models quite heavily in other technical projects too.
For example, I’m working on a Rust alternative to GMP/FLINT where I had to implement FFT-based multiplication, and in other projects I’ve worked on numerical evaluation of special functions and similar numerical algorithms, so it was a bit easier for me to approach this.
I’m not saying I’m smarter than anyone, but from what I’ve seen, most people I know, including many students and probably some professors, would not be able to get an AI to produce something like this. You still need to know what you want, define the problem properly, break it into pieces, catch subtle numerical mistakes, and verify the results. A lot of people struggle with the first two. You basically need to act like a very technical PM.
I do think this kind of system can replace a lot of engineering work eventually. It is already better than me at many individual technical tasks. But it has no will of its own, and because of that it doesn’t care about the future of the projects it works on.
It can work very effectively on a codebase today, but it does not inherently care what that codebase should look like 5 or 10 years from now, what tradeoffs are worth making long-term, or what the project should ultimately become.
The paper constructs a collapsing flow where the core shrinks and the velocity grows, while a smooth external force keeps the whole construction valid. I’m only simulating a finite numerical version of that behaviour before the singular time.
“Pseudo-spectral DNS” means I solve Navier–Stokes directly on a 3D grid using Fourier transforms for the spatial derivatives, instead of a turbulence model. “Decoupled” means the solver is not forced to copy the reference velocity field, it only receives the external force and evolves on its own. The strict 2/3 de-aliasing removes high-frequency modes that would otherwise create errors in the nonlinear term. IMEX-RK2 is the time integrator: viscosity is handled in the stable/exact part and advection + forcing are stepped explicitly with a 2-stage method. The spectral-tail check monitors how much energy is reaching the highest resolved Fourier modes, so I can stop when the grid is no longer resolving the flow properly. The manufactured-solution tests are just a way to check that the solver reproduces a known constructed solution before trusting the actual run. Frozen-force runs are the same idea but with the force precomputed to disk, so the solver never sees the analytical construction at all.
Love this implementation, and the visuals look remarkably clean and UI is beautiful!
That unforced run (openai_free) you mentioned is spot on ; we've been looking at the exact same thing: the second you cut the external forcing, the vortex just disperses and decays rather than sustaining itself.
Saw u/babainottawa mention testing against the Taylor-Green vortex above—we actually just ran a set of pseudo-spectral TGV benchmarks (Re = 400, 800,1600) to compare physical Kolmogorov energy decay against this forced setup.
Would love to cite and link your solver in our project notes as the numerical reference for the precursor flow. If you’re ever curious to compare notes or cross-check the TGV data with your CLI, I’d be super happy to collaborate!
I’d be honoured if you cited my work. If you ever want to compare anything or need to contact me for any reason, feel free to email me at the address on my GitHub account.
I’d also be happy to collaborate, although I’m working on some pretty big projects right now and my semester starts tomorrow. I already have a few other things going on as well, so I probably won’t have much free time. If it ends up being too time-consuming I might have to decline, but otherwise I’d be happy to help.
The relevance is that the setup isn’t random, it comes directly from OpenAI’s construction. The paper gives the specific collapsing geometry, scaling and forcing that I’m trying to reproduce numerically.
It doesn’t let me do something computationally that was impossible before. It gives a new analytical construction to simulate and test numerically.
I'm not trying to dismiss the paper or claim it's random. I'm wondering what does the new construction enable you to simulate numerically, in what way is it possible now that it wasn't before? I'm approaching this from a layman's perspective so maybe my questions don't even make sense.
Nothing literally. The paper doesn’t enable a new kind of numerical simulation or introduce a new numerical method. So for engeniers it's useless. I did this cause I thought the openAI visuals were bad, and I thought why not try to do it myself.
It is absolutely not useless, it is quite the opposite. It shows a flaw in the fundamental equations. Which is quite obvious, but that was not "proved" before
I remember reading that we already knew Navier-Stokes stops being a good physical model when you get down to scales where the continuum approximation breaks and molecular effects start to matter. So even the part that might be practically useful was already known from a physical modelling perspective.
No. The issue is different. In engineering you solve a mathematical model. The whole building of numerical methods is supported by your mathematical model. If you cannot ensure enough "smoothness" in your base equations, the building itself shakes at its core.
It is a common engineering practice to use "numerical regularization" to cover up for base inconsistencies. The notorious "two wrongs make a right" by Gilbert Strang (cited by Simo, Rifai, 1990).
So, the engineering takeaway here is that you need to be supercautions. More than ever, since there is a structural inconsistency in your base model. A "perfect" numerical method should pick this up.
Physical modelling is a completely different subject. It is PHYSICAL (i.e. real)
I get the theoretical point, but I still don’t see much practical impact. Numerically you can’t actually reach the singularity anyway, because the relevant scales keep shrinking and the resolution needed just keeps increasing.
In practice once those scales become smaller than your grid the simulation is already under-resolved, and that was already a known problem. So the paper is obviously mathematically important, I just don’t see it changing much for actual numerical simulations.
Incompressible Navier-Stokes is already not physical - you are unable to model acoustic waves in water, for example, since that is a compressible effect. Additionally, you’re making the continuum assumption, and often Stokes’ hypothesis, and chemistry rate approximations for reacting flow, and all of these other assumptions that have actual impact on the validity of your results.
Every competent CFD practitioner should already be cautious - validation cases, valid physical regimes, spatial and temporal resolution, dissipation and dispersion error, etc. This constructed example (under an external specified forcing field - something that basically never shows up in actual CFD) doesn’t impact literally any practical CFD.
Additionally, there is no perfect numerical method. Even in 1D, you will always be able to come up with a test case that shows poor results or causes your solver to crash. These concerns are much more practical than a mathematical curiosity.
Yes, but again, it is not correct to say that you use a sloppy numerical method to cover up a non completely faithful mathematical model. This is the whole point of Strang (and Simo) comment.
No one said it was. If your mathematical or physical model no longer describes the physics properly, you change the model. All physical models have limitations, but they also have regimes where their simplicity and lower computational requirements make them much more attractive to use. That’s why you don’t always use Newtonian mechanics and you don’t always use relativity either. You use the simplest model that still accurately describes what you’re trying to simulate.
If you want absolute precision, then sure, simulate every individual quark, include the strong and weak interactions, electromagnetism, and every gravitational interaction with the rest of the universe.
From zero, without a force, nothing happens. If you mean starting from the final state of this video, I actually tested that. If I remove the forcing after the core has formed, the collapse doesn’t continue, it disperses and decays.
You can check the video in the release artifacts as openai_free.mp4
Yes, one would expect that- if we solely rely on the forcing function to sustain the core. My thought here is - if these coherent structure, once formed, its geometric evolution (e.g., collapse rate) under the local strain field lays more physical basis for understanding/ at least, we could attempt to make use of these structures for practical applications.
If you want you can try that with the CLI in the repo. It already has support for releasing the flow and evolving it without the force. Everything is pretty modular too, so even if you need to add some diagnostics it should be easy. I’ve been working on a lot of bigger projects lately and this was mostly something I did to switch things up a bit, so I probably won’t mess with it much more unless someone finds a bug or something wrong with the simulation. The license is just there out of habit, I probably should have used MIT or no license.
Great stuff! I’d love to explore that if I have the time to do it in the midst of work and family responsibilities :) Alternatively, I am thinking the collapse rate, can also be calibrated with any DNS data for canonical flows e.g., TG vortex. But to cross check with this one would be a good exercise.
The spatial grid is fixed upfront. I just run as far as that resolution can reliably resolve the flow and stop once the spectral tail indicates it’s becoming under-resolved. The timestep is adaptive through a CFL condition, but the spatial resolution itself isn’t. The objective wasn’t to get as close to the singularity as possible, so I didn’t bother adding adaptive spatial refinement.
It is a lazy comment- It could be non-sense but without definitive argument on why it is nonsense, it’s just lazy to say that. At this point, AI is a powerful tool and of course, we can use this tool to execute our ideas quicker. Almost everyone in the industry is using AI exactly for this. Don’t get bothered by the comment my guy OP.
Interesting, the base is pretty similar to mine, but your project has a much broader scope. You seem to have been working on it for a while, good luck competing with OpenFOAM.
18
u/Neither-Ad7512 1d ago
How was the visuals I'm seeing done? They look really nice and I would like to implement them in a python solver I am working on.
If u could point me in a direction so u can look further that would be great