Best way to have callback span multiple starts

[CJ-Wright]

We may want a single callback to span multiple runs. For instance if we take a single shot per RE call but want to put them together in a scatter plot. Currently a callback clears/refreshes itself upon start document.

Expected Behavior

Have a way to specify if not to clear/refresh when we get a start in.

Current Behavior

Callback refresh on start.

Possible Solution

Have a dedicated clearing mechanism, which may or may not be called (potentially using a separate 'clear' document/callback message)

Context

Often we make many start documents even though we wish the data to be visualized together. Eg a scan on a grid with many samples may get a start document per sample (so as to preserve the search ability of the sample data) but we want to visualize the max intensity per grid position as a whole.

[danielballan]

What you have outlined seems reasonable. Putting that in (psuedo)code:

from bluesky.callbacks import CallbackBase

class Thing(CallbackBase):
    def __init__(self):
        self.state = {}

    def clear(self):
        self.state.clear()

    def start(self, doc):
        if is_the_first_run_in_a_block_of_related_runs(doc):
            self.clear()
        ...

[CJ-Wright]

Hmm ok. I don't know if having an if statement in the start is very sustainable, since the criteria could change significantly between runs and we'd have to amend each visualization callback to at least take in a function which decides if something clears or not.

(And here I always thought that Thing inherited from the Addams family 😄)

[tacaswell]

I am not sure that clearing callback objects is the right path here, I think it is better to just create new instances when you want a clean instance.

[danielballan]

That's a good point @tacaswell. Either way, I don't think bluesky itself needs to enforce any conventions here. Our interface to callbacks is (name, document). From there, client libraries have free reign to experiment.

[CJ-Wright]

@tacaswell Does that mean we should refactor the current visualization tools? Bluesky doesn't enforce conventions but it does have conventions. Eg https://github.com/NSLS-II/bluesky/blob/master/bluesky/callbacks/mpl_plotting.py#L91

[danielballan]

I would say, yes. It would be better to subscribe callback factories to the RunEngine that, for example, generate a new line on a plot per run. This would might best be done in conjunction with making BestEffortCallback pluggable.

[CJ-Wright]

One would have a second callback factory/function to clear the figure as needed?