You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The issue is that our database of elements doesn't have structure factors for ions, such as Ba2+ but element info is often stored in cif files this way.
We are currently cleaning these manually or using the pavol trick:
from diffpy.structure import loadStructure
batio3 = loadStructure('BaTiO3.cif')
batio3.element = batio3.element.rstrip('+-012345678')
We don't want "magic" in the program which will confuse users, e.g. having hte code automatically change element information, however, I think that when we make a call to the existing database of element scattering factors, it would be ok to automatically strip the ion information before making the call to the db, without permanently resetting the element information. In the future, if we get a new database, this is easy to revert.
We could also try and be a bit clever and do our best effort to parse the element info, so if we find Ba2+ we could get the scattering factor for Xe (which is the neutral element with the same number of electrons as Ba2+. This may or may not work well, so should of course be tested.
I am just saving this here to return to in future if we need to.
The text was updated successfully, but these errors were encountered:
We can easily add a new class for X-ray scattering factors table, say SFTXrayNeutral, which will ignore charge information and always return scattering factors for neutral elements.
As for the second option - we can add mapping for missing ions, such as Ba2+ --> Xe, to the standard SFTXray class. The only downside is there would be no way to tell (apart from reading the code) if returned value is from a published approximation formula or from a mapped element.
As for the f(Q) behavior - would the one for Ba2+ be closer to 54/56 * f_Ba(Q) or to f_Xe(Q)?
good points all.
As to the last question, hte answer is that we don't know of
course....until we try. But my gut feeling is that this won't make too
much difference. For example, up to now we have been using the mapping
f_Ba2+(Q) --> f_Ba(Q) which is almost certainly worse than either 54/56 *
f_Ba(Q) or f_Xe(Q) (it has the wrong number of electrons by 2!) and yet,
no-one has complained or even noticed.....
S
On Sat, Jan 5, 2019 at 11:09 PM Pavol Juhas ***@***.***> wrote:
We can easily add a new class for X-ray scattering factors table, say
SFTXrayNeutral, which will ignore charge information and always return
scattering factors for neutral elements.
As for the second option - we can add mapping for missing ions, such as Ba2+
--> Xe, to the standard SFTXray class. The only downside is there would
be no way to tell (apart from reading the code) if returned value is from a
published approximation formula or from a mapped element.
As for the f(Q) behavior - would the one for Ba2+ be closer to 54/56 *
f_Ba(Q) or to f_Xe(Q)?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#53 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEDrUcoHfUXKPrLOOCXUT2ErIudtlG_8ks5vAXcQgaJpZM4Zwqm->
.
The issue is that our database of elements doesn't have structure factors for ions, such as Ba2+ but element info is often stored in cif files this way.
We are currently cleaning these manually or using the pavol trick:
We don't want "magic" in the program which will confuse users, e.g. having hte code automatically change element information, however, I think that when we make a call to the existing database of element scattering factors, it would be ok to automatically strip the ion information before making the call to the db, without permanently resetting the element information. In the future, if we get a new database, this is easy to revert.
We could also try and be a bit clever and do our best effort to parse the element info, so if we find Ba2+ we could get the scattering factor for Xe (which is the neutral element with the same number of electrons as Ba2+. This may or may not work well, so should of course be tested.
I am just saving this here to return to in future if we need to.
The text was updated successfully, but these errors were encountered: