Keep CFD Test Cases Handy

The importance of having a suite of test cases available was brought home to me again recently. I was working on a simulation of a detonation tube and began to suspect that something might be wrong with the solver I was using. What do you do in this situation?

Well, if you have a set of test cases handy, you can quickly check if the basic capabilities you need are still working. That's what I did. In this case, it looked like waves were being propagated at the wrong speeds, so I wanted to be sure that the time marching algorithms were still functioning correctly for unsteady flows.

Having been through this a time or two in the past, I have a whole set of small test cases I can run that will test one or more aspects of a solver. Because I have run these in the past, I know how the answers SHOULD look. If the new results don't match the previous ones, then I know there is a problem.

In this case, I first turned to a case I've used many times before: a convecting vortex in a periodic box. In this case, a vortex starts off in the center of a box. A uniform flow from left to right gradually pushes the vortex out the right side of the domain, but the boundaries are “periodic,” so as it leaves the domain on the right, it comes back in on the left.

I run the case just long enough that, if the code were perfect, the vortex should have cycled through the domain five times and returned to the exact starting point. Then, by comparing the initial conditions with the final conditions, I can get a measure of how much error has accumulated in the solution.

This is what I expect it to look like (a “good” result):

Density contours in a convecting vortex case

But here is what I got this time around:

Erroneous result in convecting vortex test case

Obviously something was wrong! By taking a quick look through the code (I always like to get solvers where I can examine the source code), I found that some more recent modifications to the way time steps are specified had broken some options that I often use for unsteady simulations.

Once I knew what to look for, the fix was easy. But if I didn't have the test cases handy, it would be a lot harder to diagnose the problem.

Note that the time marching algorithms were not all broken; it was only a few options. Most people would probably not have seen a problem. But my cases were broken, so I needed to know about it and then deal with it.

So what do I learn from this case?

  • Again, like it or not, verification is every user's responsibility.
  • If something looks weird, check it out.
  • Keep some test cases handy so you can check the code whenever you get a suspicious result.

  • To learn more about verification and validation strategies, head to the main V & V page

    Or, now that you have your test cases, return to the CFD analysis tips and tricks page.

    Or, head back to the Innovative CFD home page

    New! Comments

    Have your say about what you just read! Leave a comment in the box below.