FEA can tell us many things, but integrated test and simulation programs are the only way to effectively develop products, writes Laurence Marks
I thought I’d round off this series of articles with a piece on actually making simulation work in reality. Too many people think that simulation techniques are about pushing an ‘improve my design’ button, but simulation software doesn’t just radiate goodness like some form of information age fairy godmother.
So far we’ve looked at various approaches and techniques, which can be used to represent what happens to components and systems when they are used. And for all the incredible benefits, all these have one huge shortcoming.
They are only as good and relevant as the input data, assumptions, guesses and prejudices which are their very DNA.
In fact it has been said (well I think it has been said, but as usual Google has failed to come up with the goods) that the only function of a numerical model is to reinforce the prejudices of the person that created it.
We’ll concentrate on finite element models for a while.
So the first useful thing we can do is to try and visualise what an FEA model actually is. { fig.1} shows in conceptual terms what an FEA model is all about.
A continuous body is represented by a series of spring stiffnesses, and where these spring stiffnesses connect to each other we can calculate deflections.
These calculation points are the only places in the model where we can apply loads and fixings. We calculate stresses by working out what has happened to the small sub-regions bounded by the springs stiffnesses.
The effectiveness of the process is governed by how well the springs represent the structure, how well our assessment of the restraints represents how the structure is actually fixed, and how well we’ve interpreted the loads If we focus more closely on the springs we can learn a lot.
Robert Hooke, the great unsung hero of English technology, said that the deflection of a spring was proportional to its stiffness and the load applied to it. And at a time when witches were still being burned at the stake, that was pretty impressive. But many of the materials we engineer with simply don’t obey that law – not that on-line material databases acknowledge that very often. In fact much of the information is contradictory.
Use one piece of information and you’ll get one answer, use another piece and you’ll get a very different one. So you need enough of a material definition to get a sufficiently accurate answer, but you don’t want a PhD.
But the 64 million dollar question is “how do you know that your model is rigorous enough?” We’ll leave that there for the moment and move on.
Anyone who read the Bob Johnson series of articles in DEVELOP3D will be aware of the importance of decently defined restraints. He’s evangelical about it, and for good reason. It’s pretty important. But again, even if you follow all the best advice on the subject, how do you know that you’re constraints nail it?
Hopefully a picture is forming. A finite element model is built up using a series of descriptions – geometry, material, loads, restraint, interfaces, physics etc, etc. And each one required an understanding, interpretation or description of what was happening in the real world – or a lucky guess at what was going on in the real world. Obviously some scenarios are easier to interpret than others.
But a series of intelligent guesses at what could be going on, is, after a good deal of number crunching, transformed into what are often staggeringly impressive graphics.
In this respect CFD beats FEA hands down. And those graphics are often pretty convincing, as well as being just pretty. And at this stage you either believe those results to be the single version of the truth, or you chose the path of cynicism.
Only one makes sense if you think about the inputs, but you’d be surprised how tough it is to convince some of our customers that the results are anything other than 100% definitive.
So you need some form of stake in the ground, or reference point, to provide something to compare the simulation results to. And that has to be the performance or behaviour of an actual thing. In the real world. Measured and quantified. Which means a good old fashioned test.
The process of making the simulation model behave like the test is a real learning experience, and the way in which the engineer and designer learns what really makes the thing tick; what and what isn’t important. It’s the IP of the design from a functionality point of view.
Not surprising then that the NDA [Non Disclosure Agreement] is common currency at FEA consultancy companies.
I’d always thought about rounding off this series with a piece on the Simulia Living Heart model. This is a seriously advanced model, which needs the power of both Abaqus and a multiprocessor machine to run. But the point is that for all its impressive behaviour the model only makes sense in the context of a team of engineers and medics working together.
Anyone who has ever worked in a team which is made up of doctors and engineers will appreciate that critical review and a focus on delivering useful data is never far from the top of the medical agenda. Doctors, in my experience, seem largely immune to the blinding effects of high-level graphics.
About 10 years ago I had an idea, which I am now, depressingly, seeing being presented at conferences. Rapid prototyping is revolutionising small batch production of parts. So why can’t RP techniques be used to accelerate product design by accelerating the
progress around the simulation test loop?
Surely this is a critical way ahead – there are many, many issues which need to be solved, but I’m pretty sure they can be, with the net result that product development cycles can be further reduced.
So what’s my elevator pitch here? Simply that simulation only makes sense in a world where there is, or has been, sufficient testing.
Perhaps in some silver suited future, where we can model every atom and molecule of a structure, we won’t need testing, but now integrated test and simulation programs are the only way to develop products. And before anybody else does I’ll mention the no test programs, which, where they are a reality, are only that because they have built on years and years of test data already in the vault.
We need to accept that, at the moment, simulation delivers better testing of better products, which we understand more. That has to be better than a simple “make it better button”.
