markstock

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.