Some general remarks on preloading and on preloading bolts in particular are given in
http://ftp.lstc.com/anonymous/outgoing/support/FAQ_docs/preload.pdf
and examples are provided in the series of bolt* examples in 
http://ftp.lstc.com/anonymous/outgoing/support/EXAMPLES .

To elaborate a bit concerning preload application via dynamic relaxation:

-  An internal load need not be sustained to maintain equilibrium after
   equilibrium is established in the preload phase.
   Example: *INITIAL_STRESS_SECTION
 
-  An external load needs to be sustained to maintain equilibrium of the
   preloaded state.
   Example:  *LOAD_THERMAL
_______________________________________________________________________
A "dynain" file contains a set of keyword data that can be inserted into an input deck
in order to initialize deformation, shell thickness, element history variables (stress, 
plastic strain, material-model-dependent extra history variables), and tensorial strains.  
LS-DYNA will write a dynain file at the end of an
analysis if the keyword command *interface_springback_lsdyna is included in the input
deck (see Users Manual for command syntax).  
Alternately, LS-Prepost can write a dynain file corresponding 
to any output state stored in the d3plot database by selecting 
Output > dynain ASCII.  

----------------------------------------------------------
RE: Contact when initializing from dynain

If the preload induces contact forces, dynain is generally not an ideal approach 
for initializing a subsequent analysis since dynain does not initialize the contact forces.
This omission will disrupt the state of equilibrium attained in the preload analysis if contact forces 
are produced by the preload. Dynamic oscillation of response is expected in the 2nd analysis until 
contact forces are reestablished. Furthermore, the new state of equilibrium will be slightly different 
than the original state of equilibrium. 

Exceptions...

A hypothetical, unproven approach to account for contact forces in the dynain approach 
would be to set the contact birthtime BT on card 2 of *contact to a small value, 
e.g., 1e-10, and also set the shooting node logic flag SNLOG on Optional Card B of 
*contact to 1.    Furthermore, IGNORE should be 0 and SOFT should be 0 or 1.   
The idea here is that the initial penetrations would not be removed during initialization 
and then, after one time step, the contact is birthed and contact forces corresponding 
to the penetration are created.   In this approach, equilibrium is absent in the first time 
step as contact forces are zero but then equilibrium is approximately restored in the 
second time step.  Again, I don't know how well this approach would work in practice.  
How well it works is likely to be very situation dependent.

Arup has implemented contact initialization through dynain but only for
*contact_tied_surface_to_surface_offset and only for staged construction.  Richard Sturt (9/4/09)
said the 2nd limitation could be lifted easily but the 1st limitation would be more
laborious.  Richard also provided an example.

In post-R10 releases, MORTAR contact can be initialized using dynain.
See CFLAG in *interface_springback_lsdyna.
CFLAG. Transferring contact state may be important, in particular tied information.
Setting this parameter to 1 will output Mortar contact tied segment pairs
for tied, tiebreak and tied weld options. The resulting dynain.lsda, which has to be
using LSDA format (FTYPE=3), can be included in subsequent simulation to restore
the contact state. The LS-DYNA version or core count used may be changed
between simulations, and also the contact type (for instance changing from tied
weld to simple tied), if only the contact ID and node IDs making up the segments
remain unchanged. If parts or elements are removed between simulations, and
these happen to contain segments that are in the dynain.lsda file these pairs will be
simply ignored. This provides a flexibility that is appealing in multistage processes
as is common in the simulation industry.
(Example mentioned in init_by_dynain and contact.mortar.)

_____________________________________________________________________________

This possible issue of uninitialized contact forces is also
circumvented in alternate approaches such as a dynamic relaxation approach.
The dynamic relaxation (DR) phase can be explicit transient, implicit transient, or implicit static.

http://ftp.lstc.com/anonymous/outgoing/support/FAQ_kw/gravity_preload_by_dr.k.gz illustrates preload by explicit DR. 
(See also notes in text file "drelax")

To run implicit DR:

1. Set IDRFLG=5 and set the dynamic relaxation termination time DRTERM
in *control_dynamic_relaxation
2. Add *control_implicit commands as necessary to govern implicit analysis in DR phase.
As a minimum, you'll need *control_implicit_general with DT0 set to a positive value.
3. Ramp preload linearly using *define_curve command(s) with SIDR=1.
The ramp time for preload is typically equal to DRTERM (see step 1).
4. Include *database_binary_d3drlf to write output from the implicit dynamic relaxation
phase (recommended).  The output interval is given in units of cycles, not time.
5. *control_implicit_dynamics governs whether implicit analyses are static or transient.
6. To initialize velocity as the conclusion of the dynamic relaxation phase,
set iphase=1 on *INITIAL_VELOCITY_GENERATION

See http://ftp.lstc.com/anonymous/outgoing/support/FAQ_kw/implicit_dr.k.gz for an example.

As an alternative to implicit DR is switching from implicit to explicit
via a curve (1st parameter in *control_implicit_general is negative
curve ID).