Hi Rory,

I sorted the problem out, it apparently was a lack of memory in the old 
server. I could not think that summarizeOverlaps was so demanding on 
these very deeply sequenced samples.

Still, I have one additional question for you.
I am trying to understand what DiffBind is doing for the normalization 
with the control sample. Could you elaborate the concept a little more? 
Is the raw count subtracted/rounded and subtracted or something else?
I am asking because I see that a lot of regions get quite low values in 
the final report (shown with the bCounts=TRUE option) even if the peak 
caller identified peaks over there.

Thanks in advance for the explanation! And once again, thank you for the 
nice tool you provided.

Federico


On 20.03.14 16:08, Rory Stark wrote:
> Hi Frederico-
>
> Let me know when you are able to use a recent build of DiffBind to see 
> fi it works on your paord-end data.
>
> At some point I'll probably need access to at least a subset of the 
> experiment (eg using Dropbox) so I can debug any further problems you 
> may be having.
>
> Cheers-
> Rory
>
> From: Federico Marini <marinif@uni-mainz.de <mailto:marinif@uni-mainz.de>>
> Date: Tue, 4 Mar 2014 15:21:44 +0100
> To: Rory Stark <rory.stark@cruk.cam.ac.uk 
> <mailto:rory.stark@cruk.cam.ac.uk>>
> Subject: Re: DiffBind and paired end data
>
> Dear Rory,
>
> Great to hear back from you. And even better to read that the feature 
> is going to be implemented soon.
>
> So far I am trying it then with bUseSummarizeOverlaps = TRUE and with 
> DBA$config$singleEnd <- FALSE before calling the dba.count.
> I got this warning message during the count operations:
>
>     Warnung in FUN(bf, param = param) : 'yieldSize' set to 'NA'
>
>     # (8 times, I assume it is due to the 8 samples in total -
>     triplicates + respective input, 2 conditions)
>
>
> The counting part still takes quite a very long time to perform. When 
> it was done, I sadly got this error message (sorry for some parts in 
> german):
>
>     Fehler: Error processing one or more read files. Check warnings().
>     Zusätzlich: Warnmeldungen:
>     1: In mclapply(arglist, fn, ..., mc.preschedule = TRUE,
>     mc.allow.recursive = TRUE) :
>       scheduled cores 2 encountered errors in user code, all values of
>     the jobs will be affected
>     2:
>     3:   Fehler bei der Auswertung des Argumentes 'x' bei der
>     Methodenauswahl
>     4:
>     5:
>     6:
>     7:   Fehler bei der Auswertung des Argumentes 'x' bei der
>     Methodenauswahl
>     8:
>
>
> The sessionInfo for this is as follows:
>
>     sessionInfo()
>     R version 3.0.2 (2013-09-25)
>     Platform: x86_64-pc-linux-gnu (64-bit)
>
>     locale:
>      [1] LC_CTYPE=de_DE.UTF-8 LC_NUMERIC=C
>      [3] LC_TIME=de_DE.UTF-8 LC_COLLATE=de_DE.UTF-8
>      [5] LC_MONETARY=de_DE.UTF-8 LC_MESSAGES=de_DE.UTF-8
>      [7] LC_PAPER=de_DE.UTF-8 LC_NAME=C
>      [9] LC_ADDRESS=C LC_TELEPHONE=C
>     [11] LC_MEASUREMENT=de_DE.UTF-8 LC_IDENTIFICATION=C
>
>     attached base packages:
>     [1] parallel  stats     graphics  grDevices utils     datasets 
>     methods
>     [8] base
>
>     other attached packages:
>     [1] Rsamtools_1.14.3     Biostrings_2.30.1 DiffBind_1.8.4
>     [4] GenomicRanges_1.14.4 XVector_0.2.0 IRanges_1.20.6
>     [7] BiocGenerics_0.8.0
>
>     loaded via a namespace (and not attached):
>      [1] amap_0.8-11        bitops_1.0-6 caTools_1.16       edgeR_3.4.2
>      [5] gdata_2.13.2       gplots_2.12.1 gtools_3.3.0      
>     KernSmooth_2.23-10
>      [9] limma_3.18.13      RColorBrewer_1.0-5 stats4_3.0.2      
>     tools_3.0.2
>     [13] zlibbioc_1.8.0
>
>
>
> Will you also plan to implement the recent featureCounts, too? This 
> could possibly speed up massively the operations, I guess.
>
> If I'd ask you from your hands-on experience, what is a "good" number 
> of DB sites? I assume this is not a one size fits all situation, but 
> just as an overall idea it could help to have some numbers.
>
> Thank you again for replying, and I will get back to you as soon as I 
> have a better idea of what possibly went wrong.
>
> Best regards,
>
> Federico
>
>
>
> On 04.03.14 12:36, Rory Stark wrote:
>> Hi Frederico-
>>
>> Looks like you've got it just about right — you want to use the 
>> bUseSummarizedOverlaps option. For paired end, you don't need to set 
>> the insert length (changed to fragmentSize moving forward) as with 
>> paired end data the size of each fragment is known.
>>
>> I will add the option to set the fragments parameter (in 
>> DBA$config$fragments), it should appear in the development version 1.9.9.
>>
>> Do let me know if you have any problems wit this, as this is a 
>> scenario we'd really like to see work and can help debugging if there 
>> are issues.
>>
>> Cheers-
>> Rory
>>
>> From: Federico Marini <marinif@uni-mainz.de 
>> <mailto:marinif@uni-mainz.de>>
>> Date: Mon, 24 Feb 2014 14:51:49 +0100
>> To: Rory Stark <rory.stark@cruk.cam.ac.uk 
>> <mailto:rory.stark@cruk.cam.ac.uk>>
>> Subject: DiffBind and paired end data
>>
>> Dear Dr. Stark,
>>
>> I had the pleasure to attend ("back then in 2013") to the 
>> presentation you gave at the EBI Advanced Course for RNA-seq and 
>> ChIP-seq, where you introduced DiffBind and its usage examples.
>>
>> Now I moved from IMB - Mainz and I am working in the Biostatistics 
>> department of the University of Medical Center in Mainz as a research 
>> associate, where I also have the chance of doing my PhD.
>>
>> I contact you regarding indeed DiffBind, and the possibility of doing 
>> differential binding analysis for ChIP-seq paired end data. As one of 
>> our collaborators recently produced such datasets, and they would 
>> like to investigate the aspect of changes in the binding for TFs and 
>> histone modifications, I thought the DiffBind framework would be a 
>> very solid solution for analysis.
>>
>> The doubt I have, is whether DiffBind can use the information of the 
>> paired end data, and how. Ideally I guess the best way would be this: 
>> properly paired reads will be counted just once for each of the ends, 
>> and singletons(/not properly paired) will also count one.
>>
>> I was following the discussions around 
>> https://stat.ethz.ch/pipermail/bioconductor/2013-June/053394.html, 
>> and it seems that by incorporating the summarizeOverlaps functions it 
>> would be (almost-)possible, but I would like to double check it with you.
>> bUseSummarizeOverlaps would be set to TRUE, DBA$config$singleEnd to 
>> false. Is there anything else I should take into account (e.g. the 
>> insert length in this case would be meaningful?)? Is there also a 
>> parameter to use the "fragment" parameter set to true in the 
>> summarizeOverlaps function?
>>
>> Thank you very much in advance for the attention, and thank you again 
>> for the nice package on top of it!
>>
>> Best regards,
>>
>> Federico
>>
>> -- 
>> *Federico Marini, M.Sc.*
>> Medizinische Biometrie
>> _____________________________________________
>> UNIVERSITÄTSMEDIZIN
>> der Johannes Gutenberg-Universität Mainz
>> Institut für Medizinische Biometrie, Epidemiologie und Informatik (IMBEI)
>> Abteilung Medizinische Biometrie
>> Postanschrift: 55101 Mainz Haus- und Lieferanschrift: Obere 
>> Zahlbacher Str. 69, 55131 Mainz
>> www.imbei.uni-mainz.de
>> Telefon +49 (0) 6131 17-7029
>> Telefax +49 (0) 6131 17-472433
>> E-Mail: federico.marini@unimedizin-mainz.de
>> marinif@uni-mainz.de
>
> -- 
> *Federico Marini, M.Sc.*
> Medizinische Biometrie
> _____________________________________________
> UNIVERSITÄTSMEDIZIN
> der Johannes Gutenberg-Universität Mainz
> Institut für Medizinische Biometrie, Epidemiologie und Informatik (IMBEI)
> Abteilung Medizinische Biometrie
> Postanschrift: 55101 Mainz Haus- und Lieferanschrift: Obere Zahlbacher 
> Str. 69, 55131 Mainz
> www.imbei.uni-mainz.de
> Telefon +49 (0) 6131 17-7029
> Telefax +49 (0) 6131 17-472433
> E-Mail: federico.marini@unimedizin-mainz.de
> marinif@uni-mainz.de

-- 
*Federico Marini, M.Sc.*
Medical Biostatistics
_____________________________________________
University Medical Center of the Johannes Gutenberg University Mainz
Institute of Medical Biostatistics, Epidemiology and Informatics (IMBEI)
Medical Biostatistics Department
Postal address: 55101 Mainz
Office and delivery address: Obere Zahlbacher Str. 69, 55131 Mainz
www.imbei.uni-mainz.de
Phone +49 (0) 6131 17-7029
Fax +49 (0) 6131 17-472433
E-Mail: marinif@uni-mainz.de

	[[alternative HTML version deleted]]

