How can you stay ahead in aerospace engineering simulation?

You must know who your audience is and what they expect. A simulation tool which is only ever used by its creator is worthless. A simulation tool is most useful when it is accurate and widely adopted by a community of analysts and researchers.

Selected objectives lead to the appropriate selection of the model fidelity, scope, and accuracy. Failing to put boundaries on the expected model capabilities is often the reason for unnecessarily complex and unusable models in large-scale projects. In this regard, model should be seen as an end-product for which appropriate system engineering practices must be followed.

In addition to operational objectives, you should include your operational environmental characteristics, such thermal fluctuations, physical stress: shock, vibration and abrasion, weather, electrical power surges or limitations, containment if improbable failure could have a hazardous effect on the adjacent properties, etc. both in the simulation and component material selection. And in all great designs post experimentation: built in redundancy, margin of safety, and risk management considerations depending on the reliability figure you hope to achieve.

In many scenarios, it is helpful to use multiple tools during different stages of the project. In the early days of a project, you can typically use a low-fidelity software package to get rough estimates of your design or analysis. These software packages are usually cheap, easy to use, and fast. In later stages of a project, the software's fidelity must increase, to increase the accuracy and reliability. High-fidelity software is often more expensive and take longer to run. However, in the later stages of a project, more resources (monetary and/or computing) can be allocated.

The governing equations for a simulation model are almost always differential equations. A good verification method for differential equations that are deployed in a computer environment is to come up with an analytic solution where possible and compare that with the numerical solution obtained from the computer implementation. Validation, on the other hand, should always be performed with test data obtained from the real system in question. Simulation results should only be trusted around the validated scope of the model.

Documentation of your test criteria, component design version control, environmental conditions and integrated system component version is a key component to any good verification test. Often as your product evolves, varying results need to have stable foundation of understanding to truly interpret your results. Without good documentation and validated test setup, lengthy test scenarios could long term end up being a waste of processing time or lead to more missteps and confusion.

I'm totally in line with what Mr BURKE states. On my experience I'd like to add something more. About "early days of a project". I'd like to highlight the role of analytics particularly when reinforced by sw like MathCAD or SMath. We dispose a huge amount of technical and scientific article from the past and more recent. Some methods and tools that required language coding ability and not-common calculation power can be easily handled now by a laptop; add that a lot of this technical/scientific bibliography is free together with Open source sw. They allow a first, fast "fencing" of the problem, simple trade off studies, and a good "grasp" of physics and models. Then, you can go further in details with more sophisticated FEM methods

Moel validation highlights the importance of a research team. Modelers typically do not collect the experimental data which is used to validate their models. Experimental analysis is most often performed by a different experimental team. This means that the modelers and experimental teams must have trust and good communication to understand exactly what type of data needs to be collected when validating a model.