Raven Overview

Raven is an algorithm-driven molecular cloning tool [1]. It accepts a list of target plasmids and a parts library as its input and returns a DNA assembly plan (see Guides for example Raven files). For any set of target parts, Raven determines an optimized plan for assembling the selected target plasmids with a supported DNA assembly method.

This version of Raven is open-source and the source code for the assembly algorithms is available on github. If you are interested in having Raven tailored for your company or have interest in other design-automation software, please contact Lattice Automation.

Have additional questions or wish to provide feedback to the developers? Please post to the Raven Forum.

Demonstration Video


Assembly Methods

Raven currently supports six cloning-based assembly methods: Gibson [2], MoClo (BBF RFC 94) [3], BioBricks (BBF RFC 10) [4], SLIC [5], CPEC [6], and GoldenGate [7]. Each of these supported cloning methods has technology-specific constraints and these are automatically applied in the assembly solutions.

Additional cloning methods are not currently supported, however, Raven's core algorithm is highly generalizable and new methods can be added with relative ease. Please contact the developers if you are interested in Raven support for an assembly method that is not currently supported.

Algorithms

Raven calculates an assembly plan in two major parts: first, Raven determines all intermediate cloning reactions necessary to achieve the final constructs, then it selects optimized part junctions based on method-specific constraints. Calculations are made in this order because it is assumed that performing a successful cloning step is more costly and time consuming than performing a PCR reaction.

A unique feature of Raven is its ability to incorporate experimental data to modify the assembly solutions. Raven allows the user to input efficiency information for a variety of parameters and bias or force certain assembly intermediates from appearing in the assembly solution.

For example, a user might observe higher or lower assembly efficiencies than expected due to various experimental conditions such as cell competency, specific reaction conditions and other factors. To adjust for these considerations, a user may adjust the default efficiency values guiding the efficiency optimizations.

A user may also wish to bias or force certain intermediates from appearing or not appearing. Raven optimizes around these additional constraints unless they are so restrictive that no valid solution can be found. Intermediate parts and overhangs can be biased for (recommended), biased against (discouraged), forced or forbidden. These intermediates can be specified either manually in the design tab or automatically via Eugene [8] scripts and listed in Raven files.

These strategies are applied to all supported assembly methods to produce fast, modular and efficient assembly plans. Additional details can be found in the Raven publication.

NOTE: In scarless assembly methods (CPEC, Gibson, Golden Gate, SLIC), it cannot be guaranteed that all part junctions are unique in each cloning reaction. Please check assembly plan and primers carefully before implementing. If Raven selects an incompatible part junction for a specific cloning reaction, try changing the plan by forcing or biasing the intermediate steps.

Integrated Tool Chain

This version of Raven 'stand-alone'. It does not consider genetic construct function or depend on any other tools or databases to provide optimized assembly plans. However, this tool is designed to be connected to a larger tool-chain such as the Clotho design automation platform. This tool chain uses a 'top-down' design flow and begins with the specification of device behavior and ends in physically implemented assembly.

One such specification tool in the Clotho design flow is Eugene [8], which generates a set of target constructs based on libraries of parts and genetic design rule sets. Raven can take this list of target constructs, determine the best way to build all target plasmids, and return a set of instructions for the assembly. These output instructions can be interpreted by liquid handling robots or microfluidics platforms to automatically assemble these plasmids from available resources. This flow allows a user to merely specify the behavior of a set of constructs and what resources they have and be returned a set of biological samples.

FAQ

What do I need to use Raven?
A user must minimally provide a list of target plasmids and all DNA parts that are needed to build the target plasmids. Part sequences are not mandatory, but primers will be incomplete in plans for plasmids containing parts with missing sequences.
What do I input into Raven?
Raven accepts a single .csv file that allows users to specify their basic parts, plasmids, vectors and failure tracking history. Details about this file can be found here. Example input files can be found here
What does Raven output?
Raven outputs several types of information:
  1. A graphical representation of an optimized assembly plan for the selected target parts.
  2. A set of assembly instructions for a liquid handling robot (computer-readable)
  3. A set of assembly instructions for a human user (human-readable)
    1. List of all primers to needed to accomplish assembly
    2. List of all PCR reactions to perform (all part-primer sets)
    3. List of cloning steps to perform with a graphical picture of each individual step
What information is mandatory to run Raven and what information is optional?
  • Mandatory: Target plasmids, parts composing all target parts
  • Optional: Existing overhangs for each input part; existing assembly vectors; complete parts library assembly efficiency information for a specific cloning method; recommended, discouraged, required, and forbidden intermediates
  • More information about acceptable part types and fields can be found here

Guides

This section contains documentation about specific Raven features. More examples are coming soon. In the meanwhile, please contact us at ravencadhelp@gmail.com if you have further questions.

Click the links below to download example Raven input files

Repressilator
Amplifying Logic Gates

This is the full specification for the Raven input file. Files that do not conform to this standard will result in upload errors

Each row represents a part, vector, destination vector, or plasmid. None of the columns need to be unique, but the collection of all columns in one row must be unique and if all columns are blank, the row is ignored.

  1. Library

    This field is used upon input to indicate if a part in the file is in the library and can be considered for re-use. If any character is in this column for a given row, it will be considered in the library for reuse. It is important that only parts that can be reused are marked in this section or else the outputs will be incorrect.

  2. Name

    This is the field used to name the part.

  3. Sequence

    In all cases this fields is optional, but without this field, complete primer designs will not be generated. Primer designs are not optimized, but are valid based for the selected assembly method.

  4. Left Overhang & Right Overhang

    These fields mark the overhangs of the parts generated. These overhangs are variables and not sequences. Library part reuse of is based on overhang when calculating the assembly plan. Plasmids, and destination vectors are all allowed to have overhangs.

    The MoClo assembly algorithms only recognize overhangs with the numbers 1 -> 128 for reuse. They also recognize overhangs with the '*' character as reverse compliments of the standard 128 possible MoClo overhangs (i.e. '1*' is the reverse overhang of overhang '1').

    The BioBricks assembly algorithms only recognize 'EX' for the left overhang and 'SP' for the right overhang. Upon input, this field is completely optional, but most outputs contain parts and vectors with overhangs, as this is necessary for assembly.

    CPEC, SLIC, Gibson and GoldenGate algorithms do not use the overhang fields as the constructs are designed to be scarless.

  5. Type

    This field is used to create assembly plan pictures using Pigeon-generated SBOLv-compliant glyphs.

    All plasmids must have the key string 'plasmid' in this field.

    Vectors need the key string 'vector' and destination vectors must be marked 'destination vector'.

    NOTE: The difference between 'vector' and 'destination vector' is important. A 'vector' is a linear fragment that represents the vector backbone. A 'destination vector' is a vector with an insert, making it circular. This fragment is generally a lacZ cassette in Raven. Although the 'destination vector' is a circular, replicating plasmid, it should not be indicated as a 'plasmid' in Raven. MoClo and Golden Gate assemblies produce 'destination vectors' which can be re-used as part of the library.

    All other entries are valid, and assumed to be basic part types. Part types not recognized by pigeon are assigned the wild-card glyph in Pigeon images.

    The following key strings are recognized for pigeon images for basic parts:

    TypeShorthand
    promoterp
    RBSr
    geneg
    terminatort
    reporterrep
    resistanceres
    invertase siteins
    spacers
    origino
    fusionfus

    Parts with type 'fusion' denote fusion proteins and the Name column is split with the '-' character to get all the fusion names. Parts with type 'resistance' denote a resistance cassette. Take note that restriction-based assembly cloning methods rely on cloning vectors that also have anti-biotic resistance within them.

  6. Resistance

    This field is used to denote the antibiotic resistance of a vector or destination vector.

  7. Level

    This field is used only for vectors and destination vectors. Destination vectors with level and overhangs are re-used in an assembly plan if possible. Levels start at '0'.

  8. Vector

    The vector field is used to indicate the vector backbones in which a construct lies. Complete plasmids will be re-used in assembly plans if it reduces cost. This field is also used to denote the vector backbone used by destination vectors. Destination vectors are always made of a vector backbone and the lacZ fragment as insert. For MoClo and Golden Gate assembly, which use destination vectors, the construction of destination vectors is not explicitly described in the assembly instructions, but for new destination vectors, primers are designed to amplify the lacZ fragment for insertion into the vector backbone after a SpeI digestion and ligation. To PCR this fragment with different flanking recognition sites, primers will need to be re-designed.

    NOTE: The vector specified in this column is used to indicate which vector backbone a plasmid in the library currently has. For target parts that do not yet exist in the library, this field is ignored. Vector assignments for intermediates and final clones are all specified in the design tab in the user interface.

  9. Composition

    This field starts in the column below the headers and extends infinitely based on the size of the composition of the target construct. All target constructs must have a composition size of two or greater and only these constructs will be recognized as targets.

    This field must be formatted in one of the following conventions:

    • 'partName|LeftOverhang|RightOverhang|Direction'
    • 'partName|Direction'
    • 'partName'

    The part name is mandatory. LeftOverhang and RightOverhang are optional. Direction is how a user can specify the strand or 'direction' of a part within a device. All parts are assumed to be forward (on the leading strand) in the absence of specification. The two acceptable directions are '+' and '-'. If a part in a device has Direction equal to '-' it is on the lagging strand.

The input file only recognizes four types of entries. Entries that do not fall into these categories will not be input correctly and/or cause invalid answers. Here are the acceptable entry types:

Entry TypeRequired FieldsOptional FieldsForbidden Fields
Basic PartName, TypeSequenceResistance, Level, Left Overhang, Right Overhang, Composition, Vector
PlasmidName, Type (="plasmid"), CompositionSequence, Left Overhang, Right Overhang, VectorResistance, Level
VectorName, Type (="vector"), ResistanceSequence, LevelLeft Overhang, Right Overhang, Composition, Vector
Destination VectorName, Type (="destination vector"), Left Overhang, Right Overhang, Resistance, Vector, Composition (="lacZ")Sequence, Level

References

  1. Appleton, E., Tao, J., Haddock, T. & Densmore, D. Interactive assembly algorithms for molecular cloning. Nature Methods (2014). doi:10.1038/nmeth.2939
  2. Gibson, D. G. et al. Enzymatic assembly of DNA molecules up to several hundred kilobases. Nature Methods 6 (2009).
  3. Weber, E., Engler, C., Gruetzner, R., Werner, S. & Marillonet, S. A modular cloning system for standardized assembly of multigene constructs. PloS ONE 6 (2010).
  4. Shetty, R. P., Endy, D. & Knight, T. F. Engineering BioBrick vectors from BioBrick parts. Journal of Biological Engineering 2 (2008).
  5. Li, M. Z. & Elledge, S. J. Harnessing homologous recombination in vitro to generate recombinant DNA via SLIC. Nature Methods 4, 251-256 (2007).
  6. Quan, J. & Tian, J. Circular polymerase extension cloning of complex gene libraries and pathways. PLoS ONE 4, e6441 (2009).
  7. Engler, C., Kandzia, R. & Marillonnet, S. A one pot, one step, precision cloning method with high throughput capability. PLoS ONE 3, e3647 (2008).
  8. Bilitchenko, L. et al. Eugene: a domain specific language for specifying and constraining synthetic biological parts, devices, and systems. PLoS ONE 6, e18882 (2011).