# Coupling LAMMPS to other codes

LAMMPS is designed to support being coupled to other codes. For example,
a quantum mechanics code might compute forces on a subset of atoms and
pass those forces to LAMMPS. Or a continuum finite element (FE)
simulation might use atom positions as boundary conditions on FE nodal
points, compute a FE solution, and return interpolated forces on MD
atoms.

LAMMPS can be coupled to other codes in at least 4 different ways. Each
has advantages and disadvantages, which you will have to think about in
the context of your application.

1.  Define a new [fix](fix) or [compute](compute) command that calls the
    other code. In this scenario, LAMMPS is the driver code. During
    timestepping, the fix or compute is invoked, and can make library
    calls to the other code, which has been linked to LAMMPS as a
    library. This is the way the [VORONOI](PKG-VORONOI) package, which
    computes Voronoi tesselations using the [Voro++
    library](http://math.lbl.gov/voro++)\_, is interfaced to LAMMPS. See
    the [compute voronoi](compute_voronoi_atom) command for more
    details. Also see the [Modify](Modify) pages for information on how
    to add a new fix or compute to LAMMPS.

<!-- -->

2.  Define a new LAMMPS command that calls the other code. This is
    conceptually similar to method (1), but in this case LAMMPS and the
    other code are on a more equal footing. Note that now the other code
    is not called during the timestepping of a LAMMPS run, but between
    runs. The LAMMPS input script can be used to alternate LAMMPS runs
    with calls to the other code, invoked via the new command. The
    [run](run) command facilitates this with its *every* option, which
    makes it easy to run a few steps, invoke the command, run a few
    steps, invoke the command, etc.

    In this scenario, the other code can be called as a library, as in
    1., or it could be a stand-alone code, invoked by a system() call
    made by the command (assuming your parallel machine allows one or
    more processors to start up another program). In the latter case the
    stand-alone code could communicate with LAMMPS through files that
    the command writes and reads.

    See the [Modify command](Modify_command) page for information on how
    to add a new command to LAMMPS.

<!-- -->

3.  Use LAMMPS as a library called by another code. In this case, the
    other code is the driver and calls LAMMPS as needed. Alternately, a
    wrapper code could link and call both LAMMPS and another code as
    libraries. Again, the [run](run) command has options that allow it
    to be invoked with minimal overhead (no setup or clean-up) if you
    wish to do multiple short runs, driven by another program. Details
    about using the library interface are given in the [library
    API](Library) documentation.

<!-- -->

4.  Couple LAMMPS with another code in a client/server fashion, using
    the [MDI
    Library](https://molssi-mdi.github.io/MDI_Library/html/index.html)\_
    developed by the [Molecular Sciences Software Institute
    (MolSSI)](https://molssi.org)\_ to run LAMMPS as either an MDI
    driver (client) or an MDI engine (server). The MDI driver issues
    commands to the MDI server to exchange data between them. See the
    [Howto_mdi]{.title-ref} page for more information about how LAMMPS
    can operate in either of these modes.