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
Investigate supporting multiple UBs in matrix and peak workspace #36592
Comments
Once we can show with proof-of-concept PR #36654 we can do this without breaking anything, and @zjmorgan and @AndreiSavici are happy in principle, there are some next steps: Changes to algorithms that set UB / oriented lattice (to preserve default behaviour, this will have to overwrite the set UB if there is only one, optionally we can set others at a specific index - we need to think about this aspect)
Next step after that (once we can set multiple UBs) is to make use of them!
|
Just some quick thoughts:
|
Thanks for getting back to us so quickly @AndreiSavici, some interesting ideas it would be good to discuss.
My plan was to give the user the option of selecting a single UB to use when converting to HKL - in any case with twining or multiple xtals the HKL plots look rather messy so I don't imagine people who want to make use of multiple UBs will want to do this. If they were to do this, it would be handy if one could index the cursor position in sliceviewer with the other UBs to identify spurious peaks, or even better overlay a peak from a different domain/UB and plot the positions in the HKL slices, but this is a minor thing.
That's a good idea I hadn't thought of - I like the proposal to change the table view rather than the existing data structures (namely
Maybe the above are not a big deal, I know we shouldn't be changing such core data structures lightly, but as long as we're careful to preserve default behaviour by design then I think it could save us some time and effort. What do you think? |
@MohamedAlmaki - following discussions with @AndreiSavici and @zjmorgan (thanks both) the plan is to instead use group of peak workspaces (each of which a different UB) and write a new table view so users can view these in a single table. Most algorithms (e.g. |
Describe the outcome that is desired.
This relates to the multiple UB EPIC
https://isisneutronmuon.atlassian.net/browse/SS-25?atlOrigin=eyJpIjoiODI0NDgxMTAzODZkNDk0OWI5ODJhZDZmM2E1ODZhZDMiLCJwIjoiaiJ9)
The aim of the project is to allow multiple related UBs (e.g. a set of UBs related by a given rotation) to be optimised at a time, and for peak integration methods to be able to tell when a peaks from different UBs overlap and have been integrated together.
Does the outcome relate directly to a problem? Please describe.
The aim is to have the
OrientedLattice
class contain a collection of UBs instead of a single UB and for PeaksWorkspaces to have an extra attribute which is the index of the UB used to index the peak (i.e. assign it miller indices HKL).Backwards compatibility will have to be preserved so by default the first UB should be returned by
OrientedLattice::getUB()
and similar for any setters etc.The following algorithms (at the very least) will then need to be updated to select the UB required, or loop over them:
IndexPeaks
PredictPeaks
PredictFractionalPeaks
PredictSattelitePeaks
FindUBUsingIndexedPeaks
SetUB
The PeaksWorkpace table view will also need updating to display the UB index.
The aim of this investigation is to make the changes to
OreintedLattice
and see ifIndexPeaks
andPredictPeaks
can be made to work, and then see what breaks...It would also be nice to add the column to the table view.Additional context
Details of UB matrices and indexing can be found here
https://docs.mantidproject.org/v6.1.0/concepts/Lattice.html
The text was updated successfully, but these errors were encountered: