"matrix is not positive definite"-question 1

Can you post one of the smaller models that shows the issue?

@dmapguru
Thank you for your reply.

Unfortunatly I can't share the models since they are proprietary.

What I have noticed lately is the approach that if I apply the load (Prestress + X * Design load) the solution often works. And provided that I have the correct buckling factor X the overall buckling becomes 1.0.

So I start with one of the smaller models an divide "Prestress" and "Design load" using STATSUB in the buckling analysis. The smaller model doesn't allways work and since the model is not entirely symmetric the results are not entirely reliable. But finding X with the complete model is very timeconsuming. That model has slightly more than 1 million nodes.

But when I use STATSUB the error message is quite common. For the larger models it is more or less standard. Can any ideas be drawn from that? I have done eigemmodes analysis and different static analysis's (linear and non-linear) without any unusual result.

Thank you

Thomas

If the behaviour is quite common, are you able to reproduce it on a model that you are able to share?

DG

Sorry for being a bit unclear. It is quite common for the models I am currently working on, when I use STATSUB. Other than that I have never seen this issue before.

I know what it means from a theoretical point of view. But I have no idea how to trace the issue in the model, I have tried without success. I was hoping somebody might have an idea or some useful "trick" to test.

Anyway, thanks for trying. If I can reproduce it I will certainly share that model.

/Thomas

Can you post the message(s) you are getting in the f06 file (I mean cut and paste, so I can see other information that comes with the message, like a number)?

Here are the final lines in the f06 file. I have tried setting BAILOUT to -1 but it did not work.

Thank you for trying to help

/Thomas

*** USER INFORMATION MESSAGE 5010 (LNCILS)
STURM SEQUENCE DATA FOR EIGENVALUE EXTRACTION.
TRIAL EIGENVALUE = 2.266414E+00, CYCLES = 2.396016E-01 NUMBER OF EIGENVALUES BELOW THIS VALUE = 380
User information:
This message is automatic output during eigenvalue extraction. This
can be used, along with the list of eigenvalues, to identify the modes
found. See the NASTRAN Numerical Methods User's Guide.
*** SYSTEM FATAL MESSAGE 3034 (LNNHERR)
INTERNAL FAILURE IN THE LANCZOS PROCEDURE:
M-ORTHOGONAL QR PROCEDURE FAILED TO CONVERGE. PROBABLE CAUSE:
MASS MATRIX IS INDEFINITE (MODES) OR STIFFNESS MATRIX IS INDEFINITE (BUCKLING).
USER ACTION: CONTACT SIEMENS PLM SOFTWARE CUSTOMER SUPPORT.
*** SYSTEM FATAL MESSAGE 7340 (LNNHERR)
WARNING REPORTED BY SUBROUTINE LNNDRVS (IER= 728)
USER INFORMATION: GRAM-SCHMIDT DID NOT CONVERGE.

TABLE OF SHIFTS: (LNNRIGL)
SHIFT # SHIFT VALUE FREQUENCY, CYCLES # EIGENVALUES BELOW # NEW EIGENVALUES FOUND
1. 1.0000000E+00 1.5915494E-01 0 39
2. 4.5636093E+04 3.3999643E+01 ***** 0
3. 4.7554400E+00 3.4706873E-01 4685 0
4. 1.0801588E+00 1.6541083E-01 0 0
5. 4.7554400E+00 3.4706873E-01 4685 206
6. 2.2664135E+00 2.3960160E-01 380 0

*** SYSTEM FATAL MESSAGE 7340 (LNNRIGL)
TRIDIAGONAL QL DID NOT CONVERGE.
THIS RUN IS TERMINATED. PARAM,BAILOUT,-1 MAY BE USED TO CONTINUE THE RUN.

0FATAL ERROR

It clearly says that stiffness matrix is indefinite (buckling). I do not know how Nastran works, but this is classical problem if you cannot define tension only member for cables, so you have to make sure the tension members (cables) does not go into buckling mode or/and most of the cases in tension for all types of analyses with provided stability in the system.

If you were working with SpaceGass you could define tension only members. I guess you have mistreated or did not read my post carefully on the following discussion:

saplanti,
Perhaps my reply in the other thread was unclear. The prestress in the model is based on thermal loads to ensure that the cables are always in tension. The main purpose is to give the structure a deformation for permanent loads based on measured data. I have made this analysis with non-linear methods to ensure that there are no compression in the cables.

One purpose with the buckling analysis is the get initial imperfections for the non-linear analysis and from that make a non-linear post buckling analysis. Something is making the marrix indefinite but I don't think it is the cables .

/Thomas

Whatever you do in the non-linear analysis the cables will not take any compression load with those cross sections. Even some of them relieved the load you will not be aware of it if you do not go through analyses results.

Either you are missing in your analysis or you underestimate what cables do in the buckling analysis.

You had better run a natural frequency analysis you will see what is happening. perhaps in this way you move forward.

Hope it helps.

saplanti,
I have already done a frequency analysis, as mentioned in a previous post . I can also make a buckling analysis work with only the prestress loading as well as with only the design load. The problem occurs when I use the STABSUB function to introduce prestress before I "drive" the buckling with the design load.

My worry is that for one of the fatal errors the recommendation is to contact Siemens Support. Since I can't share the model it is probably difficult to help me. So what I need help with is to interpret what exactly the error messages mean.

Thomas

So, please let us know about what they say on the issue.

If I understood Thomas' problem properly, from his initial post, it is not a problem of understanding that an instability is occurring in the model, it is a problem of knowing the cause of the instability or moreover where it is occurring. If I missed the point, please let us know how.

As you have mentioned STATSUB several times, I am going to assume we are in a context of linear buckling, i.e. SOL 105. If you define 2 SUBCASEs in SOL 105, and apply a static load in the first SUBCASE, then a METHOD= entry selects an EIGRL (or EIGB) entry in the second SUBCASE, MSC Nastran will automatically select the load from the first SUBCASE as the BUCKLING load – in other words, the second SUBCASE implicitly has STATSUB(BUCKLING)= defined to select the first SUBCASE (I don’t know what NX Nastran does). This engages an eigenvalue analysis in the second SUBCASE to solve for (K+L.Kd)U=0. K is the linear stiffness and Kd is the differential stiffness computed from the displacement solution to the first SUBCASE. L are the scale factors (eigenvalues) to apply to the applied load to obtain the critical buckling load; U are the buckled shapes. In this context, you would need an extremely large compressive load to upset the eigenvalue computation (i.e. cause a numerical conditioning problem). In buckling analysis, as Kd is fulfilling the role of the mass matrix in normal modes, this would be similar to having a very flexible structure (like a soap film) carrying huge mass distribution in a normal modes analysis; at some point the numerical procedure will break down, but only at unrealistic parameter values.

You may also define a second static SUBCASE which defines a preload for the structure. Still in the context of SOL 105, the preload will cause a linear displacement in the structure from which differential stiffness may be computed – this preload will result in differential stiffness (computed from the displaced shape it causes) that will be, in general, different from the differential stiffness Kd above, which results from the displacement caused by the buckling load. This second static SUBCASE may be selected via the STATSUB(PRELOAD)= command, so the (now third) buckling SUBCASE selects both the first static load SUBCASE with STATSUB(BUCKLING)= and the second static load SUBCASE with STATSUB(PRELOAD)= (or the other way around; MSC Nastran doesn’t care about the order of the static loads). When you do this, MSC Nastran (in the third SUBCASE) solves the eigenvalue equation ((K+KD)+L’.Kd)U’=0 – the linear stiffness has the differential stiffness from the preload SUBCASE (KD) added to it; the buckling scale factors L’ and the buckled shapes U’ will be different from the previous case that had no preload. If this preload causes the factorization of the (K+KD) matrix to yield negative factors on the diagonal, it is an indication that the preload has already (linearly) buckled the structure. You would need to solve the SOL 105 problem with the preload as the buckling load to know roughly by how much. The buckled shape might assist in indicating where the structure is buckling.

For the preload case, again in MSC Nastran (no idea about NX), when (K+KD) results in negative stiffness values on the diagonal of the stiffness matrix, an additional factorization is carried out on (K+KD) to see if this results in any negative values on the factor diagonal; if there are, the STURM count will tell us how many terms are negative and the matrix factorization module outputs the famous “THE FOLLOWING DEGREES OF FREEDOM HAVE FACTOR DIAGONAL RATIOS GREATER THAN 1.000000E+07 OR HAVE NEGATIVE TERMS ON THE FACTOR DIAGONAL” message – there will be a list of the GRID points where this has occurred; any that are negative indicate the location of the instability.

Thomas, do you have access to MSC Nastran?

DG

dmapguru,
Thanks a lot for your reply and explanation. Now I think I have a plan to solve this issue .

To answer your question, I currently don't have access to MSC.Nastran. But, as I am sure you know, MSC and NX are closely related. Most of what you write and suggest I can transfer to NX.

I am working with a cable stayed bridge and the PRELOAD is the forces in the cables. Those forces are used to give the main girders their requested geometry. When I run a buckling analysis for the cable forces alone the analysis runs fine but the first buckling factor is < 1. And after you explanation I think I have found the cause. It is buckling in secondary parts that won't influence the primary analysis, but I must stabilize that part. And when that issue is fixed hopefully the rest will work.

Thank you
Thomas