Explicit and Implicit Methods and Plasticity: A Warning for Code Writers and Users

It’s time to put a wrap on our series on constitutive equations, both elastic and plastic. We’ll do this in a more qualitative way by pointing out a trap in code writing that can have an effect on the results.

We generally divide problems into two kinds: static and dynamic. With static elastic problems, we can solve the equations in one shot, although we have to deal sometimes with geometric non-linearity (especially when elastic buckling is involved.) With dynamic problems time stepping is involved by definition. When we include plasticity, because of the path dependence issue we’re always using some kind of stepping in the solution. That stepping takes at least two levels: the stepping like we discussed in our last post and load and/or displacement stepping as the load or displacement is increased. Therefore, in a problem involving plasticity, we are stepping the problem one way or the other.

But how large do the steps need to be? In the case of dynamic stepping, that problem is wrapped up with the whole question of implicit vs. explicit methods. To make things simple, explicit methods are those which take information from the past and use that in each step to predict the state at the end of the step, while implicit methods use information from both start and finish of the step to predict the step end state. Implicit methods have the advantage of allowing the model to have larger time steps, which is one reason why they’ve gained currency with, say, computational fluid dynamics models.

Probably the most popular dynamic method used for analyses such as this is Newmark’s Method, which admits both static and dynamic implementations. An example of Newmark’s Method for a simple system (a ram/cushion/pile system) can be found here. In that analysis, except for inextensibility issues (the cap not sticking to the pile, for example) the analysis was entirely elastic.

It would seem that using an implicit method would be the optimal solution for a dynamic system. However, that runs into a serious problem, as discussed by Warrington (2016):

Consider the elasto-plastic model as depicted (above). At low values of strain, elasticity applies and the relationship between stress and strain is determined by the slope of the line, the modulus of elasticity. In the elasto-plastic models considered, the reality is that the relationship between stress and strain is always linear; the key difference between the elastic and plastic regions is that, upon entrance into the plastic region, there are irrecoverable strains which take place. Cook, Malkus and Plesha (1989) observe that, in the plastic region, there is a plastic modulus, which is less than the elastic modulus and, in the case of softening materials, actually negative. They also observe that, in this region, the acoustic speed is lower than that in the elastic region…This is a similar phenomenon to that of the variations in elastic modulus and acoustic speed based on strain, which complicated the determination of the applicable soil properties.

With a purely elasto-plastic model, the plastic modulus is zero, and thus the acoustic speed is also zero. This effectively decouples the mass from the elasticity in the purely plastic region. This result is more pronounced as the time (and thus the distance) step is increased; the model tends to “skip over” the elastic region and the inertial effects in that region. Thus with larger time steps inertial effects are significantly reduced, and their ability to resist pile movement is likewise reduced.

For problems such as this, the best solution is to use an explicit method with very small time steps to “catch” all of the effects of the plasticity. One major advantage of that approach is that explicit methods allow us to dispense with assembling the global stiffness matrix, giving rise to “matrix-free” methods you hear about. That significantly reduces both memory requirements and computational costs in a model. It has also led to changing even problems we consider as “static” (like static load testing) to dynamic problems with small time steps, no stiffness matrices and long run times, an acknowledgement that, strictly speaking, there are no real “static” problems, a fact that makes many civil engineers freak out.

Chances are that the effects of this have been built into whatever code you might be using, and that you’re not aware of how your code is handing it. The wise user of numerical modelling solutions would do well to familiarise him or herself of how the code being used actually handles problems such as this and becomes a more informed user of the tools at hand.