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

Element/Species: order full_electron_structure by energy #3944

Merged
merged 2 commits into from
Jul 23, 2024

Conversation

rkingsbury
Copy link
Contributor

Summary

This is a follow up to #3902 to address an inconsistent behavior I encountered. The major change in this PR is that full_electronic_structure is now always returned as a sorted list according to the Madelung rule, so that the final element is always the valence shell. Prior to this PR, this was sometimes but not always the case, as I elaborate below.

Major changes:

  • Element and Species.full_electronic_structure are now sorted by increasing energy level according to the Madelung rule
  • Updated and expanded unit tests to ensure valence and full_electronic_structure both work as expected
  • Minor changes to crystal field methods and associated unit tests to accommodate the sorting.
  • (indirectly related): added a n_electrons property to Species and Element

Background

As we discussed in #3902, electronic_structure should not be sorted by energy level, because this is how NIST and many other sources report it (e.g., for Ce(0) we have '[Xe].4f1.5d1.6s2').

full_electronic_structure parses electronic_structure into a list but did not make any attempt to sort it. In theory, given the above convention, one might expect this to mean that full_electronic_structure always gives orbitals in order of increasing quantum numbers (e.g. 1s, 2s ... 3d, 4s, 4p, 4d, 4f, 5s...), but that was not always the case. For example, it worked for Fe(0) which gave

[(1, 's', 2),
 (2, 's', 2),
 (2, 'p', 6),
 (3, 's', 2),
 (3, 'p', 6),
 (3, 'd', 6),
 (4, 's', 2)]

but for Ce(0) we get

[(1, 's', 2),
 (2, 's', 2),
 (2, 'p', 6),
 (3, 's', 2),
 (3, 'p', 6),
 (3, 'd', 10),
 (4, 's', 2),
 (4, 'p', 6),
 (4, 'd', 10),
 (5, 's', 2),
 (5, 'p', 6),
 (4, 'f', 1),
 (5, 'd', 1),
 (6, 's', 2)]

Ultimately, this is caused by the fact that when electronic_structure is written in shorthand (for example, Ce is [Xe].4f1.5d1.6s2), full_electronic_structure just takes that structure of the atom ([Xe]) and appends the new orbitals to it. This can result in unpredictable ordering of the orbitals as shown above.

valence DOES make an attempt to sort the orbitals, but because of the issues raised above, it will fail to find the correct valence for some Species.

The changes in this PR remedy all of the above problems and ensure that full_electronic_structure has a consistent meaning for all Element and Species.

@rkingsbury rkingsbury marked this pull request as ready for review July 21, 2024 19:53
@shyuep shyuep merged commit 09cf748 into materialsproject:master Jul 23, 2024
32 of 33 checks passed
@janosh janosh changed the title Element/Species: order full_electron_structure by energy Element/Species: order full_electron_structure by energy Aug 9, 2024
@janosh janosh added enhancement A new feature or improvement to an existing one core Pymatgen core labels Aug 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Pymatgen core enhancement A new feature or improvement to an existing one
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants