RE: Advice on print-tip normalization
4
0
Entering edit mode
Mark Reimers ▴ 70
@mark-reimers-658
Last seen 10.2 years ago
Hello Gene, I don't have any advice but some related observations based on looking at regional biases on spotted microarrays. In the slide data that have come in, there seems often to be a bias toward red on the top and bottom edges of the print-tip groups, and a bias toward green in the middle of the print- tip blocks. No explanation occurs to me, but this effect is apparent on most of the arrays. One of our collaborators claims the effect disappears with a more effective washing treatment, but hasn't sent slide images. Such an effect ought to produce the periodicity you comment on below. Has any one else noticed a similar phenomenon? Regards Mark Date: Fri, 17 Sep 2004 10:32:33 -0700 From: Gene Cutler <gcutler@amgen.com> Subject: [BioC] Advice on print-tip normalization To: bioconductor@stat.math.ethz.ch Message-ID: <8EC0413E-08CF-11D9-95E4-000A95C91324@amgen.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Hello. I've just started using the marray package for processing a set of spotted oligo arrays. The arrays, when intensities or log ratios are plotted against probe number, show a clear pattern of rising/falling values with a periodicity equal to the grid block size (~3600 spots). I can see a similar periodicity in the printTip boxplots generated with marray. Running printTipLoess smoothes out the boxplot nicely (and the MA plot also looks much nicer), but, surprisingly, when I export the normalized values and plot them against position, the grid block periodicity is little changed. I've tried different span values for the printTipLoess as well as trying with or without scaling (e.g. printTipMAD), but nothing I do seems to have much effect on this data artifact. Does anyone have any suggestions? Thanks. -- Gene Cutler Research Investigator Bioinformatics Amgen SF Mark Reimers, senior research fellow, National Cancer Inst., and SRA, 9000 Rockville Pike, bldg 37, room 5068 Bethesda MD 20892 [[alternative HTML version deleted]]
Cancer probe marray oligo Cancer probe marray oligo • 1.8k views
ADD COMMENT •
0
Entering edit mode
SAURIN ★ 1.1k
@saurin-799
Last seen 10.2 years ago
Hi BioC, I have problem installing Rgraphviz on my Linux Fedora 2 with 32bit AMD Athlon with 512 RAM login as me: (not as root) I have installed latest graphviz : graphviz-1.16-1.src.rpm $whereis graphviz graphviz: /usr/lib/graphviz /usr/include/graphviz /usr/share/graphviz if do: R CMD INSTALL -l /usr/local/lib/R/library Rgraphviz_1.4.23.tar.gz get get: ERROR: compilation failed for package 'Rgraphviz' If someone has problem like this and solved , please let me know. Thank you, Saurin
ADD COMMENT •
0
Entering edit mode
> R CMD INSTALL -l /usr/local/lib/R/library > Rgraphviz_1.4.23.tar.gz > > get get: > ERROR: compilation failed for package 'Rgraphviz' Would you like to include just a *little* more of the output? Thanks -J
ADD REPLY •
0
Entering edit mode
Hi Jeff, More output of Rgraphviz compilation error: $ R CMD INSTALL -l /usr/local/lib/R/library Rgraphviz_1.4.23.tar.gz I get : -------------------------------- * Installing *source* package 'Rgraphviz' ... checking for graphviz... checking for dotneato-config... /usr/bin/dotneato-config /usr/bin/dotneato-config configure: creating ./config.status config.status: creating src/Makevars ** libs gcc -I/usr/local/lib/R/include -I/usr/include/graphviz -DGRAPHVIZ_1_12 -I/usr/local/include -D__NO_MATH_INLINES -mieee-fp -Wall -fPIC -g -O2 -c Rgraphviz.c -o Rgraphviz.o In file included from /usr/include/graphviz/render.h:49, from common.h:22, from Rgraphviz.c:1: /usr/include/graphviz/macros.h:28:1: warning: "NEW" redefined In file included from common.h:13, from Rgraphviz.c:1: /usr/local/lib/R/include/Rdefines.h:129:1: warning: this is the location of the previous definition In file included from /usr/include/graphviz/types.h:11, from /usr/include/graphviz/render.h:51, from common.h:22, from Rgraphviz.c:1: /usr/include/graphviz/pathplan.h:11: warning: ignoring #pragma prototyped In file included from /usr/include/graphviz/pathplan.h:16, from /usr/include/graphviz/types.h:11, from /usr/include/graphviz/render.h:51, from common.h:22, from Rgraphviz.c:1: /usr/include/graphviz/pathgeom.h:11: warning: ignoring #pragma prototyped In file included from /usr/include/graphviz/render.h:52, from common.h:22, from Rgraphviz.c:1: /usr/include/graphviz/graph.h:11: warning: ignoring #pragma prototyped In file included from /usr/include/graphviz/render.h:55, from common.h:22, from Rgraphviz.c:1: /usr/include/graphviz/gvrender.h:12: warning: ignoring #pragma prototyped In file included from /usr/include/graphviz/gvrender.h:19, from /usr/include/graphviz/render.h:55, from common.h:22, from Rgraphviz.c:1: /usr/include/graphviz/gvrenderint.h:12: warning: ignoring #pragma prototyped In file included from common.h:23, from Rgraphviz.c:1: /usr/include/graphviz/graph.h:11: warning: ignoring #pragma prototyped In file included from common.h:26, from Rgraphviz.c:1: /usr/include/graphviz/adjust.h:11: warning: ignoring #pragma prototyped In file included from common.h:28, from Rgraphviz.c:1: /usr/include/graphviz/gvrender.h:12: warning: ignoring #pragma prototyped gcc -I/usr/local/lib/R/include -I/usr/include/graphviz -DGRAPHVIZ_1_12 -I/usr/local/include -D__NO_MATH_INLINES -mieee-fp -Wall -fPIC -g -O2 -c RgraphvizInit.c -o RgraphvizInit.o In file included from /usr/include/graphviz/render.h:49, from common.h:22, from RgraphvizInit.c:1: /usr/include/graphviz/macros.h:28:1: warning: "NEW" redefined In file included from common.h:13, from RgraphvizInit.c:1: /usr/local/lib/R/include/Rdefines.h:129:1: warning: this is the location of the previous definition In file included from /usr/include/graphviz/types.h:11, from /usr/include/graphviz/render.h:51, from common.h:22, from RgraphvizInit.c:1: /usr/include/graphviz/pathplan.h:11: warning: ignoring #pragma prototyped In file included from /usr/include/graphviz/pathplan.h:16, from /usr/include/graphviz/types.h:11, from /usr/include/graphviz/render.h:51, from common.h:22, from RgraphvizInit.c:1: /usr/include/graphviz/pathgeom.h:11: warning: ignoring #pragma prototyped In file included from /usr/include/graphviz/render.h:52, from common.h:22, from RgraphvizInit.c:1: /usr/include/graphviz/graph.h:11: warning: ignoring #pragma prototyped In file included from /usr/include/graphviz/render.h:55, from common.h:22, from RgraphvizInit.c:1: /usr/include/graphviz/gvrender.h:12: warning: ignoring #pragma prototyped In file included from /usr/include/graphviz/gvrender.h:19, from /usr/include/graphviz/render.h:55, from common.h:22, from RgraphvizInit.c:1: /usr/include/graphviz/gvrenderint.h:12: warning: ignoring #pragma prototyped In file included from common.h:23, from RgraphvizInit.c:1: /usr/include/graphviz/graph.h:11: warning: ignoring #pragma prototyped In file included from common.h:26, from RgraphvizInit.c:1: /usr/include/graphviz/adjust.h:11: warning: ignoring #pragma prototyped In file included from common.h:28, from RgraphvizInit.c:1: /usr/include/graphviz/gvrender.h:12: warning: ignoring #pragma prototyped common.h:33: warning: `gvc' defined but not used gcc -shared -L/usr/local/lib -o Rgraphviz.so Rgraphviz.o RgraphvizInit.o -Wl -L/usr/lib/graphviz -ldotneato -lm /usr/bin/ld: cannot find -ldotneato collect2: ld returned 1 exit status make: *** [Rgraphviz.so] Error 1 ERROR: compilation failed for package 'Rgraphviz' ** Removing '/usr/local/lib/R/library/Rgraphviz' --------------------------------------------- Please let me know... Thank you, Saurin --- Jeff Gentry <jgentry@jimmy.harvard.edu> wrote: > > R CMD INSTALL -l /usr/local/lib/R/library > > Rgraphviz_1.4.23.tar.gz > > > > get get: > > ERROR: compilation failed for package 'Rgraphviz' > > Would you like to include just a *little* more of > the output? > > Thanks > -J > > _______________________________ Declare Yourself - Register online to vote today!
ADD REPLY •
0
Entering edit mode
> /usr/bin/ld: cannot find -ldotneato > collect2: ld returned 1 exit status include the graphviz library dir (e.g. /usr/local/lib/graphviz) in your LD_LIBRARY_PATH.
ADD REPLY •
0
Entering edit mode
@gordon-smyth
Last seen 56 minutes ago
WEHI, Melbourne, Australia
Spots in a given position within a print-tip group are always printed from the same 384-well plate of DNA. Genes of similar function or homology are often grouped together on a plate. If there are systematic differences between plates due to the nature of the probes, this would lead to periodicity through the print-tip groups, but you certainly don't want to remove this structure in the normalization. Gordon > Hello Gene, > I don't have any advice but some related observations based on looking at > regional biases on spotted microarrays. In the slide data that have come in, > there seems often to be a bias toward red on the top and bottom edges of the > print-tip groups, and a bias toward green in the middle of the print-tip > blocks. No explanation occurs to me, but this effect is apparent on most of > the arrays. One of our collaborators claims the effect disappears with a > more effective washing treatment, but hasn't sent slide images. > > Such an effect ought to produce the periodicity you comment on below. > > Has any one else noticed a similar phenomenon? > > > Regards > > Mark > > > Date: Fri, 17 Sep 2004 10:32:33 -0700 > From: Gene Cutler <gcutler@amgen.com> > Subject: [BioC] Advice on print-tip normalization > To: bioconductor@stat.math.ethz.ch > Message-ID: <8EC0413E-08CF-11D9-95E4-000A95C91324@amgen.com> > Content-Type: text/plain; charset=US-ASCII; format=flowed > > Hello. I've just started using the marray package for processing a set > of spotted oligo arrays. The arrays, when intensities or log ratios > are plotted against probe number, show a clear pattern of > rising/falling values with a periodicity equal to the grid block size > (~3600 spots). I can see a similar periodicity in the printTip > boxplots generated with marray. Running printTipLoess smoothes out the > boxplot nicely (and the MA plot also looks much nicer), but, > surprisingly, when I export the normalized values and plot them against > position, the grid block periodicity is little changed. > > I've tried different span values for the printTipLoess as well as > trying with or without scaling (e.g. printTipMAD), but nothing I do > seems to have much effect on this data artifact. > > Does anyone have any suggestions? > > Thanks. > > -- > Gene Cutler > Research Investigator > Bioinformatics > Amgen SF > > > > Mark Reimers, > senior research fellow, > National Cancer Inst., and SRA, > 9000 Rockville Pike, bldg 37, room 5068 > Bethesda MD 20892 > > > [[alternative HTML version deleted]] > > _______________________________________________ > Bioconductor mailing list > Bioconductor@stat.math.ethz.ch > https://stat.ethz.ch/mailman/listinfo/bioconductor >
ADD COMMENT •
0
Entering edit mode
Thanks for everyone's input. I've been looking at the data more carefully and here's what I've found: array geometry: grid = 12 rows x 4 cols, block = 28 rows x 27 cols I see two periodicities. 1) When the intensities are ordered by block column, there are 27 cycles of rising/falling intensities. This gives 1344 spots per cycle which equals 48 columns of spots per cycle. When these 27 cycles are overlayed and averaged together, I can see that each 1344 spot cycle contains another periodicity of 12 cycles: 112 spots per subcycle == 4 columns per subcycle. 2) When the intensities are ordered by block row, there are 12 cycles of rising/falling intensities. This gives 3024 spots per cycle which equals 112 rows of spots per cycle or 4 grid blocks per cycle. When these 12 cycles are overlayed and averaged, I do not see any subcycles. The coincidence of these cycles with whole row and column numbers suggests that it is a print tip effect. I don't really understand print tip geometry yet, so the implications of the numbers above aren't clear to me. Anyway, the marray boxplot shows what looks like a similar that goes away after printTipLoess normalization. However, if I extract the normalized intensities and then plot those, the two cycles I describe above are still evident. >> >> Date: Fri, 17 Sep 2004 10:32:33 -0700 >> From: Gene Cutler <gcutler@amgen.com> >> Subject: [BioC] Advice on print-tip normalization >> >> Hello. I've just started using the marray package for processing a >> set >> of spotted oligo arrays. The arrays, when intensities or log ratios >> are plotted against probe number, show a clear pattern of >> rising/falling values with a periodicity equal to the grid block size >> (~3600 spots). I can see a similar periodicity in the printTip >> boxplots generated with marray. Running printTipLoess smoothes out >> the >> boxplot nicely (and the MA plot also looks much nicer), but, >> surprisingly, when I export the normalized values and plot them >> against >> position, the grid block periodicity is little changed. >> >> I've tried different span values for the printTipLoess as well as >> trying with or without scaling (e.g. printTipMAD), but nothing I do >> seems to have much effect on this data artifact. >> >> Gene Cutler Research Investigator Bioinformatics Amgen SF
ADD REPLY •
0
Entering edit mode
Ramon Diaz ★ 1.1k
@ramon-diaz-159
Last seen 10.2 years ago
Dear Mark and Gene, With regards to the periodicity the "Print-order normalization of cDNA microarrays" by Gordon Smyth (http://www.statsci.org/smyth/pubs/porder/porder.html) could be of interest. I do have observed sometimes these print order effects here, and have used the approaches suggested in Smyth's document. Best, R. On Wednesday 22 September 2004 15:11, Reimers, Mark (NIH/NCI) wrote: > Hello Gene, > I don't have any advice but some related observations based on looking at > regional biases on spotted microarrays. In the slide data that have come > in, there seems often to be a bias toward red on the top and bottom edges > of the print-tip groups, and a bias toward green in the middle of the > print-tip blocks. No explanation occurs to me, but this effect is apparent > on most of the arrays. One of our collaborators claims the effect > disappears with a more effective washing treatment, but hasn't sent slide > images. > > Such an effect ought to produce the periodicity you comment on below. > > Has any one else noticed a similar phenomenon? > > > Regards > > Mark > > > Date: Fri, 17 Sep 2004 10:32:33 -0700 > From: Gene Cutler <gcutler@amgen.com> > Subject: [BioC] Advice on print-tip normalization > To: bioconductor@stat.math.ethz.ch > Message-ID: <8EC0413E-08CF-11D9-95E4-000A95C91324@amgen.com> > Content-Type: text/plain; charset=US-ASCII; format=flowed > > Hello. I've just started using the marray package for processing a set > of spotted oligo arrays. The arrays, when intensities or log ratios > are plotted against probe number, show a clear pattern of > rising/falling values with a periodicity equal to the grid block size > (~3600 spots). I can see a similar periodicity in the printTip > boxplots generated with marray. Running printTipLoess smoothes out the > boxplot nicely (and the MA plot also looks much nicer), but, > surprisingly, when I export the normalized values and plot them against > position, the grid block periodicity is little changed. > > I've tried different span values for the printTipLoess as well as > trying with or without scaling (e.g. printTipMAD), but nothing I do > seems to have much effect on this data artifact. > > Does anyone have any suggestions? > > Thanks. > > -- > Gene Cutler > Research Investigator > Bioinformatics > Amgen SF > > > > Mark Reimers, > senior research fellow, > National Cancer Inst., and SRA, > 9000 Rockville Pike, bldg 37, room 5068 > Bethesda MD 20892 > > > [[alternative HTML version deleted]] > > _______________________________________________ > Bioconductor mailing list > Bioconductor@stat.math.ethz.ch > https://stat.ethz.ch/mailman/listinfo/bioconductor -- Ram?n D?az-Uriarte Bioinformatics Unit Centro Nacional de Investigaciones Oncol?gicas (CNIO) (Spanish National Cancer Center) Melchor Fern?ndez Almagro, 3 28029 Madrid (Spain) Fax: +-34-91-224-6972 Phone: +-34-91-224-6900 http://ligarto.org/rdiaz PGP KeyID: 0xE89B3462 (http://ligarto.org/rdiaz/0xE89B3462.asc)
ADD COMMENT •
0
Entering edit mode
Gene Cutler ▴ 50
@gene-cutler-916
Last seen 10.2 years ago
On Sep 22, 2004, at 6:11 AM, Reimers, Mark (NIH/NCI) wrote: > Hello Gene, > I don't have any advice but some related observations based on looking > at regional biases on spotted microarrays. In the slide data that have > come in, there seems often to be a bias toward red on the top and > bottom edges of the print-tip groups, and a bias toward green in the > middle of the print-tip blocks. No explanation occurs to me, but this > effect is apparent on most of the arrays. One of our collaborators > claims the effect disappears with a more effective washing treatment, > but hasn't sent slide images. > What I'm seeing are largely overlapping periodicities in both channels. The intensities start low at the beginning of a block, peak in the middle, and go down again at the end. This repeats in each of the 48 blocks across the slide, getting more exaggerated across the array. This is accompanied by a greater scatter in the intensity ratios, with much more noise in the center of the grids, where both channel intensities are highest. Gene Cutler Research Investigator Bioinformatics Amgen SF 1120 Veterans Blvd. South San Francisco, CA 94080 (650) 244-2489
ADD COMMENT •
0
Entering edit mode
Probably a stupid suggestion but here goes. It seems like differing amount of probes are being deposited systematically. So, is there a way to check if your print tips are all level or the spotting/washing well which the print tip comes in contact with is level as well ? On Thu, 2004-09-23 at 17:27, Gene Cutler wrote: > On Sep 22, 2004, at 6:11 AM, Reimers, Mark (NIH/NCI) wrote: > > > Hello Gene, > > I don't have any advice but some related observations based on looking > > at regional biases on spotted microarrays. In the slide data that have > > come in, there seems often to be a bias toward red on the top and > > bottom edges of the print-tip groups, and a bias toward green in the > > middle of the print-tip blocks. No explanation occurs to me, but this > > effect is apparent on most of the arrays. One of our collaborators > > claims the effect disappears with a more effective washing treatment, > > but hasn't sent slide images. > > > > What I'm seeing are largely overlapping periodicities in both channels. > The intensities start low at the beginning of a block, peak in the > middle, and go down again at the end. This repeats in each of the 48 > blocks across the slide, getting more exaggerated across the array. > This is accompanied by a greater scatter in the intensity ratios, with > much more noise in the center of the grids, where both channel > intensities are highest. > > > > > > > Gene Cutler > Research Investigator > Bioinformatics > > Amgen SF > 1120 Veterans Blvd. > South San Francisco, CA 94080 > (650) 244-2489 > > _______________________________________________ > Bioconductor mailing list > Bioconductor@stat.math.ethz.ch > https://stat.ethz.ch/mailman/listinfo/bioconductor >
ADD REPLY •

Login before adding your answer.

Similar Posts
Loading Similar Posts
Traffic: 826 users visited in the last hour
Content Search
Users
Tags
Badges
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