Discussion List Archives

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cif_core_2.4 discussion 1

  • To: Distribution list of the IUCr COMCIFS Core Dictionary Maintenance Group <coredmg@iucr.org>
  • Subject: Re: cif_core_2.4 discussion 1
  • From: Howard Flack <Howard.Flack@cryst.unige.ch>
  • Date: Wed, 12 Nov 2003 15:35:05 +0100
  • Organization: University of Geneva
  • References: <Pine.SOL.4.33.0310151538270.26288-100000@mcmail.cis.mcmaster.ca>


Comments from H.D.Flack

> PLEASE RESPOND TO THIS EMAIL BY NOVEMBER 30
  I seem to have made it on time for once. I wonder whether the distribution list is working properly because the only other comments I have seen come from Owen Johnson?

# Item 1.

> # the number of the symmetry operation in the _symmetry_equiv_pos_as_xyz loop

  _symmetry_equiv_pos_as_xyz has become _space_group_symop_operation_xyz as you well know.
  I'm somewhat unhappy that it is only in the pdf form of the current core dictionary that one is informed that items in the _symmetry section have been superseded. This information does not appear either in the text file or in the HTML form. I also noticed by searching in the text version of the core dictionary that there are still references to the _symmetry_* which have not be changed to the corresponding _space_group_* form. (It may be all of these are in _geom in which case they have been left unchanged on purpose at the moment.)

  The form of the text and the augumentation make it clear that the one and only way of introducing symmetry equivalent information is by way of _space_group_symop_operation_xyz. This precludes any automatic generation by way of the information given through _space_group_name_Hall . As I understand it, the Hall space group algorithm does not guarantee an unique order or labelling of the symmetry-equivalent positions. However is any development already under way or planned? If so, the whole text and rationale of Item 1 need rethinking. In any case maybe a more satisfactory way would be to generate an unique code from the coordinates of the equivalent position itself. This sounds like a perfect application for 'Methods'.

>;        An identifier that points to the symmetry operation S in the
> space_group_symop list.  S is defined in the expression below for the symmetry
> operation applied to the first listed atom.  The coordinates X' of an atom
> forming the distances and angles listed in the GEOM categories is given by:
>                    X' = SX + T

  The algebra is a bit wonky here. The symmetry operation S itself, as expressed in matrix form through _space_group_symop_operation_xyz, is a matrix-vector pair {W,w} of which only the matrix part operates on X, the coordinates of the atom. This gives as a matrix/vector equation:
                     X' = WX + w + T
On the other hand David may have had in mind that in  X' = SX + T, S and T are the operations themselves but then it is not correct to use X and X' which represent the coordinates of a point in a particular basis rather than representing the points themselves.

Over lunch in Zurich a few weeks ago, Tony Linden complained to me about some aspect of the new _space_group items. Unfortunately I forgot to note it down and he is away in the UK at the moment. If he replies to my e-mail by the time I have finished commenting all of the items, I'll let you know what he said.




# Item 2.

  Secretary please note that once agreement has been achieved on this item, that of _diffrn_reflns_resolution_full,  ..._resolution_max, ...._theta_full and ..._theta_max only ...._theta_full has a sentence like "The fraction of unique reflections measured out to this angle is given by _diffrn_measured_fraction_theta_full". Either all or none of them should have this information and it needs to brought up to date after resolution of item 2.

>  Should the definition of 'symmetry equivalent' be left to the author?
   Certainly NOT otherwise the value given is meaningless. 

>  Suggestions are welcome. 

    Today's best suggestion from HDF would be to have four data items instead of 2; in two of these (one _full and one _max) the definition would read
    "Fraction of unique (symmetry-independent in the Laue group) reflections"
and in the other two (one _full and one _max)
    "Fraction of unique (symmetry-independent in the crystal point group) reflections" to which one should add somewhere that for centrosymmetric point group one should only use the items referring to the Laue group.

    Does one need to explain that if the crystal point group is non-centrosymmetric it does not contain a centre of symmetry?




# Item 3.   


  I think my suggestion and David's text are just fantastic.




# Item 4.   

# STATUS: Open for discussion

  Please feel free to do whatever you think is appropriate. I'll agree so long as I do not have to do anything on Item 4.



# Item 5.
> _refine_ls_F_calc_accuracy   
> ;       The estimated accuracy in electrons (for X-ray diffraction)
>       reached during the evaluation of the structure factor given
>        by _refine_ls_F_calc_formula following the method outlined
>        in _refine_ls_F_calc_details.

  I suggest that in the definition "The estimated accuracy in electrons (for X-ray diffraction)" be changed to "The estimated accuracy in electrons (for X-ray diffraction) due to numerical approximations"

> _refine_ls_restrained_wR_factor_all
> recommend that we adopt this form.
  OK apart from
>                 sum(wY(obs)^2^+ sum~r~(w~r~P(targ)^2^) ]^1/2^
  should be
                 {sum(wY(obs)^2^) + sum~r~(w~r~P(targ)^2^)} ]^1/2^

> # _refine_ls_restraints_weighting_scheme
> # --------------------------------------
> # COMMENT:  IDB: Are the restraints mentioned in the following item specified
> # anywhere?  Can one describe the weights assigned to each restraint when the
> # restraints themselves are not defined?

   Very pertinent questions. I do not know the answer to either.
   I made a similar mess with _chemical_absolute_configuration . It does not allow you to indicate to which molecule it applies. When I discovered my mistake, I then discovered that CIF does not currently allow one to describe molecules. David's revenge was to put me on coreCIFchem.


# Item 6. 

> _atom_site_refinement_flag_adp
 
  Curt's proposals sound very reasonable indeed. Has he had any further thoughts on the matter. I'm happy with the general thrust of his comments. In case you had forgotten, I enjoyed that meal in the Chinese restaurant in LA.


H.  



_______________________________________________
coreDMG mailing list
coreDMG@iucr.org
http://scripts.iucr.org/mailman/listinfo/coredmg







[Send comment to list secretary]

[Reply to list (subscribers only)]