Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

feat: general beamcenter calibration #57

Open
pdudenas opened this issue Nov 10, 2022 · 4 comments · May be fixed by #83
Open

feat: general beamcenter calibration #57

pdudenas opened this issue Nov 10, 2022 · 4 comments · May be fixed by #83
Labels
enhancement New feature or request

Comments

@pdudenas
Copy link
Collaborator

The beam center recorded in SST1 metadata is a decent starting place, but I find refinement is often necessary. I've found that simply minimizing the variance of I(chi) over some q slice is a pretty robust method and doesn't require having sharp peaks. The downside is it's fairly slow, calling integrate_radial. I know @pbeaucage has tinkered around with this problem, and I'm curious if anyone else has. Below is the function that I minimize with scipy.optimize.minimize

def func2(x, image, q_min, q_max, chi_min, chi_max, integrator):
    poni1, poni2, rot1, rot2 = x
    integrator.poni1 = poni1
    integrator.poni2 = poni2
    integrator.rot1 = rot1
    integrator.rot2 = rot2

    image_chi, image_int = integrator.integrate_radial(image, 150, radial_range=(q_min, q_max), azimuth_range=(chi_min, chi_max))
    return np.var(image_int[image_int != 0 ])
@pdudenas pdudenas added the enhancement New feature or request label Nov 10, 2022
@pbeaucage
Copy link
Collaborator

This is a faster/better version of what I did. I support shipping this in SST1RSoXS unless anybody else has a better solution.

The real, long-term solution is to take the scans that @EliotGann and I did last beamtime (direct beam on detector with undulator massively detuned) and fit a Gauss2D to those results. I am an advocate for writing a macro that does this and running that macro once a day or something like that until we know how much (if at all) the beamcenter really moves. Based on our diagnosis of the ugly beam shape, I suspect that any vibrations on the mesh will move the beamcenter around potentially significantly.

@pdudenas
Copy link
Collaborator Author

pdudenas commented Feb 1, 2023

To get back to this, how do you want to integrate this into PyHyper @pbeaucage ? Put it in the RSoXS class so that it's accessible through .rsoxs, have it in it's own file, or somewhere else?

@pbeaucage
Copy link
Collaborator

My first vote would be to put it into the much-neglected .util. namespace, similar to the integration checking and mask drawing widgets... I'm not sure that organization makes sense but it's at least consistent with the other things around it.

@pdudenas
Copy link
Collaborator Author

pdudenas commented Feb 2, 2023

I created a util xarray accessor to hold the beamcentering. You can invoke it with dataArray.util.refine_geometry(energy, q_min, q_max, chi_min, chi_max), which I thought was fairly clean. It will update the poni1 and poni2 in the dataArray attributes if the optimization is successful.

If there are performance concerns with extra accessors, or you just want a class similar to the integration checking and mask utils, I can convert it.

link to code

@pbeaucage pbeaucage linked a pull request Apr 11, 2023 that will close this issue
General beamcenter calibration #83
Draft
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

General beamcenter calibration usnistgov/PyHyperScattering
2 participants
@pbeaucage @pdudenas