diversify _atom_type_scat.inv_mott_bethe_* and _ats.gaussian_* to better deliniate coefs

[rowlesmr]

The definition of _atom_type_scat.inv_mott_bethe_coefs holds the gaussian constant, scale and exponent in a single list.

This PR gives three new data names (and their SU counterparts) to split up the three types of values into three data names:

• _atom_type_scat.inv_mott_bethe_c_coefs
• _atom_type_scat.inv_mott_bethe_d_coefs
• _atom_type_scat.inv_mott_bethe_constant

the coeffs from the equation f(s; Z~0~) = Z~0~ - 8π * a~0~ * s^2^ * {e + Sum[ c~i~ * exp(-d~i~ * s^2^), i=1:N]} are stored separately: e (the constant), c~i~ in c_coefs, and d~i~ in d_coefs.

Ideally _atom_type_scat.inv_mott_bethe_coefs would just be straight up removed, as I don't think it's been released yet, but the RC has been set up, so probably not.

Argh. v3.3.0 has come out in the meantime.

.

edit:

Added

• _atom_type_scat.inv_mott_bethe_as
• _atom_type_scat.inv_mott_bethe_bs
• _atom_type_scat.inv_mott_bethe_c
• _atom_type_scat.gaussian_as
• _atom_type_scat.gaussian_bs
• _atom_type_scat.gaussian_c
• _atom_type_scat.cromer_mann_as
• _atom_type_scat.cromer_mann_bs

[vaitkus]

Argh. v3.3.0 has come out in the meantime.

According to the tags in this GitHub repository, version 3.3.0 has not yet been released. :)

If _atom_type_scat.inv_mott_bethe_coefs has been added in this development cycle, I think it can be safely removed if so desired. Changes can be applied to the release candidate if needed.

It seems reasonable to move the e constant out of the list, but I am unsure if the c and d should be split into separate lists given that these lists are expected to be of equal size and the corresponding elements should have inverse units (I think). However, this might be a more of a matter of taste.

[rowlesmr]

Yes, both lists need to be the same length. But in a single list, elements need to be present in pairs.

I like the two-list idea as it allows you to easily loop (in a programming sense)

e = _constant
cs = _c_coefs
ds = _d_coefs

total = 0
for i in range(len(cs)):
    total += cs[i] * exp (-ds[i] * s**2)
total += e
``

[rowlesmr]

According to the tags in this GitHub repository, version 3.3.0 has not yet been released. :)

If _atom_type_scat.inv_mott_bethe_coefs has been added in this development cycle, I think it can be safely removed if so desired. Changes can be applied to the release candidate if needed.

@jamesrhester can I have some inputhere please? Is this possible? I've also noticed that the same can be done for _atom_type_scat.gaussian_coefs, _atom_type_scat.cromer_mann_coeffs

I can also unify the nomenclature between them all.

[rowlesmr]

Dimensional analysis:
f(s; Z~0~) = Z~0~ - 8π * a~0~ * s^2^ * {e + Sum[ c~i~ * exp(-d~i~ * s^2^), i=1:N]}

s=sin(Th)/lambda

Given that the save frame for cromer_mann_c (the Cromer-Mann constant, which is in units of f) is defined as none units, I'm going to assume that none is the units of atom scattering

Units:

1. Z~0~: none (N)
2. 8π * a~0~ * s^2^: unitless * length * length^-2^: inverse_length (1/L)
3. {e + Sum[ c~i~ * exp(-d~i~ * s^2^), i=1:N]}: needs to be of the correct units to multiply with 2 to match units with 1.
   • the exponent is unitless, so d~i~: length^2 (L^2)
   • the constant and sum are of the same units, so e == Sum: none * length (NL)

N - (1 * L * L^-2)*(NL + Sum(NL * exp(L^2 * L^-2))`
N - (1/L)*(NL + Sum(NL * 1))
N - (1/L)*(NL +NL)
N - (NL / L)
N - N

So:

• units of e are length (angstroms) (technically, the same units as the wavelength)
• units of c are length (angstroms) (technically, the same units as the wavelength)
• units of d are length^2 (angstrom_squared) (technically, the same units as the wavelength^2)

[vaitkus]

• units of c are length (angstroms) (technically, the same units as the wavelength)

• units of d are length^2 (angstrom_squared) (technically, the same units as the wavelength^2)

Seems like an argument for having them in separate lists then.

[rowlesmr]

I've rejigged data names, unified nomenclature, and updated units. I haven't deleted or deprecated anything.

[jamesrhester]

@jamesrhester can I have some inputhere please? Is this possible? I've also noticed that the same can be done for _atom_type_scat.gaussian_coefs, _atom_type_scat.cromer_mann_coeffs

If @nautolycus hasn't started his typesetting then we can potentially make such a large change (in typesetting terms a lot of new definitions can wreck the flow on the page. Small adjustments are OK). I don't think this is important enough to force @nautolycus to redo any work, though.

That said, I do agree with the thrust of the changes, if only for the next release. The less heterogeneity in lists, the better.

[rowlesmr]

Roger doger. What about in regards deleting/deprecating the datanames? is that possible? Would prefer to delete, but if they're already part of a release... (assuming @nautolycus is good with the additions)

[jamesrhester]

Roger doger. What about in regards deleting/deprecating the datanames? is that possible? Would prefer to delete, but if they're already part of a release...

I strongly doubt any of these data names have been used in a data file. They were introduced in order to enable automated calculation of structure factors using dREL and are not something most software feels moved to report in a data file. So I'd be comfortable removing them. Let's wait and see whether or not @nautolycus has started his typesetting and we'll make a call after that.

[nautolycus]

So I'd be comfortable removing them. Let's wait and see whether or not @nautolycus has started his typesetting and we'll make a call after that.

Sorry, I'm not following GitHub messages closely at the moment, so please also email me where immediate input is required. I have no quibble with such a change from the viewpoint of presentation/typesetting. In general, any changes up to the publication of the release candidate are OK, though a heads-up on any significant changes will be appreciated.

[jamesrhester]

I'm seeing some data names changed to coefs (hi_angle_Fox) and some changed to coeffs (_atom_type_scat.exponential_polynomial_coeffs). What's the thinking here?

[rowlesmr]

I'm seeing some data names changed to coefs (hi_angle_Fox) and some changed to coeffs (_atom_type_scat.exponential_polynomial_coeffs). What's the thinking here?

That's me missing them. Given the previous use of *_coef in refine_ls, I thought to go to using that as the abbreviation.