cif_core.dic: should _atom_type_scat.length_neutron import the defaults from templ_enum.cif

[vaitkus]

The templ_enum.cif file contains the length_neutron save frame which seemingly contains the default values of bound coherent neutron scattering lengths for various elements. This save frame is currently not imported by any of the dictionaries, but it could potentially be used by the _atom_type_scat.length_neutron definition from the cif_core.dic dictionary.

Maybe there is a good reason this is not being done?

[rowlesmr]

Maybe there is a good reason this is not being done?

We're just finding out!

.

But to actually answer the question, I'm guessing because _atom_type_scat.length_neutron is defined as the scattering lengths of the atoms used in the analysis, and the length_neutron save frame is the scattering lengths of the natural abundances of the isotopes.

.

Also, should the value actually be Complex instead of Real? I've never had to think about neutrons before, so I don't know how the imaginary component impacts on either powder of single-crystal intensities.

[rowlesmr]

Just having a quick read of ITC and ITH, and I don't know if I understand how neutron intensities are calculated.

ITC eqn 6.1.1.93 says:
F(S) = \sum_{j=1}^m f_j T_j \exp(iS \dot r_j)

where F is the structure factor, j is the atom number, m is the number of atoms, f is the scattering factor, T is the temperature factor, and r is the atom position. Furthermore, f = f0 + f' + if''.

Scattered intensities are proportional to |F|^2, and so we can replace f^2 with ff*, giving a (Real) value of ((f0 + f')^2 + (f'')^2).

ITH, eqn 2.3.7 gives the exact same equation, but replaces f for b, the bound coherent scattering length.

.

How, then, can the values in length_neutron be all Real?

If the scattering lengths in Table 4.4.4.1 are Real, then the values in the save frame appear to line up, but when they're Complex, they don't:

Dy - 16.9 vs 16.9 - 0.276i (this is just the real component)
Sm - 4.2 vs 0.80 - 1.65i (I can't see the relationship here)
Cd - 5.1 vs 4.87 - 0.70i (I can't see the relationship here)

When comparing with the lengths that TOPAS uses, TOPAS just seems to use the real component (divided by 10, for some reason). GSASII is similar (see line 771) with magnitudes, and also records the imaginary component for some isotopes, and not others.

What am I missing?

[rowlesmr]

Also, how are we supposed to represent complex values in CIF-speak? I can't find a reference or see any examples anywhere.

[vaitkus]

Also, how are we supposed to represent complex values in CIF-speak? I can't find a reference or see any examples anywhere.

I do not think that this is currently specified in any publicly available sources, but it will be in the new edition of ITG. Last I saw it, the description of complex CIF numbers from the draft version of a chapter read:

CIF string should have form ’a ± bj’ (whitespace optional) where a and b are interpreted as numbers.

So "-3.14+42j", "42 + 3.14(8)j", "4.2(1)-62.8(1)j" should all work. This is the format that is currently expected by the CIF validator which is used to check dictionaries in the repositories.

[rowlesmr]

Ta a lot.

Why j? We're not electrical engineers...

[vaitkus]

Using j instead of i also looks a bit unusual to me, but this probably depends on the person's background. @jamesrhester may be able to comment more on this as one of the coauthors of the previously mentioned chapter.

[rowlesmr]