FAQ & Tips

Xtal is a suite of programs aimed primarily towards solving the structures of small molecule organic and organometallic crystals from single crystal X-ray diffraction data. It does a lot of other things as well.

SHELXS, SIRware, ShakeN'Bake, Crystals, WinGX, XD, VALRAY, Prometheus, GSAS, Jana2000, Rady, Molly to name just a few. And then there are the powder solution programs ...

Its free. Its well documented. You can do anything you like with it except sell it. Its more versatile than some of the alternatives, but less functional than others. It expands your toolbox. It works under UNIX and MS Windows.

This is GENERIC form of THE MOST FAQ! We have found that 95% of all user problems are due to not reading the writeup of the relevant program! PLEASE read the The Gnu Xtal System User's Manual carefully before contacting the User Group or Xtal Coordinator about why a calculation does not work.

For Xtal users wanting to print Xtal-generated postscript files on NON-postscript printers, check out the options of the freeware graphics viewer and conversion software GhostScript.

Editing the supplied "cifreq" to contain your own details (name, address, machine details, etc.) and storing that in a path which is accessible to the Xtal executable, will mean that this version will be used in the generation of CIFs by CIFIO.

If you are using the "master on" option, the text archive file with the extension .aaa will be read and generated at the start and finish of each Xtal run. It is possible to edit the .aaa file with a normal text editor, and this is useful if a minor change is needed to the data therein. However, EXTREME caution needs to be exercised (and a spare unedited .aaa retained in case of problems. Users who wish to add data to a .aaa file MUST know the archive key number and logical record type, AND remember that an .aaa file is a type of CIF... so that structure must be adhered to.

After users have edited a CIF (.cif) file, adding values or text, it is important to make sure that it has not been corrupted. The best approach is to run the program PREPUB which will check that the file construction is compliant AND validate some of the contained data. Alternately, use the command "CIFIO cifin dict" to read the CIF with CIFIO.

By default Xtal attempts to use a shared colormap for rendering graphics. On X11 displays with limited color map entries (e.g. 8 bit displays), often the requested color cells are not available or have been used by othe processes. You will know if this is the case when a majority of XTAL colors are white. A command has been added to the reset system line to switch from common to private colour maps to permit full use of all entries in a private colourmap (this results in flashing as the mouse is moved in and out of the Xtal graphics window).

The Graphical interface under Microsoft Windows shares the global colourmap. In display modes with only 256 colours, all of these may be consumed by the window manager. Xtal colours then get mapped to the nearest approximation of what was requested. (which can be awful!) Best results are obtained by running in a display mode with 65535 colours, where at least a few colour map entries are left free.

Generally on UNIX boxes, Xtal is executed via a shell script from the command line which takes the control file name, appends a ".dat" identifier and directs the contents of the file to the standard input stream of the Xtal binary executable. Under Microsoft windows an identical procedure is achieved using the DOS batch file mechanism and running the program from a DOS command window. It is possible however, to map the Xtal control file name to an executable file, to enable program execution via the windowing interface. To do this you have to associate the file name with the executable, by going to the "view" menubar option of the folder where your data files are located, choosing "Folder Options" from the drop down menu and going to the "file types" tag of the options window. At this point you can add a "New Type" which is simply a matter of adding the Xtal control file extension (.dat or .inp) to the list and associating it with an executable file. There are two ways of doing this. The first is to associate the control file extension type ".dat" with a new version of the xtal.bat file which requires the .dat extension on the filename passed to it via the command line. In this method, the .bat file handles the input and output redirection, but the DOS limitation is that you cannot extract the basename from the control file passed on the command line in order to generate a compid.lst from the compid.dat file - the best you can do is compid.dat.lst, or use a generic "listout" filename. The second alternative is to associate the control filename directly with the Xtal binary itself, rather than the intermediate .bat file. In Xtal, there is rudimentary control over the input control file and the output list file. By default, if no arguments are contained on the Xtal binary command line, the binary reads from standard input and writes to standard out. If one argument is present on this command line, it is treated as a potential .dat or .inp file and a .lst extension output filename is constructed for writing. If you choose this method, you will also have to set the global environment variable XTALHOME. This is set as follows: Goto "START"->"settings"->"control panel" and select the "SYSTEM" icon. Choose the "environment" tab and then enter XTALHOME as the variable with the complete drive path to the Xtal auxilliary files (cifmap etc) (don't forget the trailing backslash on the pathname @#$%!@!!!) Choose OK. Then logout and log back in again for the variable definition to take effect. With this done, running Xtal should be as simple as clicking on the icon of the .inp or .dat file and viewing the output listing in notepad.

Running SORTRF for noncentrosymmetric structures with Friedel reflections packed into the same reflection packet, occasionally leads to the situation where the Friedel is present but its inversion related parent is not. The core dump can be avoided by culling such reflection packets from the archive using the following instruction run after SORTRF:

modhkl
purge  -4.+19 $1 1 1304
    

To run LSLS and refine enantiomorphs using the twin operation for non-centrosymmetric structures, it is a prerequisite that reflections and their Friedel mates must be archived in separate packets using "SORTRF sepfrl". This means that twice as much reflection data is stored in the archive and twice as many reflections will actually be used in calculating Fourier maps. Note that this has the much sought after side effect of artificially improving the R-factor by doubling the number of observations in the least squares. Avoid this by packing Friedel mates into the same packet after running LSLS and before running FOURR. Otherwise you may get into all sorts of strife attempting to explain topographical features of your difference density which don't actually exist!

Their are differences between running FOURR using Beevers-Lipson summations or using the FFT. The most significant of which is that the FFT produces a fourier map that does not duplicate the first layer, the first row of every layer and the first point of every row. The upshot of this is that if you run a program such as PEKPIK, peak locations occuring close to the assymetric unit boundary on the the last layer/last row/last point are not interpolated correctly accross that boundary. Something to watch out for if you use the non-default option.

That was a Digital Visual Fortran compilation problem in Xtal3.6, fixed by upgrading the compiler before version 3.7 was released.