Add access to the linear polarisation rate

[vincefn]

@kif
The linear polarisation rate is not interfaced in python ; it would also be useful to add a parameter for an azimuthal angle, in case the pattern is not recorded in the plane perpendicular to the polarisation plane.
Both parameters (linear polarisation and azimuthal angle) should also be listed as RefinablePar.

See https://gsas-ii.readthedocs.io/en/latest/GSASIIpwd.html#GSASIIpwd.Polarization and
J.Appl.Cryst.(2020).53, 1559–1561

[kif]

Here is a quick & dirty monkey patch:

import io
import xml.etree.ElementTree as et
from pyobjcryst.powderpattern import PowderPattern

def get_polarization(powder_pattern):
    with io.StringIO() as file:
        powder_pattern.XMLOutput(file, 2)
        file.seek(0)
        xml_root = et.fromstring(file.read())
    xml_pol = xml_root.find("Radiation").find("LinearPolarRate")
    return float(xml_pol.text)
PowderPattern.LinearPolarRate=get_polarization

[vincefn]

A much less dirty approach would be to use the Radiation object (accessible through powder_pattern.GetRadiation()) XML string - using XMLInput on the entire PowderPattern has plenty of side effects (re-creating the powder pattern components), whereas re-importing just the radiation object is almost inconsequential.

In fact, you can input a modified value for just the linear polarisation rate with a stripped-down XML string:

s = "<Radiation>  <LinearPolarRate>0.9</LinearPolarRate> </Radiation>"
r.XMLInput(s)

Note however that after changing the linear polarisation rate, you'll need to change another parameter (such as the wavelength) to trigger an actual re-calculation of the powder pattern (because of the cached calculations and the fact that the linear polarisation rate is not a RefinablePar and thus its change does not invalidate stored computed values IIRC)....

[sbillinge]

@vincefn please can you look at this. If it is a quickish fix, do you want to try and include it in the upcpming release or put it off?

[vincefn]

You could add easily access through the radiation cpp extension, since there are {Get|Set}LinearPolarRate() functions. But with the issue I mentioned above - changing the polarisation rate will currently not trigger a recalculation of the pattern :-/, and this would need upstream changes (a dirty fix would be to overload SetLinearPolarRate so fakes a change in the wavelength, and a change in the Radiation MasterClock).

[sbillinge]

Let's put it off to the next release in that case. I don't want to hold up the current one. Thanks for hte feedback @vincefn