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

Add support in the MapBinner for per-scan (or sub-obs) map-making. #75

Merged
merged 1 commit into from
Mar 18, 2022

Conversation

nwhitehorn
Copy link
Member

@nwhitehorn nwhitehorn commented Mar 9, 2022

This adds a new parameter (map_per_scan) to the map binner that can
control when maps are emitted. If defaults to False, preserving existing
behavior. If set to True, or to a callable that returns True, it will
result in the in-progress map being flushed to the data stream. This
enables simple creation of per-scan maps (set to True) or more complex
bundlings (with a callable).

This adds a new parameter (map_per_scan) to the map binner that can
control when maps are emitted. If defaults to False, preserving existing
behavior. If set to True, or to a callable that returns True, it will
result in the in-progress map being flushed to the data stream. This
enables simple creation of per-scan maps (set to True) or more complex
bundlings (with a callable).
" this case, the callable will be called on each Scan frame and passed \n"
" the frame as an argument. If it returns True, the map binner will emit \n"
" a map frame with the data since the last emitted map frame but *before* \n"
" the current Scan; if False, the binner will continue accumulating data.\n"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the callable case, doesn't it make more sense to include the current Scan frame instead of emitting only everything that came before?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea is that this indicates the start of new data, which is easier to detect than the end of old data since you don't have to know the future.

@nwhitehorn nwhitehorn marked this pull request as ready for review March 18, 2022 14:40
@nwhitehorn nwhitehorn merged commit 8330fc0 into master Mar 18, 2022
@arahlin arahlin deleted the per_scan_maps branch March 18, 2022 15:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants