A Programmer's Apology

Now, consider each equation.

First, each is constructed as a separate object which can is evaluated in parallel threads. However, the transformed equations refer to the solutions of the untransformed equations, so they can't begin calculating until the first are done. The spheres are given as implicit equations which as solved by evaluating the function on a cubic lattice then root-finding along the edge of each cube. This is computationally expensive, but also embarrassingly parallelizable and subdivided into as many tasks as the computer has CPU cores. Each field lines is computed by an ODE solver. The ODE intial conditions are specified here as points distributed about a surface described by an implicit equation. As that implicit equation is solved (which itself could be done in parallel), each field line is an independent calculation submitted for threaded parallel execution. The transformed tubes and surfaces on the right are also done in parallel. The details, as with all programming, are ensuring that each calculation does not begin until the results it is dependent upon are complete, and ensuring that calculations running in parallel are truly independent of one other.

I spent last week parallelizing the code which implements this, reviewing it for race conditions arising from dependencies between components. While conceptually straightforward, the actual programming required delicate care.

How many race conditions do I see? Let me count them, one, tthwreoe.