Argument against SEAMLESS springback or using explicit/implicit switching 
as opposed to using dynain in a separate analysis

I am able to see the differences you mention. One explanation for these differences could be that since you are simply running an explicit-implicit switch, LS-DYNA will internally apply a bunch of defaults that are required by the implicit solver. Some of those are Objective stress update is on, langrange multiplier formulations for joints, IGAP is on by default in contacts, etc... So, one or more of these changes is causing the differences. We could spend time to isolate which ones are the reason.

I spoke to some of my colleagues who are more familiar with springback analysis. Apparently, the industry practice is to write out a dynain file at the end of the explicit run using the keyword *INTERFACE_SPRINGBACK_LSDYNA. Then you can use this dynain file to run your springback. Is this solution something you can adapt? There are obvious advantages too, you always have a dynain file to go back to if your implicit springback fails to run/converge, especially since your runs take a long time to solve, and, your explicit input will always be how you have defined it, LS-DYNA will not change any of the defaults like it is doing now.

sp
Ticket#2019101710000191

__________________________________________________

After explicit analysis in which elastic and perhaps plastic strains are developed, 
one may want the know the final deformation after the load is removed.  
Three alternatives are described below. 

Methods 1 and 2 require a dynain file which describes the last state of the model 
after the explicit analysis.  Use *interface_springback_lsdyna in the explicit 
input deck to create the dynain file.  The dynain file includes keyword 
commands (*node, *element, *initial_stress) which describe the final state of the explicit run. 
Example:
Use http://ftp.lstc.com/anonymous/outgoing/support/FAQ_kw/shells.dynain.k to create a dynain file.


Method 1:  Make a separate implicit analysis to calculate the sprungback state.
Include the dynain file in a new input deck and remove the load.  
Use *control_implicit_general (and optionally, other *control_implicit_... commands) 
to invoke an implicit analysis that will take the model from the initial state 
(described by the dynain file) to the final, sprungback state.   
Typically, the implicit analysis is a multi-step, static analysis.
When attempting an implicit analysis, carefully read and adhere to the guidelines provided in 
http://ftp.lstc.com/anonymous/outgoing/support/FAQ/implicit_guidelines .
Example:
Use http://ftp.lstc.com/anonymous/outgoing/support/FAQ_kw/shells.impl_springback.k to calculate 
the sprungback state using the dynain file from shells.dynain.k.
(Another example of Method 1: 
Run  http://ftp.lstc.com/anonymous/outgoing/support/FAQ_kw/hemi.draw.31.k 
and then  http://ftp.lstc.com/anonymous/outgoing/support/FAQ_kw/hemi.draw.31.springback.inerrelief.k.
The dynain produced by the springback run (sb.dynain) could be used to initialize a 
subsequent transient analysis where a prestressed condition is desired.
Furthermore, if you want to use a different shell mesh
and/or different initial orientation than at the conclusion of
of the springback simulation, see *initial_lag_mapping in the Users Manual.) 


Method 2:  Make a separate, explicit dynamic relaxation analysis to calculate the sprungback state.
Include the dynain file in a new input deck and remove the load. 
Dynamic relaxation (aka DR) is invoked by setting SIDR to 1 in a dummy load curve (*define_curve).  
In the DR run, the termination time can be set to zero in *control_termination since we want 
the job to stop after the dynamic relaxation is finished.
The results of the springback analysis will be in the d3drlf database (*database_binary_d3drlf).  
Example:
Use http://ftp.lstc.com/anonymous/outgoing/support/FAQ_kw/shells.dr_springback.k to calculate the 
sprungback state using the dynain file from shells.dynain.k.


Method 3:  No dynain needed.  Switch from explicit analysis to implicit analysis on-the-fly. 
At the time when the dynamic event is finished, simply switch to implicit analysis and remove the load.  
The switch is invoked by defining a load curve which indicates
which time intervals are run implicitly, and which are run explicitly.
The abscissa of the curve is time and the ordinate is 1.0 during the time
the solution is to be implicit and is 0.0 during the time when the solution is to
be explicit.  Thus this curve is a step function.
Set IMFLAG in *control_implicit_general to -|curve ID| (the curve ID but with a negative sign).
Again, an implicit analysis adhere to the guidelines provided in 
http://ftp.lstc.com/anonymous/outgoing/support/FAQ/implicit_guidelines .
Examples:
http://ftp.lstc.com/anonymous/outgoing/support/FAQ_kw/shells.switch_springback.k  
http://ftp.lstc.com/anonymous/outgoing/support/FAQ_kw/impldr_spinning_solid_blade_with_springback_via_switch_curve_and_ZEROVflag.k
In the latter example, an elastic blade is preloaded for a specified angular velocity, then 
spun at that velocity in an explicit analysis from t=0 to t=2, and then finally allowed to 
springback elastically in an implicit analysis from t=2 to t=3.

________________________________________________________

RE: seamless springback

The SPR option, i.e., *CONTROL_IMPLICIT_option_SPR, sets controls ONLY for the implicit
springback phase.  RG says this applies to springback invoked either with *interface_springback_seamless or 
with IMFLAG<0 (curve).
-----------------------------------------

It seems that IMFLAG=2 is merely a convenience to specify implicit
controls when using *INTERFACE_SPRINGBACK_SEAMLESS.  It does not
affect the computation flow other than allowing the user set values
on *CONTROL_IMPLICIT_GENERAL.  Do not ask me why.  The decision was
made in the far distant past, that is 15+ years ago, before Roger.
I tried setting IMFLAG=0 with *INTERFACE_SPRINGBACK_SEAMLESS active.
The results were the same.

I think that the manual needs changing with regard to IMFLAG=2.
But You really need the specifications on
*INTERFACE_SPRINGBACK_SEAMLESS.  The manual gives the impression
that IMFLAG=2 triggers springback but it does not.

With springback phase the end time is advanced from the end time of
the simulation plus NSBS*DT0.  Both NSBS and DT0 are from
*control_implicit_general.  If not specified DT0 is set to the
current end time and the end time is advanced to twice the current
end time.

Auto time step control is always switched on during seamless
springback.  *CONTROL_IMPLICIT_AUTO does not change this activation.
The values of DTMIN and DTMAX, if specified, are honored.

In summary, NSBS is used merely to established the new end time as
a function of old end time and DT0.  Auto time stepping is always
on.  That explains Jim's observations.

rg
5/12/15


IMFLAG=2 in *control_implicit_general does not by itself invoke seamless springback.  It seems *interface_springback_seamless is required to invoke seamless springback.

Which raises the question, what purpose does IMFLAG=2 serve?  I don't know the answer to that.  I can get a perfectly good seamless springback solution from smp d dev by setting IMFLAG=0 (see attached example).  

Note implicit stabilization is invoked by default for seamless springback.   To turn off implicit stabilization, it's necessary to add IAS=2 in *control_implicit_stabilization.

Another observation is that automatic time step control appears to be activated by default for seamless springback, as evidenced by the changing step size.

My final observation is that using dev smp, the forming contacts appear to deactivate automatically when the seamless springback commences.   Using R7.1.2 or R8.0.0, the contacts appear to remain intact.    Maybe Roger or Xinhai have something to say about this apparent discrepancy.

For the most part, I think we just need to update the User's Manual based on the above observations.  You are certainly free to disagree.

I didn't have much luck trying to run the example using MPP.   MPP ends with a negative volume during the explicit phase, presumably due to issues with MPP forming contact handling this coarsely meshed model.

jd
5/11/13
Ticket#2015051110000076