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

[ddlm-group] Your thoughts on correct approach for DDLm modulatedstructures dictionary GEOM categories

  • To: ddlm-group <ddlm-group@iucr.org>
  • Subject: [ddlm-group] Your thoughts on correct approach for DDLm modulatedstructures dictionary GEOM categories
  • From: James Hester <jamesrhester@gmail.com>
  • Date: Thu, 17 Nov 2016 16:57:06 +1100
  • DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;h=mime-version:from:date:message-id:subject:to;bh=MGxeyduTwh+qPrhZClPnlGjqWb2KH4M8UZ8BDZLAAQs=;b=0nDHdW2OqEGGgmn1KOyCLCsXlOK1fxS6tJWTjzZEu4cNZprnJRWGYGpPQNgfw6hbdbsKNOm+tRwObkg7Yyxj+KX0ZZC5+wKy0rCdUTKfKqt0wZDlqflOjVhhhVA6pFHuh9jQ26nmT9BzUq8DxlOTrXRjHxI2mt2L33kxFR7oUAYZhVOmhRP6WtTCLToHeVlQorsr2oNb2Yf9dmJIuaoenHostChswgGJoV8+wg69lj3TAjkU3dbLzYLKGd8hZYqNJ6nx0bm4JUs6ufnSoSRDi9Y3ZAyYS6tWPNIA7ElaWroBxhhoGJplNuzFbNKxLjYmRZA6WJy8cYZrVGNykYh4gA==
Dear DDLm-group,

I am currently going through the DDLm conversion of the modulated structures dictionary. It goes without saying that it will be split into a core_cif compatible section and an _audit.schema-using extension dictionary, as numerous categories receive extra keys due to the extra m1,m2,m3... reflection indices. That in itself is not a problem; however, I have come across the following "interesting" situation in the GEOM categories, and would like your input into how to resolve this:

The core cif method of identifying a particular atom site for geometry calculation uses the atom label and a symmetry operator of the form n_qrs, where n is a symmetry operator and qrs are unit cell translations + 5.  So the key datanames for the list of bonds (GEOM_BOND category) are atom_labels 1 and 2, and site_symmetry 1 and 2.  The bond length can be calculated using the information encoded in these keys.

The DDL1 modulated structures dictionary needs more than three translations, so defines new datanames site_ssg_symmetry 1,2 where the value might be n_qrstuv (i.e. more translations).  The intention is clearly to replace the original site_symmetry keys with the site_ssg_symmetry keys, so, strictly speaking, GEOM_BOND et. al. are new categories in the ms CIF dictionary. This is starkly evident in the dREL for geom_bond.distance from core_cif: it is no longer correct, reflecting the fact that most core cif compatible software that seeks to (re)calculate geom_bond.distance will fail when presented with a msCIF file.

We seek a resolution that keeps the dREL correct and minimises the chances of incorrect interpretation of a CIF file.

I see two alternatives:
(1) Allow dictionaries that operate under a different _audit.schema to replace keys, thereby keeping the same category name for what is essentially a different category. Any dREL-containing definitions must have the dREL rewritten or removed.

Advantages: "Very similar" datanames do not need to be renamed. DDLm datanames can match DDL1 datanames as closely as possible
Disadvantages: potential trivial redefinition of many datanames in all affected categories. Sets a precedent for giving different categories the same name?

(2) Change the GEOM_ categories to (e.g.) GEOM_SSG categories

Advantages: Strictly correct, no chance of confusion for _audit.schema non-aware programs (hopefully fewer of these as time goes on)
Disadvantages: Will proliferate datanames?

I am inclined towards (1) on the grounds that:
(a) Once _audit.schema is declared and checked, it is clear that the CIF software author is aware of MS CIF, including any redefinitions, so there is little danger of silent software mistakes;
(b) Fundamentally the site_symmetry_ datanames are decomposable into 4 key columns each (symmetry operator, 3 translations).  So MS CIF is simply adding more key columns, in accordance with how we expect _audit.schema to operate.
(c) We (COMCIFS) can always reserve the right to reject new dictionaries that attempt a category rename.

Can any of you see a problem with option (1)?


T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148
ddlm-group mailing list

Reply to: [list | sender only]