This is a fairly involved one, but there is strong motivation to get this implemented to
handle the case of multi-energy sources, e.g., an X-ray tube
handle the case of different incoming beam directions
The strategy would be to
modify the instrument config spec and __init__ method to accept multiple beam blocks analogously to how detectors are handled; and
enable additional looping over beams to all of the functions that need it downstream (again, analogously to how detectors are handled).
I would posit that it makes more sense to put the beam-relative loops inside the existing detector loops since there are likely to be fewer beam specifications than detectors. There are some challenges to how we will handle beams with the same propagation vector, but two energies that are close; we will likely need to catch that case and use it to fit a multi-peaked model to Bragg peaks where needed. @saransh13 @psavery -- could use your input on this.
This seems like a big lift, and would require a lot of thinking to make it work in a robust way. I've reduced the priority to low for now, we can come back to this in the future.
This is a fairly involved one, but there is strong motivation to get this implemented to
The strategy would be to
__init__
method to accept multiple beam blocks analogously to how detectors are handled; andenable additional looping over beams to all of the functions that need it downstream (again, analogously to how detectors are handled).
I would posit that it makes more sense to put the beam-relative loops inside the existing detector loops since there are likely to be fewer beam specifications than detectors. There are some challenges to how we will handle beams with the same propagation vector, but two energies that are close; we will likely need to catch that case and use it to fit a multi-peaked model to Bragg peaks where needed. @saransh13 @psavery -- could use your input on this.