Open ambarb opened 7 years ago
reproduced the above after restarting session. utilized the same orientation matrix from testing done during shutdown, which belonged to previous user.
You should be able to reproduce this with
tardis.describe()
The bug is someplace in the code that sorts out what type the value is, but I can not think of anything we changed between last cycle and now that would have caused this. Do you have un-commited changes to hklpy on the BL computer?
At least the first problem.
The output from tardis.describe() indicates that the upper and lower limits for h,k, and l and their septoints are all 0. This must be why it fails, correct? I will try that tomorrow am. @cmazzoli do you know if there are any other little things like this?
If some change was made locally, then I would say it was ages ago. Is it possible to investigate this?
Try tardis.l.describe()
?
And I poked around a bit and could only find one checkout of hlkpy and it is a previous version. I have a guess at what the problem is, but need to poke at the live objects to be sure.
should we move this to Bluesky hklpy issues or did we address
+1 for moving it to the proposed location, and then close after testing.
Hi guys, for what I remember there was a long discussion on this issue, started with the first implementation of HKL. Long story short, people did not realize that moving 1 (or 2) of the {H, K, L} variables in the Miller's indexes triplet [H, K ,L] MUST CORRESPOND to the other 2 (or 1, respectively) keeping their current value(s). Probably it was not evident the role of {H, K, L} as pseudo motors for diffraction, essentially. Anyway, this ended up being a major problem and pain, especially for basic trajectories in reciprocal lattice (RL), as they had to be defined as completely general.. (full triplet declared per RL position, instead of only the specific subset of indexes). We even risked collisions, as Andi pointed out..
So, we complained and you guys come up with a solution. I seem to remember that this was working ok, starting when the correct implementation of RL positions was taken into account, together with a new definition of our diffractometer (tardis) object (containing {H, K, L} as part of it).
Now, I must confess that I am a little surprised of this issue, but it might be simply wrong in my recollection as a side effect of min-safe. Apologies if this is the case.
Best regards, Claudio
On Jul 1, 2020, at 4:18 PM, Maksim Rakitin notifications@github.com wrote:
+1 for moving it to the proposed location, and then close after testing.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/NSLS-II/Bug-Reports/issues/140#issuecomment-652625939, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACUOKFTJWJE3PONZTWY6NFLRZOK2LANCNFSM4CRFLNZQ.
Thank you for the background, Claudio!
bluesky 0.6.4 py35_0 ophyd 0.3.1 py35_1 hkl 5.0.0.2080 py35_0 hklpy 0.3.11 py35_0
spec-like scans work for actual motors and HKL is calculated correctly (dscan, d2scan, and d3scan). ascan and dscan on tardis.l will go to the first point and then abort. tried simliar scan by using
RE(relative_scan([], tardis.l, -0.025, 0.025, 3), print)
with similar error(ValueError: 0.156 not a valid type (int, float, ndarray, str)
, which is the first value of tardis.1 in the scan). Specifics are below (with and withoutmsg_hook = print
) . Found the case to be the same for dscan of tardis.k over a small range (theta scan).However, what seems to work by eyeball in hkl scanning is
RE(list_scan([], tardis, [(0.095, 0.018, 0.156),(0.095, 0.018, 0.18),(0.095, 0.018, 0.215)]), print)
. The data was not printed in the table The user friendliness of this method for large data sets and cutting through space in different ways is not as straight forward as the spec-like scans.SCAN THAT SEEMED TO WORK:
Will take further action to restart session to see if error reproduces. Will report back again.
ascan followed by relative_scan examples
With msg_hook = print for ascan and relative_scan