#Homer annotate peaks how to#

Remember that the directory is something you named - it'll probably be 'ChIPseq/H3K4me3_tags' or something like that. I’ll assume you have all been paying attention and know where your peakfile from yesterday is and that you haven’t deleted anything in the past day, so go to that directory and run the following command: So now to get the subset of the peaks that are around Taejoon’s promoters, you will want to tell getDistalPeaks the appropriate parameters. You probably used it last night when you fired up IGV for the first time, make sure you know where it is. gtf file that is solely for the two scaffolds in your genome reference/index. To make things exceptionally smooth, I generated a. This requires the fasta of the genome sequence and the annotation file (.gtf). Fortunately, I was able to bully the developer into including some custom genome functionality. HOMER was designed for relatively well-studied genomes. You’ll note that there are other options to get sequence in and around various features (gene bodies, etc.) getDistalPeaks was originally designed to get peaks far away from a feature, but the developer put in this option so you can get close ones. You’ll note among other options is one called -prox. Run it first to have a look at the options: The tool we are going to use is called getDistalPeaks. Go to the directory with the H3K4me3 peakfile (after you called the peaks in HOMER it is probably called “regions.txt”). Even on that scaffold there are a lot and you wouldn’t want to do that by hand, and forget about the rest of the genome, where there are about 22,000.įortunately, there is an easy script in HOMER to do this. Suppose you only want the ones that are definitively promoters, based on the gene models. You probably noticed that most, but not all, H3K4me3 peaks in the browser lay on top of the transcriptional start sites. You’re probably noticing that the peaks aren’t as discrete - I think this has to do with how the script using a sliding-window approach to add up the reads - so maybe play with all the makeUCSCfile settings to see how the outputs look different. Now, when you do other chipseqs, you can do this with all of them and be able to compare them directly. If you shut down IGV last night, fire it up again, and load the baby genome, the gtf file, the baby sorted bam files, and now also load the new bedGraph file you just made. There is a standardized file format for genome browsers called “bedGraph”. We’re doing this because if you run different experiments and sequence to different read depths, the pileup of reads could be dramatically higher when they are not actually enriched any differently. You’ll figure it out.įirst, let’s normalize the bam file that you’re looking at on the browser to a standard library size. Should it not work, try running the command alone and looking at the syntax.

#Homer annotate peaks how to#

Fortunately, if you run each command by itself, you will get that short instructional thing about how to use it. It may be that the target directory isn’t specified, or that I used the wrong option. Just like real life! When they don’t work, you will have to fuss with them and figure out what went wrong. Nice! You guys did such a great job yesterday that today I am going to throw some typos into the commands. You also called H3K4me3 peaks over background with findPeaks, converted them into bed files with. You took fastq reads from an H3K4me3 experiment, made a genomic bowtie2 index from a fasta file, aligned the reads, converted the aligned sam files to bam files, sorted them, indexed them, and put them on IGV.