About Cats2D

 

More about the project

Why do I do this?

Cats2D has come to define my professional career. It is a great code and I think I can make it much better. I view it as a demonstration of what can be accomplished by insisting on high quality numerics without compromise. I think of Cats2D like a great cathedral that is never finished. There is always more statuary to carve, and seemingly endless catacombs to wander below. I never tire of it.

Where is this project going?

There is no clear direction other than to continue working on the code and writing the documentation. There are some unfinished features, some features that are completed but could be better, and a few major features I would like to install. The documentation is in terrible shape and should be a high priority. I am starting to long for a sense of completion in which all features work properly and are documented properly, what might be considered a 'release' version.

What am I hoping to accomplish?

Uncertain. I derive great enjoyment from using and developing Cats2D myself, but it seems a waste to not have others use it. Finding the right formula is tough, though. I don't want to run a business focused on licensing the code to general customers because I am unwilling to support its use except by highly qualified candidates. I would prefer an arrangement of license plus support with a few committed partners. I can also envision an educational role for the code. It would make a great tool for teaching numerics and physics together on challenging problems. But how to bring that about is a mystery.

What are the barriers to progress?

Having to do everything myself. A small team could help me test the code, fix bugs, create documentation, and contribute to development, particularly a graphical interface to a useful mesh generator. I have years of work on my plate and it makes me impatient. The good news is that productivity and morale are way up now that I am free of the bike shedding.

What are the barriers to success?

The small pool of appropriately trained potential end users. Misguided perception of simulation is also a huge problem. I expect to write more on these issues in the near future.

How does this project relate to the current milieu in scientific computing?

What I am doing here seems to fall outside of it. It is difficult to do this kind of work over a sustained period of time in an institutional research setting. The reasons are more cultural and historical than practical, but always come back to the same thing: a failed paradigm based on separating intellectual leadership from algorithm development and hands on use. This, too, is something I expect to write more on in the future.

What are the essential skills for this kind of work?

Physics. Know it, or throw in the towel. I can't bear to review one more poor manuscript by someone running a commercial code who lacks the requisite comprehension of the physics. It sounds elitist, but fluid mechanics and transport phenomena are inherently difficult subjects. If you can't wrap your head around Bird, Stewart and Lightfoot, you shouldn't be attempting this kind of work.

Differential equations and vector calculus are critical too. You aren't going to understand the physics if you don't understand how conservation principles are cast as differential equations, or how to use classical techniques to analyze them. If you don't understand the difference between the gradient and divergence operators you are unlikely to succeed.

Numerical methods are important, but I think there is some confusion about how big of a role methods play in this kind of work. We really only need to learn the methods we are using, and most methods are fairly obvious to anyone with a decent math background. Numerical methods simply do not constitute the sort of general body of knowledge encompassed by physics or differential equations. I could teach you the practical use of the finite element method in a few months; it takes years to gain competence at fluid mechanics.

Algorithm development presents a much greater issue than numerical methods. It's one thing to understand the mechanics of Gaussian elimination on paper; it's another thing entirely to write a scalable sparse linear equation solver for modern computer architectures. Failure to recognize this is the single greatest factor explaining the lack of progress in physics-based computing witnessed over the past 25 years.

What surprises me the most?

One surprise is how much I've been able to accomplish since I started putting all my time into the project. I've written more code in the past two years than I did in the ten years prior. The more I do this kind of work the faster it goes. The whole thing used to seem hopeless; nowadays it doesn't. Another surprise is the amount of intellectually interesting findings that have popped up along the way.