AMS Divergence

Altair Forum User
Altair Forum User
Altair Employee
edited October 2020 in Community Q&A

Hi,,

 

I am using AMS for one of my simulations. And it's showing AMS divergence error .Continuously. I have run with various time steps.. For all the run it showing the same result.. I run the same model with standard mass scaling and it is good. I changed the interfaces to the recommended values.. Any solution for this problem?? 

Tagged:

Answers

  • Altair Forum User
    Altair Forum User
    Altair Employee
    edited December 2016

    Hi Raghav,

    Check the model for any incompatible kinematic conditions and should be resolved if any. AMS can fail in such situations, whereas the classic time step control for the same model can run normally.

    What type of interfaces are present in the model?.Also,as a workaround you can try with  /DT/INTER/DEL to avoid possible divergence.

     

  • Altair Forum User
    Altair Forum User
    Altair Employee
    edited December 2016

    Hi,,,

     

    Checked for incompatbile conditions and sorted them ... I use /INTER/DEL with lowest possible time step.. However i am getting the same problem...

     

    Alsothe time step is not being stable.....I am using the same time step to that of CMS case... 

     

    Can you suggest me a way to keep the time step stable for the interfaces??? .. Other than increasing the stiffness...

  • Altair Forum User
    Altair Forum User
    Altair Employee
    edited December 2016

    Hi Raghav,

    Computational convergence and accurate results can be obtained by setting a target time step to 10 to 20 times higher than traditional mass scaling method (/DT/NODA/CST).

    Can you share the model files with the out files also (starter and engine files and both out files) ?.

  • Altair Forum User
    Altair Forum User
    Altair Employee
    edited December 2016

    Hi...

     

    Thanks for the suggestion.. I am sorry that I cannot share the files.. as they are with my teacher....However I can access them and verify for possible mistakes..  Can you suggest me a way to keep the time step stable for the interfaces??? .. Other than increasing the stiffness...

  • Altair Forum User
    Altair Forum User
    Altair Employee
    edited December 2016

    Hi Raghav,

    Check the time step imposed for running AMS. This can be one reason for diverging. As said above,  the target time step should be 10 to 20 times higher than traditional mass scaling method.

    You can vary the Gapmin and try to avoid any type of penetrations, And use Inacti=6. Please provide some more information on the type of analysis (quasi-static, drop, crash...etc) you are performing and the contacts defined in the model (contact type used).

    Please share the out files (starter out and engine out files) also so that we will get some idea.

  • Altair Forum User
    Altair Forum User
    Altair Employee
    edited December 2016

    Hi,,

     

    It's a crash analysis. type 7 contact, I tried with various range of time steps starting from original time step to 10 times to the traditional time step.. If I increase the time step the energy error is high 99% and the simulation is terminated... If I use lower time steps the solver is running into infinite loop.. and output is not getting mapped... then I have to force quit the simulation... The major issue I see on the .out files is about the interface type 7... I tried changing the gap.. ans as a default I use inact6 and Isfff 4 and I form 2 while implementing AMS...

  • Altair Forum User
    Altair Forum User
    Altair Employee
    edited December 2016

    Hi Raghav,

    AMS is not recommended for crash analysis. The conventional mass scaling, that is /DT/NODA/CST (mass error preferably less than 2 percent) is advisable for crash simulations where as AMS is recommended for quasi static simulations, where the velocity is low and the kinetic energy is very small and in such cases the effect is insignificant or negligible.

    Please share the out files for reviewing.

  • Altair Forum User
    Altair Forum User
    Altair Employee
    edited January 2017


    MESSAGE ID :          205

     ** RUN KILLED : ENERGY ERROR LIMIT REACHED
    Also it saying warning minimum timestep slave node deleted from the interface. And after that it is showing energy error limit reached..

  • Altair Forum User
    Altair Forum User
    Altair Employee
    edited January 2017

    Hi Raghav,

    This energy error can happen due to too low time step because of mesh size or penetrations in structure. Please check the interface defined in the model. Try varying the minimum gap. The message 'Delete Slave Node' is written when the stability time step of the interface for the slave/master couple; which is considered is lower than the minimum time step which was specified in option /DT/INTER/DEL.

    Please share the engine out (_0001.out) file also.

  • Altair Forum User
    Altair Forum User
    Altair Employee
    edited January 2017

    Hi,

     

    Pl let me know what would you be looking into the .out file(engine) As I mentioned above there was no other information given it it except for the warning with corresponding interface ID.

    Any suggestions to get rid of this problem..??

  • Altair Forum User
    Altair Forum User
    Altair Employee
    edited January 2017

    Hi,

    From the engine out file, we need to review the energy balance of the system during every cycle. Also, we need to see the time step variation during the run.

    Please check the starter out file for any warnings listed (especially Incompatible Kinematic conditions which can result in energy error).

    The suggestions to sort out this error are, 1). Check for any Incompatible Kinematic Conditions in the model. 2). Timestep too low because of mesh size or high interface penetrations/distortions in structure.

  • Altair Forum User
    Altair Forum User
    Altair Employee
    edited January 2017

    HI,

     

    I found only one incompatable kinematic condition due to RWALL. I have created that as a ground (infinite plane) so I cannot delete it.. 2) There is no warning..regarding the low time step... However as informed before the timestep is dropping and eventually the run is stopped... Any suggestions pls?

  • Altair Forum User
    Altair Forum User
    Altair Employee
    edited January 2017

    Hi Raghav,

    From the engine out file please check for the time step and what is causing for this. Please find the attached image.

    Please share the out files so that we can have a look. If possible, please share the model files through the secure dropbox link in the signature so that we can suggest the workarounds.

    <?xml version="1.0" encoding="UTF-8"?>Capture.PNG

  • Altair Forum User
    Altair Forum User
    Altair Employee
    edited January 2017

    Hi

     

    It is mainly coming with a type 7 interface.. The time step is dropping and then eventually resulting into this error. Also pl mention the work around. 

     

    Thanks 

     

     

  • Altair Forum User
    Altair Forum User
    Altair Employee
    edited January 2017

    Hi,

    For an interface responsible for low time step, these are some possible workarounds.

    >.First check the gap that is used for this interface.The value must be physically realistic and based on shell thicknesses in case of contact between shells. In case of constant gap (Igap =0) with no input gap (Gapmin=0), RADIOSS determines a default value for Gapmin and you can check this value in the starter out file.

    >.If some elements fail on the master side or on the slave side of the interface, it is important to set Idel =2 (or Idel =1) for this interface. This will prevent nodes connected to deleted elements whose stresses are released to impact with a possible high velocity.

    >. Check stiffness defined (Istf). Try with Istf = 2. (Review Help Menu about Istf for /INTER/TYPE7)