5 Replies Latest reply on Aug 8, 2017 3:41 PM by John Willett

    Please Translate: "Equilibrium is not achieved.  Results are saved up to the current iteration."

    John Willett

      I'm running SW Premium (so only linear static simulations), either 2016 SP5.0 or 2017 SP3.0, and getting this error message after a long simulation using the Intel Direct Sparse solver.  I won't go present the model because it's a complex assembly with many contacts, both bonded and no-penetration, and I'm just looking for general guidance.  I don't understand what iterations it's talking about with a direct solver, although perhaps the iterating occurs when solving the contact constraints?  What does this message really mean?


      A few details seem particularly relevant:


      1) I've carefully checked all of the fixtures and contact conditions, and I'm convinced the model is properly restrained.  Both the Interference Detection and Contact Visualization Plot tools agree that the contacts are where I think they are.  I've also tried to provide adequate mesh density on all critical contact areas.  In any case, there's no explicit complaint about large displacements or insufficient restraints.


      2) The only external load is gravity, one part is fixed, and all the others are either bonded or restrained with surface-to-surface no-penetration conditions, but there are (quite stiff) springs that allow (very slight) sliding along three of the no-penetration contacts.


      3) The main oddity is that the study solves happily (although after a similarly long time) with gravity oriented in one direction (perpendicular to the springs, although they flex anyhow because of the torques produced by a COM offset from the fixture) but fails when gravity is oriented parallel to the springs, which should result in a much simpler, symmetric solution.  Might this mean that the study barely achieves equilibrium in the successful case but that changing the orientation pushes it just over the iteration limit?  (I assume this limit is inaccessible to me in linear static simulation.)


      4) In the orientation that completes successfully, should I expect to find useful diagnostic information in the .OUT file (assuming I run it again and save that evanescent file elsewhere)?


      Thanks in advance for any suggestions. -- John Willett

        • Re: Please Translate: "Equilibrium is not achieved.  Results are saved up to the current iteration."
          John Willett

          Update:  I re-ran both orientations described above in SW Premium 2017 SP3.0 and examined the corresponding .OUT files.  I'm not sure how to interpret this information, but here are some bits that might be relevant:


          Vertical (gravity parallel to springs -- the case that failed to reach equilibrium):

          Last "CONTACT ITERATION NUMBER" =      75 (Is this the upper limit?)


          "TOTAL STRAIN ENERGY. . . . . . . . . . . =  0.158073E+00"

          " Ave. Percentage Error (APE)      =  0.183945E+02"

          "S O L U T I O N    T I M E   L O G... (   2:36:32)"


          Horizontal (gravity perpendicular to springs -- the case that successfully reached equilibrium):

          Last "CONTACT ITERATION NUMBER" =      50

          "TOTAL NUMBER OF ACTIVE CONTACT ELEMENT(S) = 22447" (Why smaller?)

          "TOTAL STRAIN ENERGY. . . . . . . . . . . =  0.335303E-03" (Much smaller!)

          "Ave. Percentage Error (APE) =  0.937037E+02"

          "S O L U T I O N    T I M E   L O G... (   1:46:25)"


          Does any of this help explain why equilibrium is not obtained? -- John Willett

            • Re: Please Translate: "Equilibrium is not achieved.  Results are saved up to the current iteration."
              Lesley Ott



              I have the same problem. I have a problem with loads and gravity which solves, but when I add a temperature load I get the same error message as you. Hopefully, someone will respond with a clue as to what to look for.

              • Re: Please Translate: "Equilibrium is not achieved.  Results are saved up to the current iteration."
                John Willett

                Second Update: Questions about Contact Sets -- Since this error appears to be caused by equilibrium failure during the contact-analysis phase of the simulation, I'm wondering if I made wrong choices in setting up the no-penetration contact sets in this study.  I'm trying to follow the somewhat confusing recommendations on setting up contact sets found in FAQID__x281.pdf, for example:


                1) "Position your parts so as to establish initial contact..." -- All of my no-penetration contact sets are in initial contact on part of their paired faces, so this should be satisfied.  After meshing, however, I suppose that interference might develop between opposing surfaces, depending on just how the mesher approximates these surfaces.  Might this be an issue?  Is this a reason to use node-to-surface conditions instead of the normally-preferred surface-to-surface conditions?


                (By the way, I've always set the "Gap (clearance)" option to "Ignore clearances only if gap is less than 0."  This would seem to minimize the contact areas that the program has to consider, but is it a bad idea for other reasons?)


                2) "You typically shouldn't create many No Penetration contact sets with only one Source and one Target.

                Instead, you should create fewer No Penetration contact sets. In each of them, include all the faces that make physical sense to group together. This will be the case for instance for contiguous faces on the same part. Also, if a part A touches simultaneously parts B and C [I think parts A and B should be reversed here for the illustration to make sense], then is probably makes sense to define a single contact set for it." -- This can often result in uncertainty about which source face is to be compared with which target face, which would seem to make unnecessary work for the program.  Is this a potential issue?  (My initial inclination was to specify individual pairs of source and target, but the advice is clearly against that.  Why?)


                3) "Target face(s) should be flatter, larger than Source entities. Target face(s) can be meshed coarser than

                Source entities." -- This recommendation often conflicts with (2).  In such cases which should take precedence?  In general, when is it important to specify individual pairs of source and target instead of grouping them together as recommended in (2)?


                In general do people have favored ways of grouping contact sets to avoid this kind of equilibrium failure? -- John Willett