sample finding issue

[MehmetTopsakal]

From our last beamtime (October 2018) here is the drawing of the sample holder that is 3D printed.

Life would be much easier if they made the sample holder like this:

Unfortunately radiactive samples were prepared according to the first one.

[MehmetTopsakal]

So we run xy-grid scan on the sample.

[MehmetTopsakal]

Here is the plot for for one of the samples we run:

Q-vs-I of 13x13=169 x,y points on the left. Their x,y positions on the right. Color of the circle shows variations in the spectra. Similar color means similar spectrum. Position of sample is clear in the plot. Background points are in brown color. Points in the upper left correspond to sample holder.

[MehmetTopsakal]

Getting these 13x13 points was time consuming. In addition, we were having hot spots and aftergove problems. So we decided to "rotate" and "move" the sample

[MehmetTopsakal]

Here is the situation with "rotate" and "move":

Instead of 169, now we have only 21 scans. On the right side, I am plotting max intensity of each scan. As expected, beam doesn't hit the sample for some of the positions, so we have less intensity. Highes intensiy occurs at #6. The color of the bar plots has a meaning. It show how similar each scan to others.

[MehmetTopsakal]

Here I average scans [55,56,57,42,43,44,29,30,31] of xy-grid case and compare the averaged spectrum with the highest intensity scan (# 6) on the "spin+"move" case.

Somehow, "spin+"move" case intensities are ~3x weaker than xy-grid one. No filter was used in each setup.

@sbillinge @dooryhee @CJ-Wright Which of these plots would you prefer to use if you were going to write a paper on this sample?

[MehmetTopsakal]

This is another sample.

It is very inhomogenous. And "spin+"move" case is quite different than xy-grid case.

[sbillinge]

]I see. So this is specifically about Lynne's radioactive samples that are TEM grids, and they are supported in a holder that is like a washer (a ring with a hole in it) and measured in normal transmission. Then what is the goal? To find the center of the sample? Or to find positions on the sample that give good signal, which may not be at the center of the TEM grid (which itself is not at the center of the sample holder?) I think perhaps from what you are saying is that the goal is to get the "best" signal, which is why you ask "which scan would you use?" but theanswer to that depends on what is going to be done with the scan. Will it be turned into a PDF or will Rietveld be carried out or what?

This is a general problem (2D data acquisition) that Saasank has been also working on in my group, so Mehmet, I am cc'ing him into the conversation and perhaps we could combine approaches. For example, he has tried scanning using a lissajous curve instead of a gridscan, and I think he has a bluesky scanplan to run that.

It seems to me that separating the two issues would be good. First, try and find the TEM grid in the holder as quickly (i.e., in as few scans as possible), then carrying out a finer scan over the TEM grid itself. Introducing rotatations will potentially average over more material, though I would recommend rotating about an axis perpendicular to the beam to get better powder statistics. As soon as you introduce rotations, there is another alignment issue introduced that the axis of rotation has to be aligned to the beam axis to avoid parallax. Again, maybe separating these so solving the "no-rotation" problem first, then trying to make it better yet with rotations?

These are just some thoughts and suggestions.

S

On Sat, Jan 5, 2019 at 11:57 PM MehmetTopsakal notifications@github.com wrote:

This is another sample.

[image: image] https://user-images.githubusercontent.com/12613640/50732229-96fb2300-1144-11e9-8663-45d79d1fddb5.png

It is very inhomogenous. And "spin+"move" case is quite different than xy-grid case.

[image: image] https://user-images.githubusercontent.com/12613640/50732267-8b5c2c00-1145-11e9-9b29-4e2d3472d4a3.png

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/xpdAcq/mission-control/issues/160#issuecomment-451715481, or mute the thread https://github.com/notifications/unsubscribe-auth/AEDrUVRJlEe_gG3u4erEYHFWIohCyURCks5vAYJQgaJpZM4ZyPvJ .

[Sasaank]

Hello Mehmet and Simon,

I do have a Lissajous scanplan that has been working in the simulation environment (I haven't gotten a chance to test it on the beamline). For the first issue that Simon mentions, I have some (untested) code to find the center and boundary of circular wells in a 3d printed sample holder (the Wanda arrays). I think that I could amend it to work for this use case as well. As for the second issue, I am not quite sure I understand why the gridscan produced different results than the spin and move. It seems to me that all that should have changed would be the time at which a certain location in the sample was scanned.

[MehmetTopsakal]

@CJ-Wright @sbillinge

I think we don't need to "automate" sample finding at XPD. If there is a way to generate the plot in the third cell above, that will be enough. A user can do a coarse grid search and determine the approximate sample position. Then he/she change sample position using cs-studio and do a fine scan.

I am closing this.

[dooryhee]

I am challenging this conclusion. Recently users had off-centered samples and we spent a lot of time grid-scanning each. The time overhead was significant. Automated sample finding would be very helpful. As Simon is saying, rotation does not solve the problem since the sample might rotate in and out of the beam. Also the idea is that we want to run N “mis-aligned” samples with no user intervention (N large, overnight run). E

From: MehmetTopsakal notifications@github.com Sent: Monday, February 25, 2019 12:34 PM To: xpdAcq/mission-control mission-control@noreply.github.com Cc: Dooryhee, Eric edooryhee@bnl.gov; Mention mention@noreply.github.com Subject: Re: [xpdAcq/mission-control] sample finding issue (#160)

@CJ-Wrighthttps://github.com/CJ-Wright @sbillingehttps://github.com/sbillinge

I think we don't need to "automate" sample finding at XPD. If there is a way to generate the plot in the third cell above, that will be enough. A user can do a coarse grid search and determine the approximate sample position. Then he/she change sample position using cs-studio and do a fine scan.

I am closing this.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/xpdAcq/mission-control/issues/160#issuecomment-467103237, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ALyE3RVlvjAcPYeWfJBzkNxjzTGMb1NIks5vRB5qgaJpZM4ZyPvJ.

[MehmetTopsakal]

@dooryhee

Okay.

Actually, I have the function which can find the center of mass of the sample.

Next week I will try to figure out how to make it work