# Next Generation Sequencing (NGS)/Velvet
## Velvet practical: Part 1

This practical will cover the following items:
* Compile Velvet
* Single end
* K-mer length
* Coverage cut-offs
* Whole genome sequence as input???

### Prepare the environment

First make sure that you are in your home directory by typing:
cd
and making absolutely sure you're there by typing:
pwd
Now create sub-directories for this and the two other velvet practicals. All these directories will be made as sub-directories of a directory for the whole course called NGS. For this you can use the following commands:
mkdir -p NGS/velvet/{part1,part2,part3}
After creating the directories, examine the structure and move into the directory ready for the first velvet exercise by typing:
ls -R NGS;
cd NGS/velvet/part1; pwd;

### Downloading and Compile Velvet

You can find the latest version of velvet at:
http://www.ebi.ac.uk/~zerbino/velvet/
You could go to this URL and download the latest velvet version, or equivalently, you could type the following, which will download, unpack, inspect, compile and execute your locally compiled version of velvet:
Take a look at the executables you have created. They will be displayed as green by the command:
ls --color=always;
Have a look of the output the command produces and you will see the following parameters passed into the compiler:
“MAXKMERLENGTH=31” and “CATEGORIES=2”
This indicates that the default compilation was set for De Bruijn graph KMERs of maximum size 31 and to allow a maximum of just 2 read categories. You can override these, and other, default configuration choices using command line parameters. Assume, you want to run velvet with a KMER length of 41 using 3 categories, velvet needs to be recompiled to enable this functionality by typing:
make clean; make velveth velvetg MAXKMERLENGTH=41 CATEGORIES=3; ./velveth
velvet can also be used to process SOLID colour space data. To do this you need a further make parameter. With the following command clean away your last compilation and try the following parameters:
make clean; make MAXKMERLENGTH=41 CATEGORIES=3 color ./velveth_de
For a further description of velvet compile and runtime parameters please see the velvet Manual: https://github.com/dzerbino/velvet/wiki/Manual

## Single ended read assembly

The following exercise focuses on velvet using single-end reads, how the available parameters effect an assembly and how to measure and compare the changes. To begin with, first move back to the directory you prepared for this exercise, create a new folder with a suitable name for this part and move into it. The command to download the file from the internet would be:
wget ftp://ftp.sra.ebi.ac.uk/vol1/fastq/SRR022/SRR022825/SRR022825.fastq.gz
wget ftp://ftp.sra.ebi.ac.uk/vol1/fastq/SRR022/SRR022823/SRR022823.fastq.gz
or if you had the files installed locally, just create soft links to the files. Continue by copying (or typing):
<syntax highlight="text> cd ~/NGS/velvet/part1 mkdir SRS004748 cd SRS004748 pwd ln -s ~/NGS/Data/SRR022825.fastq.gz . ln -s ~/NGS/Data/SRR022823.fastq.gz . ls -l </syntaxhighlight>
Now run velveth for the reads in SRR022825.fastq.gz and SRR022823.fastq.gz using the following options:
- A de Bruijn graph k-mer of 25
- An output directory called run_25
velveth run_25 25 -fastq.gz -short SRR022825.fastq.gz SRR022823.fastq.gz
velveth talks to itself for a while and ends with some files in the output directory. Move into the output directory run_25 and take a look around at what velveth had done so far. The UNIX command less allows you to look at output files (press q for quit). Just in case you still need a hint:
Now move one directory level up and run velvetg on your output directory, with the commands:
Move back into your results directory to examine the effects of velvetg:
cd run_25; ls -l;
FOR YOU: once you run the command above:
* Q1: What extra files do you see in the folder run_25?
* Q2:What do you suppose they might represent?
* Q3: In the Log file in run_25, what is the N50?
Backup the contigs.fa file and calculate the N50 (and the N25,N75) value with the command:
cp contigs.fa contigs.fa.0
YOU now try:
gnx -min 100 -nx 25,50,75 contigs.fa
* Q4. Does the value of N50 agree with the value stored in the Log file?
* Q5. If not, why do you think this might be?
Briefly, the Kmer coverage (and much more information) for each contig is stored in the file stats.txt and can be used with R to visualize the coverage distribution. Take a look at the stats.txt file, start R, load and visualize the data using the following commands:
A weighted histogram is a better way of visualizing the coverage information, because of noise (lot of very short contigs). You can see an example output below:
After choosing the expected coverage and the coverage cut-off, you can exit R by typing:
The weighted histogram suggests to me that the expected coverage is around 14 and that everything below 6 is likely to be noise.
Some coverage is also represented at around 20, 30 and greater 50, which might be contamination or repeats (depending on the dataset), but at the moment this should not worry you.
To see the improvements, rerun velvetg first with -cov_cutoff 6 and after checking the N50 use only / add -exp_cov 14 to the command line option.
Also keep a copy of the contigs file for comparison:
* Q6. What is the N50 with no parameter:
* Q7. What is the N50 with -cov_cutoff 6:
* Q8. What is the N50 with -exp_cov 14:
* Q9. What is the N50 with -cov_cutoff 6 -exp_cov 14:
* Q10Did you notice a variation in the time velvetg took to run? If so, can you explain why that might be?
You were running velvetg with the given -exp_cov and -cov_cutoff parameters. Now try to experiment using different cut-offs, expected parameters and also explore other settings (e.g. -max_coverage, -max_branch_length, -unused_reads, -amos_file, -read_trkg or see velvetg help menu).
Run velvetg with just -cov_cutoff 6 but requesting an amos file:
velvetg run_25 -cov_cutoff 6 -amos_file yes
Now take a swift look at the assembly with tablet:
tablet run_25/velvet_asm.afg &
velvet_asm.afg being the file velvetg made is response to the inclusion of the -amos_file yes switch. tablet will take quite a bit of memory and you can safely ignore the complaints from tablet. Once the file has loaded, select one of the longer contigs. Note the lack of Read information and the one dimensional nature of the contig display. Close down tablet when you have seen enough. Now rerun velvetg adding the additional parameter -exp_cov 7 with no need to save any files as the amos file needs to be changed. Now rerun velvetg adding the additional parameter -exp_cov 14 with no need to save any files as the AMOS file needs to be changed.
velvetg run_25 -cov_cutoff 6 -exp_cov 14 -amos_file yes
Again, view the amos file with tablet:
tablet run_25/velvet_asm.afg &
Select a longish contig as before and explore the display options before close down table. FOR YOU:
* Q11. Why do you think there was read information only for the second use of tablet?
* Q12. You may have noticed velvetg took a little longer with -exp_cov 14 on. Does this make sense ?
If you want to explore the behaviour of velvet even further, you could experiment with the following.
Reduce the sequence coverage by only choosing one input file for the assembly e.g. SRR022825.fastq.gz
Increase the sequence coverage by downloading further files from the same ENA sample SRS004748 (http://www.ebi.ac.uk/ena/data/view/SRS004748).
FOR YOU: How did the N50 change by
* Q13. reducing the coverage?
* Q14. increasing the coverage?