-
Notifications
You must be signed in to change notification settings - Fork 874
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
SpaceGroup changes #3859
SpaceGroup changes #3859
Conversation
… corrected Schoenflies point group attribute, changed handling of rhombohedral space group type settings by adding a SpaceGroup hexagonal bool attribute, modified and added tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks @kaueltzen for submitting this fix! 👍 i left 3 questions
pymatgen/symmetry/groups.py
Outdated
if int_symbol in SpaceGroup.sg_encoding: | ||
self.full_symbol = SpaceGroup.sg_encoding[int_symbol]["full_symbol"] | ||
self.point_group = SpaceGroup.sg_encoding[int_symbol]["point_group"] | ||
else: | ||
self.full_symbol = re.sub(r" ", "", spg["universal_h_m"]) | ||
self.point_group = spg["schoenflies"] | ||
self.full_symbol = spg["hermann_mauguin"] # TODO full symbol not available from spg->maybe not add? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you elaborate on this TODO? does this mean the current full_symbol
is incorrect or incomplete?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes - as far as I can see, the full symbol (e.g., F4/m-32/m instead of Fm-3m) is only contained in SpaceGroup.sg_encoding, but not in SpaceGroup.SYMM_OPS. Both spg keys "hermann_mauguin" and "universal_h_m" do not contain this information. We could still set this attribute but issue a warning (maybe that's better than not setting it in these cases?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a warning and this seems to be only invoked when initializing non-standard settings (as expected). E.g., SpaceGroup("Pmc2_1")
does not invoke a warning, but SpaceGroup("P2_1ma")
does.
However, I struggle to write a test for that:
def test_full_symbol_warning(self):
with pytest.warns(Warning,
match="Full symbol not available, falling back to short Hermann Mauguin symbol P2_1ma instead.") as warns:
_ = SpaceGroup("P2_1ma")
assert len(warns) == 1
This fails with Failed: DID NOT WARN. No warnings of type (<class 'UserWarning'>,) were emitted. Emitted warnings: [].
and I don't understand why. Any ideas?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are you sure you weren't testing against the PyPI release of pymatgen
? your test passes for me. just pushed it to this PR. i expect it'll pass here as well
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for figuring out this issue! a33cc3c
pymatgen/symmetry/groups.py
Outdated
self.full_symbol = re.sub(r" ", "", spg["universal_h_m"]) | ||
self.point_group = spg["schoenflies"] | ||
self.full_symbol = spg["hermann_mauguin"] # TODO full symbol not available from spg->maybe not add? | ||
self.point_group = spg["schoenflies"].split("^")[0] # TODO map onto Hermann Mauguin notation? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let's come to a decision here before merging this PR. what would be the benefits of mapping onto Hermann Mauguin notation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The information is the same, but in these cases we'd have different notations for space group (Hermann Mauguin) and point group (Schoenflies) within one object. Also, it might cause issues if one wants to compare the point groups for a larger dataset (and the same point group could be there in different representations).
In order to map it, we would either need a database or we could, in principle, extract the point group in Hermann Mauguin notation from the space group symbol (by removing the centering and translation parts of symmetry elements) - this would require additional testing, though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe there could be a PointGroup class method from_spacegroup() that does exactly this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that sounds like a good idea! would you prefer to do that in a separate PR (or just open an issue for it)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great, i'd prefer to just open an issue for it and add it in this PR - will do both tomorrow (:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added the new class method and also added this info directly to the symm_ops.json
database so it does not have to be called every time when initializing a SpaceGroup
object. The changes to symm_ops.json
and symm_data.json
are documented in dev_scripts.update_space_group_data.py
- was not sure if this is the correct place, though!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thank you! this is great. it's super valuable to leave such a thorough paper trial for people to understand what happened later
def test_valid_symbol(self): # Added after issue #3845 | ||
for num in range(1, 231): | ||
symbol = SpaceGroup.from_int_number(num).symbol | ||
assert SpaceGroup(symbol).int_number == num |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is definitely a good test to have and an argument in favor of the changes in this PR
def test_hexagonal(self): | ||
for num in (146, 148, 155, 160, 161, 166, 167): | ||
sg = SpaceGroup.from_int_number(num, hexagonal=False) | ||
assert not sg.symbol.endswith("H") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why remove this test?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed it as the representation ("H" as last character) is not part of the symbol attribute in any case now.
We could maybe still keep this test and replace the assertion with a test for the hexagonal attribute assert sg.hexagonal == False
to check that this is given correctly to the SpaceGroup init.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
replacing the assertion with a test for the hexagonal attribute sounds good
Many thanks for this @kaueltzen! In case it is helpful in future, adding a note that the Important note for this PR: this technically counts as a breaking change. I can imagine cases whereby users are generating and storing space group strings in a database, for example, with the previous logic. Therefore, can you add a note to |
Thanks @mkhorton ! We know it is breaking. We had asked in the issue how to handle this. Thanks for pointing out how to do it in the best way! Very helpful. |
No problem, apologies I’d missed the issue comment. |
Thanks @mkhorton for pointing that out! Will add a note. |
Another minor issue: the space group types I2_12_12_1 and P2_12_12_1 are mapped onto I/P2_12_121 in |
…odified symm_ops.json and symm_data.json (documented in dev_scripts/update_space_group_data.py) to have same notation, added point group and short Hermann Mauguin symbol to symm_ops, fixed some typos, fixed rhombohedral space group type orbit issue.
Signed-off-by: Katharina Ueltzen <94910364+kaueltzen@users.noreply.github.com>
…on-underscore space group notations.
… point_group attribute setting.
…entity blickrichtungen and missed underscores, added warning to SpaceGroup init if full symbol is not available (for non-standard settings), added tests.
…und to annoying test pollution from side effects to std lib warnings registry
…12_12_1 and I2_12_12_1.
As far as I see it, all review requests have been addressed by @kaueltzen . Would be great if this could be merged if the changes are fine. |
Oh, now there are some conflicts 🫠 |
It is just a switch to a src based layout. Once you move the files, the conflicts should be simple to resolve. |
Resolve merge conflicts.
@shyuep is there anything that still needs to be done here? We would be very happy if this could be merged and fixed. |
Merged. Thanks, |
@shyuep thank you! |
Looks like this PR breaks one of the unit tests in windows?
Feel free to ping me if there's anything I could help :) |
@kaueltzen could you maybe take a look? |
Hi @DanielYang59 i cannot see where this might be due to the SpaceGroup changes. it seems like it is due to the latest spglib release? https://spglib.readthedocs.io/en/stable/releases.html#v2-5-0-9-jul-2024 The output data is not longer in dict format but in classes like SpglibDataset. The dict-like interface is planned to be removed, so there will be a lot of necessary changes in pymatgen. would modifiying the version of spglib to <2.5.0 in pyproject.toml be ok for you for now? |
@kaueltzen Apologize, I didn't look very closely into the failure (just noticed unit tests begin to fail after this PR, and this is related to spacegroup). Sorry for misleading you. I could confirm using |
Great 👍 and thanks for looking into this! |
…ntroduced by myself in materialsproject#3859
* Modified SpaceGroup.is_subgroup() following issue #3937, added tests. * Added crystal_system attribute to PointGroup, modified is_subgroup warning of SymmetryGroup. * Modified is_subgroup of PointGroup to raise NotImplementedError if group subgroup relationship would be possible (fr. crystal system), but cannot be checked currently due to crystallographic direction issue. * Enabled PointGroup init from different settings, added test for that, added missing setting differences (trigonal groups), re-enabled SpaceGroup.is_subgroup shortcut with constraint of non-klassengleiche group subgroup relationship * Removed bug in short Hermann Mauguin symbol of some trigonal groups introduced by myself in #3859 --------- Signed-off-by: Katharina Ueltzen <94910364+kaueltzen@users.noreply.github.com>
Summary
Fixes #3845 , #3861 and #3862 .
Includes the following changes in the symmetry module:
int_symbol
string parameter with the setting appended as before. The latter overrides the former for backwards compatibility.SpaceGroup point_group
attribute now always refers to the point group in Hermann Mauguin notation.from_space_group
was added toPointGroup
which initializes the 32 crystal classes from a SpaceGroup string in Hermann-Mauguin notation.symm_data.json
andsymm_ops.json
were made which are documented in dev_scripts/update_spacegroup_data.py .