I extract the data and plot all the curves myself in Origin:) You may find it's much easier to control in this way, and the file can be saved for later revise, although it takes time.
Sincerely, Ling Yang -----Original Message----- From: Luca Lutterotti [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 21, 2007 4:37 PM To: rietveld_l@ill.fr Subject: Re: Powder Diffraction In Q-Space Alan, I do not want to take the decision out of the author, but the contrary. When programs just only plot in one scale, than the author is forced to use that one. Can I plot in square root or in Q space with Topas if I like to do that? cheers, Luca On Feb 21, 2007, at 10:28 PM, AlanCoelho wrote: > > > I was not aware of Journals having rules stating that data must be > plotted > in square root scale and this is precisely the point. I certainly > do not > want an edict stating that authors must do so. It should be up to > the author > to choose whatever x-axis and y-axis scales that best shows up > features. > > If an author is writing a paper on an instrumet correction, say for > example > cylindrical or PSD correction, then it is sensible to use 2Th. > > Thus please do not take these decisions away from the author. > > And I was referring to the Fourier transform of the whole pattern > as is done > in PDF work not on a peak by peak basis for correcting aberrations. I > brought up the point because when people talk about Q space > especially for > comparison purposes there's typcally a conversion to Q space. A > quick visual > display opearting on a point by point basis is adequate in most > cases but > for analysis the conversion should be done properly; a point missed > by many. > > cheers > alan > > -----Original Message----- > From: Luca Lutterotti [mailto:[EMAIL PROTECTED] > Sent: Thursday, 22 February 2007 6:59 AM > To: rietveld_l@ill.fr > Subject: Re: Powder Diffraction In Q-Space > > Alan, > > if it is trivial to plot in the square root I presume it is already > available in Topas as well GSAS and Fullprof just to mention few. And > if it is so trivial and already available as a button options why no > one is using it. Why every time I look at a paper with a Rietveld > refinement I can only appreciate the big peaks and why the residuals > are so little meaningful at end? Every one can choose what he prefers > obviously, but why all (without exceptions) are using not exactly the > best way to just do a plot? Should not be trivial? > > Conversion from 2theta - d -1/d is trivial in MY OPINION. This is > really a problem of the programmer not of the users (in a Rietveld > list). Constant step or variable step? Why it should influence the > conversion except for the speed of the conversion. I am using fast > fourier transform in my program for computing peak profiles directly > from distribution of crystallites and microstrain; I don't assume any > constant step, but seems like I can do it. > > And this step or FT has really nothing to do with the original post > of Klaus-Dieter who was focusing on just asking people if we can try > to get used to a common way to plot data different from the > conventional one. There are obviously favorable points and cons. Why > we cannot discuss it. Seems like for the Rietveld users is not so > trivial. > > Oh, and no one is setting up web sites just to show > opinions.........may be these were already there....... > > Cheers, > Luca > > On Feb 21, 2007, at 8:11 PM, AlanCoelho wrote: > >> >> Whether a program has a button to display data as a function of 1/d >> or a >> button to take the square toor of intensities is trivial to the >> point of not >> being talked about much less setting up web sites to get opinions. >> >> The only point worth talking about is how a conversion from 2Th to >> 1/d is >> done in regards to takeing the fourier transform of a powder pattern. >> >> alan >> >> >> -----Original Message----- >> From: Joerg Bergmann [mailto:[EMAIL PROTECTED] >> Sent: Thursday, 22 February 2007 4:30 AM >> To: rietveld_l@ill.fr >> Subject: Re: Powder Diffraction In Q-Space >> >> It's a principle of software design not to presume any kind of >> equidistant data. Unfortunately, file formats for non-equidistant >> data are seldom. So I could not implement any in BGMN, until now. >> But, in principle, there is no restriction. >> >> Regards >> >> Joerg Bergmann >> >> >> > > >
