The "Usual Suspects"

by Tony Abbey, FE Training

I have been living in the US now for 13 years and occasionally I get a little nostalgic for the TV shows I grew up with in the UK. I found a DVD catalogue which included what in the US we call Cop Shows. The English vernacular I remember is Police Dramas. I ordered some old favourites such as “The Sweeney”, “The Professionals” and even an extraordinarily dated “Dixon of Dock Green”.

As I sat through a few it struck me that there was often a common stage in the plot line. If a bank had been robbed, security van hijacked or similar knavery, the first thing our heroes did was to arrest the ‘usual suspects’. The thinking is pretty logical; if somebody’s going to rob a bank they have probably done it before. Police dramas are somewhat telescoped in time. We need a solution within an hour - or if it’s a special show at most 90 minutes.

I’m sure real policemen cringe at some of the procedures but there is probably merit in the ‘usual suspects’ theory. In FE Analysis we don’t have many crimes but sometimes things do go dramatically wrong. The solution fails to run or we get dubious answers. 

I spent many years working on FEA help desks with problems ranging from straightforward to very obscure. However, we adopted the same tactic as the shows; look for the ‘usual suspects’ first before diving in too deeply.

If we assume that we have done all the set up checks required in the building of the model, but the model fails to run then we go to diagnostic mode. The diagnostic errors from the analysis are the starting point. Over the years diagnostic messages have evolved from raw ‘developer speak’ to formats that are more understandable and can give a good indication of what went wrong and how to fix it. However it’s difficult for any FEA code to identify from an isolated numerical error what is going on in the model. It would take a dedicated diagnostic tool to give better insight, taking clues from many aspects of the model and able to run auxiliary analysis checks. The result is that sometimes we need this ‘raw’ form of message. The trouble is it takes a lot of experience to decipher it!  If we get stuck, then this is where the ‘usual suspects’ come in, we quickly run through a fixed list, ignoring the message.

We are in a similar position when a modern car breaks down. There are all sorts of sophisticated diagnostics available – but we just aren’t experienced enough to understand them. However what we can do is to check some basics; is there fuel in the tank and oil in the engine, is the battery flat, does the engine crank, can we smell fuel as it cranks – and so on. Based on these ‘usual suspects’, we can identify some problems and deal with them. Last year I was convinced I had an electrical failure and called for road side assistance. I went through all the obvious again, then I noticed - I was trying to start the car in ‘Drive’! I was able to cancel before the tow truck arrived and avoid an even more mortifying experience.
I am going to issue a challenge in this blog – send me ideas on what the ‘usual suspects’ may be! 
Here is one to be going on with:
Constraints missing?

• Symptom: Rigid body modes, singularities.

• Identification: It is quick to look at the analysis file and make sure they are listed – with valid cross reference ID. Otherwise we can look in the pre-processor visually and in the entity listing.

• Further Identification: – run a Normal Modes analysis to find incomplete constraints.

• Fix: Put correct constraints in or correct cross referencing.

• Probable Causes: Forgot to hit ‘apply’ button in pre-processor after set up. Incorrect cross reference IDs. Forgetting parts. Forgetting 1 or 2 global DOF. Or just had a bad day and forgot altogether!

If we can build a good list perhaps you can emulate the cop shows and debug the FEA problem within the hour, including advertising breaks!

Until next time,

Regards,

Tony

View all blog posts