Today I wish to discuss what things can influence the outcome of *stability path* method in a negative way. As I wrote before, *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 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, 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 threw 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 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 analysis definition can be divided as follows:

**CRITICAL ERRORS:**

**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**This can happen to almost any model, but will be most important in situations when a drastic change in*increments*or solution strategy:*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.

**LESS CRITICAL ERRORS:**

**To few**this is especially true if an*steps*(*increments*) were set:*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.if to few*Convergence*problems:*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 cover most common mistakes in nonlinear analysis definition. I will try to describe how to avoid them in future.

Have a nice day!

## Leave A Comment