Dear Ling Fei (& others), GSAS requires all powder data to be records 80 visible characters long and each terminated with an additional 2 characters (CR & LF). Thus, the length of the file in bytes should be divisible by 82. CNVFILE will try to fix this; it does not do any other formatting. Powder4 evidently does not get this exactly right. GSAS programs that read these files POWPLOT & EXPEDT will attempt to also fix the file, hence the message. Although this "automatic" fix works pretty well, there is a chance it will screw up the data input so it is wise to make sure beforehand that the file does conform to the rules exactly. The reason for all this is that GSAS reads these files as "direct access" which requires identical length records and the particular format is the only one that works in both Windows and Linux/Unix. Bob Von Dreele
________________________________ From: Ling Fei Zhang [mailto:[EMAIL PROTECTED] Sent: Mon 11/15/2004 6:54 AM To: [EMAIL PROTECTED] Dear GSAS people, Here is Lingfei, and I am sorry for bothering you, given incapability of reading this error-like message, when I get into the step to input the "raw histogram input file name", i.e., what I put in is, >xr95630.gsa, and I make sure all the files are in the working directory, there is no path. then I got this: "File is apparently sequential access format Conversion to scratch complete Use CNVFILE to avoid this conversion Header on file: YBCO powder Daresbury Station 2.3 2003" by following this, there is question asking to user to confirm "is this the correct file"..., Here, my feeling is I have reviewed the manual and even the example data formatting, and make sure I edited the formatting information like this, similar to the formatting of Y2O3.gs provided, Y2O3 data dont lead to this error-like message. "YBCO powder Daresbury Station 2.3 2003 BANK 1 4501 451 CONST 2000 1.00 0 0 STD" In the last row of 451, there are 9 zeros to fill the empty. My inquiry is summarised simply, namely how the quoted message above appear, and what that means to the user? it seems the conversion could be done by this mechanism of CNVFILE, normally I use Powder4 to do formatting instead of using CNVFILE. Why this conversion should be avoided, and if this message could be leading any negative impact on the data import? Thanks for sharing your idea, Lingfei ******************************************* Neutron Scattering Physics Group Institute for Materials Research Maxwell Building 111 University of Salford Salford, M5 4WT United Kingdom Tel:0161 295 3269 Facsimile:0161 295 5147 Email:[EMAIL PROTECTED] *******************************************
