markstock
markstock on Hacker News
The (typically government) agencies that pay for these scans create specifications for the data to meet. This is not hard to find. IIRC the accuracy is generally less than 0.1m (though the precision is usually 0.01 meters or feet).
But IFS and L-systems don't help explain the phenomena (the "how"), just its expression. Fractals are not a building block, physical forces are. Where one or more physical forces are dominant over a range of spatial or temporal timescales, self-similar behavior can result.
I have no problem using the word "fractal" to communicate these shapes, but I'd like folks to realize that fractals are not a force, not a goal of nature, and do not answer "how."
This seems very related to adaptive meshing algorithms, for which there are many naive formulations, and not all are intractable.
Yes, the simpler versions were discovered earlier. The point that my brain wanted to make was that the article, like so many others in science communications, omits parts of the story that would make present discoveries seem less groundbreaking. There was an underlying assumption in the article that Navier-Stokes is all we use, and until this research, we didn't have anything better. Yet drag on satellites, nanofluidics, shock waves all benefit from the extra terms Boltzmann gave us. It adds extra context and would not have been difficult to mention.
It's a little weird to talk about the origins and our understanding of the Euler and Navier-Stokes equations and not mention that they are both truncations of the Boltzmann equation from gaskinetics.
You just reminded me of a great feature that I think I first noticed in The Gimp: you don't have to search through the list of file types when exporting (I almost typed "saving"!), just type the extension in the file name and it'll save in that format! Love that part.
It's when I want to close the image or the application - the extra click to confirm that, yes, I am aware this image was not "saved" and that I could be losing data. I admit I have not looked into whether I can disable that extra notification.
Now that it's not late at night I can see a mistake: the primary benefit of regularization in nbody methods (self-influence being zero and not infinity) is stabilization of the dynamics. A close pass will not send one or both particles shooting out into the void with excessive energy.
The second advantage is removing the conditional in the inner loop.
And Gimp users are not more likely to know that? It adds up to extra clicks for 90% of the images I load.
The tweaks that SW included are pretty common to similar simulations:
1) the attraction-repulsion pair is typical of "boids" simulations, and also features in the Lennard-Jones forces acting in atoms (albeit with different powers on the decay rate);
2) making the force drop to zero for particle-particle distances approaching zero is effectively treating each particle as a "cloud" and not a singular point, it's called "regularization" in vortex particle methods and "Plummer softening" in gravitational methods; it's primary benefit is with SIMD and parallelization by removing the need for a (i != j) conditional; and
3) slow contraction (multiplying each particles' position by (1-epsilon)) is a technique used by generative digital artists to ensure that visual activity does not stray too far from a directed point.
The unique component of this simulation is the (computationally-efficient) dependence of a very small number (N=2 here) of neighbor particles. The typical O(N^2) that limits real-time simulations to 10k-50k particles becomes O(N).
The nice thing is that every gpu is like a little distributed-memory machine, and programming it for optimal memory locality (registers, shared, global) and bandwidth is an essential skill. One step up is using multi-node distributed memory machines, which you could set up at home with openmpi, but is often easier to get access in an academic setting. In short, learn how to use CUDA and MPI. That's my personal take on "HPC", though obviously it can mean different things to different people.
The author is spot on. As an HPC performance engineer and computational artist, I could tell numerous stories about it, but I'll summarize three:
The common method for evaluating MPI performance on a supercomputer is with the OSU microbenchmarks, and with the -z option will print tail latencies. These are far more useful values to predict real-world performance on the big machines.
Second, while means DO say something useful, they are the top part of a profiling hierarchy. Deeper levels are sampling experiments (with minor effects on performance) to tracing (potentially larger effects on the code being measured). Seeing parallel timeline traces of a complex app has helped me and my team debug many performance problems. Look at HPCToolkit, Score-P, rocprof, and other tools.
Lastly, the reason I do computer artwork in the first place was because of a bug in an old fortran77 code which simulated turbulent mixing in 3d. I couldn't find our code mistake at first, but then I visualized the computational elements with a raytracer I had been playing with, and the result was not only shockingly beautiful, but pointed me to the line of code with the bug.
Please don't call this "full N-body dynamics" if only the outer planets are involved in the integration.
My go-to rule that's held since 2008 has been that a GPU can do about 10x the math that a similarly-priced CPU running properly optimized code can.
My 5070Ti can realize about 20 TF/s while a 12-core Zen5 can do 2.
There have been polls. The AI hate thing is almost exclusively a USA thing.
Generative artist here: the beautiful thing about this exploration is that these techniques can be applied to ANY vector field, whether they originate in random noise or global simulations.
The reason these add so much visual interest to a simple noise function is that each pixels color now relies on many more of the random values. Generative art blossoms with this extra computational effort.
Yes, I do 4th order interpolation (M4') on the GPU. This paper is for 3rd order, though, but the methods may extend.
I suppose because the fetches are generally to similar memory regions, there may not be a substantial performance improvement due to L1 and L2 hits on recent GPUs.
I should add that this is a major "tell" for detecting when an app uses the Stable Fluids method: obvious mass loss (and very viscous, energy-dissipating flow).
People who run WSL are not normal users. The filesystem problems make Windows+WSL feel like a Trabant when you're used to a Porsche.
Because Windows is the operating system of Not Getting Fired. Fear is a stronger motivator than creativity or productivity.
On the other side, I am a lifelong Linux user, and even with advanced LLMs, trying to get Microsoft Windows to behave sanely takes hours every month for years on end (thanks, day job). Things Linux figured out in 2003 are still magic or completely undoable on Windows.
Before you go adding vorticity confinement, consider performing a higher-order backward advection scheme (Runge-Kutta 2nd or similar), and using a higher-order interpolation method (triangle-shaped cloud instead of bilinear).
In my implementations I use 4th order for both and vortices stick around a lot longer.
You are correct: Stable Fluids extends to 3d relatively easily.
One of the nice aspects of Stable Fluids is that you don't need to iterate the pressure correction terms to convergence. Just run a fixed number of Jacobi or Gauss-Seidel sweeps and keep performance consistent. The only drawback of this is some mass loss in areas, which for the present purposes is acceptable.
Then you want Foundations of Multidimensional and Metric Data Structures by Samet. Unless you already have it, then enjoy some pretty (organic) trees.
Sure, I usually measure performance of methods like these in terms of FLOP/s; getting 50-65% of theoretical peak FLOP/s for any given CPU or GPU hardware is close to ideal.
Quadtrees and octrees are themselves quite deep research areas. If the acceleration data structures interest you, I highly recommend Hanan Samet's book "Foundations of Multidimensional and Metric Data Structures". It's from 2006, but is basically the bible for the field.
Note that even without an acceleration structure ("direct summation" in N-body research terminology), a CUDA program or GLSL shader program can exceed 60 fps with 10,000 to 20,000 particles. And a parallel, C/C++/fortran vectorized CPU code can do the same with over 5 thousand.