HTqPCR : readCtData problem?
1
0
Entering edit mode
Heidi Dvinge ★ 2.0k
@heidi-dvinge-2195
Last seen 10.3 years ago
> Dear Heidi, > > In HTqPCR I am getting a strange toptable where it looks like it is > treating probes in biological replicates as separate > probes. > Dear Steve, just to clear my mind here, exactly what type of replicates are we talking about? 1) The same miRNA is present three times on the qPCR card for each sample? Per default, this isn't taken into account by limmaCtData. You'll need to resort your qPCRset by featureNames(), so that all triplicates are next to each other, and then call limmaCtData(..., ndups=3, spacing=1) to indicate the number of duplications (3) and the spacing between them (1, since they are adjacent in the resorted qPCRset). As I recall, there's an example of this in ?limmaCtData with duplicate spots. 2) The same miRNA is present three times on the qPCR card, but in different "lanes" belonging to different samples? In that case the qPCRset will ahve to be reformatted after readCtData, to reflect that there are multiple samples on each 384 well card. changeCtLayout () should give some examples on this, although I admit that the vignettes could use some more examples on this. I'm asking since in the example you present below, you say you're reading in a file with 3 samples (which BTW looks fine), but according to you design matrix you have 8 different samples. (more below) > For example: > > 68 hsa-miR-629-4395547 N14 -2.462024092 0.018610579 0.707201997 -4.648018479 25.07223112 35.08434984 39.73236831 > Undetermined Undetermined > 144 hsa-miR-629-4395547 N14 -2.462024092 0.018610579 0.707201997 -4.648018479 25.07223112 35.08434984 39.73236831 > Undetermined Undetermined > 220 hsa-miR-629-4395547 N14 -2.462024092 0.018610579 0.707201997 -4.648018479 25.07223112 35.08434984 39.73236831 > Undetermined Undetermined > 5 hsa-miR-107-4373154 C13 -1.917877218 0.062890552 0.794930138 -4.173391821 18.0433063 33.48123219 37.65462402 OK > Undetermined > 81 hsa-miR-107-4373154 C13 -1.917877218 0.062890552 0.794930138 -4.173391821 18.0433063 33.48123219 37.65462402 OK > Undetermined > 157 hsa-miR-107-4373154 C13 -1.917877218 0.062890552 0.794930138 -4.173391821 18.0433063 33.48123219 37.65462402 OK > Undetermined > > > I am using: > > raw<-readCtData(files = files$File, > path=".",SDS=TRUE,n.data=3,samples=samples) > > There are 3 replicates per file and the header looks like: > > SDS 2.4 RQ Results 1.2 > Filename 7.10.10 8A.2.sdm > Assay Type RQ Study > EmbeddedFile 8A 13.9.10 A > Run DateTime Mon Sep 13 17:08:13 BST 2010 > Operator > ThermalCycleParams > EmbeddedFile 8B 14.9.10 A > Run DateTime Tue Sep 14 15:02:13 BST 2010 > Operator > ThermalCycleParams > EmbeddedFile 8C 15.9.10 A > Run DateTime Wed Sep 15 14:45:18 BST 2010 > Operator > ThermalCycleParams > > # Plate Pos Flag Sample Detector Task Ct > Delta Ct Avg Delta Ct ?Ct SE Delta > Delta Ct SDRQ RQ Min RQ Max Omit HMD FOS LME NAW > EW BPR HRN HNS EAF BAF > TAF CAF HS > D > > > Would readCtData parse this type of file correctly? > This should be okay. Per default, readCtData reads the beginning of the file and discards everything prior to the line beginning with "#". Everything following that is considered the actual data, and n.features*n.data lines are read in, in your case 384*3, and this is split into 3 different samples. HTH \Heidi > > Here are my design and contrast matrices, which I think look fine. > > > > design > SAMP1 SAMP2 SAMP3 SAMP4 SAMP5 SAMP6 SAMP7 SAMP8 > 1 1 0 0 0 0 0 0 0 > 2 1 0 0 0 0 0 0 0 > 3 1 0 0 0 0 0 0 0 > 4 0 1 0 0 0 0 0 0 > 5 0 1 0 0 0 0 0 0 > 6 0 1 0 0 0 0 0 0 > 7 0 0 1 0 0 0 0 0 > 8 0 0 1 0 0 0 0 0 > 9 0 0 1 0 0 0 0 0 > 10 0 0 0 1 0 0 0 0 > 11 0 0 0 1 0 0 0 0 > 12 0 0 0 1 0 0 0 0 > 13 0 0 0 0 1 0 0 0 > 14 0 0 0 0 1 0 0 0 > 15 0 0 0 0 1 0 0 0 > 16 0 0 0 0 0 1 0 0 > 17 0 0 0 0 0 1 0 0 > 18 0 0 0 0 0 1 0 0 > 19 0 0 0 0 0 0 1 0 > 20 0 0 0 0 0 0 1 0 > 21 0 0 0 0 0 0 1 0 > 22 0 0 0 0 0 0 0 1 > 23 0 0 0 0 0 0 0 1 > 24 0 0 0 0 0 0 0 1 > attr(,"assign") > [1] 1 1 1 1 1 1 1 1 > attr(,"contrasts") > attr(,"contrasts")$SAMP > [1] "contr.treatment" > > cont.matrix > Contrasts > Levels C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 C11 C12 > SAMP1 -1 0 0 0 1 0 0 0 0 -1 0 0 > SAMP2 1 0 0 0 0 0 -1 0 -1 0 0 0 > SAMP3 0 -1 0 0 -1 0 0 0 0 0 0 -1 > SAMP4 0 1 0 0 0 0 1 0 0 0 -1 0 > SAMP5 0 0 -1 0 0 1 0 0 0 1 0 0 > SAMP6 0 0 1 0 0 0 0 -1 1 0 0 0 > SAMP7 0 0 0 -1 0 -1 0 0 0 0 0 1 > SAMP8 0 0 0 1 0 0 0 1 0 0 1 0 > > > > I am finally running the command: > > qDE.limma<-limmaCtData(sr.norm,design=design,contrasts=cont.matrix) > > Let me know if you need more information. > > Kind regards and thanks, > > Steve > ============================================ > Head of Computational Biology Research Group > Weatherall Institute of Molecular Medicine > University of Oxford > John Radcliffe Hospital > Headington > Oxford OX3 9DS > +44 1865 222640 >
miRNA qPCR HTqPCR miRNA qPCR HTqPCR • 1.6k views
ADD COMMENT
0
Entering edit mode
Heidi Dvinge ★ 2.0k
@heidi-dvinge-2195
Last seen 10.3 years ago
Hello Steve, thanks for sending me the file, I've just tried playing with it. ndups is indeed for technical replicates, so you don't need that here. Apparently there's a bug hiding somewhere. The results look correct so the biological replicates are actually taken into account, but the entire output is repeated 3 times. Hence, each feature (miRNA in your case) is present 3 times, with identical t and p-values. This is the case even if the design file is manipulated to contain 2 replicates of each sample instead of 3. I.e. limmaCtData does not report an individual result for each biological replicate, but does consider them jointly as you would want. I'll try to figure our why/when this happens, but in the meantime you can just ignore the duplication of the results. Sorry for the hassle this might cause you. It never ceases to amaze me what bugs I somehow manage to introduce into my code :) Just for my debugging purposes, how do you read in all 8 files containing your 24 samples? Do you run readCtData(files=c("file1", ..., "file8"), ...) with 3 samples in each file => qPCRset object with 384x24 rows/columns? Or do you read each file into a separate qPCRset object => 8 qPCRset objects with 384x3 rows/columns and then combine them with cbind()? HTH \Heidi > Dear Heidi, > >> just to clear my mind here, exactly what type of replicates are we >> talking >> about? > > Biological. > >> >> 1) The same miRNA is present three times on the qPCR card for each >> sample? >> Per default, this isn't taken into account by limmaCtData. You'll need >> to >> resort your qPCRset by featureNames(), so that all triplicates are next >> to >> each other, and then call limmaCtData(..., ndups=3, spacing=1) to >> indicate >> the number of duplications (3) and the spacing between them (1, since >> they >> are adjacent in the resorted qPCRset). As I recall, there's an example >> of >> this in ?limmaCtData with duplicate spots. >> > > These are separate arrays really because they are biological replicates. > Isn't ndups in limma is usually for technical > replicates? > >> 2) The same miRNA is present three times on the qPCR card, but in >> different "lanes" belonging to different samples? In that case the >> qPCRset >> will ahve to be reformatted after readCtData, to reflect that there are >> multiple samples on each 384 well card. changeCtLayout () should give >> some >> examples on this, although I admit that the vignettes could use some >> more >> examples on this. >> >> I'm asking since in the example you present below, you say you're >> reading >> in a file with 3 samples (which BTW looks fine), but according to you >> design matrix you have 8 different samples. >> > > So there are 8 files, each containing 3 x 384 wells for each biological > replicate, which is where the 24 comes from. > > I have attached one of the files for you to look at ( I didn't include > this to BioC for that reason ). > > I have got the user to export each file separately, so each replicate is > in a separate file. Will HTqPCR be able to > process this correctly in that case? > > Kind regards and thanks, > > Steve > ============================================ > Head of Computational Biology Research Group > Weatherall Institute of Molecular Medicine > University of Oxford > John Radcliffe Hospital > Headington > Oxford OX3 9DS > +44 1865 222640 >
ADD COMMENT
0
Entering edit mode
Dear Heidi, > > thanks for sending me the file, I've just tried playing with it. > > ndups is indeed for technical replicates, so you don't need that here. > Apparently there's a bug hiding somewhere. The results look correct so the > biological replicates are actually taken into account, but the entire > output is repeated 3 times. Hence, each feature (miRNA in your case) is > present 3 times, with identical t and p-values. This is the case even if > the design file is manipulated to contain 2 replicates of each sample > instead of 3. I.e. limmaCtData does not report an individual result for > each biological replicate, but does consider them jointly as you would > want. That's a shame...I was hoping the high p values I am getting were due to the fact that the biological replicates *weren't* being taken into account. > > I'll try to figure our why/when this happens, but in the meantime you can > just ignore the duplication of the results. Sorry for the hassle this > might cause you. > Thanks. No problem. > It never ceases to amaze me what bugs I somehow manage to introduce into > my code :) > :-) > Just for my debugging purposes, how do you read in all 8 files containing > your 24 samples? Do you run readCtData(files=c("file1", ..., "file8"), > ...) with 3 samples in each file => qPCRset object with 384x24 > rows/columns? Or do you read each file into a separate qPCRset object => 8 > qPCRset objects with 384x3 rows/columns and then combine them with > cbind()? As it says in the manual: raw<-readCtData(files = files$File, path=".",SDS=TRUE,n.data=3,samples=samples_A) > files$File [1] 1A.txt 2A.txt 3A.txt 4A.txt 5A.txt 6A.txt 7A.txt 8A.txt Levels: 1A.txt 2A.txt 3A.txt 4A.txt 5A.txt 6A.txt 7A.txt 8A.txt Thanks, Steve > >> Dear Heidi, >> >>> just to clear my mind here, exactly what type of replicates are we >>> talking >>> about? >> >> Biological. >> >>> >>> 1) The same miRNA is present three times on the qPCR card for each >>> sample? >>> Per default, this isn't taken into account by limmaCtData. You'll need >>> to >>> resort your qPCRset by featureNames(), so that all triplicates are next >>> to >>> each other, and then call limmaCtData(..., ndups=3, spacing=1) to >>> indicate >>> the number of duplications (3) and the spacing between them (1, since >>> they >>> are adjacent in the resorted qPCRset). As I recall, there's an example >>> of >>> this in ?limmaCtData with duplicate spots. >>> >> >> These are separate arrays really because they are biological replicates. >> Isn't ndups in limma is usually for technical >> replicates? >> >>> 2) The same miRNA is present three times on the qPCR card, but in >>> different "lanes" belonging to different samples? In that case the >>> qPCRset >>> will ahve to be reformatted after readCtData, to reflect that there are >>> multiple samples on each 384 well card. changeCtLayout () should give >>> some >>> examples on this, although I admit that the vignettes could use some >>> more >>> examples on this. >>> >>> I'm asking since in the example you present below, you say you're >>> reading >>> in a file with 3 samples (which BTW looks fine), but according to you >>> design matrix you have 8 different samples. >>> >> >> So there are 8 files, each containing 3 x 384 wells for each biological >> replicate, which is where the 24 comes from. >> >> I have attached one of the files for you to look at ( I didn't include >> this to BioC for that reason ). >> >> I have got the user to export each file separately, so each replicate is >> in a separate file. Will HTqPCR be able to >> process this correctly in that case? >> >> Kind regards and thanks, >> >> Steve >>
ADD REPLY

Login before adding your answer.

Traffic: 742 users visited in the last hour
Help About
FAQ
Access RSS
API
Stats

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.

Powered by the version 2.3.6