supports specifying disconnected omega ranges in config file

[ddale]

This pull request allows disconnected omega ranges to be specified in the config file.

@joelvbernier, is this sufficient for you to modify the analysis routines to support disconnected ranges? Ideally, one would just use cfg.image_series.omega.positions, but start, stop, step, and steps are also available if they are needed. The latter properties currently may return either lists or individual values, depending on how they are defined in the yml file. This could be tweaked so the config class always returns lists, it might simplify the API a little.

[ddale]

Taking this implementation all the way through is turning out to be non-trivial. The chacheframes feature expects one array of frames, and one array of omega [start, step]. I don't think we need to store the omega values, since those are available from the cfg file.

How should we handle data series comprised of disconnected ranges? One way would be to simply append the ranges so we end up with a single data series. The other would be to treat each individual range as a single data series, and have a data series container (zeroth order a list). HEXRD currently does the latter: several functions/classes accept a list of ReadGE instances, each with its own associated omega information. It is probably best to stick with the current approach for now.

cacheframes will need to be modified. It currently stores a 3D array, it will need to store a list of such 3D arrays. Not a 4D array, since the length may vary from one disconnected range to the next.

I'm lost on what to do with pullSpots. How is that function supposed to be used with multiple readers?

Unfortunately, I don't have time to commit to completing this feature so it can be used from the command line interface. I propose to merge this branch into master, and open a new issue with a copy of this explanation, and perhaps you could ask Continuum to look into it.

[joelvbernier]

We should cache frames for each contiguous reader block. The initial abstraction for a ‘reader’ object was for it to correspond to a single contiguous wedge of omega values; an imageseries could then reference one or more readers.

On Jan 9, 2015, at 8:32 AM, Darren Dale notifications@github.com wrote:

Taking this implementation all the way through is turning out to be non-trivial. The chacheframes feature expects one array of frames, and one array of omega [start, step]. I don't think we need to store the omega values, since those are available from the cfg file.

How should we handle data series comprised of disconnected ranges? One way would be to simply append the ranges so we end up with a single data series. The other would be to treat each individual range as a single data series, and have a data series container (zeroth order a list). HEXRD currently does the latter: several functions/classes accept a list of ReadGE instances, each with its own associated omega information. It is probably best to stick with the current approach for now.

cacheframes will need to be modified. It currently stores a 3D array, it will need to store a list of such 3D arrays. Not a 4D array, since the length may vary from one disconnected range to the next.

I'm lost on what to do with pullSpots. How is that function supposed to be used with multiple readers?

Unfortunately, I don't have time to commit to completing this feature so it can be used from the command line interface. I propose to merge this branch into master, and open a new issue with a copy of this explanation, and perhaps you could ask Continuum to look into it.

— Reply to this email directly or view it on GitHub https://github.com/praxes/hexrd/pull/91#issuecomment-69358973.

[donald-e-boyce]

obsolete/out of date