Y2K Linux bug ??
Hi ! The latest mails archived at : http://www.mail-archive.com/rietveld_l@ill.fr/ are dated by January 1999... Is this already an effect of Y2K ? Armel Le Bail http://www.cristal.org/
Re: Y2K Linux bug ??
At 11:15 08/11/1999 +0100, [EMAIL PROTECTED] wrote: >The latest mails archived at : >http://www.mail-archive.com/rietveld_l@ill.fr/ >are dated by January 1999... Is this already an effect >of Y2K ? Hmm. As you see from the header, the mails that I receive from our Rietveld server are correctly dated (The server is a Unix machine, not Linux). Please check your archive set-up Armel. It might be something to do with the world being upside down because of the result of the rugby world cup final :-) Alan. Alan Hewat, ILL Grenoble, FRANCE <[EMAIL PROTECTED]> tel (33) 4.76.20.72.13 ftp://ftp.ill.fr/pub/dif fax (33) 4.76.20.76.48 http://www.ill.fr/dif/
Re: [sdpd] Re: PowBase
At 22:14 07/11/99 -0200, Helio Salim de Amorim wrote: >I think that PowBase is yet a remarkable step and your public domain >character a very important aspect. I think also, that is not necessary a >hard standardization but a few directions like, >- the data must be an ASCII file. >- unpublished data may be accepted (these are the cases, for example, of >good measurements of standards or rare materials) and in this case the >authors must include in the data file a heading (or footnote) with a >description of relevant experimental conditions and comments about the >sample ( that typically presented in a regular paper). >By our part PowBase have total approve and a sincere personal thanks for the >initiative. Thanks a lot, it was your suggestion ! Powbase has already reached some cruising speed with 79 patterns added in 5 days. Theoretically, 190 days would suffice for being the equivalent of the 3000 patterns in PDF-3. Of course, maintaining that speed depends on you. http://sdpd.univ-lemans.fr/powbase/ The current entry format replies to almost all recent suggestions, and it is really the most simple I can imagine (free format). It is not CIF nor CIF star, but those formats will be accepted too. Best, Armel Le Bail http://www.cristal.org/
Re: CIF format
Kurt wrote: >Can I dump the extracted structure factors from GSAS >into ESPOIR, for example? It would be nice if this was really happening... I am not a GSAS user, but as the ESPOIR programmer, I would say that nothing is more easy than to dump structure factors into it. The format is free, ascii, corresponding to one line per h,k,l, "|Fobs|", so that the following possibilities can be accepted : 200 1 0 1 251.2 2 2 0 348.3 ... or 200 1 0 1 251.20 0.52 2 2 0 348.30 0.65 ... or more stuff unused after the "|Fobs|". If no GSAS output fits into that format, it is surprising. Best, Armel Le Bail http://sdpd.univ-lemans.fr/course/
gsas in dos & UNIX
hello, Does anyone know if it is possible to use the same *.EXP file on dos & UNIX (Linux) machines? If so, what changes must be made to the file? Thanks in advance, Roger Mason
Re: [Re: [sdpd] Re: PowBase]
Dear All, I think that standardisation is an important topic at the moment- the dawn of a database of diffraction patterns. If you take a look through the different formats that GSAS and FULLPROF can accept (I name those only for convenience) it is a bit of a jungle- I include of course both 2-axis and TOF data. This situation has been given to us by history and the way that the Rietveld codes were created and evolved, but it is an unnecessary complication that is easy to get rid of. The powder CIF is doubtless the most sensible format for stocking data as it details all the appropriate experimental conditions (sample holders, cryostat, oven, etc) and whilst these and other pieces of information can be very important, they may easily be forgotten when someone submits a data file. What we need also is a standard set of routines (or programs) that we can all use to convert data and experimental details to the powder cif format, and from that to those we wish to use in the refinement. If all software authors have to do this job the movement to this format will be very slow, and I personally find it a pain to reinvent the wheel constantly. Armel, how would you feel about accepting magnetic data? -are you accepting all waifs and strays (sdf's in French)? :-) Or perhaps Alan, you would prefer to house them at the ILL. Sincerely, -Andrew >I think also, that is not necessary a >hard standardization but a few directions like, >- the data must be an ASCII file. >- unpublished data may be accepted (these are the cases, for example, of >good measurements of standards or rare materials) and in this case the >authors must include in the data file a heading (or footnote) with a >description of relevant experimental conditions and comments about the >sample ( that typically presented in a regular paper). --- Andrew S. Wills (Dr.) SPSMS/DRFMC/MDN Centre D'Etudes Nucléaires de Grenoble 17 Avenue des Martyrs Cedex 9 Grenoble, 38054 France email: [EMAIL PROTECTED] Get your own FREE, personal Netscape WebMail account today at http://webmail.netscape.com.
Re: [gsas in dos & UNIX]
Hi Roger, I don't think that there will be problems with the EXP file, but there could be with the data file as the end of line statements may not be there in the UNIX version and all the data may be on one line. If this is the case you will simply need to convert it to an 80 column per line format for it to work in DOS. If you do have problems, the first thing to check is that all the files (instrument parameter, data and exp) have 80 characters per line (this is a classic starting problem for new GSAS users). You can do this easily by opening it in Word (or non-Bill Gates editor) and using the 'view nonprint characters' button (the one that looks like '1P' ). There is a program in the first menu of GSAS (I forget the name) that pads ascii files with the extra spaces required. I hope that this is useful, -Andrew Does anyone know if it is possible to use the same *.EXP file on dos & UNIX (Linux) machines? If so, what changes must be made to the file? Thanks in advance, Roger Mason Get your own FREE, personal Netscape WebMail account today at http://webmail.netscape.com.
Data Format
dear all, since standard data formats were mentioned, I would just like to draw your attention to the NeXus project, which has the (ambitious) purpose of developing a unified data format for x-rays and neutrons. http://www.neutron.anl.gov/NEXUS/ http://lns00.psi.ch/NeXus/ The NeXus format is based on HDF, which is an industrial standard. I'm not directly involved, but I know that they specifically looked at CIF as an alternative. They found that, in it's native format, CIF it is not suitable to handle large amounts of raw data. There is, however, something called imgCIF, which might address the problem. I quote from the NeXus web site: "In a round table discussion at the [NOBUGS] workshop [ILL, JAN96], we discussed the merits of the NeXus proposal compared to a proposal to extend CIF by including binary images (imgCIF). Those involved in the NeXus proposal did not think that imgCIF would have sufficient flexibility to describe complex neutron instrumentation. Those involved in the imgCIF proposal preferred the CIF use of ASCII header information and were concerned about HDF's ability to handle the high data rates at synchrotron sources. We have decided not to try and merge the two proposals at this stage, particularly since, in our view, they are serving different purposes." If you wonder why powder diffractionists should be concerned with large data files, please note that the new ISIS high-flux powder diffractometer GEM, of which I am responsible, produces about 64 Mbytes of integers (14 Mbytes when compressed) for every data set (this will increase to ~150 Mbytes when the instrument is complete), and we can get good-quality data in as little as 10 seconds. This is the brave new world, gentlemen Paolo
Re: a few words about pdCIF
Lubomir Smrcok wrote: > It would be nice if you make public the subroutines you have > mentioned in your mail. Sorry, no intent to be obscure, just brief. See http://www.iucr.org/iucr-top/cif/index.html (in the Americas, http://www.us.iucr.org/iucr-top/cif/index.html) and look for CIFtbx2 (and CIFtbx) under software. Ignore anything about DDL2 or greater unless you are into macromolecular work. Brian
Re: gsas in dos & UNIX
Roger (& others), The transfer of GSAS files from unix (linux) to PC is straightforward, but one does have to do certain things to get it right. The problem is that these files (exp, data & iparm) are all in fixed record length (80 character) direct access format. On unix machines this has the appearance of one very long record with no intervening "end of record" marks while on a PC each 80 character record is terminated by two additional bytes (CR/LF). The safest way to tranfer these files from unix is to first use the convdtos utility in GSAS to convert them to standard sequential file format. Then tranfer the files (e-mail attachments or ftp) to the PC. Then use the cnvfile utility in PC-GSAS to convert them back to 80 character records. Do not transfer the direct access format files directly from unix to PC as they are unreadable. To transfer these files from PC to unix one only need to transfer the files (e-mail of ftp) and then use the GSAS utility convstod to make them direct access. I hope that helps, Bob Von Dreele At 09:28 AM 11/8/99 -03-30, you wrote: >hello, > >Does anyone know if it is possible to use the same *.EXP file on dos & >UNIX (Linux) machines? > >If so, what changes must be made to the file? > >Thanks in advance, > >Roger Mason
Re: gsas in dos & UNIX
Roger Mason wrote: > Does anyone know if it is possible to use the same *.EXP file on dos & > UNIX (Linux) machines? > > If so, what changes must be made to the file? The file contents are exactly the same for the .EXP as well as the data and instrument parameter files, but in DOS the records must be exactly 82 characters per line, including the CR-LF terminator. In UNIX the files should be exactly 80 characters per line with no terminators. To xfer files from UNIX to DOS you need to add a terminator or else when the files get into DOS, you have one huge record that is very hard to work with. This can be done in UNIX with the GSAS CONVDTOS program. (DTOS = Direct-access to Sequential). One the files are in DOS, you then format them using the CONVERT program in GSAS that adds the CR-LF terminator. To go from DOS format to UNIX, run CONVSTOD. The version of CONVSTOD/CONVDTOS that is in the current release of GSAS is full of "features." For example, it will ruin files that are converted twice. (My fault not Bob.) A newer version can be found at ftp://ftp.ncnr.nist.gov/pub/cryst/gsas/cconvstod.c with compiled versions at ftp://ftp.ncnr.nist.gov/pub/cryst/gsas/exe_XXX/convutil.tar.gz (XXX=SGI and linux). [Link the executable to .../gsas/exe/convstod and .../gsas/exe/convdtos and run from the menus or from the command line as .../gsas/exe/convstod < input > output The sequential files produced by this version of convdtos are in the DOS format. It does not screw up the file, if you convert a file that is already in the correct format. Brian Brian H. Toby, Ph.D.Leader, Crystallography Team [EMAIL PROTECTED] NIST Center for Neutron Research, Stop 8562 voice: 301-975-4297 National Institute of Standards & Technology FAX: 301-921-9847Gaithersburg, MD 20899-8562
Re: Thin samples in Bragg-Brentano geometry
Kurt (& others), The real problem with small samples in Bragg- Brentano geometry is assuring that the sample covers uniformly the entire "foot print" of the incident x-ray beam at all scattering angles used in the scan, i.e. there are no "bare spots". If this is not achieved then the observed diffraction intensities will bear little relation to what should be observed (particularly at low angles). The sample thickness for typical samples (metal oxides, say) is infinite at 20 or so microns so the problem isn't the thickness but is ensuring the coverage. Bob Von Dreele At 05:44 PM 11/7/99 -0700, you wrote: >Rietvelders, > >For a lot of small powder samples (say 10 milligrams) in Bragg-Brentano >geometry, the sample has to be spread very thin over the diffracting >surface of a slide in the diffractometer. I notice that a lot of the >textbook formulas are for "infinitely thick" samples. Is there a special >way to deal with the thin samples? It seems like the absorption part of >the formula for peak intensities (for example, for phase fractions in >multiphase mixtures) will be changed. > > - Kurt Leinenweber > >* >Kurt Leinenweber >Dept. of Chemistry >Arizona State University >Tempe, AZ 85287-1604 > >Phone (480)-965-8853 >Fax (480)-965-0474 > >
Re: [Re: [sdpd] Re: PowBase]
Andrew S. Wills wrote : >Armel, how would you feel about accepting magnetic data? -are you accepting >all waifs and strays (sdf's in French)? :-) Or perhaps Alan, you would prefer >to house them at the ILL. I think that sounding opinions about doing or not a database, and asking to researchers if they are ready to share their data would have surprising results (large percentage of "no", very probably). So, the question is, will the base increase ? The ICDD base receives data from ICDD members, grants in aid, essentially (?), and the failure of this method to provide a complete database is evident with the recent add of calculated patterns from ICSD and in a near future from CSD. The size of PowBase for 80 patterns is 800Ko, thanks to compression by Winzip. A base of 3000 patterns would be 30Mo, and this is not a problem, even on a simple PC with full Internet connection. The same PC stores already a base of more than 1 most cited chemists (ISI data). But clearly, ToF large data should be left at ISIS or elsewhere. And a base of magnetic data would be self consistent at ILL. How to manage a very simple database is explained at the PowBase Web site. But who wants to manage a free database apart me ?-)). Or who has permission to do it ? Is that possible at NIST ? Ask yourself why such databases are so few. The Studsvisk database of amorphous diffraction patterns (powder-like) is still underdeveloped (because nobody sends data ?). Now let us discuss about standard formats. Why CIF has to be so complex ? The aim is to produce a completely self consistent block of data which would allow to do not need the corresponding publication at all. In fact, IUCr can almost produce automatically a standard publication from a CIF file. And the atomic coordinates are supposed to be included, of course. But if one considers that the publication will be available separately, then the format has certainly not to be so complete, and only the point by point intensities are really needed (for a constant wavelength powder pattern). May be you heard about PubMedCentral or E-Biomed, a free access project for electronic publications at NIH. It is a pity that the project was not more general, because a big PubCentral would solve that problem : no need for a so complete and complex CIF when publications are available online (and for free...). I would have one question about PDF-3. Up to now, ICDD never produced atomic coordinates. And I guess that the World has been commercially divided in databases with or without atomic coordinates. So the question is, will the CIF star include atomic coordinates inside PDF-3 ? If not, either the publication or another database (ICSD, CSD) will be needed, eventually, if more than an identification of a compound is the target. Best, Armel Le Bail http://sdpd.univ-lemans.fr/powbase/ Armel Le Bail - Universite du Maine, Laboratoire des Fluorures, CNRS ESA 6010, Av. O. Messiaen, 72085 Le Mans Cedex 9, France http://www.cristal.org/
Re: Data Format
[EMAIL PROTECTED] wrote: > I would just like to draw your > attention to the NeXus project, which has the (ambitious) purpose of > developing a unified data format for x-rays and neutrons. > http://www.neutron.anl.gov/NEXUS/ > http://lns00.psi.ch/NeXus/ The NeXus format is an excellent way to deal in binary with the large amounts of data generated by many energy-dispersive and PSD instruments. CIF stinks for this and my impressions are that imgCIF is a Band-Aid that is far less versatile than NeXus. NeXus is also designed for other types of scattering experiments than diffraction. The unanswered question that faces the powder-diffraction crystallographic community is, if crystallographers standardize on CIF for communication of structural results (pretty much a fact already) and major neutron and x-ray sources standardize on NeXus (pretty likely), how does the gap get bridged? Brian Brian H. Toby, Ph.D.Leader, Crystallography Team [EMAIL PROTECTED] NIST Center for Neutron Research, Stop 8562 voice: 301-975-4297 National Institute of Standards & Technology FAX: 301-921-9847Gaithersburg, MD 20899-8562
RIET: Re: [sdpd] Re: Use of CIF as advocated by Lachlan
(keeping the entire text of Robin's Email as it was not Cc'd to the Rietveld list). Robin Shirley ([EMAIL PROTECTED]) writes: > Lachlan Cranswick writes [Fri, 5 Nov 1999 17:59:40 + (GMT)]: > > > While the database system Armel has done looks good,, > > this still leaves the problem of a common file > > format. If CIF was used, many of the problems/requests > > described by Andrew would become non-issues. > > I'm reluctant to take issue with Lachlan, who does such a good job at > the CCP14 website, and indeed publishes CRYSFIRE from there. > > However, I have to say that I'd feel happier about supporting CIF as a common > file format if (a) it were considerably simpler to read and (b) the CIF > committee were more responsive to practical powder-related issues. > > Firstly let me say that, in a spirit of general co-operation, several years > ago I extended CRYS/CRYSFIRE to support a basic form of CIF as a file-save > option (i.e. for output). > > However I can't support it as an input format due to its excessive > complexity. I simply don't have the address space available in CRYS, and > most of what's included in CIF would be irrelevant for this purpose. > > Also, my attitude is partly coloured by the fact that, both at Beijing in > 1993 and at Seattle in 1996, I submitted a formal proposal concerning a small > set of Powder-CIF extensions which would cover issues connected with indexing > (copies emailed on request), as at present these are not touched on. > > On each occasion I took the precaution of first running them past Brian Toby > to confirm that their syntax was well formed. And both times absolutely > nothing happened. I didn't even receive the courtesy of an acknowledgement. > > Brian told me at Seattle that the committee seemed to have lost the 1993 > proposals. After resubmitting them, I again got no reply, so I didn't bother > trying again at Edinburgh. > > In the light of this, I'm afraid that as a software author I don't feel > encouraged to put myself out to support CIF as a common file format, when > the CIF committee rather gives the impression of living in an ivory tower > remote from actual users. > > Robin Shirley > School of Human Sciences > University of Surrey > UK > For a sizable database, I don't see an alternative to CIF for being able to transfer Crystallographic structure and data information in a civilised manner (?) (compared to having a dozen or so different formats where things could become a mess quite quickly). If not CIF, then what? (Does NEXUS just handle data - or can it include structure information?) - On the single crystal side, Louis Farrugia's CIF conversion software is very solid; showing good CIF conversion can be done, both in converting "structure" and "reflection" data into WinGX's shelx format. http://www.chem.gla.ac.uk/~louis/software/ http://www.ccp14.ac.uk/ccp/web-mirrors/farrugia/~louis/software/ http://ccp14.sims.nrc.ca/ccp/web-mirrors/farrugia/~louis/software/ How much programming effort (hours, days?) would it considered standard to be able to program in a CIF to X converter for say GSAS or Fullprof, or X? Is any source code available that could be used as a template for powder authors? Is there any instance of a powder program being able to import a CIF into the program's native powder format? Lachlan. PS: With respect to Robin's comments on trying to get additions to PowderCIF for Powder Indexing,;what is the present mechanism for getting things implemented into the Powder CIF area? -- Lachlan M. D. Cranswick Collaborative Computational Project No 14 (CCP14) for Single Crystal and Powder Diffraction Daresbury Laboratory, Warrington, WA4 4AD U.K Tel: +44-1925-603703 Fax: +44-1925-603124 E-mail: [EMAIL PROTECTED] Ext: 3703 Room C14 http://www.ccp14.ac.uk
Re: Data Format - GEM and 64 Mbyte datasets
[EMAIL PROTECTED] Wrote: At 13:47 08/11/99 -, you wrote: >dear all, >If you wonder why powder diffractionists should be concerned with large data >files, please note that the new ISIS high-flux powder diffractometer GEM, of >which I am responsible, produces about 64 Mbytes of integers (14 Mbytes when >compressed) for every data set (this will increase to ~150 Mbytes when the >instrument is complete), and we can get good-quality data in as little as 10 >seconds. This is the brave new world, gentlemen > >Paolo Is there GEM related information on available software (or portability tools) that are being developed in parallel with the hardware so that GEM can produce "usable" and "analyzable" data? Users might consider it a backward step to have diffraction hardware that produces 64 Mbyte datasets - where present available analysis software is more optimised for files measured in Kbytes? Lachlan. Lachlan M. D. Cranswick Collaborative Computational Project No 14 (CCP14) for Single Crystal and Powder Diffraction Daresbury Laboratory, Warrington, WA4 4AD U.K Tel: +44-1925-603703 Fax: +44-1925-603124 E-mail: [EMAIL PROTECTED] Ext: 3703 Room C14 http://www.ccp14.ac.uk
RE: Data Format - GEM and 64 Mbyte datasets
Lachlan: >Is there GEM related information on available software (or portability >tools) that are being developed in parallel with the hardware so that GEM >can produce "usable" and "analyzable" data? Yes, we have a major software effort to handle these data and reduce them down to manageable sizes. Files will still be quite a lot bigger than CW files, because we have the wavelength and angle information which come out separately, but I am aiming at something like 500Kbites uncompressed (7 patternsx3000 time channelsx 32 bytes of data/errors). The problem is that the reduction algorithms are not set in stone. The user must be able to interact with the software and select the optimal way to combine detectors into groups. Our answer to this challenge, for the moment, is and IDL based platform called ARIEL, which also has some fortran bits for added speed. It was designed to be instrument-independent, so it can handle all the ISIS diffractometers, and, hopefully, other institutions as well. We have acquired the right to distribute IDL executables free of charge even for the users who don't have IDL. Still, this means serious multi-histogram Rietveld (7 patterns or sometimes more). To make things simpler for the users, I will try to produce data normalised on an absolute cross-section scale, so that the histogram scales can be all set to the same value. I'm sure this is possible, because it's done routinely for liquid-amorphous scattering. Also, I would aim at having all the patterns on the same Q scale, so that the instrument parameters do not need to be refined. ARIEL is designed to do all these things, but we are not quite there yet. The fast data output poses even more challenges. Ultimately, Rietveld code will need to be updated to cope with all this. Paolo
Re: RIET: Re: [sdpd] Re: Use of CIF as advocated by Lachlan
Robin Shirley ([EMAIL PROTECTED]) writes: > However, I have to say that I'd feel happier about supporting CIF as a common > file format if (a) it were considerably simpler to read and (b) the CIF > committee were more responsive to practical powder-related issues. I do owe Robin an apology for my inaction. I have still not completed all the tasks I have promised with respect to pdCIF v1.0 and so I have not started work on v1.1, which will incorporate some of the additions suggested by Robin and others. CIF is something that I work on at home, not as part of my employment and time for it is scarce. A volunteer to take over for me would be very welcome. L. Cranswick wrote: > PS: With respect to Robin's comments on trying to get additions > to PowderCIF for Powder Indexing,;what is the present mechanism > for getting things implemented into the Powder CIF area? As of right now, the procedure is to read through the pdCIF dictionary to determine what it is you want to store that is not present and then define the term to be added. You then write to me with a case for why the terms are necessary and then let your e-mail age in CIF inbox for a while. A IUCr committee (pdDMG) will eventually evalute these suggestions. I hope to be ready to start this soon. I would like to note that while there is a lot of information that can be stored in a powder CIF, software that reads CIFs needs only to deal with the relevant fields for the task at hand and can ignore the rest. While CIF has provisions for including structural information, peak and reflection tables,... life does not need to be so complex. For storage of raw lab data, one can write a very simple CIF file that looks like this: data_myCIF _pd_meas_2theta_range_min 5.0 _pd_meas_2theta_range_max 65.0 _pd_meas_2theta_range_step 0.02 loop_ _pd_meas_counts_total 10 16 23 18 ... That's it! Not so complex. Of course it would be a good idea to use the appropriate CIF terms to describe if the data are x-ray or neutron, specify wavelengths used, if a theta-compensating slit was used,... As many people keep rediscovering, ambiguous data can be very hard to use. > (Does NEXUS just handle data - or can it include structure > information?) There is no reason that NeXus could not include any kind of information, but no provisions exist as far as I know. It is really being implemented as a raw data format. Brian Brian H. Toby, Ph.D.Leader, Crystallography Team [EMAIL PROTECTED] NIST Center for Neutron Research, Stop 8562 voice: 301-975-4297 National Institute of Standards & Technology FAX: 301-921-9847Gaithersburg, MD 20899-8562
Advice on a new diffractometer
Hi everyone, There is a diffractometer here for rapid data collection (Siemens D5000, 7.5 degree position-sensitive detector, no monochromator and can't be retrofitted for one). My question is, what would be a good choice for a second diffractometer in this situation (ie what brand, what kind of monochromators and detectors, etc)? I am hoping to be able to collect data that can be used to find unit cells and do refinements, perform Monte Carlo solutions for complex phases, etc. The PSD system is not very good for this (it even has K-beta bumps that come through the nickel filter!) Thanks! - Kurt Leinenweber * Kurt Leinenweber Dept. of Chemistry Arizona State University Tempe, AZ 85287-1604 Phone (480)-965-8853 Fax (480)-965-0474
rietveld_l@ill.fr
Identité Message:<[EMAIL PROTECTED]> X-Sender: [EMAIL PROTECTED](Non vérifié) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Tue, 09 Nov 1999 07:26:32 +0100 To: RIETVELD_L Distribution List <[EMAIL PROTECTED]> From: Armel Le Bail <[EMAIL PROTECTED]> Subject: Re: Advice on a new diffractometer Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >My question is, what would be a good choice for a second diffractometer in >this situation (ie what brand, what kind of monochromators and detectors, >etc)? Try "NIST" as keyword in PowBase, you will obtain 2 patterns which are the best you can do in a laboratory, and a link to a discussion on that question and to more demonstration patterns. Armel Le Bail http://sdpd.univ-lemans.fr/powbase/
