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

Ionic and Shannon radii handling #27

Open
dandavies99 opened this issue Jan 7, 2020 · 2 comments
Open

Ionic and Shannon radii handling #27

dandavies99 opened this issue Jan 7, 2020 · 2 comments

Comments

@dandavies99
Copy link
Member

The way that ionic and Shannon radii of Species are handled is confusing. There are several related problems:

problem 1:
Species currently have:

  • Shannon radii, which depend on the coordination environment
  • Ionic radii, which shouldn't* but do depend on coordination environment

(*If you subscribe to the idea that having one average ionic radius for each Species is a useful quantity.)

E.g. Different Shannon radii can be accessed for Ba:

Species('Ba', oxidation=2 , coordination=6).shannon_radius
1.49

Species('Ba', oxidation=2 , coordination=8).shannon_radius
1.56

But so can different ionic radii:

Species('Ba', oxidation=2 , coordination=6).ionic_radius
1.35

Species('Ba', oxidation=2 , coordination=8).ionic_radius
1.42

The data is loaded from shannon_radii.csv which contains multiple ionic radii for each Species, e.g.:

 ion,charge,coordination,crystal_radius,ionic_radius,comments,
...
 Ba,2,6_n,1.49,1.35,,
 Ba,2,7_n,1.52,1.38,,
 Ba,2,8_n,1.56,1.42,,
 Ba,2,9_n,1.61,1.47,,
 Ba,2,10_n,1.66,1.52,,
 Ba,2,11_n,1.71,1.57,,
 Ba,2,12_n,1.75,1.61,,

Problem 2:
When no 'coordination' is supplied, it is not obvious which ionic radius is chosen in shannon_radii.csv . In many screening studies we do not want to specify specific coordination environments and are interested in an average or typical value. E.g for Fe2+ the square planar ionic radius is selected:

Species('Fe', oxidation=2).ionic_radius
0.64

shannon_radii.csv:

Fe,2,4_n,0.77,0.63,,
Fe,2,4_sq,0.78,0.64,,
Fe,2,6_n,0.84,0.7,,
Fe,2,8_n,1.06,0.92,,

Problem 3:
It's not (obviously) possible to distinguish between Shannon radii for square planar and tetrahedral environments because 'coordination' is supplied as an integer, e.g.:

Species('Ag', oxidation=1, coordination=4).shannon_radius
1.16

shannon_radii.csv:

 Ag,1,4_n,1.14,1,,
 Ag,1,4_sq,1.16,1.02,,

Problem 4:
There is a file called ionic_radii.csv lurking around in data/ that as far as I can tell is no longer used for anything.

Suggestions:

  • Delete ionic_radii.csv
  • Decide whether or not we want different ionic radii available for the same Species. If there is no good reason, find a reputable source of ionic radii and update these.
  • Implement an intelligent way to select Shannon radii if no 'coordination' is given. This could possibly be to raise a warning and revert to the ionic radius, or to add a column in shannon_radii.csv that indicates a default coordination environment for each Species.
  • Implement some way to specify that you want to use the less common coordination environments '..sq' and '..py', as opposed to '.._n'.
@AntObi
Copy link
Contributor

AntObi commented Mar 11, 2021

In response to problem 1:

From Shannon, R. D. (1976). Acta Cryst. A32, 751-767., the ionic radii do indeed depend on the coordination environment. The difference between the shannon (referred to as crystal within shannon_radii.csv) and ionic radii are is that the crystal radius is based on r(VIO2-)=1.26 and r(VIF-)=1.19Å and that ionic radius is based on r(VIO2-)=1.40Å. Crystal radii correspond more closely to the physical size of ions.

In response to problem 2:
The default coordination in SMACT is 4 (though it is not obvious if the tetrahedral or square planar will be consistently selected as highlighted in problem 3).
We could add an average radii to the species class (can be computed for each instance of species, or calculated and added to the shannon_radii.csv).

We could also make the default coordination for a species, the most abundant coordination environment for that species by adding the relative abundance to the shannon_radii.csv file using the analysis from the following paper:
Waroquiers, D. et al., (2017). Statistical analysis of coordination environments in oxides. Chemistry of Materials, 29(19), pp.8346-8360.

In response to problem 3:
We could enable a selection of the environments as an argument to the species class with a default value(".._n"). We would need a way of making it easy to understand what different environments are available (a key to tell the user if an environment is available and what the environments correspond e.g. sq corresponds to square planar).

I can work on implementing your suggestions. Let me know what you think about the points I've raised.

@dandavies99
Copy link
Member Author

You seem to be right about problem 1 looking again at the original reference. I think my confusion comes from the fact that in pymatgen it is possible to get an ionic radius as long as you have an element + oxidation state, but to get a Shannon radius you need to also supply a coordination environment. I'm not 100% sure how ionic radii are decided upon though.

In general, I'm fairly sure that Shannon radii in pymatgen == Effective radii in the Shannon paper, and Ionic radii == Crystal radii in the Shannon paper. It would be good to keep the terminology as consistent as possible with codes like pymatgen.

We could also make the default coordination for a species, the most abundant coordination environment for that species by adding the relative abundance to the shannon_radii.csv file using the analysis from the following paper

^ I really like this idea, I think it would make a lot of sense! And for problem 3, I think that's a good idea to clarify the coordination. Again, we could take a leaf out of pymatgen's book who use some convention with roman numerals.

Thinking about all this, I'm wondering whether it would make more sense to rely more heavily on the pymatgen.core.periodic_table module within SMACT in general, as pymatgen is a dependency anyway...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants