Address of the bookmark: http://www.cbcb.umd.edu/software/phymm/

Address of the bookmark: http://eforge.cs.ucl.ac.uk/eFORGE.v1.2/?documentation

Download

Minia 2.0.7 Linux 64-bits binaries (Source code) (Legacy codebase)

For the impatient

A typical Minia command line looks like:

./minia -in reads.fa -kmer-size 31 -abundance-min 3 -out output_prefix

Type

./minia

for a quick explanation of the parameters.

For more information, refer to the manual.

KmerGenie can be used to determine the best k-mer size, minimum abundance of correct k-mers, and genome size estimation for your dataset.

Address of the bookmark: http://minia.genouest.org/

http://evomics.org/learning/assembly-and-alignment/velvet/

Address of the bookmark: http://evomics.org/learning/assembly-and-alignment/velvet/

The arguments accepted by ScaffMatch are:

  -w) Working directory -- this is the directory where ScaffMatch files are stored. These are .sam files produced after mapping reads to contigs and the resulting scaffolds file `scaffolds.fa` fasta file;

  -c) Contig fasta file;

  -m) Command line argument with no options. It is used when .sam files are used instead of reads .fastq files. Do not use this option if you provide reads files;

  -1) (Comma separated list of) either .fastq or .sam file(s) corresponding to the first read of the read pair;

  -2) (Comma separated list of) either .fastq or .sam file(s) corresponding to the second read of the read pair;

  -i) (Comma separated list of) insert size(s) of the library(-ies);

  -s) (Comma separated list of) library(-ies) standard deviation(s) of insert size(s);

  -t) Bundle threshold. Pairs of contigs supported by number of read pairs less than the value of this argument are discarded. Optional argument, by default it is equal to 5;

  -g) Matching heuristics: use `max_weight` for Maximum Weight Matching heuristics with the Insertion step, use `backbone` for Maximum Weight Matching heuristics without the Insertion step, use `greedy` for Greedy Matching heuristics;

  -l) Log file - where to store the logs. Optional argument. By default, stdout is used.

Address of the bookmark: http://alan.cs.gsu.edu/NGS/?q=content/scaffmatch

Address of the bookmark: http://garm-meta-assem.sourceforge.net/

Address of the bookmark: https://github.com/mahulchak/quickmerge

More at http://www.homolog.us/Tutorials/index.php?p=1.4&s=1

Address of the bookmark: http://www.homolog.us/Tutorials/index.php?p=1.4&s=1

Progressive Cactus is a whole-genome alignment package.

Requirements

• git
• gcc 4.2 or newer
• python 2.7
• wget
• 64bit processor and build environment
• 150GB+ of memory on at least one machine when aligning mammal-sized genomes; less memory is needed for smaller genomes.
• Parasol or SGE for cluster support.
• 750M disk space

Instructions

IMPORTANT NOTE: Progressive Cactus does not presently support installation into paths that contain spaces. Until this is resolved, you can use a softlink as a workaround: ln -s "path with spaces" "installation path without spaces"

In the parent directory of where you want Progressive Cactus installed:

git clone git://github.com/glennhickey/progressiveCactus.git
cd progressiveCactus
git pull
git submodule update --init
make

It is also convenient to add the location of progressiveCactus/bin to your PATH environment variable. In order to run the included tools (ex hal2maf) in the submodules/ directory structure, first source progressiveCactus/environment to load the installed environment.

If any errors occur during the build process, you are unlikely to be able to use the tool. Please submit a GitHub issue so we can help out: not only will you help yourself, but others who wish to use the tool as well.

Note that all dependencies are also built and included in the submodules/ directory. This increases the size and build time but greatly simplifies installation and version management. The installation does not create or modify any files outside the progressiveCactus/ directory.

Address of the bookmark: https://github.com/glennhickey/progressiveCactus

• For each genome, obtain a set of exon annotations. These annotations can be a combination of both exon predictions (e.g. Genscan) and annotations that have been experimentally verified (e.g. RefSeq). Ideally, we would like to have these annotations be as sensitive as possible. Specificity is not a concern, as incorrect annotations are not likely not have significant alignments with other gene annotations.
• Compare all exons against all exons in other genomes and record significant alignments between exons. Currently, we use BLAT to do this all-vs-all comparison with alignments being performed in protein space.
• Construct a graph with each vertex corresponding to a exon and edges between vertices whose corresponding exons have significant alignments.
• Identify cliques in this graph. These cliques are potential anchors to be used in the map.
• Starting with the largest cliques (those that have exons in all or most of the genomes), join neighboring (adjacent in genomic coordinates, in each genome) cliques to form runs. Smaller cliques that are inconsistent with runs formed by larger cliques are filtered out. After the smallest cliques have been considered, cliques that are not part of a run are discarded.
• The extents of each run in each genome are outputted as orthologous segments. The cliques from each run are used to output the exact genomic coordinates of anchors within each orthologous segment. These anchors can be used by genomic alignment programs (such as MAVID) to do a detailed alignment of each orthologous segment.

https://www.biostat.wisc.edu/~cdewey/mercator/

Address of the bookmark: https://www.biostat.wisc.edu/~cdewey/mercator/