No_Reincarnation Stopping Deleted Elements "Coming Back to Life"

No_Reincarnation Stopping deleted elements "coming back to life"

Ansys LS-DYNA writes deletion tables at the end of every state in the output file which set a flag against any element that has been deleted.

In normal usage elements start off "alive", then "die" (get deleted) if their material model implements failure and they are deemed to have failed, and they remain dead for the rest of the analysis. However some keywords in Ansys LS-DYNA use these tables in a slightly different way, for example *DEFINE_CONSTRUCTION_STAGE , can result in an element starting off "dead" and then coming to life at some later stage in the analysis. Therefore D3PLOT cannot adopt the "once you are dead you remain dead" approach as its default, and instead the deletion status of every element at every state is stored so that elements can die and come back to life at will.

However there is a bug in some versions of Ansys LS-DYNA where elements that "die" due to material failure are (correctly) marked as deleted at that state, but somehow this information is lost later on in the analysis and they appear to come back to life again. Since deleted elements have no stiffness they can develop huge deflections, and drawing these can mess up plots horribly, so a means of solving this problem is required, and the No_Reincarnation feature provides this.

Clicking on No_Reincarnation does the following:

• For every model in the database D3PLOT starts at state 1 and works its way linearly forwards to the last state, propagating the deletion status of elements forward by setting the deletion status of an element in state <i> to be a logical OR of that and its status in state <i-1> . Therefore once an element is deleted it cannot come back to life again.
  
  
• This process may be slow if the analysis has many states since D3PLOT has to read the deletion status of each state if it is not already in memory. States will only be in memory if they have been displayed, so if you have read in a model and then jumped directly to the last state it will have to read the deletion tables of all the intervening states.
  
  
• If set this flag remains in force for any model read subsequently.
  
  
• If unset reading of any subsequent models will behave normally, ie deletion status in each state will revert to being independent of any other state. However propagation of deletion in models to which this process has already been applied is not undone - once applied to a model this process is irreversible, and if you need to revert to normal deletion behaviour in that model you will have to Reread it.