I ran a small unpublished experiment where I used an input from another experiment (same cell line) and got broadly similar results, in terms of peak numbers.  I cannot put my finger on a particular study, but I don't think this is an unusual strategy.

EDIT: reference to ENCODE guidelines, see "Controls" P7 in 'https://genome.ucsc.edu/encode/protocols/dataStandards/ChIP_DNase_FAIRE_DNAme_v2_2011.pdf'. 

My interpretation being that input is required for changes of condition, treatment, etc.  Obviously the best control is the input split from the IP reaction, but given economic constraints I would argue a pooled input will (on the whole) give similar results.

EDIT2: a 2014 seqanswers discussion gives evidence for both sides of the debate, however my sentiment is nicely summised by 'dbrg77', see end of 'http://seqanswers.com/forums/showthread.php?t=35377'.

Hello! The sequencing libraries should be constructed separately from each individual ChIP, either case or control. They can be barcoded and combined in the flow cell of the sequencer, but you don't want to combine them before constructing the libraries. The sequencing facility often will construct your libraries for you. It is good to have as many controls as case samples, but why so many? Having a large n is good, but if you haven't done it before, it is also good to do a smaller pilot experiment, say 3x3. One of the good reasons to do a smaller set is the sequencing depth of both the control and case. For human data, you will want at least 20M reads (40M better) and about 20-30% more reads from your input data. If you are doing 10 samples you may not be able to get all of your samples loaded on the same machine. As long as the libraries are made at the same time there shouldn't be too much batch variation and so you can load your pairs in two runs. What software are you going to use? I have used macs2 with IDR and the code here, https://sites.google.com/site/anshulkundaje/projects/idr. I also re-run the data with SPP stand alone software to get the NSC, RSC, and FRiP data which you need. There may be newer data, but I did these awhile ago and this was the reference paper I used. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3431496/  Good luck!!

Yes. For ChIP samples an input must always be sequenced as well. It's the only way to know the level of non-specific IP you're getting in your ChIP.

I agree with Matthew Edward Thornton, that a pilot expt might be good idea esp. if you're making the libraries yourself for the first time. It is also a good idea to confirm your ChIP with qPCR if you have any exiiting known targets, prior to doing any sequencing.

Finally, the amount of sequencing required is heavily dependent on the type of protein your ChIPing against. For a std transcription factor 20-30M reads is usually enough, but for some ubiquitous histone acetylation marks you will need 100+M reads. You need to consider how widespread the DNA binding is for your protein.

Thanks for the advice from both of you.

Matthew - The whole reason I am thinking about a higher n number is because I am unsure as to the variation between individuals in each of the experimental groups. I have also read that having more biological replicates helps for reliaility in peak identification (https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3962196/).

My transcription factor is NF-kB (RelA), so fairly broad, but not as broad as histone marks, for example. So I am aiming for at least 20million reads per sample, but as mentioned this may have to be split into 2 runs to get the desired reads per sample.

With regards to analysis. I was looking at MACS. Also seen THOR (http://nar.oxfordjournals.org/content/early/2016/08/01/nar.gkw680.full) which looks promising.

On the topic of the input. So would you recommend giving more reads to the input samples?

Thanks again for both your time to provide advice.

No. I wouldn't recommend sequencing the input more deeply. You can get 20-30% variability between your libraries anyway. Just treat them equivalently.

I'm not sure doing more biological reps here will help particularly. Peak callers are not quantitative - you end calling more singleton peaks which are likely spurious. May be best to do three reps with ChIP-seq and keep the rest to validate with qPCR? Just a suggestion.

I did see it recommended to add about 20% more sequencing reads to the input for the peak callers. I am not an authoritative expert. I have just processed the data using peak callers. The peaks are what is important, you can verify an increase or decrease in the gene expression upstream of the peak afterwards by qPCR. The phantompeakqualtools and SPP or macs2 (in the code above) qualify peaks base on the pileup of reads from both ends of the cDNA fragment. You will have reads from the 5' and 3' ends of the fragment. Having a slightly higher number of reads from input, giving higher background adds stringency to the peak calling. If you have good data your NSC and RSC and FRiP will be good as well. If you look at the piles using the UCSC genome browser by uploading a bamfile as a 'custom track' this helps verify real peaks. To do this requires aligning to a compatible genome and gtf for UCSC genome browser (they have good gtf anyway). I don't know anything about THOR and I have used macs2. If you follow the ENCODE protocol, then you shouldn't have much to worry about.  I do greatly agree with Christian Cole that a small pilot should be performed.  One of the key experimental details is the fragment size, too big and you have problems, too small also problems. As far as quantitative, straight up RNA-seq with the addition of the Ambion ExFold ERCC spike-in controls will give you a super comparison to go with your ChIP-seq data. has anyone used an NFkB antibody as part of modENCODE? http://genome-euro.ucsc.edu/ENCODE/antibodies.html  I found one that may help. If possible I would use their antibody as it was ENCODE validated. The Kundjae scripts are in R and linux and are really good.  I hope that you will consider them.

As for the reliability the Kundjae scripts use IDR a statistical procedure which gives a metric of reliability in peak calling. It splits your data into subsets to compare the fractions of peaks against each other. The idea is that random fractions should be able to recapitulate the peaks called from the whole. So you can use fewer biological replicates. This is not as good as having a large number of biological replicates, but it is still quite expensive and time consuming to hammer out a large n of high quality. Good luck!!

Article The NF-kappa B Genomic Landscape in Lymphoblastoid B Cells

With regards to peak callers you also need to consider what kind of signal you are trying to detect. As Chris says about the required depth being dependent on the type of signal, transcription factors lower depth broad histone marks higher depth, the width of the signal rather dictates the caller too, while MACS is excellent for signals that match its model, narrow transcription factors signals and slightly broader signals in promoters for example when the signal covers the whole transcript or even broader regions I have tended to find SICER very useful. Where as if you a searching for nucleosome signals there are useful tools like PING and nucleR in bioconductor. I am not sure I have found  good tool for really broad enrichment signals covering megabases yet, or maybe I jus haven't had data of sufficient depth.

http://home.gwu.edu/~wpeng/Software.htm

My view on the input sample is that it is a control for the genome background, i.e. some areas of the genome will be mapped more frequently than others.  This is often seen in an input track as huge peaks of reads; often at telemeres.  Replication is a gold standard, but budgets are often tight.  I would suggest that although an input sample for every individual is optimum, it is also workable to use a representative input sample, either from an individual, or more usefully from a pool of the individuals.  Or i think in this case a pool of cases, and a pool of controls.  Unless there is a suspicion that the treatment affects the underlying sequence, there is not much to be gained from using an input per person.  Unless you have the budget!

Ian, that's fair point. Have there been any papers which implement this strategy?

Maybe it makes more sense to analyze the pilot experiment and proceed accordingly. If you sequence 2 cases and 2 controls (both ChIPs and Inputs - i.e. 8 libraries) in one lane using barcoding, you will get an idea of the actual libraries construction limitations (if any), of the sequence depth, and of the variability between Inputs. If there are no time constraints, I would suggest to perform peak calling versus each respective Input per sample, and versus all the combined Inputs to see the differences in peaks. If for example, you see than no great differences arise after analysis versus different Inputs, I would randomly choose a few only inputs and I would include maybe 1 input per lane to control for the sequencing run as well. Unfortunately, the budget and time-constraints of the project will play the most significant role in your overall design. Good luck!

I ran a small unpublished experiment where I used an input from another experiment (same cell line) and got broadly similar results, in terms of peak numbers.  I cannot put my finger on a particular study, but I don't think this is an unusual strategy.

EDIT: reference to ENCODE guidelines, see "Controls" P7 in 'https://genome.ucsc.edu/encode/protocols/dataStandards/ChIP_DNase_FAIRE_DNAme_v2_2011.pdf'. 

My interpretation being that input is required for changes of condition, treatment, etc.  Obviously the best control is the input split from the IP reaction, but given economic constraints I would argue a pooled input will (on the whole) give similar results.

EDIT2: a 2014 seqanswers discussion gives evidence for both sides of the debate, however my sentiment is nicely summised by 'dbrg77', see end of 'http://seqanswers.com/forums/showthread.php?t=35377'.

I agree with Ian. We have frequently run ChIP-seq experiments where we pool all Inputs and only sequence the pool instead of each independent input. Optimal of course is sequencing each individual but most times the pool is sufficient. I would also recommend to always run a control qPCR on a small aliquot of your IP with positive and negative control primers for your target of interest before creating libraries.

Hi

It is critical to always include unspecific IgG control samples because ChIP assays do not generate uniform unspecific background signals that can be compensated for by global mathematical models. On the contrary, the ChIP background signal is a mix of general background noise and strong highly local signals that can only be detected and compensated for by experimental data.

Also be very careful when choosing the program for peak calling and analysis ( http://nar.oxfordjournals.org/content/40/9/e70.long). Some programs are truly abysmal in their performance.

Best/P