SP-1841: Backwards compatible updates for Band/Filter #149
+259
−146
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR has the goal to make the move from "filter" to "band" backwards compatible.
This lets us tag at 3.5.0, making the band update a "feature" rather than breaking change, and lets @tribeiro deploy this at the summit without having to make over ts_scheduler.
I've tested this with the current develop of ts_fbs_utils and the unit tests there run. I've also tested it with sim_runner and our baseline survey configuration.
I am unsure of how to test this in a full run with ts_scheduler to ensure there are no breakages (this is technically true for any update we make).
It would be good if both @tribeiro and @yoachim could take a look.
The main place I am concerned about is in the Conditions object and in add_observation.
in the Conditions: ts_scheduler currently reaches into the conditions object and adds information to relevant fields one-by-one. In this call, the "mounted_filters" and "current_filter" are set, using the physical filternames. When using the modelobservatory, both the current_band and current_filters are set directly using the band name.
With this PR, I have changed mounted_filters and current_filter to be set using a setter, so that if current_filter is set, then current_band is updated (splitting physical filtername down to band) and likewise for mounted_filters. Thus setting mounted_filters or current_filter will update the mounted_bands and current_band (which are the values which are then used inside the remainder of the FBS when referring to conditions values).
in add_observation: I am assuming that incoming observations from ts_scheduler will have 'filter' filled out (which could even be the full physical filter name) and will have 'band' as a field available to be filled, but that it won't have any information -- so then add_observation has a small "feature" at present to fill out 'band' if it wasn't already present (and should, in general split physical filter names properly down to band). With sim_runner, 'band' will already be filled out and so nothing will happen.