Discussion List Archives

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

Re: Please advise regarding a design of CIF dictionaries for materialproperties

  • To: "Discussion list of the IUCr Committee for the Maintenance of the CIFStandard (COMCIFS)" <comcifs@iucr.org>
  • Subject: Re: Please advise regarding a design of CIF dictionaries for materialproperties
  • From: Nick Spadaccini <nick@csse.uwa.edu.au>
  • Date: Sun, 02 Oct 2011 18:18:06 +0800
  • In-Reply-To: <4E832F86.6080805@ibt.lt>
This is a long response to your queries frm the point of view we (Syd and I)
work from. Our DDL is a significant evolution on from either DDL or DDL2,
but I have tries to stick to the generic issues with CIF and any DDL. Hope
it is understandable.

cheers

Nick

--------------------------------
Associate Professor N. Spadaccini, PhD.
Adjunct Research Fellow
The University of Western Australia
35 Stirling Highway
CRAWLEY, Perth,  WA  6009 AUSTRALIA
MBDP  M002

CRICOS Provider Code: 00126G

e: Nick.Spadaccini@uwa.edu.au



On 28/09/11 10:30 PM, "Saulius Grazulis" <grazulis@ibt.lt> wrote:

> Each tensor can be measured at different temperatures or pressures. To
> preset data convenietly, for both humans and computers, we curretnly
> plan to put each tensors' measurements into a separate loop. Since tag
> names may not be repeated int the same data block, we will have to
> define similar measurement condition tags for each tensor:
> 
> _prop_elastic_stiffness_temperature
> _prop_piezoelectric_temperature
> 
> (_prop_ is a prefix registered for MPOD in the IUCr prefix list).
> 
> Now, although this is only a small overhead in CIFs, it would be an
> overkill to specify all these tags separately in a dictionary. Thus, I

My initial question is how would this be overkill? This is meant to be a
dictionary for the wider community, filled with definitions relevant to the
discipline. A dictionary is effectively written once, and then (apart from
updates) resides in perpetuity. It is not as if you have to re-write these
definitions every time you want to use a dictionary.

If what you want to do is for programmatic convenience then you can use any
internal formalism you want. But the CIF dictionary are not there for
programmatic convenience they are strictly definitional. In that sense all
data items should be strictly and completely defined.

> would like to "contract" the definition of all
> _prop_<property>_temperature tags into one dictionary datablock:
> 
> data_prop_temperature
> loop_
> _name '_prop_elastic_stiffness_temperature'
>       '_prop_piezoelectric_temperature'
>       # Other names will follow and may be added in the future releases
>       # of the dictionary
> _type             numb
> _type_conditions  esd
> _category         prop # or prop_temperature ? or prop_elastic?
> _list             both
> _description
> ;
>    Specifies measurement temperature of a property in Kelvins.
> ;
> _example
> ;
>    Please see below in this mail...
> ;
> 
> Now, my questions are -- is there a problem if:

The above approach can dramatically increase complexity from both a human
readable approach and from an machine parsing approach in a more general
application. Firstly prop_ is not a category, it is a prefix (effectively
meaningless) designed only to protect namespaces of exiting data items. I
would have though from a definitional point of view the categories (plural)
would elastic_ (defining the elastic properties of materials) and say
piezoelectric_ (defining that property of materials) [in STAR/DDLm
categories and sub-categories are extensively employed]. Each of these
categories has attributes, typically the tensor of the property and the
temperature at which it is measured.

You seem to view all these temperatures as the same. However they are each
experimental measure of temperature at which tensors of very different
properties of material are measured. I don't see why they would bundled into
one definition.

So your example in general sense would have to work like this (remember what
you want has to be generally applicable, otherwise it is just your specific
hack). You have a list of _names, and you will have a list of categories_.
So how do you know which category_ goes with which name_? The order right?
Wrong. Order of packets in a loop_ is NOT guaranteed in STAR/CIF so there is
the first problem. Loops require a key to be included, and these are used to
uniquely identify the packet, not their ordering. Also each item in a
definition has a loop_ of examples. But if you have a loop of names in a
definition you will need an inner loop of examples - ie nested loops. Second
problem.

Besides the problems, the complexity of parsing your definition is
significantly increased. The structural example to what you want to do is to
say the "length" of the cell, and of a bond are the same property so have
_cell_length and _bond_length all bundled in the same definition. Not going
to actually provide an easier approach than separate definitions.

The total number of "temperatures" you are talking about are probably less
than 100. There is no great overhead in defining them all separately - they
would be certainly easier to read.
 
> a) tags of the same property are split into several loops in data CIFs?

I believe your definition of your property is not what you would call a
category. You CANNOT split tags of the same category across loops. The
reason is a loop has to have a key defined. In the REFLN category the key is
h k l (or [h, k, l] in STAR/DDLm. If you want to split the REFLN category
across 2 loops, you can have h k l in one, then what do you have in the
other loop as the key?

> b) one dictionary data block describes names that are potentially in
> different categories (but otherwise have the same characteristics)? For
> example, would the dictionary entry above be considered correct if we
> declare _prop_elastic_stiffness_temperature to be in
> 'prop_elastic_stiffness' category, and _prop_piezoelectric_temperature
> to be in 'prop_piezoelectric' category, and still have one dictionary
> datablock to specify their properties?

My explanation above describes why that won't work.
 
> b') or the category is so inclusive that it describes data spanning
> several loops (like '_prop_' category in the above example)?

Again prop_ is a prefix, not something one would define as the category. If
your definitions were to be absorbed by IUCr you should be able to drop the
prop_ prefix and make sure there are no namespace clashes. The fact that it
could be dropped indicates it is not an important part of an item's
definition (but certainly elastic and piezoelectric are).

> c) data_... block name in the dictionary no longer matches tag name. I
> guess this should not be a problem... Is it?

It is a convenience to have the data block name match the _name of the item,
it is NOT a requirement of the DDLs (well certainly was not at its
inception, but I am not sure if interpretations have since changed).

> d) would it break anything if category name is not the prefix of the tag
> (e.g. declaring _prop_piezoelectric_temperature to have category
> _prop_temperature, to describe all temperature tags in one data block)?

The name_ is actually just a string and for convenience includes the
category name. In STAR/DDLm we have blown it out yo be the following

save_Anything.YouLike

  _definition.id      Something.different_if_you_wish
  _category.id        RealCategory
  _object.id          ItemName
save_

The definition is in a save frame (the name of which can be anything). The
_definition.id is the tag (string) that appears in a data file which
identifies the value. And the concatenation of _category.id and _object.id (
RealCategory.ItemName) is the unique identifier that is utilised within
dREL. So over time _names can change and _aliases added, but the unique
identifier remains the same. The above definition (for convenience but not
mandatory) would normally appear as

save_RealCategory.ItemName

  _definition.id      RealCategory.ItemName
  _category.id        RealCategory
  _object.id          ItemName
save_
 
> e) Any other anticipated problems?

What follows is long winded but it is the way we would do it in STAR/DDLm

>>>> So here's your jigged example in instance format 1:

loop_
_prop_elastic_stiffness.material_id
_prop_elastic_stiffness.temperature
_prop_elastic_stiffness.c11
_prop_elastic_stiffness.c12
_prop_elastic_stiffness.c13
_prop_elastic_stiffness.c21
_prop_elastic_stiffness.c22
_prop_elastic_stiffness.c23
_prop_elastic_stiffness.c31
_prop_elastic_stiffness.c32
_prop_elastic_stiffness.c33
Copper  273  375.1  -48.5  -48.5  375.1   -48.5  375.1  101.4   101.4 101.4
Copper  293  375.1  -48.5  -48.5  375.1   -48.5  375.1  101.4   101.4 101.4
Copper  313  375.1  -48.5  -48.5  375.1   -48.5  375.1  101.4   101.4 101.4

loop_
_prop_piezoelectric.material_id
_prop_piezoelectric.temperature
_prop_piezoelectric.frequency
_prop_piezoelectric.d11
_prop_piezoelectric.d12
_prop_piezoelectric.d21
_prop_piezoelectric.d22
PIN-PMN-PT 100.0 5500 2190 1022 511 123
PIN-PMN-PT 105.0 5500 2190 1022 511 123
PIN-PMN-PT 110.0 5500 2190 1022 511 123

>>>>> Based on the definitions below the identical data can be expressed in
instance format 2:

>>>>> We exploit available data structures in DDLm.

loop_
_prop_elastic_stiffness.key
_prop_elastic_stiffness.tensor
[Copper, 273]  [375.1, -48.5, -48.5, 375.1, -48.5, 375.1, 101.4, 101.4,
101.4]
[Copper, 293]  [375.1, -48.5, -48.5, 375.1, -48.5, 375.1, 101.4, 101.4,
101.4]
[Copper, 313]  [375.1, -48.5, -48.5, 375.1, -48.5, 375.1, 101.4, 101.4,
101.4]

loop_
_prop_piezoelectric.key
_prop_piezoelectric.tensor
[PIN-PMN-PT, 100.0, 5500] [2190,1022,511,123]
[PIN-PMN-PT, 105.0, 5500] [2190,1022,511,123]
[PIN-PMN-PT, 110.0, 5500] [2190,1022,511,123]


>>>> Here are the definitions..............

>>>> We declare a hierarchy of category starting with prop.elastic.stiffness (bu
these maybe overkill - as I have said prop is not necessary and elastic maybe
the only category you want - this is something you would decide.

#---------------------------------------------------------------------------
-

save_PROP
    _definition.id               PROP
    _definition.scope            Category
    _definition.class            Set
    _definition.update           2011-09-27
    _description.text
;
     The CATEGORY of data items which specify the properties of materials.
;
    _name.category_id            MATERIAL
    _name.object_id              PROP

#---------------------------------------------------------------------------
-

save_PROP_ELASTIC
    _definition.id               PROP_ELASTIC
    _definition.scope            Category
    _definition.class            Set
    _definition.update           2011-09-27
    _description.text
;
     The CATEGORY of data items specifying elastic properties of materials.
;
    _name.category_id            PROP
    _name.object_id              ELASTIC

#---------------------------------------------------------------------------
-

save_PROP_ELASTIC_STIFFNESS
    _definition.id               PROP_ELASTIC_STIFFNESS
    _definition.scope            Category
    _definition.class            Loop
    _definition.update           2011-09-27
    _description.text
;
     The CATEGORY of data items which specify the elastic stiffness
     for materials at different temperatures in terms of 3x3 tensors.
;
    _name.category_id            PROP_ELASTIC
    _name.object_id              STIFFNESS
    _category.key_id           '_prop_elastic_stiffness.key'

>>>>> Note that the key can be constructed, provided the components are present.
Conversely from the ky you could get to _prop_elastic_stiffness.material_id,
_prop_elastic_stiffness.temperature by including the methods in their
definitions.


save_prop_elastic_stiffness.key
    _definition.id             '_prop_elastic_stiffness.key'
    _definition.update           2011-09-27
    _description.text
;
     Value is a unique key to a set of PROP_ELASTIC_STIFFNESS items
     in a looped list.
;
    _name.category_id            stiffness
    _name.object_id              key
    _type.purpose                Key
    _type.container              Single
    _type.contents               Inherited
     loop_
    _method.purpose
    _method.expression
     Evaluation
;    _prop_elastic_stiffness.key = [_prop_elastic_stiffness.material_id,
                                    _prop_elastic_stiffness.temperature]
;
     save_

save_prop_elastic_stiffness.material_id
    _definition.id             '_prop_elastic_stiffness.material_id'
    _definition.update           2011-08-01
    _description.text
;
     Name identifying each material whose properties are measured.
;
    _name.category_id            stiffness
    _name.object_id              material_id
    _name.linked_item_id       '_exptl.material_id'
    _type.purpose                Link
    _type.container              Single
    _type.contents               Text
     save_

save_prop_elastic_stiffness.temperature
    _definition.id             '_prop_elastic_stiffness.temperature'
    _import.get         [{"file":'templ_attr.cif',"fram":'temperature'}]
    _name.category_id            stiffness
    _name.object_id              temperature
     save_


save_prop_elastic_stiffness.tensor
    _definition.id             '_prop_elastic_stiffnes.tensor'
    _definition.update           2011-08-01
    _description.text
;
     The 3x3 matrix specifying the elastic stiffness tensor.
;
    _name.category_id            tensor
    _name.object_id              stiffness
    _type.purpose                Measured
    _type.container              List
    _type.contents               Real
    _type.dimension              [3,3]
     loop_
    _method.purpose
    _method.expression
     Evaluation
;
     With  o  as

      _prop_elastic_stiffness.tensor  =  [[ o.c11, o.c12, o.c13 ],
                                          [ o.c21, o.c22, o.c23 ],
                                          [ o.c31, o.c32, o.c33 ]]
;
     save_


save_prop_elastic_stiffness.c11
    _definition.id             '_prop_elastic_stiffness.c11'
    _import.get         [{"file":'templ_attr.cif',"fram":'stiff_tens'}]
    _name.category_id            stiffness
    _name.object_id              c11
     save_

save_prop_elastic_stiffness.c12
    _definition.id             '_prop_elastic_stiffness.c12'
    _import.get         [{"file":'templ_attr.cif',"fram":'stiff_tens'}]
    _name.category_id            stiffness
    _name.object_id              c12
     save_

save_prop_elastic_stiffness.c13
    _definition.id             '_prop_elastic_stiffness.c13'
    _import.get         [{"file":'templ_attr.cif',"fram":'stiff_tens'}]
    _name.category_id            stiffness
    _name.object_id              c13
     save_

save_prop_elastic_stiffness.c21
    _definition.id             '_prop_elastic_stiffness.c21'
    _import.get         [{"file":'templ_attr.cif',"fram":'stiff_tens'}]
    _name.category_id            stiffness
    _name.object_id              c21
     save_

save_prop_elastic_stiffness.c22
    _definition.id             '_prop_elastic_stiffness.c22'
    _import.get         [{"file":'templ_attr.cif',"fram":'stiff_tens'}]
    _name.category_id            stiffness
    _name.object_id              c22
     save_

save_prop_elastic_stiffness.c23
    _definition.id             '_prop_elastic_stiffness.c23'
    _import.get         [{"file":'templ_attr.cif',"fram":'stiff_tens'}]
    _name.category_id            stiffness
    _name.object_id              c23
     save_

save_prop_elastic_stiffness.c31
    _definition.id             '_prop_elastic_stiffness.c31'
    _import.get         [{"file":'templ_attr.cif',"fram":'stiff_tens'}]
    _name.category_id            stiffness
    _name.object_id              c31
     save_

save_prop_elastic_stiffness.c32
    _definition.id             '_prop_elastic_stiffness.c32'
    _import.get         [{"file":'templ_attr.cif',"fram":'stiff_tens'}]
    _name.category_id            stiffness
    _name.object_id              c32
     save_

save_prop_elastic_stiffness.c33
    _definition.id             '_prop_elastic_stiffness.c33'
    _import.get         [{"file":'templ_attr.cif',"fram":'stiff_tens'}]
    _name.category_id            stiffness
    _name.object_id              c33
     save_

    save_    # close the prop_elastic_stiffness category
    save_    # close the prop_elastic category

#---------------------------------------------------------------------------
-


save_PROP_PIEZOELECTRIC
    _definition.id               PROP_PIEZOELECTRIC
    _definition.scope            Category
    _definition.class            Set
    _definition.update           2011-09-27
    _description.text
;
     The CATEGORY of data items which specify the piezoelectric properties.
;
    _name.category_id            PROP
    _name.object_id              PIEZOELECTRIC
    _category.key_id           '_prop_piezoelectric.key'


save_prop_piezoelectric.key
    _definition.id             '_prop_piezoelectric.key'
    _definition.update           2011-09-27
    _description.text
;
     Value is a unique key to a set of PROP_PIEZOELECTRIC items
     in a looped list.
;
    _name.category_id            piezoelectric
    _name.object_id              key
    _type.purpose                Key
    _type.container              Single
    _type.contents               Inherited
     loop_
    _method.purpose
    _method.expression
     Evaluation
;    _prop_elastic_stiffness.key = [_prop_piezoelectric.material_id,
                                    _prop_piezoelectric.temperature,
                                    _prop_piezoelectric.frequency]
;
     save_


save_prop_piezoelectric.material_id
    _definition.id             '_prop_piezoelectric1.material_id'
    _definition.update           2011-09-27
    _description.text
;
     Name identifying each material whose properties are measured.
;
    _name.category_id            piezoelectric
    _name.object_id              material_id
    _name.linked_item_id       '_exptl.material_id'
    _type.purpose                Link
    _type.container              Single
    _type.contents               Text
     save_

##### NOTE!!!
##### The material_id definitions could also be abbreviated using
##### imported templates provided the id's identically equivalent!
#####


save_prop_piezoelectric.temperature
    _definition.id             '_prop_piezoelectric.temperature'
    _import.get         [{"file":'templ_attr.cif',"fram":'temperature'}]
    _name.category_id            piezoelectric
    _name.object_id              temperature
     save_


#####
##### Etc, etc...... you get the idea by now.
#####



>>>> Here is how the definition templates appear in the attributes template
file "templ_attr.cif".


save_temperature
    _definition.update           2011-09-27
    _description.text
;
     The temperature value in Kelvins.
;
    _type.purpose                Measured
    _type.container              Single
    _type.contents               Real
    _enumeration.range           0.0:
    _units.code                  kelvins
     save_


save_stiff_tens
    _definition.update           2011-09-27
    _description.text
;
     These are the tensor elements in units..... and blah blah
     and has the form blah blah  <<< pinched this from the UIJ template>>>

        T = exp{-2pi^2^ sum~i~ [sum~j~ (U^ij^ h~i~ h~j~ a*~i~ a*~j~) ] }

     h = the Miller indices
     a* = the reciprocal-space cell lengths

     The unique elements of the real symmetric matrix are entered by row.
;
    _type.purpose                Measured
    _type.container              Single
    _type.contents               Real
    _units.code                  Gražulis
     save_

Reply to: [list | sender only]