[CSX] HKL problems with calculations

[cmazzoli]

@dchabot, @klauer
HKL libs somtimes cannot calculate accessible positions. If suitably guided, then a reasonable solution is proposed.

In [117]: tardis.move([0,0,0.4375*3])
---------------------------------------------------------------------------
GError                                    Traceback (most recent call last)
/home/xf23id1/Repos/hklpy/hkl/engine.py in pseudo_positions(self, values)
    191             geometry_list = self._engine.pseudo_axis_values_set(values,
--> 192                                                                 self._units)
    193         except GLib.GError as ex:

GError: none of the functions were solved !!!

During handling of the above exception, another exception occurred:

ValueError                                Traceback (most recent call last)
/home/xf23id1/Beamline/BDT/2016_04_14/2016_04_15.py in <module>()
----> 1 tardis.move([0,0,0.4375*3])

/home/xf23id1/conda_envs/collection/lib/python3.4/site-packages/ophyd/pseudopos.py in wrapped(self, *args, **kwargs)
    171                 pos, new_kwargs = self.to_real_tuple(*args, **kwargs)
    172 
--> 173             return method(self, pos, **new_kwargs)
    174 
    175         return wrapped

/home/xf23id1/conda_envs/collection/lib/python3.4/site-packages/ophyd/pseudopos.py in move(self, position, wait, timeout, moved_cb)
    734         '''
    735         return super().move(position, wait=wait, timeout=timeout,
--> 736                             moved_cb=moved_cb)
    737 
    738     move.__doc__ = SoftPositioner.move.__doc__

/home/xf23id1/conda_envs/collection/lib/python3.4/site-packages/ophyd/positioner.py in move(self, position, wait, timeout, moved_cb)
    282             If motion fails other than timing out
    283         '''
--> 284         status = super().move(position, moved_cb=moved_cb, timeout=timeout)
    285 
    286         self._setup_move(position, status)

/home/xf23id1/conda_envs/collection/lib/python3.4/site-packages/ophyd/positioner.py in move(self, position, moved_cb, timeout)
    113             timeout = self._timeout
    114 
--> 115         self.check_value(position)
    116 
    117         self._run_subs(sub_type=self._SUB_REQ_DONE, success=False)

/home/xf23id1/conda_envs/collection/lib/python3.4/site-packages/ophyd/pseudopos.py in check_value(self, pseudo_pos)
    518                                                             pos, high))
    519 
--> 520         real_pos = self.forward(pseudo_pos)
    521         for real, pos in zip(self._real, real_pos):
    522             real.check_value(pos)

/home/xf23id1/Repos/hklpy/hkl/diffract.py in forward(self, pseudo)
     89 
     90     def forward(self, pseudo):
---> 91         solutions = self._calc.forward(pseudo)
     92         logger.debug('pseudo to real: {}'.format(solutions))
     93 

/home/xf23id1/Repos/hklpy/hkl/calc.py in forward(self, position, engine)
    313                 raise ValueError('Engine unset')
    314 
--> 315             self.engine.pseudo_positions = position
    316             return self.engine.solutions
    317 

/home/xf23id1/Repos/hklpy/hkl/engine.py in pseudo_positions(self, values)
    192                                                                 self._units)
    193         except GLib.GError as ex:
--> 194             raise ValueError('Calculation failed (%s)' % ex)
    195 
    196         Position = self._calc.Position

ValueError: Calculation failed (none of the functions were solved !!!)

In [118]: tardis.calc.energy
Out[118]: 0.07769768884

In [119]: tardis.calc.energy = (pgm_en.readback.value+7)/10000

In [120]: tardis.move([0,0,1])
Out[120]: MoveStatus(done=True, pos=tardis, elapsed=62.0, success=True, settle_time=0.0)

In [121]: 0.4375*3
Out[121]: 1.3125

In [122]: tardis.move([0,0,0.4375*2.6])
Out[122]: MoveStatus(done=True, pos=tardis, elapsed=23.2, success=True, settle_time=0.0)

In [123]: tardis.calc.forward([0,0,0.4375*2.6])
Out[123]: (PosCalcE6C(theta=59.75450175095632, omega=0.0, chi=0.0, phi=0.0, delta=119.50900350191284, gamma=3.285004519304743e-14),)

In [124]: tardis.calc.forward([0,0,0.4375*2.8])
Out[124]: (PosCalcE6C(theta=68.48584832920217, omega=0.0, chi=0.0, phi=0.0, delta=136.97169657924374, gamma=2.2732917903030795e-22),)

In [125]: tardis.calc.forward([0,0,0.4375*2.9])
Out[125]: (PosCalcE6C(theta=74.48340045343471, omega=0.0, chi=0.0, phi=0.0, delta=148.96679929368838, gamma=-8.326468246403186e-22),)

In [126]: tardis.calc.forward([0,0,0.4375*2.95])
Out[126]: (PosCalcE6C(theta=78.56953890967387, omega=0.0, chi=0.0, phi=0.0, delta=157.13907810479606, gamma=-1.848441392744114e-22),)

In [127]: tardis.calc.forward([0,0,0.4375*2.98])
Out[127]: (PosCalcE6C(theta=81.94489018387564, omega=0.0, chi=0.0, phi=0.0, delta=163.8897804748048, gamma=-4.7699760202894017e-23),)

In [128]: tardis.calc.forward([0,0,0.4375*2.99])
Out[128]: (PosCalcE6C(theta=83.44177541564504, omega=0.0, chi=0.0, phi=0.0, delta=166.88355226396592, gamma=-4.353838974164389e-22),)

In [129]: tardis.calc.forward([0,0,0.4375*3])
Out[129]: (PosCalcE6C(theta=85.40006166682436, omega=0.0, chi=0.0, phi=0.0, delta=170.80012249813058, gamma=3.0309245044027176e-22),)

[dchabot]

From the above trace, it looks like the calculations succeed once the energy has been reset:

In [118]: tardis.calc.energy
Out[118]: 0.07769768884

In [119]: tardis.calc.energy = (pgm_en.readback.value+7)/10000

Any idea what the "energy" is after this calculation?

It seems possible that 0.0777 keV could lead to the failure of the equation solver to converge on a solution.

Is csx1 really capable of going down to 78 eV?

[dchabot]

Also, I wonder if the axes that are 'fixed' (phi, chi, omega) and not included in the fitting of solutions should be included in the fit...?

[stuwilkins]

Should that not be:

tardis.calc.energy = (pgm_en.readback.value+7)/1000

i.e. the energy is in keV?

[dchabot]

@stuwilkins, yes, AFAIU the energies are expected in keV and wavelengths in Angstroms.

[cmazzoli]

Guys,
sorry for my delay.

About the conversion: the program uses SI internally so we need to cheat a bit if we want to use Angstrom and keV, from where the conversion factor (10^4). So, the numbers I reported READ as 770 eV, exactly where I wanted to be. Indeed I found the reflections..

Sorry, I should have been more detailed but you should consider that I was performing an experiment (funny behavior = problem) and it was already quite late in the night. Let’s concentrate on the problem then:
I don’t know why actualizing the energy (already declared identically few lines above the reported ones..) made the calculation to find the spot after having failed the first try. I could have reported many other cases where either by moving motors, getting closer to position you would like to drive the diffractometer, or even asking for its current position, SOMETIMES ended up in a successful calculation (and sometimes still not..).

This is the thing that we should sort out because at the moment it is difficult to trust the program (that actually works perfectly if you have the patience of driving it to an acceptable solution..).

About the “fitting” parameters: if they are fixed by the geometry, you need to required them to stay fixed. This is the way in which the solutions are managed (i.e. the system stays constrained.. otherwise would be extra redundant and potentially infinite sets of solutions would be found). Does it make sense? now I don’t know if for some reasons the syntax of the libraries may require something different but ,as a matter of fact, several times we correctly found solutions and tested them as correct in the experimental geometry.

Cla.
PS: what in the hell AFAIU means!!!???

On Apr 18, 2016, at 10:35 AM, dchabot notifications@github.com wrote:

@stuwilkins, yes, AFAIU the energies are expected in keV and wavelengths in Angstroms.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

[dchabot]

@cmazzoli, I understand that some of the axes need to be constrained to fixed values, but my question was whether we can can constrain them and still include them in the fitting algorithm. At the moment, chi, phi, and omega are fixed to zero and excluded from the fit (eg: tardis.calc['phi'].fit = False). I have no idea if this would be a helpful exercise or not.

AFAIU == 'as far as i understand' :-)

[cmazzoli]

Hi Daron,
you are right, we should try your suggestion. As written, I don’t understand why but given that I don’t know how the libraries are implemented, it could be very well the case..

Thank you for the additional explanation :)

Claudio

On Apr 19, 2016, at 10:26 AM, dchabot notifications@github.com wrote:

@cmazzoli, I understand that some of the axes need to be constrained to fixed values, but my question was whether we can can constrain them and still include them in the fitting algorithm. At the moment, chi, phi, and omega are fixed to zero and excluded from the fit (eg: tardis.calc['phi'].fit = False). I have no idea if this would be a helpful exercise or not.

AFAIU == 'as far as i understand' :-)

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

[klauer]

I'm not sure where this issue is coming from. @dchabot's suggestion seems like it would be worth exploring, at least. Please let us know your results, @cmazzoli.

[cmazzoli]

By now we repeatedly tested the implementation of @klauer in a number of cases and it works beautifully. Thanks!
In my opinion this thread can be closed..

[klauer]

Great!