Expand record keeping of which channel assignments are in a tune file.

[kmharrington]

Describe the problem

Writing this up so there's a reference for when I implement this change (or in case there's a better way to do this). While working through pipeline development with SO we've realized we'd like more tracking with respect to which channel assignments are part of which tuning file.

As best I understand, in the current pysmurf behavior setup_notches is run over a single SMuRF band and then active tuning file is updated for that band. Effectively, this means tuning files build on each other and this works great if no one ever "backtracks." However, it is just as easy to load an older tuning or one that is missing relevant bands, meaning there are possible situations where the most recent tuning file does not correspond to the set of most recent channel assignment files. If the creation of these channel assignments and tuning files are connected with explicit actions done while observing, we'll want to know which are connected to which.

Describe the solution you'd like

I think the most straightforward fix for this is getting the {timestamp}_channel_assignments_b{band} file names into the freq_resp dictionary here: https://github.com/slaclab/pysmurf/blob/4.2.1-67-g5e231d44/python/pysmurf/client/tune/smurf_tune.py#L3845

Adding another key there like self.freq_resp[band]['assignment'] = filename will mean we'll always be able to uniquely track which sets of channel assignments are in a tuning file and will have a record of any back-tracking or odd behavior done by the users. It looks like self.freq_resp is always just loaded/saved by band, so I don't expect this to cause other errors as long as there isn't already an assignment key that shows up somewhere else.

It's not 100% clear to me the best way to pass the arguments around to get that filename into that dictionary, but I'm certain it's doable somehow. (Any suggestions?)

Additional details

I'm happy to work on implementing this myself / submitting a PR. I am curious if I'm missing something about pysmurf's behavior here or if there's an easier way to go about this. Thanks!

[kmharrington]

Actually, these fixes got reverted? Can we put them back in?

[kmharrington]

Right, I missed the memo that we're using develop now.