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.
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, spiralling 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.
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.
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.
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.