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.

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

Requested functionality for unit-cell/wavelength conversion #45

Open
PrinceWalnut opened this issue Nov 28, 2023 · 4 comments
Open

Requested functionality for unit-cell/wavelength conversion #45

PrinceWalnut opened this issue Nov 28, 2023 · 4 comments
Assignees
Labels
enhancement New feature or request

Comments

@PrinceWalnut
Copy link
Member

The laue.index command is monochromatic and frequently causes a deviation of 5-10% in unit cell axis lengths from the published cell, presumably with a corresponding shift in wavelength in the opposite direction. Indexing at the correct cell is frequently impossible (at least with the BioCARS spectrum), but incorrect unit cells can impact downstream analyses.

A function/command for rescaling the unit cell, wavelength, and any other coupled parameters would be helpful for users to correct the unit cell after laue.optimize_indexing assigns wavelengths.

@kmdalton @DHekstra, any ideas for algorithms regarding this? Would a simple arithmetic solution based on % difference between indexed/correct cell and multiplying the unit cell axes/wavelengths be sufficient?

@PrinceWalnut PrinceWalnut added the enhancement New feature or request label Nov 28, 2023
@PrinceWalnut PrinceWalnut self-assigned this Nov 28, 2023
@phyy-nx
Copy link
Collaborator

phyy-nx commented Nov 28, 2023

Does laue.index include a refinement step? What about using refinement.parameterisation.crystal.unit_cell.restraints.tie_to_target? This adds a restraint on the unit cell, specifying values for the unit cell, and sigmas for the desired error off of those values.

@DHekstra
Copy link
Contributor

@phyy-nx, interesting. that is different than just specifying the unit cell, which in our case appears to be brittle--that often just fails.

As I understand it, the basic phenomenon is that during (monochromatic) indexing dials.index will lock onto some pattern, but it does not need to be at the peak wavelength. We see unit cell dimensions that can be off by as much as 5 or 10%. What @PrinceWalnut is suggesting is that we do a posterior correction of wavelength and unit cell dimensions.

Most naively, if we take Bragg's law, we can try rescaling all the lambdas and all the d's by a constant, scaling both the unit cells and the wavelengths to match either a reference spectrum or a reference unit cell. It's really just an aesthetic fix--getting the miller indices right and the wavelengths up to a scalar is all we need for downstream processing as long as we have reliable unit cell dimensions from some other source.

From staring at Bragg's law, there is one other catch, which is that sin(theta) \approx sqrt(X^2+Y^2)/D at small angles, such that errors in detector distance complicate the idea that one can simply rescale both the unit cell dimensions and the wavelength.

@phyy-nx
Copy link
Collaborator

phyy-nx commented Nov 28, 2023

Makes sense, a posterior correction would be fine. I think it would be worth trying tie_to_target regardless, especially if detector distance is fixed, and wavelength and unit cell are allowed to refine.

@PrinceWalnut
Copy link
Member Author

PrinceWalnut commented Nov 28, 2023

While it is an aesthetic fix, I would argue it's important for users doing diagnostic steps prior to careless, as Maggie/Dennis/Harrison have demonstrated. I expect that it would also be helpful prior to certain routines like laue.optimize_indexing where an initial estimate is used, since the indexed unit cell may be outside of the radius of convergence.

Do we have any reason to believe imported detector parameters are likely to be significantly off enough to impact a simple rescaling method?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants