Sometimes you cannot avoid being successful, despite how hard you try. However, if you carefully follow these 10 guidelines, failure is almost unavoidable. Moreover, you might even be lucky enough to drag along all people working with you. So if you have the ambition to fail at whatever CFD project given to you, make sure to follow these guidelines to the letter.
1: Do not invest time in learning the basics of CFD
Do not read any book, paper or even Wikipedia page about CFD. This is a waste of time and you even risk learning something which could be beneficial for your project. Instead, blindly trust the default settings of the CFD simulation software. This way, you increase your changes in obtaining unphysical results, or even better, no results at all e.g. caused by the violation of the CFL criterion or similar.
2: Refuse all simple test cases
If someone asks you to compute a laminar flow in a tube, say: ‘no need to do this, we have an analytical solution for this! Why waste CPU time?’. Indeed, you should NEVER compare your simulation results with analytical solutions. If you do, there will be no excuse for your if your results do not match. Worse, you might even find bugs in your settings or code. It is better to avoid this and to stick only to complex turbulent flows where you can say when CFD results do not match experiments: ‘hmm, probably, this is due to the fact that the smallest scales of turbulence were not really isotropic!’.
3: Never do CFD with small meshes
Always remember: you can completely fill any machine by applying extensive mesh refinement. So please, make use of this fact and never do CFD with small meshes. Start right away with the largest mesh that can fit on the machine. This has multiple advantages:
- The simulation will take much more CPU time so that running tests will become very time consuming.
- This will also slow down the machine so that the other users will also have problems to work. When this happens, don't forget to request access to special batch queues for you so you can completely block the machine with your runs.
- Large meshes require more storage space. So if you try real hard, you might even be able to fill the hard drives too.
If enough users behave this way, you cannot only be sure to fail but also help the whole team to fail!
4: Do not organize the files and directories where you run the code
Use as few directories as possible to organize your file, and certainly do not write anywhere what you do or why or what the results are. The unique directory is great: this way, the results of run N get erased or, even better, get mixed with the results of runs N-1, N-2, etc. And please, do not use explanatory names like ‘Velocity_at_point_1’. The name 'A000001' is much better. Imagine how nice it will look to have almost the same names for all files. Instead of 'A', you can also use ‘TOTO’ as a name but I recommend ‘NEW’.
5: Do not invest time in post-processing tools
Do not write scripts that make post-processing fast, simple or consistent. Instead, customize each figure by using different zooms, colors and scales on each figure. If possible, never inspect the output of your simulations. This could show you a big problem at an unexpected place and ways to fix the problem.
6: Plot everything in colour
When post-processing your results, plot everything in color, even y=f(x) curves. Especially green and yellow will look great on your screen. Moreover, never use symbols on your curves and never add labels, legends or titles. This way, discussions with those who could help you because they understand CFD will be impossible. In addition, it will also impede publication in journals in cases where you would have forgotten to apply the other rules of this post.
7: Always change two things at the same time in your code
If it is required to make multiple changes to your CFD code, for what reason whatsoever, it is absolutely mandatory to make at least two changes at the same time. This way, when the code fails, you will be unable to say why.
8: Never come back to a previous version
Do not save a backup on your hard drive before you start making changes to your code. This way, even if you refuse to apply guideline 7, you are guaranteed to lose lots of time when it turns out that your newer code does not work. The very important thing here is: ‘NEVER come back to a previous version!’. The reason why the code does not work now is not the lines you changed… it is the lines you haven’t changed yet.
9: Do not setup a version control system
Guidelines 7 and 8 have no real interest if you save the versions of your code or worse, if you use CVS, SVN or git. Only the feeble CFD guys need this kind of safety net. If you never save previous versions and apply Guidelines 7 and 8 with enthusiasm, your codes will, without any doubt, become total messes! After a while, they will not even compile and the best destination for them will be the trash can.
10: Never use any debugging tool
Never use any debugging tool and minimize the number of printing statements. Ideally, your code only outputs "start ... stop" in the terminal during a simulation. If you change something, start from the assumption you did it right the first time and do not check. Do not add new diagnostics in your code (like checking that you conserve global mass or enthalpy): if asked why you do not do it, say ‘well, if it was useful, the guys before me would have done it!’. All this information would only help you to understand what your code is really doing.
The content of this post is to a great extent based on recommendations on how to successfully fail in CFD, written by T. Poinsot in 2012. For sake of readability, explicit quotations are left out of the text.