ICDD and the Rietveld Method a subject discussed on the Rietveld Mailing List Hi all, A subject for discussion. Please reply to all. Two years ago a colleague and me submitted a paper to the Powder Diffraction journal. It was a simple ab initio structure determination. We faced the problem to give the dobs, Iobs and hkl list. The paper was constructed in order to defend the point of view that the Iobs should be the "Iobs" from the final Rietveld refinement. Moreover, we proposed to put a "R" mark on the JCPDS files which would present such Rietveld data. Note that a problem is that we could have all "Iobs", all dcalcs, all hkls, but certainly not all dobs in the ICDD-JCPDS sense... This part of the article was not accepted. The editor suggested us to rebuild it and to submit our views to ICDD, arguing that they were already considering this possibility for a "R" mark. We do it. Since that, no response from ICDD. Opinions ? Armel Le Bail - Laboratoire des Fluorures, CNRS-URA-449, Universite du Maine, 72017 Le Mans Cedex, FRANCE - armel@ONE.univ-lemans.fr From: SMTP%"X-rayX-press" 11-NOV-1995 17:42:57.64 To: armel CC: Subj: Rietveld patterns in the PDF Armel Le Bail brings up a complicated question that has been the subject of extensive debate at the ICDD. The fundamental problem is as follows: The primary use of the PDF is phase ID. If the PDF reference pattern lists more lines as being present than a normal resolution diffraction pattern would observe, then a user might reject the reference as not matching his unknown. So the problem with a Rietveld refinement is that it "knows" a lot more about the pattern than a "blind" second derivative peak picker would "know". The intensities of lines in a, Rietveld refined, unresolved cluster are not really "observed" - they are more "inferred" from the model and consistent with the refinement. Reporting them as a normal observed intensity is not only incorrect it could lead to a failure to correctly identify the phase. Fundamentally the ds and Is obtained from a Rietveld refinement are some kind of hybrid between observed and calculated. Another problem is that preferred orientation and other pattern distortions have been modeled in a way that the refined pattern will not even agree with a simple calculated pattern (from structure factors only). So, some have argued to simply not include structurally refined patterns in the file. However, this policy would not only lose important patterns - leaving no possibility of a phase identification by a PDF user, it would reject some of the best powder patterns flowing into the literature. Others argue that the Rietveld pattern be run through a conventional peak picker and the resolvable peaks be listed in the PDF. This approach would mean that most Rietveld patterns would never make it to the PDF because many authors would not care (or have the facilities) to cooperate. The solution adopted by the ICDD has been to include the Rietveld pattern in the PDF with a special "R" quality mark on it, to warn users of the PDF of its origin. This leave open questions as to how lines are to be extracted from the observed pattern to be reported. Are lines too close together to ever be observable on a diffractometer to be listed as separate "observed" lines? Did the authors of the article allow for some kind of resolution function in preparing their list? etc. In fact, the ICDD as usual takes the authors data as they report it and prepare the PDF entry. These solutions are not perfect but it was the best that the debate in the ICDD technical committee could come up with. We would welcome other ideas and I think Armel has started a particular good example of the use of this mail server. Bob Snyder NYS College of Ceramics Alfred University Alfred NY 14802 > Hi all, > A subject for discussion. Please reply to all. Two years ago >a colleague and me submitted a paper to the Powder Diffraction >journal. It was a simple ab initio structure determination. We >faced the problem to give the dobs, Iobs and hkl list. The paper >was constructed in order to defend the point of view that the >Iobs should be the "Iobs" from the final Rietveld refinement. >Moreover, we proposed to put a "R" mark on the JCPDS files which >would present such Rietveld data. Note that a problem is that >we could have all "Iobs", all dcalcs, all hkls, but certainly not >all dobs in the ICDD-JCPDS sense... > This part of the article was not accepted. The editor suggested >us to rebuild it and to submit our views to ICDD, arguing that they >were already considering this possibility for a "R" mark. We do it. >Since that, no response from ICDD. > Opinions ? > >Armel Le Bail - Laboratoire des Fluorures, CNRS-URA-449, > Universite du Maine, 72017 Le Mans Cedex, FRANCE - > armel@ONE.univ-lemans.fr ================== RFC 822 Headers ================== From: SMTP%"LachlanCranswick" 11-NOV-1995 19:31:41.58 To: armel CC: Subj: Re: "R" mark in the JCPDS-ICDD Forwarded message: > Reply-To: X-ray X-press > > The primary use of the PDF is phase ID. If the PDF reference > pattern lists more lines as being present than a normal resolution > diffraction pattern would observe, then a user might reject the reference > as not matching his unknown. From a user point of view, it would be handy for phase ID to have ICDD cards for phases collected under a variety of conditions (diffractometer, film, flat plate, micro-diffractometer, capilliary, Gandolfi, calculated, single wavelength, double wavelength, etc). While a bit off topic, this relates to having both (Rietveld) calculated data and the raw data as well. ============== We have had phase ID examples where the ICDD had the patterns for the raw data - but data calculated from the structure was more appropriate. Perhaps this could be due to more people using modern diffractometers with monochromators and sensitive detectors while many current cards were collected on film or less sophisticated equipment? ============= For Rietveld data, having HKL's very close should not be a problem for most modern search match programs as it should be visually obvious when peaks are overlapping? (Though it would be interesting to see what the present search match algorithms would make of matching a phase with 3 HKLs very close to each other in the ICDD card when only one raw data peak is visible?) ============== Rietveld preferred orientation and other corrections could be a thorny one. Perhaps a solution is to mention in the card that preferred orientation was used and on which HKLs? Cheers, Lachlan. PS : I hope this email makes sense. There is a certain time at night, beyond which it is dangerous to send emails out into the world. :-) -- Lachlan M.D. Cranswick _--_|\ lachlan@dmp.CSIRO.AU CSIRO - Division of Minerals /CSIRO \ tel +61 3 9647 0367 339 Williamstown Rd, \_.--.*/ fax +61 3 9646 3223 Port Melbourne, Australia, 3207 v (http://www.dmp.csiro.au/tour/lachlan.htm - Still under construction) ================== RFC 822 Headers ================== From: SMTP%"X-rayX-press" 13-NOV-1995 03:49:09.77 To: armel CC: Subj: Cam Hubbard heard from. I distributed the first round of "Rietveld PDF patterns" to some members of the ICDD technical committee who may not subscribe to this mail server (Ting Huang, Ron Jenkins, Cam Hubbard, Jim Kaduk, Tom Blanton, Gerry Johnson) and Cam Hubbard responded with the following. From: SMTP%"hubbardcr@ma160.ms.ornl.gov" 12-NOV-1995 16:51:05.81 Reply to: Snyder RE: This is the first round of a discussion on the Rietveld mail server that will be of interest to us at ICDD. Bottom from LeBail and top is my RE - many others will probably be heard from. I will collect the discussion and pass it on. My quick thoughts while I should be taking care of my Group's funding and operation are: 1. The problem of use of Rietveld data in the file is really a problem of the search engine and match algorithm. Also there is the need for education. Nowhere within the database is there a problem with the data storage. R quality marks could be OK - certainly better than the C for calculated as we have used C to mean simulation of the powder diffraction trace and subsequent analysis of it like it were an experimental trace. (Should C be renamed S for simulated pattern when R is introduced for Rietveld calculated?) 2. Many search engine algorithms on computers today can handle the full detail of the Rietveld d/I lists. In particular, the so called third generation codes handle it beautifully. They could even potentially spit out info on texture as well. Clearly if we tell the authors of computer algorithms which search the PDF, the intent to include such R type data then they will write code to handle it or they will be dropped by users wanting to get the correct answers for more modern codes. In either case the community benefits. 3. Manual methods (Hanawalt index) also have rules (e.g. one strong line within a certain window) that makes these patterns work for hand searches. Perhaps better rules are needed, but what is in place work OK for some patterns with resolution much higher than the average user will get during phase ID data collection. The trained user of the file can handle the match part - For those that can't, there you have a topic for ICDD workshops and training efforts. 4. To me it is truly disappointing that Rietveld and simulated patterns are not being saved in PDF with full detail for use by ICDD customers. Clearly, a disgrace for the ICDD that this has lingered on for over a decade since a number of us recognized and proposed the need. Camden Hubbard Oak Ridge National Lab ================== RFC 822 Headers ================== From: SMTP%"LubomirSmrcok" 13-NOV-1995 10:40:26.09 To: armel CC: Subj: Re: Cam Hubbard heard from. On Sun, 12 Nov 1995, X-ray X-press wrote: > I distributed the first round of "Rietveld PDF patterns" to some members > of the ICDD technical committee who may not subscribe to this mail server > (Ting Huang, Ron Jenkins, Cam Hubbard, Jim Kaduk, Tom Blanton, Gerry Johnson) > and Cam Hubbard responded with the following. Bob, although the PDF database is not my every day bread, I support all what was said by Cam Hubbard. It is still better to have the "R" patterns included and slowly persuade code manufacturers of any generation to use also these patterns, than to ignore plenty of accumulated information. ICDD, like all manufacturers, is a little bit more conservative than a common user may expect. However, they are doing their jobs also for us and it should be our role to try to move them. By the way, have you also met some people stating that "one experiment is better than 100's of your bloody calculactions ?!" Lubo Smrcok Institute of Inorganic Chemistry Slovak Academy of Sciences SK-842 36 Bratislava Slovak Republic E-mail : uachsmrk@savba.sk http://www.savba.sk/sav/cryst/cry.html ================== RFC 822 Headers ================== From: SMTP%"howard@rollanet.org(ScottA.Howard)" 13-NOV-1995 19:26:56.04 To: armel CC: Subj: Re: "R" mark in the JCPDS-ICDD >Forwarded message: >> Reply-To: X-ray X-press >> >> The primary use of the PDF is phase ID. If the PDF reference >> pattern lists more lines as being present than a normal resolution >> diffraction pattern would observe, then a user might reject the reference >> as not matching his unknown. > >>From a user point of view, it would be handy >for phase ID to have ICDD cards for phases >collected under a variety of conditions (diffractometer, film, >flat plate, micro-diffractometer, capilliary, Gandolfi, >calculated, single wavelength, double wavelength, etc). >While a bit off topic, this relates to having both >(Rietveld) calculated data and the raw data as well. > I would also like to see Rietveld data on ICDD cards. But I am going to put my stick in to further stir things up. If one has a set of Rietveld ICDD card data, one will have to massage it to put it into a form suitable for use in the current standard search/match methods. If we have to do that, why not go one step further and store L/p and absorption corrected data? Looking at the diffraction line intensity equation, |Fhkl|^2 is multiplied by L/p(theta), which includes both monochromator & polarization corrections (polarization corrections are not always required) and by A(theta), which varies by instrument/specimen geometry. The result would be a value that is instrument independent, except for a change in radiation wavelength. Yeah, it will take a bit longer to calculate values for search/match. But Moore's law says processor speeds are *doubling* every 18 months. Maybe we shouldn't think of Rietveld ICDD card data as just useable in Rietveld and search/match programs. We may also want to consider whole-pattern fitting methodologies. With current and near future (3 years?) processor speeds whole-pattern, rather than profile, fitting will probably become the de-facto pattern handling procedure. Recording values proportional to |Fhkl|^2, along with a scaling factor, would also make Rietveld-based quant methods using these data a minor procedure. Preferred orientation and thin-film corrections could also be easily handled. (They are the next best thing to crystal structure data.) Scott A. Howard, Ph.D. | SSSS A H H howard@RollaNet.com | S A A H H http://www.RollaNet.org/~howard | SSSS AAAAA HHHH Phone USA: (314)364-0851 | S A A H H See one, do one, teach one! | SSSS A A H H ================== RFC 822 Headers ================== From: SMTP%"kaduk@amoco.com" 13-NOV-1995 23:04:45.09 To: armel CC: Subj: Rietveld Patterns in the PDF The issue of how (or whether) to include Rietveld patterns in the PDF has caused a lot of heated discussion at the ICDD meetings, and the current state may be the "least unsatisfactory" one. My personal opinion (not shared by many others) is that the peak positions and intensities derived from a profile fit (either with or without a structure model) represent the best estimate of what is really in the pattern - the reflections are there no matter how we describe them. When using a structural model, the Fobs derived from a profile fit are "biased" by the model, but so what? They're still better than any other measure I know. James A. Kaduk Amoco Corporation P.O. Box 3011 MC F-9 150 W. Warrenville Rd. Naperville IL 60566 708-420-4547 708-420-5252 (FAX) kaduk@amoco.com ================== RFC 822 Headers ================== From: armel 14-NOV-1995 04:07:17.65 To: armel CC: Subj: 'R' mark : more For those interested in the article sent to ICDD, October 1994, entitled "Claim for a 'R' mark in the Powder Diffraction File", the main part is available by ftp anonymous at aviion.univ-lemans.fr pub/fluorlab/rmark95.txt as an ASCII file, approximately 9Kb long. armel@one.univ-lemans.fr ================== RFC 822 Headers ================== rmark95.txt : Claim for a 'R' (Rietveld) Mark in the Powder Diffraction File Abstract It is shown that the full powder data characterizing a moderately complex structure determined ab initio and refined by the Rietveld (R) method are hardly inserted into the Powder Diffraction File (PDF) mould. The Rietveld method allows to estimate 'observed' intensities at d positions unobservable in the usual PDF sense (although cell parameters are refined), hence the claim for a 'R' quality mark taking account of this paradox. Introduction Quality marks are assigned to powder pattern data by the Powder Diffraction File (PDF) editors. In the guidelines for a 'C' mark (calculated from structural parameters), it is explicitly specified that "if the structure was derived by X-ray Rietveld methods, the calculated pattern is accepted only in unusual circumstances ; the original powder pattern is preferred" (Wong-ng, Hubbard, Stalick & Evans, 1988). Such a preference is paradoxical because the Rietveld (1967, 1969) (R) method is recognized to propose the more complete way to characterize a powder pattern when the structure has been determined. More and more crystal structures are determined ab initio from powder diffraction data (Cheetham & Wilkinson, 1991, 1992) and the majority is from conventional X-ray data, monochromatized or not. Once determined, these structures are refined by the R method whose efficiency and credibility are uncomparable to those of methods used to produce dobs and Iobs which are then called the "original powder pattern". Arguments are thus given here in order to support the creation of a 'R' quality mark to distinguish the powder data that have been the more fully characterized. Experimental and data analysis The Table 1 referenced below is from one experimental case which is used as a support for the arguments developped here : [Pd(NH3)4]Cr2O7 (Laligant & Le Bail, 1995). Claim for a 'R' mark in the PDF The PDF lists essentially data observed from an experimental powder pattern (dobs and Iobs). Since no dobs are available from the R method, the decision of the PDF editors to prefer the "original powder pattern" instead of a calculated one may be understood. However, things are not so simple. The R method delivers 'Iobs' so called because they are estimated in a quite specific way by the Rietveld decomposition formula. Also, the R method proposes refined cell parameters that fit the whole experimental powder pattern with the structure constraint, so that the associated dcalc should be better considered than those originating from a single crystal study (a fortiori when no single phase powder was prepared) or the dobs of a few unambiguously indexed reflections. Not any PDF card was given in the form presented in Table 1 (Laligant & Le Bail, 1995). Either from the structure factor extracting stage (structure unknown but cell and eventually space group tentatively proposed) or the final Rietveld refinement stage (structure determined), we can list 'Iobs' values for which we have no corresponding dobs in the usual sense (that we could reasonably estimate/refine from the raw data by various methods not requiring the cell knowledge), we have only dcalc. When the structure is unknown, Iobs are extractable by whole pattern fitting techniques with cell constraint like in the Pawley (1981) or Le Bail (1992) methods (with the Rietveld 'Iobs' sense in the latter). Of course, several exactly overlapping reflections are generally given the same structure factor by such extracting methods, there is no miracle. Such 'observed' intensities are also biased in the R method because they are obtained by a partition of the raw data according to the calculated intensities (i.e. two superposed reflections are given 'Iobs' values in the same ratio that the Icalc ones, whereas the sums of these observed or calculated intensities may be different). In spite of these disadvantages, 'Iobs' are of great value. The RB factor is calculated from them compared to the Icalc and they allow to perform more or less efficient Fourier difference syntheses. It is suggested here for the first time that best 'Iobs' for Fourier difference map would even be obtained after a few iterations of the R decomposition formula instead of one application at the last refinement cycle. The paper from Laligant & Le Bail (1995) gives at least the 50th demonstration that 'Iobs' extracted by iterating the Rietveld decomposition formula are sufficiently well estimated for attempting with success a structure determination by the direct or Patterson methods. On another hand, the statement "the original powder pattern is preferred" merits some examination because dobs and Iobs are in fact extracted by pattern decomposition methods (those without cell constraint) that may fail to estimate them accurately. Many of the reflections listed in Table 1 (Laligant & Le Bail, 1995) have clearly not excellent observed d positions. The EVA Socabim software gives understandably poor estimation of the weak reflections positions (for instance 020 and 002, with I/Io < 1%), in part because stripping the alpha-2 component introduces additional noise (data were not smoothed). In case of strongly overlapping reflections, shoulders are detected by eyes that are not located automatically in spite of efforts in varying the search parameters (of the 022 and 102 reflections, only the 022 was detected although both are very intense and their separation exceed half the FWHM - but note their different estimated 'Iobs' in Table 1). Some observed positions are clearly the mean for a series of neighbouring reflections. Sometimes numerous weak overlapping reflections of almost equal intensities produce a large bump for which the automatic search proposes not any position (see ranges 24.1 - 24.6 or 27.6 - 28.0 2-theta degrees). Even if a position is suggested, the practice to give in the PDF one dobs value for numerous more or less overlapping reflections is quite not satisfying. In such cases peak fitting techniques are not more efficient. Indeed, we were not able to produce better peak position (if compared to dcalc) and intensity estimations than those obtained by the derivative method by the use of the profile fitting FIT Socabim program with various tests on peak shapes. Knowing or not the number of peaks and their calculated position in a set of neighbouring reflections can make a large difference at the extracting stage of the 'observed' reflection positions. Finally, one of the criteria for a star(*) quality mark is that "intensity must be measured objectively", something difficult to realize with decomposition methods without cell constraint. This is a brief summary of the main difficulties encountered by somebody asked for a moderately complex powder pattern by the JCPDS-ICDD. We believe that the best estimation of the peak positions are those calculated from the cell parameters refined directly from whole pattern fitting (without dobs production). We think the JCPDS-ICDD should revise its policy and allow inclusion of 'Iobs' and dcalc with a 'R' mark in the PDF or at least, should not prefer traditional Iobs and dobs to Is and ds calculated from Rietveld refinement results. Conclusion Ways to observe powder data have considerably changed over the 30 past years. Difficulties to insert the present data in the usual PDF form have been emphasized. We have suggested that calculated ds and 'Iobs' from Rietveld refinement should be preferred to the "original powder pattern" to be included in the PDF. Maybe one point prevents the 'R' quality being systematically recognized as the higher evaluation, even better than the star(*) category : for that, the Rietveld refinement should be performed on a sample mixed with a standard. References Cheetham, A.K. & Wilkinson, A.P. (1991). J. Phys. Chem. Solids 52, 1199-1208. Cheetham, A.K. & Wilkinson, A.P. (1992). Angew. Chem., Int. Ed. Engl. 31, 1557-1570. Laligant, Y. & Le Bail, A. (1995). Powder Diffraction, 10, 159-164. Le Bail, A. (1992). NIST Special Publication 846, 213. Pawley, G.S. (1981). J. Appl. Crystallogr. 14, 357-361. Rietveld, H.M. (1967). Acta Crystallogr. 22, 151-152. Rietveld, H.M. (1969). J. Appl. Crystallogr. 2, 65-71. Wong-ng, W., Hubbard, C.R, Stalick, J.K. & Evans, E.H. (1988). Methods & Practices in X-ray Powder Diffraction, JCPDS-ICDD, 9.3, 1-7. A. Le Bail Laboratoire des Fluorures, CNRS URA 449, Universite du Maine, Avenue O. Messiaen, 72017 Le Mans Cedex, France E-mail : armel@one.univ-lemans.fr ========================================================================= From: SMTP%"CarstenSchinzer" 14-NOV-1995 14:24:50.01 To: armel CC: Subj: Diffraction patterns etc. Hello all, to my point of view it actually IS important to have as much info available as possible. Why not JCPDS-card with R-marks? Also more computing seems to be possible, as was stated, when instrument-independent data were claimed. B U T - remember: NOT every JCPDS-user is familiar with crystallography. We all know how to use our tools and each of us has found a way to deal with lots of different data-formats. The following will give you an insight, what problems we have to face right here in our place to come to a refinement of a single pattern: A friend in the neighbouring group prepared a diffraction pattern on a Siemens diffractometer. First problem: The data is collected on a PC (not linked to Internet), but the program is on a unix-machine in the net. Data conversion from RAW to an ascii format is recommended. Siemens' routine does not work correctly (who knows why). Solution: Employ DRX-Win (which is commercial and only the commercial version will read/write ascii-data). But also here, you have to face a bug: XY-format in columns is made, but x is always INTEGER (therefore, with a resolution of .02 2Q, you will have 50 lines reading like this: 10 625 10 631 etc. Solution: Use EXCEL (which you have to call with american number format setting, because the unix machine will read the german floating number 10,02 as two numbers) to calculate the 2Qs correctly, save as text file. Now: transfer to the host - no problem. Another conversion is recommended into the format my Rietveld program reads (actually I use FullProf, MINREF or SIMREF, which have three different input-files and three different data-formats). After ca. 2 h work, the data have arrived where they can be used and in format I'd like them to be !! A "standard computer user" in our group (we are all chemists) would have given up at problem no 2 or 3. Guess, what time it had cost, when I did this for the first time in my life! Now I'm doing this in routine operation. The point of all this is: Don't think egoistic with this computer stuff! I think JCPDS is a successful concept, because it is easy for everyone to access the data. Don't make access too complicated, or all the people who are not interested in long problem-solving sessions on the computer may not buy it any more. By the way, a point that really makes me mad is: Why are the Rietveld codes free shareware when you have to do a thousands of tricks to get the ready-fitted profile visible? E.g. FullProf (to my knowledge) does not support any ascii-plot format. The only tool I know to plot FullProf's results is DRX-Win, which you can buy for some 400 $. Wow - this is a long message! I'll have to be off for lunch with the group. I wait for answers. Greetings Carsten ================== RFC 822 Headers ================== From: SMTP%"Nita.Dragoe@chimsol.u-psud.fr(Nita.Dragoe)" 14-NOV-1995 19:30:22.85 To: armel CC: Subj: Returned mail: User unknown (fwd) > > > > Hello all, > > > > to my point of view it actually IS important to have as much info > > available as possible. Why not JCPDS-card with R-marks? > > Also more computing seems to be possible, as was stated, when > > instrument-independent data were claimed. > > > > B U T - remember: NOT every JCPDS-user is familiar with crystallography. > In my opinion this is not the point (let those familiar with the > crystallography to use their knowledge). > > As regarding the data format: > I'm using different data format programs and for such purpose > I wrote a program to do data conversion. I still can improve it > if you need to and I'm sure that there are plenty of home-made > computer programs capable to do all the conversion you need. > > I think that is good to have JCPDS R card and this is quite easy > to build if a good standardisation is carried out. > > All the best > > N Dragoe > ================== RFC 822 Headers ================== Other related postings on sci.techniques.xtallography : ================================================================ From: SMTP%"stx-gate@xtal.cmc.uab.edu" 19-OCT-1995 17:25:27.70 To: sci_tech_xtal@xtal.cmc.uab.edu CC: Subj: stx2029 JCPDS/ICDD and calculated XRD powder patterns In Re : stx2001 Crystal structure of Bassanite.., Lachlan wrote : >It might be an interesting exercise just to calculate XRD powder patterns >based on published crystal structures, then see what they best >match with in the JCPDS/ICDD? :-) Yes, very interesting. The result may be predicted and it is not :-), it is :-(((. Why ? The JCPDS/ICDD policy is to not include systematically calculated powder patterns, After years of such a policy, there are "only" 60000 patterns in the base. IMHO, less than 1/3 are modern data. Is it too late to do something ? More than 10000 structures are determined per year now whereas only 2000 new powder patterns appear in the database. There is something wrong. Two persons in a good library might copy public domain atomic coordinates, then use something like Lazy-Pulverix and prepare 3 files per hour, 25 files a day, each of them, 5 days per week, 40 weeks per year = 10000. Why not ? There is place for them on a 650 Mo CD-ROM (and soon 5 Go or evenmore). These cards may have the "C" identifier, plus a "T" identifier if the measurement was not at room temperature, a "N" identifier for neutrons, a "S" identifier for synchrotron with uncommon wavelength, etc... Where is the problem ? In fact a good database should include coordinates and thus would be able to simulate patterns at any temperature, wavelenght, radiation....;. When the JCPDS-ICDD ask me for data, I send them such a calculated pattern. So, Lachlan, at least you will obtain some match with in the JCPDS/ICDD if you start from some of my papers. Signed : a user unhappy for not to find a huge number of known compounds in the JCPDS/ICDD. Unhappy users could try a petition. Copy this mail and send it to : info@icdd.com , adding eventually "I agree with that", or just :-(((. Alternately, you may comfort ICDD in its policy by sending this mail adding "I disagree with that", or just :-). Armel Le Bail - Laboratoire des Fluorures, CNRS-URA-449, Universite du Maine, 72017 Le Mans Cedex, FRANCE - lebail@naimn2.cnrs-imn.fr Try also URL ftp://aviion.univ-lemans.fr/pub/fluorlab/aritve.html ================== RFC 822 Headers ================== And the only responses (other than classical propositions for "grants in aid" or etc.) obtained : From: SMTP%"GGJ@psuvm.psu.edu" 19-OCT-1995 22:31:18.50 To: lebail@cnrs-imn.fr CC: Subj: copyright and how long will it take to obtain the copyright permision to do the task that you are proposing ? perhaps legality is not a question, but it certainly is in some places who have signed the international copyright agreement. as a user of icsd, i certainly can not use their data without much analysis, because of the 'difficulties' in the db. Your email certainly makes one think! good luck, it would be interesting to know the results of your survey regarding the icdd ================== RFC 822 Headers ================== From: SMTP%"GGJ@psuvm.psu.edu" 30-OCT-1995 02:54:15.97 To: lebail@cnrs-imn.fr CC: Subj: Re: JCPDS/ICDD and calculated XRD powder patterns you posted this before !!! please post something new !! ================== RFC 822 Headers ================== From: "JERRY JOHNSON" =====================================================================