Some random notes on the art of debugging (of numerical codes) - Part 1
- Consistency is the key. Start small. Write 1D version first, test it and when it was OK move to higher dimension codes. It's much easier to debug in 1D than 2D. Your 2D code should do the exact same thing as your 1D code if you feed it the same emulated 1D data in 2D format. This is the same for 2D to 3D expansion.
- Try the naive test cases before running your big-bang simulation. Zero state, unit state and well-known physical special conditions are good starters. If your method is symmetric, definitely test for the conservation of symmetry on symmetric initial condition. Think about special conditions that only test a special part of your code. Be creative.
- If you are going to test the order of convergence without comparing with exact solution, that is using some sort of three level Richardson extrapolation, test the tester routine with manually coarsen data from some arbitrary fine data before accusing your code of order deficiency. I guess you don't want to measure the Golden Gate Bridge with a 10-cm ruler which takes few hours and then find out the ruler has a half-life of order 10 second and thermal linear expansion coefficient of order 10/°C, do you?
- If running your code line-by-line takes one day, it better to do that instead of 10-day clueless wandering in thousands lines of code.
- Take notes of the debugging procedure and use revision control, period
- If you are coding using
GNU tools and you are an
Emacs person, learn to use
GDB in
Emacs, it is incredibly powerful. Add
Speedbar and you are on fire.
Labels: coding, emacs, office