Limits and excluded regions

[operandos]

Hi, I'm doing a Rietveld refinement of lab XRD data which includes large background peaks at high angles.
I set up histogram excluded regions in a project using the GUI.
Excluded regions were [64.58, 65.58] and [77.84, 78.84]. When I open this project in the scripting interface I can inspect the excluded regions I set up:

In:  hist.get('Limits')  
Out: [(10.0, 80.0), [10.0, 80.0], [64.58, 65.58], [77.84, 78.84]]

In a new project (starting without any excluded regions) my attempt to add exclusions to hist parameters via the scripting interface is as follows:

limits = hist.get('Limits')
exclusions = [[64.58, 65.58], [77.84, 78.84]]
limits.extend(exclusions)
hist.set_refinements({"Limits": limits,
                          "Background": {"no. coeffs": coeffs, "refine": True},
                          "Sample Parameters": ["Scale"]})

Returns the error:

hist.set_refinements({"Limits": limits,

  File ~\gsas2full\GSASII\GSASIIscriptable.py:3444 in set_refinements
    old_limits[0], old_limits[1] = new_limits

ValueError: too many values to unpack (expected 2)

Any help, pointers, code most welcome and appreciated!

Cheers, Operandos

[briantoby]

Hmmm, this looks like a limitation in the set_refinements code in that it was not set up to expect excluded regions in the input. A workaround, until I can think more on this, would be to do this:

limits = hist.get('Limits')
exclusions = [[64.58, 65.58], [77.84, 78.84]]
limits.extend(exclusions)
hist['Limits'] = limits

Actually, the last command is probably not needed as the 3rd one will likely modify hist['Limits']. The extend method is new to me (but looks convenient).

Quick question: your [64.58, 65.58] exclusion overlaps with the [64.5, 65.6] exclusion. Intended? I don't think the code will have a problem with that.

Brian

[operandos]

Thanks Brian, That has sorted out adding excluded regions to my project with simply:

if limits is None:
    limits = hist.get('Limits')
if exclusions is not None:
    limits.extend(exclusions)

I just wanted to replicate the excluded ranges I had set up using the GUI in a new project using the scripting, so I have modified my question to avoid confusion.

Cheers, Operandos

[operandos]

ps. Is there an appropriate forum for asking more general questions? I am finding it difficult to use the add_EqnConstr function with the current documentation. eg. when I set up a constraint to get atomic fractions of two atoms in the same site to add to 1:

gpx.add_EqnConstr(1.0,['0::AFrac:0','0::AFrac:1'], [1,1])

Then add atomic fractions to the refinement

phs[list(phs.keys())[0]].set_refinements({"Atoms":{"Li1":"F","Ni1":"F"}})

During refinement the message is returned:

Note these constraint warning(s):

Problem with constraint equation: 0::AFrac:0  + 0::AFrac:1  = 1.0
  parameter(s) not defined: 0::AFrac:0, 0::AFrac:1
  Ignoring constraint, no valid entries

And I do not get the Li1 and Ni1 fractions adding up to 1 (as was intended) !

Is something missing from the second argument of the add_EqnConstr - :param list varlist:? As usual when working out the script equivalent of a fitting routine done via the GUI (man_fit), I have opened and inspected a project in the scripting interface

In: man_fit.get_Constraints('Phase')
Out: 
[[[1.0,
   <Phase: rId=4276165032405382299 (#?); Atom rId=3034517829180680096 (#? -- not found!); Variable name="AFrac"> (?::AFrac:?)],
  [1.0,
   <Phase: rId=4276165032405382299 (#?); Atom rId=1848380567001226641 (#? -- not found!); Variable name="AFrac"> (?::AFrac:?)],
  1.0,
  None,
  'c']]

Which I don't really understand...

Any help with this function is much appreciated!

All the best, Operandos

[briantoby]

The scripting could have a bug. Would you be able to share the script and data so that I can see what is going on?

Constraints are translated from a variable name 0::AUiso:0 to a form where the atom number and phase number are found in a lookup table. I suspect that needs to be initialized before the inspection will work properly. That initialization might even be the scripting problem.

I'm recovering from COVID at the moment and it may be a few more days (I dearly hope not more than that) before my brain fog lifts to where I am able to work on this.