Re: [Jmol-developers] Re: ISCD cif file validity -- symmetry

[Peter Murray-R. <pm...@ca...>]

At 12:19 16/10/2004 -0500, Bob Hanson wrote:
>Peter, you should probably look at the CIF files yourself if you are 
>concerned. Just do a simple query at 
>http://icsdweb.fiz-karlsruhe.de/index.php perhaps for "C" as an element. 
>Check a hit, ask for "Details" then "export".  You'll see immediately what 
>they look like.
>
>Sorry, they aren't that radically wrong. I was just excising pieces and I 
>didn't grab all the lines. For example, you will see:

I'm afraid the discussion on this list has confused me. The point was made 
that the CIF files from ICSD did not follow the CIF standard. Examples were 
given of what appeared to be broken CIFs (missing coordinates (or 
coordinates with '-') and missing symmetry operators. I said that *iff* 
these files had come out of the ICSD then they were a disservice and I 
asked for an example.

In fact I have checked with a random entry on ICSD of which I reproduce 
part (I am not legally allowed to print the whole CIF): You will see that 
the symmetry operator 'x,y,z' *IS* present and so are the coordinates for 
atoms at 0,0,0. This is what I expected.

I actually wrote:
"
>>Make ABSOLUTELY sure they are direct from ICSD. Then I will send them to 
>>David Brown (one of the authors of CIF) and I am sure he will get ICSD to 
>>change them. But I have to be sure they came direct from ICSD.
"
I would guess that you have got coordinates from somewhere else and should 
be very careful of asserting that they came from ICSD.

------------------------------------------------ from ICSD -------------
loop_
_publ_author_name
Greaves, C.;Slater, P.R.
_cell_length_a                     3.8606(2)
_cell_length_b                     3.8606(2)
_cell_length_c                     11.803(1)
_cell_angle_alpha                  90.
_cell_angle_beta                   90.
_cell_angle_gamma                  90.
_cell_volume                       175.91
_cell_formula_units_Z              1
_symmetry_space_group_name_H-M     'P 4/m m m'
_symmetry_Int_Tables_number        123
_refine_ls_R_factor_all            0.025000
loop_
_symmetry_equiv_pos_site_id
_symmetry_equiv_pos_as_xyz
   1     'y, x, -z'
   2     '-y, -x, -z'
   3     '-y, x, -z'
   4     'y, -x, -z'
   5     '-x, y, -z'
   6     'x, -y, -z'
   7     'x, y, -z'
   8     '-x, -y, -z'
   9     '-y, -x, z'
   10     'y, x, z'
   11     'y, -x, z'
   12     '-y, x, z'
   13     'x, -y, z'
   14     '-x, y, z'
   15     '-x, -y, z'
   16     'x, y, z'
loop_
_atom_type_symbol
_atom_type_oxidation_number
Y3+     3.
Ba2+     2.
Cu1+1     1.81
O2-     -2.
loop_
_atom_site_label
_atom_site_type_symbol
_atom_site_symmetry_multiplicity
_atom_site_Wyckoff_symbol
_atom_site_fract_x
_atom_site_fract_y
_atom_site_fract_z
_atom_site_B_iso_or_equiv
_atom_site_occupancy
Y1 Y3+ 1 d 0.5 0.5 0.5 0.76(3) 1.
Ba1 Ba2+ 2 h 0.5 0.5 0.1946(2) 0.92(4) 1.
Cu1 Cu1+1 1 a 0 0 0 0.93(4) 1.
Cu2 Cu1+1 2 g 0 0 0.3616(1) 0.52(2) 1.
O1 O2- 4 i 0 0.5 0.035(1) 0. 0.085
O2 O2- 4 i 0.5 0 0.3788(1) 0. 1.
O3 O2- 2 g 0 0 0.1513(2) 0. 0.94
loop_
_atom_site_aniso_label
_atom_site_aniso_type_symbol
_atom_site_aniso_U_11
_atom_site_aniso_U_22
_atom_site_aniso_U_33
_atom_site_aniso_U_12
_atom_site_aniso_U_13
_atom_site_aniso_U_23
Y1 Y3+
Ba1 Ba2+
Cu1 Cu1+1
Cu2 Cu1+1
O1 O2- 2.8(9) 1.0(7) -1.4(6) 0 0 0
O2 O2- 0.36(4) 0.65(5) 2.56(9) 0 0 0
O3 O2- 0.45(6) 0.45(6) 2.9(1) 0 0 0
#End of data_67206-ICSD
-----------------------------------------
>loop_
>_symmetry_equiv_pos_site_id
>_symmetry_equiv_pos_as_xyz
>   1     '-y, -x+1/2, z+1/4'
>   2     'y, -x, -z'
>   3     'y, x+1/2, z+1/4'
>
>So the loop business is all there correctly.
>There are no "serious problems" with these files. Jmol reads them just fine.
>They are certainly not doing us a disservice.
>
>I'm sure if you can find the place in the CIF format description that
>specifies that the trivial "x, y, z" must be present, they will see to it that
>it gets in there. But it shouldn't be a big deal. I wouldn't obsess over it.
>
>>
>>>Oh, I see now. ICSD does not report the (trivial) 'x, y, z'.
>>>I think it's safe to say 'x, y, z' is implied and not necessary.
>>1
>>I think it is extremely unsafe for ICSD to omit it.
>
>Why would you say that, if every possible space group has this? These 
>entries would be used to take the starting positions and generate the 
>symmetry-equivalent positions. You always start with the primary (x,y,z)
>coordinates in hand. It's not like it's a programming dilemma, right?
>But, I agree, it would be SMART to have 'x,y,z' there somewhere.
>
>>
>>>>>I'm guessing that any CIF file showing only fractional coordinates
>>>>>must contain this record.
>>>>
>>>>
>>>>Strictly not. All crystals implicit have 'x,y,z' and that would be the 
>>>>default. Rather more difficult, you can specify the spacegroup and look 
>>>>the positions up in Int. Tab. for Cryst. unfortunately there don't seem 
>>>>to be any open collections of space group operators
>
>Amazing. All CIF files should (IMHO) be required to specify the 
>symmetry-equivalent positions irrespective of what the space group is 
>named, at least if only the primary coordinates are provided. I would have 
>thought that these operations would be the key set of information, not the 
>name.
>
>>>
>>>
>>>I'm sure web can get this list from IUCr.
>>
>>No - I asked on Monday
>
>>
>>>  But it's a BIG list. There are
>>>230 space groups and about 40 optional origins/coordinate systems (see 
>>>ftp://ftp.iucr.org/pub/cif_sym_1.0.dic).
>>
>>This is the dictionary governing the symmetry, not the operations themselves.
>
>right, you need them all.
>
>>
>>>  Several of the 230 groups have
>>>96 equivalent positions, and some have 192.
>>
>>Correct.
>>
>>>  You want to list all of these somewhere in Jmol code? I think this is 
>>> going to be a big burden on Jmol.
>>
>>It isn't unreasonable for a crystallographically aware program (like 
>>SHELX and now Jmol) to have access to a lookup-table of space groups. 
>>This need only be accessed if the author includes the space group symbol 
>>but not the positions. Also if the space group is Hall it is possible to 
>>calculate the operators from the symbols.
>>
>>>Personally, I think this is a flaw in the CIF standard.
>>
>>I'd regard it as a problem in conformance. Theoretically it is perfectly 
>>allowable to give just the spacegroup and refer the reader to 
>>International tables but it makes it difficult for program writers. I 
>>think some authors for some journals do not include the operators and 
>>should be strongly urged to do so
>>
>>>This business is SO tricky, it only seems reasonable to include all 
>>>positions.
>>
>>I agree. There are shortcuts in some listings where the operators 
>>deducible from centre of symmetry and also the lattice centering are 
>>omitted. This reduces 192 in (say Fm3m) to 24 (192 = 24*2(centre)*4(lattice)
>>
>>>  Don't atoms with
>>>different equivalent positions have different labels, anyway?
>>
>>Sometimes, but they are not normally included in the CIF.
>
>>
>>>Am I understanding correctly that what we are after here is being able
>>>to read CIF files that contain only
>>>
>>>loop_
>>>_atom_site_label
>>>_atom_site_type_symbol
>>>_atom_site_symmetry_multiplicity
>>>_atom_site_Wyckoff_symbol
>>>_atom_site_fract_x
>>>_atom_site_fract_y
>>>_atom_site_fract_z
>>>_atom_site_B_iso_or_equiv
>>>_atom_site_occupancy
>>>
>>>information for the (x,y,z) identity operation?
>>>For example, buckyball with one single atom listed?
>>
>>Buckyball would actually require more atoms as crystals do not support 
>>icosahedral symmetry. But the logic is correct. Thus an octahedron of B 
>>atoms (B6) might just have one atom reported.
>>
>>>I'm not familiar with such files, although I understand that "in the old 
>>>days" this is how just about all crystal files were delivered.
>>
>>Correct
>>
>>>  Where are they arising from? Peter, maybe you sent us some copies. I 
>>> think I missed that. Is this possibly something we can avoid?
>>
>>No. I am currently starting discussions on the CIF discussion group as to 
>>how to manage symmetry and disorder
>>
>>>I have implemented code in Molecular Origami that ALMOST does this. But 
>>>I had trouble with identifying the origins. My solution was to identify 
>>>a set of "minimum operations" that defined each point
>>>group. It was very compact. For example,
>>>
>>>Fd-3m(origin at CxCyCz)=227,192,F 4102/d1 -3111 2023/m
>>>Fd-3m(origin at i)=227,192,F 4131/d -3 2022/m1
>>>Fd-3c(origin at CxCyCz)=228,192,F 4102/d3 -3333 2023/c
>>>Fd-3c(origin at i)=228,192,F 4113/d -3 2020/c1
>>>Im-3m=229,96,I 4/m -3 2/m
>>>Ia-3d=230,96,I 4120/a2 -3 2021/d
>>>
>>>(Don't ask what all this means. I simply give these as examples of how 
>>>192 or 96
>>>equivalent positions can be coded into a single short expression.)
>>
>>They can actually be completely encoded in the Hall space group symbol 
>>and this should be the preferred way of doing this. If you create code 
>>that translates Hall symbols that would be very useful. From what you 
>>say, it shouldn't be too hard to adapt your code
>
>Unfortunately that won't be enough. We have from the specs:
>
>;             Hermann-Mauguin space-group symbol. Note that the H-M symbol 
>does
>               not necessarily contain complete information about the symmetry
>               and the space-group origin. If used always supply the FULL 
> symbol
>               from International Tables for Crystallography, Vol. A 
> (1987) and
>               indicate the origin and the setting if it is not implicit. If
>               there is any doubt that the equivalent positions can be 
> uniquely
>               deduced from this symbol specify the _symmetry_equiv_pos_as_xyz
>               or *_Hall data items as well. Leave spaces between symbols
>               referring to different axes.
>;
>ftp://ftp.iucr.org/pub/cif_core.dic
>
>>
>>>Be aware that if you are going to do this right, you also have to take 
>>>into account (ah, so fun!) trigonal and hexagonal coordinates.
>>
>>Yes
>>
>>>I have spent enough time on this problem to know it is a VERY serious 
>>>project.
>>
>>Yes.
>>OTOH it is formally completable. I can give you encouragement!
>
>me? not me...
>
>>If you have some ICSD CIFs that you think are broken, please send them to 
>>me (though I can't do much for ca 2 weeks). Make ABSOLUTELY sure they are 
>>direct from ICSD. Then I will send them to David Brown (one of the 
>>authors of CIF) and I am sure he will get ICSD to change them. But I have 
>>to be sure they came direct from ICSD.
>
>again, download any file from their www interface. None have (x,y,z)
>
>>If you want CIFs certified to be correct, look at (say)
>>http://journals.iucr.org/e/issues/2004/10/00/EAtxtisscontsbdy.html
>>and click on any link denoted by CIF. The inorganic ones should give you 
>>an idea of how to manage highly symmetric structures
>>P.
>>
>>>Bob
>>>
>>>
>>>--
>>>Robert M. Hanson, ha...@st..., 507-646-3107
>>>Professor of Chemistry, St. Olaf College 1520 St. Olaf Ave., Northfield, 
>>>MN 55057
>>>mailto:ha...@st... http://www.stolaf.edu/people/hansonr
>>>
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
>>>Use IT products in your business? Tell us what you think of them. Give us
>>>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
>>>http://productguide.itmanagersjournal.com/guidepromo.tmpl
>>>_______________________________________________
>>>Jmol-developers mailing list
>>>Jmo...@li...
>>>https://lists.sourceforge.net/lists/listinfo/jmol-developers
>>
>>Peter Murray-Rust
>>Unilever Centre for Molecular Informatics
>>Chemistry Department, Cambridge University
>>Lensfield Road, CAMBRIDGE, CB2 1EW, UK
>>Tel: +44-1223-763069
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
>>Use IT products in your business? Tell us what you think of them. Give us
>>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
>>http://productguide.itmanagersjournal.com/guidepromo.tmpl
>>_______________________________________________
>>Jmol-developers mailing list
>>Jmo...@li...
>>https://lists.sourceforge.net/lists/listinfo/jmol-developers
>
>--
>Robert M. Hanson, ha...@st..., 507-646-3107
>Professor of Chemistry, St. Olaf College 1520 St. Olaf Ave., Northfield, 
>MN 55057
>mailto:ha...@st... http://www.stolaf.edu/people/hansonr
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
>Use IT products in your business? Tell us what you think of them. Give us
>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
>http://productguide.itmanagersjournal.com/guidepromo.tmpl
>_______________________________________________
>Jmol-developers mailing list
>Jmo...@li...
>https://lists.sourceforge.net/lists/listinfo/jmol-developers

Peter Murray-Rust
Unilever Centre for Molecular Informatics
Chemistry Department, Cambridge University
Lensfield Road, CAMBRIDGE, CB2 1EW, UK
Tel: +44-1223-763069