Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Space group additions: space_group_hall and space_group_it_number #405

Merged
merged 10 commits into from
Jun 1, 2022

Conversation

merkys
Copy link
Member

@merkys merkys commented May 30, 2022

Partially addresses #35 This PR introduces two symmetry space group notations, Hall symbol and IT number, closely following their usage in CIF. Both Hall symbol and IT number have their drawbacks: in some cases both need additional information to uniquely define symmetry space group of a crystal. To cover this drawback, a list of symmetry operations is needed, and its introduction is envisaged in #35. Nevertheless standardizing Hall symbol and IT number would facilitate searches on these widely used notations.

@rartino
Copy link
Contributor

rartino commented May 30, 2022

Correct me if I am wrong, but I have come to the conclusion that it is not 100% safe to assume there is a standard Hall symbol for all possibilities - in case a structure isn't placed with a "proper" origin. Is it absolutely safe to assume there is a non-standard Hall symbol that describes structures given with a completely arbitary origin?

Also, I think I'm for MAY support level on these. If you don't know the symmetry information it can be very expensive (arguably sometimes even impossible) to assign them.

@merkys
Copy link
Member Author

merkys commented May 31, 2022

Correct me if I am wrong, but I have come to the conclusion that it is not 100% safe to assume there is a standard Hall symbol for all possibilities - in case a structure isn't placed with a "proper" origin. Is it absolutely safe to assume there is a non-standard Hall symbol that describes structures given with a completely arbitary origin?

Right, but maybe we can say that only standard Hall symbols are supported, and they should be provided only for structures with "proper" origin? My point is that if we cannot use standard Hall symbol/IT number to unambiguously define symmetry, these fields should be null, and in future symmetry operator lists should be used to define such situations.

Also, I think I'm for MAY support level on these. If you don't know the symmetry information it can be very expensive (arguably sometimes even impossible) to assign them.

Sure, I am fine with OPTIONAL/MAY support level.

@merkys merkys added topic/property-standardization The specification of the precise data representation of properties and entries type/proposal Proposal for addition/removal of features. May need broad discussion to reach consensus. status/has-concrete-suggestion This issue has one or more concrete suggestions spelled out that can be brought up for consensus. labels May 31, 2022
@rartino
Copy link
Contributor

rartino commented May 31, 2022

Based on a discussion with @BobHanson I now believe there exists a non-standard Hall symbol for every set of symmetry operators. So, I support this and we should not require the field to be a standard Hall symbol. (But is there also a redundancy in Hall symbols? Should we say that a standard Hall symbol SHOULD be given if it exists for the structure?)

(However, we also discussed that if the system has magnetism or other atomic-assigned properties that affects symmetry, then the Hall symbols are not sufficient to describe the symmetry.)

Copy link
Contributor

@rartino rartino left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few suggested changes

optimade.rst Outdated Show resolved Hide resolved
optimade.rst Outdated Show resolved Hide resolved
optimade.rst Outdated Show resolved Hide resolved
optimade.rst Show resolved Hide resolved
Co-authored-by: Rickard Armiento <gitcommits@armiento.net>
optimade.rst Outdated Show resolved Hide resolved
Co-authored-by: Rickard Armiento <gitcommits@armiento.net>
optimade.rst Outdated Show resolved Hide resolved
merkys and others added 5 commits May 31, 2022 17:58
Co-authored-by: Rickard Armiento <gitcommits@armiento.net>
Co-authored-by: Rickard Armiento <gitcommits@armiento.net>
Co-authored-by: Rickard Armiento <gitcommits@armiento.net>
Co-authored-by: Rickard Armiento <gitcommits@armiento.net>
@merkys merkys merged commit 8d6403b into Materials-Consortia:develop Jun 1, 2022
@merkys merkys deleted the space-group-additions branch June 1, 2022 08:19
- **Support**: OPTIONAL support in implementations, i.e., MAY be :val:`null`.
- **Query**: Support for queries on this property is OPTIONAL.
- Each component of the Hall symbol MUST be separated by a single space symbol.
- If there exists a standard Hall symbol which represents the symmetry it SHOULD be used.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- If there exists a standard Hall symbol which represents the symmetry it SHOULD be used.

@BobHanson
Copy link

I see this thread now.

A list of Hall symbols and a bit about how they are constructed can be seen in https://sourceforge.net/p/jmol/code/HEAD/tree/trunk/Jmol/src/org/jmol/symmetry/SpaceGroup.java.

After thinking about what Giovanni said in the session, I agree completely that although the Hall symbol would, for example, allow a regression back to fractional coordinates from Cartesians, it's really not something that anyone would be interested in for any other reason. It's too specific for searching -- If I am interested in a space group, say ITA #40, I don't care how the originator set the origin. That's just a particular choice they happened to make for whatever reason. (The structure looked prettier that way?)

All of these are #40:

ITA#
       Schoenflies
                      Hermann-Mauguin
                                      Hall
"40: c2v^16;   a m a 2;   a 2 -2a",  
"40: c2v^16;   b b m 2;  b 2 -2b",  
"40: c2v^16;   b 2 m b;  b -2b 2",  
"40: c2v^16;   c 2 c m;   c -2c 2",  
"40: c2v^16;   c c 2 m;   c -2c -2c",  
"40: c2v^16;   a m 2 a;   a -2a -2a",  

In ITA#4, you can see the situation where different H-M notations refer to the same space group setting, and where the same H-M notation refers to two different Hall descriptions:

"4:b c2^2;   p 1 21 1;   p 2yb",   //full name
"4:b c2^2;   p 21;         p 2yb",  
"4:b c2^2;   p 1 21 1;   p 2y1",   //nonstandard
"4:c  c2^2;  p 1 1 21;   p 2c",  
"4:c  c2^2;  p 1 1 21;   p 21",   //nonstandard
"4:a  c2^2;  p 21 1 1;   p 2xa",  
"4:a  c2^2;  p 21 1 1;   p 2x1",   //nonstandard

"nonstandard" here refers to the setting, not the symbols.

Thus, the purpose of Hall notation is an unambiguous description of any setting of a space group. This is not relevant here.

Suggestion: Just give ITA space group number. I will always know that, and I can look it up easily enough at a service such as http://img.chem.ucl.ac.uk/sgp/large/sgp.htm in order to relate it to H-M notation.

@merkys
Copy link
Member Author

merkys commented Jun 2, 2022

A wish has been expressed to also include space group Hermann-Mauguin symbol. This might need more discussion, as given space-group type may be described by more than one Hermann-Mauguin symbol (citing CIF CORE dictionary).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status/has-concrete-suggestion This issue has one or more concrete suggestions spelled out that can be brought up for consensus. topic/property-standardization The specification of the precise data representation of properties and entries type/proposal Proposal for addition/removal of features. May need broad discussion to reach consensus.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants