# FEA: Changes in initial geometry cause divergence of solution

In this previous quesiton I posted, alephzero kindly noted that many of the convergence problems I was having were due to extremely high slenderness ratios that NASTRAN did not feel comfortable executing. This is all well and good, and while the accepted answer to the question indicates I may need a change in either my model or my software, I seem to have found an interesting quirk about my structure.

Consider the following two images. The following is true about both:

• The left single beam has an extremely high stiffness
• The right single rod has an area of $10^{-7}$ m$^2$
• The bottom beams are composed of $1000$ elements
• The left-most two nodes are fixed in 123456
• An angular velocity of $18 \frac{\text{rad}}{\text{sec}}$ was applied

Just because I have a thousand elements does mean I necessarily fixed the slenderness problem, but I might have made a dent in it.

In the first image, the $1000$ elements are lined horizontally and the maximum deflection is on the order of a millimeter, with a curved shape that agrees with my expectation (right-most node tries to move to the right, the rod it's connected to is too stiff to extend, moves in an arc upward keeping the rod the same length, rest of the elements conform to this new curve).

However, with almost none of the parameters changed in the second image, I get deflections of about one kilometer. All that changed was the initial geometric state, where I start with a curve instead of a horizontal line.

Does this seem like normal behavior? Naively, I would expect that changing the initial geometry slightly (the right-most node moved up $30$ cm or something from the first to the second image) shouldn't cause massive fluctuations in the deflection, so is there some modeling error I'm not considering here?

The .f06 file does complain about a few of the rightward nodes having problems in the second translational direction, and this is clear looking at the deflection, but I don't know why these nodes are having problems.

Any set of nonlinear equations may have a several mathematical solutions (and often an unknown number of solutions), some of which may not correspond to anything physical. Your first solution does appear to correspond to something physically realistic. The second one clearly isn't physical, unless the material is linear elastic up to strains of 1000 or more, but the mathematics doesn't know anything about your material behaviour.

Solving nonlinear equations is usually done by an iterative procedure. If the unconverged solution becomes physically unrealistic during an iteration, it often stays that way for the rest of the solution process.

As was discussed in the other thread, the first iteration, with the internal stresses all zero, corresponds to a linear solution, and for the curved structure the linear displacements will be huge. After that, what happens might be correct mathematically, but it isn't "engineering".

For the straight structure, any divergence from "straight" will probably be suppressed automatically on the first iteration. You then have a situation where the structure has the right order of magnitude of tension along the beam, which will give the right order of magnitude of bending stiffness, and the subsequent iterations will converge to a physically sensible answer.

It would be instructive to plot the deformed shape after each iteration for the two solutions, to see how the convergence progressed in each.

You might want to investigate what the convergence criteria mean physically for your problem. IIRC Nastran has a choice of checking the size of the displacement increments, and/or the change in internal strain energy of each element, and/or the residual loads at each node point. It's possible that your second solution has "converged" according to the criterion you selected (i.e. the default one, if you didn't specify it) but not according to the others.

I suspect the first solution would converge to the same result with far fewer elements - e.g. 100 elements, or maybe even only 10, instead of 1000. That would be another an indication that it corresponds to something physically real.

Yet another idea for a solution strategy

Since the OP has found a way to get a converged solution starting from a straight configuration of the beam, that suggests a possible way to analyse the curved beam: First do a load step that applies loads straighten out the beam, then do a second load step which simultaneously removes those loads and applies the "real" loads to the model.

To find the loads required to straighten the beam, you could apply non-zero prescribed displacements to the model (using SPC input, not SPC1) and request output of the reaction forces with SPCF=ALL in the case control. The required non-zero displacements in the input are simply the distances between the corresponding grid points in the curved and straight models.

Note that Nastran fill fail if you constrain every degree of freedom in the model - you have to let it calculate something for itself! Probably, fixing all the translations but not the rotations would be enough. If that doesn't work, you can create a dummy element that is not connected to anything else in the model, fix one end of it, and apply no loads to it. Nastran will then be happy to calculate that the other end of it doesn't move, and give you the reaction forces to all the other constraints.

• Thanks for the answer again! Two quick points - these were linear analyses. The nonlinear analysis in the first case converges to the same solution, and the nonlinear analysis for the second case immediately diverges (at extremely low load %s). Two, the convergence criteria were pretty strict ($10^{-2}$ displacement, $10^{-4}$ force, $10^{-6}$ work) for the nonlinear analysis I ran. May 25, 2016 at 16:17
• I've added a section to my answer with another idea for how to solve the curved beam model. May 25, 2016 at 20:30