Let’s start with a problem:

*“A ladder hangs over the side of a ship anchored in port. The bottom rung of the ladder touches the water. The ladder is 30 cm wide and 270 cm long. The rungs are 1 cm thick and the distance between them is 34 cm. If the tide is rising at a rate of 15cm per hour, how long will it be before the water reaches the top rung?”*

I’ll give you some time to think.

Got it?

If you are like me, you just went into calculation mode and tried to envision the ladder on the ship and what distance the water needs to travel etc.

Now envision the boat on the water and the water rising. What happens? Indeed, the boat, including the ladder, will rise with the tide, so it will be a long wait.

Does this have anything to do with finite element analysis? Well, not really. But I do think it is a nice example of the necessity to see the bigger picture, which is something I definitely need to remind myself of when doing FEA. Therefore in this blog I want to go through some questions that may help doing this.

**1. What is my problem?**

This is an obvious but very important question. The more specific the goal is defined, the clearer it becomes how modelling choices should be made. Only specifying the topic to be simulated is not enough; being specific on the required output and the location where this output should be measured can help when setting up the analysis. For example: the goal will probably not be to simulate an aluminum can, but to determine whether it will buckle when it is loaded by a certain amount of weight.

**2. How good does the solution need to be?**

When it is clear which question should be answered, the accuracy required tends to become more clear as well. In general a yes or no question (e.g. is the plastic limit reached under this loading?) requires less accuracy than a question that is to be answered with a value (e.g. what is the loading at which the plastic limit is reached?). Furthermore, there can be all kinds of uncertainties when setting up an analysis. The available material data may be limited, it may not be possible to measure the loading accurately or it may vary in practice, the actual geometry may differ a bit from the drawing etc. This can influence results and it is good to be aware of that: it gives an idea of the accuracy of the solution that is to be expected. This is important to know, because it does not make sense to spend a lot of effort trying to make the error in the finite element calculations very small, when it is negligible compared to other errors any way. For example: if the error on the load applied could be a factor two, the answer to the research question I can confidently make probably won’t change with a 1% uncertainty on a stress outcome.

**3. What assumptions am I making and are they causing (numerical) issues?**

Unfortunately, finite element analyses don’t always finish the way I want them to. I can then be tempted to try many different things, hoping something will work out. In practice, it usually leads to a lot of data (of which I don’t always know what is what afterwards) and stress levels rising. It tends to be more useful to try to understand what is going on, physically and numerically.

A finite element analysis always involves many approximations: the geometry is approximated in the mesh, interpolation is performed within the elements, parts can be assumed rigid (or not included at all), the behavior may be assumed to be static, etc. Often the approximations are what leads to (convergence) issues: it tends to be easier to simulate something physical than something non-physical. Therefore determining which approximations are made, can help finding a solution direction. For example: assuming a problem is static while in fact it is not, can cause convergence issues when instabilities are present.

**4. Is what I am doing necessary or even useful to reach the goal?**

So, what it basically boils down to, is that I need to remind myself to regularly take the step back and look at what I am doing: to look at the boat on the water instead of the ladder on the boat so to say. As engineers we like to solve problems so when we encounter a problem, we try to solve it (at least I do). If unexpected behavior is observed, I try to understand and/or remove it. If an analysis does not converge, I try to make it. But sometimes, the problem I am trying to solve, is not the actual problem. My problem may fail to converge, because the maximal load the part can carry has been reached. If I want to know whether the part can withstand this amount of loading, I already have my answer: it can’t, while I may be tempted to run the analysis to completion. For me, it is an ongoing process to remember to remind myself to take a look at the bigger picture, to ask the right questions to determine what the real problem is that a customer is facing and to communicate how things are going to get feedback and make good choices on which direction to take.