Recently I’ve been motivated to come up with a list of golden rules for successful simulation projects. This is my first stab at it.
Keep your eyes on the prize: Even in the world of parallel processing and fancy graphics every simulation project, task and undertaking needs to have a target, a “raison d’etre”. What information is the model going to provide and with what accuracy? Write it down. Stick it up by your monitor. And keep referring back to it.
Start simple: If your geometry doesn’t allow you to build a simplified version of your problem it probably isn’t good enough. If there’s one thing that will send any timescales you’ve imagined, guessed or had forced upon you, spiraling out of control, it’s the inability to generate a basic, rapidly solving, model which can be developed. For a simulation project to work, the simulation engineer must be in control of the geometry, not a slave to it. You can work around bad geometry supplied by a draughtsman who doesn’t appreciate what you are trying to do, but you aren’t the master of your own destiny any more. You certainly aren’t in control of timescales.
Don’t be a show off. If it isn’t critical to getting the result you are looking for don’t include it. If your failure criterion is yield, it’s hardly worth modeling post yield behavior. Remember that every contact interface, every element that goes plastic, and every unrestrained dynamic motion could be the difference between delivering a report on time or what could be politely called “a high pressure” situation.
Be aware of what your model can tell you. And what it can’t. In a typical global model of a structure or assembly you aren’t going to be resolving the local stresses in the washers with any useful degree of accuracy. The behavior of an M6 caphead, a nyloc and accompanying washers is possibly a given, provided the load and pretension aren’t beyond general allowable limits. Don’t forget this is engineering.
If a trick made a model work in a previous study, don’t be a slave to it. This is probably “start off simple” again. But you can’t say start off simple too many times. And if the model delivers the goods, keep it simple.
Meshes still matter. However far we’ve come in pre-processing and modeling terms a bad mesh means a bad model. And bad models are generally reluctant to deliver the goods. It’s almost always better to idealise a feature away than to include it at the cost of mesh quality.
So none of this happens by accident. And not much of it can be retrospectively imposed on a project that is going wrong without an embarrassing return to the start line. So start off simple, fight to keep it simple and remember this is engineering.