[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
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]
- Follow-Ups:
- The meaning pf "categories"? [Was: Re: Please advise regarding adesign of CIF dictionaries for material properties] (Saulius Grazulis)
- Re: Please advise regarding a design of CIF dictionaries for materialproperties (Saulius Grazulis)
- Re: Please advise regarding a design of CIF dictionaries for materialproperties (Saulius Grazulis)
- References:
- Please advise regarding a design of CIF dictionaries for materialproperties (Saulius Grazulis)
- Prev by Date: Re: Please advise regarding a design of CIF dictionaries for materialproperties
- Next by Date: Re: Please advise regarding a design of CIF dictionaries for materialproperties
- Prev by thread: RE: Please advise regarding a design of CIF dictionaries formaterialpr operties. .
- Next by thread: Re: Please advise regarding a design of CIF dictionaries for materialproperties
- Index(es):