What are the best practices for FEA verification of code and software?

We rely on finite element analysis tools as mechanical engineers to simulate product designs under real-world situations. However, if the programme is not thoroughly tested, the results may be dangerously misleading. Industry standards serve to verify the validity of software by specifying tight methods for code testing, comparison to analytical solutions, inter-program correlations, experimental data matching, sensitivity studies, and strong documentation. Following these consensus principles lowers errors and fosters justifiable trust in simulation results. Our quality control processes are designed to detect flaws early so that products work as intended when lives are at stake.

Verification is used to establish whether simulation software (in this case FEA software but could be CFD, multiphysics or other) performs reliably when performing in various representative, typical and known case scenarios. Validation in the other side is dedicated to ascertain whether a established simulation model works out correctly in a particular application. The same validation method can be used to scrutinize a simulation model on various software packages, indifferently. Usually, validation is conducted by comparison with empirical or traditional calculation results. The software should only be verified once and it is usually conducted by recognised bodies such as NAFEMS. Validation needs to be performed on every analysis model.

For verifying simulation software code, we use a set of benchmark verification models. These allow to check simulation software features in both isolation and combination. Bearing in mind, FEA, CFD, etc are all based in numerical methods driving from the discretization of continuous mathematical models. Hence, they do not provide exact results and code verification not only checks the code is capable to resolve a particular problem, but also to check the accuracy of the results. This way, we can say, benchmark models need to be tailored to be representative, well defined, polyvalent and commonly agreed and accepted. I would recommend visiting NAFEMS website and consulting for further info on this matter.

One key reason for the importance of verification reports is to document the extents of verification study. Verification results always comes with a degree of deviation, and this deviation area becomes more grey when we reach the borders of verified zone. Without proper and clear documentation for this extents, engineer can easily fall in false results.

We all like to press a button and get an answer without knowing much of what is going on. However, this is dangerous. FEA and other simulation software are relatively easy to use. With features such as Windows friendly GUI's, big icons, one button does everything, etc. However, you will find, the best simulation software is still that one that works with an old school MS-DOS looking GUI, code writing reliant, so you have to type in your model rather than drawing it pressing pretty icons. You can read code an know the guts of your model, debug it, etc. Otherwise, the wrong button pressed the wrong moment you could be blaming the software for wrong results and it is the analyst, more skilled in GUI's than in applied mathematics and code.