Today I wish to discuss what things can influence the outcome of the stability path method in a negative way. As I wrote before, a stability path is a tool, that uses outcomes from analysis steps (or increments) you have defined and computed for a given model. By itself, it only presents results in a certain way (to those of you who are in Europe it may be worth to know this concept is acceptable by the European Civil Engineering Code and is described in EN 1993-1-6), but the outcome of the analysis may be faulty in several different ways.
The most commonly known problems concern “wrong input”: It is obvious to anyone that if the Boundary Conditions, Loads or Contact Definitions are wrong, the outcome of the analysis will be incorrect. Mesh can also strongly influence the outcome, as well as element type, but this specific topic will be covered later on. Different methods are used in order to avoid “wrong input”, but of course, from time to time, something will slip through in the first version of the model. This is why I do an LA and LBA analysis at first. This allows me to see if the model behaves correctly and most of the mistakes I have made so far were caught at this stage – it is beneficial to do this since LA and LBA calculations take only a short time to compute: time well invested if you wish to verify the input. But apart from the possible mistakes I listed above, there is also one possibility far less described in manuals I think:
Wrongly defined analysis
If your input data (model geometry, loads, BC, etc.) is perfect, the task can still be badly defined. In nonlinear analysis, especially if stability issues are possible, correct settings for the solver are crucial. Some errors in that regard will be of small significance and others will be far more important. Basically, the errors in the analysis definition can be divided as follows:
Geometrical nonlinearity on / off: sometimes we will want to run a geometrically linear analysis and sometimes that non linearity will be important. Usually this is set somewhere in the analysis definition (in contrast to material nonlinearity that is defined in material properties). I think this makes it easier to “forget” about it, but also such a mistake is harder to find, especially since geometric nonlinearity is more subtle than material nonlinearity and its influence is harder to spot in the outcomes in many cases (even threw the influence itself can be very big).
Load type and solution method mechanisms: This problem usually concern shells (or other structures with specific stability paths). In stability path for shells after instability failure shell actually decrease deformations a bit in order to follow it’s stability path (as shown below). Sometimes this is not possible (i.e. in laboratory tests where you use hydraulic press for enforcing displacement shell won’t be able to “lift” the press, which means that there will be a different stability path – in such cases arc length method should not be used.
Wrongly defined increments or solution strategy: This can happen to almost any model, but will be most important in situations when a drastic change in stability path is occurring during the analysis. If the increment you have defined is too big, or the solver can “speed up” analysis by increasing increment automatically sometimes you can either “jump over” bifurcation point (and resulting capacity will be too high), or you can “fall below” bifurcation point (and the resulting capacity will be to small). Example of this mistake is shown below, note that each point on the curve is an increment (also called step) – if there are to few points the curve might not catch a proper shape.
To few steps (increments) were set: this is especially true if an arc-length methods are used (and those are very often used in stability problems). In arc-length and other methods we only indicate how big should the first increment be, and later solver adjust the size of increment automatically (based on defined criteria). If we reduce the maximal number of steps (in Nastran for nonlinear analysis in SOL 106 the default maximal increment amount is 20, which is very small), then the solver may not reach the point at which the capacity failure will occur, and we will not know what the outcome is. This however will be clearly see on the stability path (the curve will only rise), so this is the easiest mistake to spot, and only wastes computing time as we have run the analysis again, or at least restart the previous one from a last increment.
Material nonlinearity on/ off: this is a mistake that can lead to huge differences in the outcomes but after first glance, at the outcomes it is easy to spot that something went wrong. If by mistake linear elastic material was used, it usually is very apparent in the results so rarely mistakes will have effect. This is why I decided to put in in less critical errors – you will notice the mistake easily and only loose computing time for a second run of the analysis.
Convergence problems: if to few iterations are allowed for each increment or wrong solution strategy is chosen calculations may not converge at some point, meaning that no outcome will be given for specific increment and analysis ends. Of course if convergence failed before model reached a state that interests us, than we will have to tweak the settings and re-run (or restart) analysis wasting some computing time.
Wrong output request: sometimes we wish to calculate a certain aspect of the model (i.e. strain energy) – if we forget to set into output request that this should also be calculated, a re-run of the analysis will be needed.
I think this list covers the most common mistakes in the nonlinear analysis definition. I will try to describe how to avoid them in the future.
Have a nice day!
Want to learn more?
This is awesome! I’ve prepared a special free FEA course for my subscribers. You can get it below.
I have over 10 years of practical FEA experience (I'm running my own Engineering Consultancy), and I've been an academic teacher for a decade. Here, I gladly share my engineering knowledge through courses, and on the blog!