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

Group-subgroup relationship bugs in SpaceGroup and PointGroup class #3937

Closed
kaueltzen opened this issue Jul 18, 2024 · 0 comments · Fixed by #3941
Closed

Group-subgroup relationship bugs in SpaceGroup and PointGroup class #3937

kaueltzen opened this issue Jul 18, 2024 · 0 comments · Fixed by #3941
Labels

Comments

@kaueltzen
Copy link
Contributor

kaueltzen commented Jul 18, 2024

Python version

3.10

Pymatgen version

master

Operating system version

No response

Current behavior

Hey, two remarks regarding the is_subgroup method of SpaceGroup:

First, the current implementation does not allow isomorphic group-subgroup relationships (same space group type) because of

new_sub_groups.update([j for j in max_subgroups[i] if j not in all_groups])

For example, I would expect the following code to not raise an error:
assert SpaceGroup("P3").is_subgroup(SpaceGroup("P3"))
The if j not in all_groups needs to be removed in the first iteration.

Second, the current implementation disregards klassengleiche group-supergroup relationships where the overall translational symmetry is increased, but not through centering. For example, I would expect this to not raise an error:
assert SpaceGroup("Fm-3m").is_subgroup(SpaceGroup("Pm-3m"))

However, because of

if len(supergroup.symmetry_ops) < len(self.symmetry_ops):
this returns False. I assume it is to save resources? I would either remove it completely (safest) or restrict it to certain cases, if possible(?).


Also, I had a look at the uncommented PointGroup subgroup test:

# assert pg3m.is_subgroup(pgm3m)

This test is failing because the -3 is defined along (111) in m-3m, but along (001) in -3m (therefore, the matrices are different). Generally, this affects all group-subgroup relationships if the groups are in crystal systems with different crystallographic directions / blickrichtungen. For example, this is also failing,
assert PointGroup("2").is_subgroup(PointGroup("4"))
because the rotation axis is along c in the tetragonal, but is notated along b in the monoclinic system (in this database).
I would specify this in the warning
warnings.warn("This is not fully functional. Only trivial subsets are tested right now. ")

In the future, it would probably be best to have a database similar to the maximal subgroup database of space group types.


If you agree, I can implement and test the SpaceGroup changes.

Expected Behavior

I would expect my code snippets from above to not raise an error.

Minimal example

No response

Relevant files to reproduce this bug

No response

@kaueltzen kaueltzen added the bug label Jul 18, 2024
kaueltzen added a commit to kaueltzen/pymatgen that referenced this issue Jul 19, 2024
shyuep pushed a commit that referenced this issue Nov 13, 2024
* 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant