Frame-by-Frame Energy Correction & Masks in Omega

[kenygren]

Due to issues in mono stability and changes in incoming beam energies over the course of an experiment (and/or a rotation series) - we would like the ability to:

1. Mask omega frames that have incoming beam characteristics that are outside of the range
2. Allow for an array of energies (one corresponding to each frame/ omega in the series) be input in the g_vec calculation

I believe the former is a much easier implementation and would be a good starting place before incorporating more detailed energy corrections.

[psavery]

Sounds good, Kelly!

For 1, I am thinking we could add a function to remove frames from the OmegaImageSeries class (or even the regular image series class if it might be applicable to other cases) that are outside the range. Could potentially be an operator on ProcessedImageSeries, or a stand-alone function if that is easier. We could apply this function at the beginning of both find orientations and fit grains so that the invalid frames are skipped. And we could have an option to apply this via the GUI as well. This would also adjust the omega wedges so that wedges associated with invalid frames are skipped. What do you think, @donald-e-boyce? Can we get an example, @kenygren?

For 2, we might just need to find a place to put this array of energies (maybe in the config, or on the image series, since the energies are associated with specific frames). Then I think we'll need to make sure it is applied to the PlaneData in all the places it is used. Adding this array as an argument on simulate_rotation_series() might be a good place to start, and I think that will cover most of fit grains via its usage in pull_spots().

@kenygren do we also need to take into account the array of energies during indexing / find orientations as well? I'm wondering because I know indexing just roughly computes the orientations, and I'm not sure if the energy differences are significant enough to affect this. If we need to, then we'll also need to find the places HKLs are used in indexing (and we might have to refactor a few places as well to loop over frames, to take into account the fact that each frame might have a different energy).

Any thoughts, @donald-e-boyce?

[donald-e-boyce]

For 1: The ProcessedImageSeries accepts a list of frame numbers if you want to use a subset of the frames. It doesn't update the omega metadata, so you would have to do that separately. That would be a one-liner though. That feature has been used to reverse the order of the frames for data where the rotation direction was reversed, but it would work easily here.

I did notice that in GenerateEtaOmeMaps, it requires all omega wedges to be the same size (angular difference). I don't understand why though. Still we would have to modify some things for this to work.

        if this_det_ims.omegawedges.nwedges > 1:
            delta_omes = [(i['ostop'] - i['ostart'])/i['nsteps']
                          for i in this_det_ims.omegawedges.wedges]
            check_wedges = mutil.uniqueVectors(np.atleast_2d(delta_omes),
                                               tol=1e-6).squeeze()
            assert check_wedges.size == 1,
                "all wedges must have the same delta omega to 1e-6"

For 2: I've never liked the beam energy being part of the material class. It seems like it should be part of the instrument. Rather, the beam energy should be an argument to the gvec calculation.

Still I think this way is more sound and doesn't eliminate usable data, but it would involve more detailed code changes, so number 1 is probably worth implementing in the short run while we figure this one out.

It seems the beam energies should be associated with the HEDM instrument, but another possiblity is to have them as metadata for the imageseries. We already have the omega ranges associated with each frame. We could just add a beam energy metadata object that could be either contant or an array of values, one per frame. One could argue that it makes more sense to associate it with the HEDM instrument, as putting it in the imageseries involves a lot of duplication since there is an imageseries for each detector. That is true, but you can say the same thing for the omega ranges.

Anyway, I think it would be a very good improvement to allow for a beam energy for each frame, but it may be a significant effort. It may affect the transforms module, among other things, which has been the subject of much effort toward performance optimization.

[donald-e-boyce]

I made an example with an imageseries with certain frames removed. Everthing worked fine, both find-orientations and fit-grains. This was for a single crystal ruby, so we may want to do some bigger examples.

The code section above checks that the omega step is the same across all wedges. I misunderstood and thought all the wedges had to be the same size.