Closed aimalz closed 3 months ago
Note that we can take this opportunity to associate some notion of object ID with all catalogs (and add it to SHARED_PARAMS).
@aimalz during a tag-up call you said that there is something that breaks/isn't functioning in a specific degrader in the current set up and referenced this issue. Reading above, I don't see reference to any specific problem, can you point to the specific functionality that is missing/broken?
Copied from the original summary section.
High level goal, people should know what stages are what, and see what all the options are.
In spectroscopic_selections.py
(one PR for this block):
SpecSelection
to its own module in rail_base__repr__
should contain the reference for the cutsQuantityCut
and SpecSuccessChecker
) for each surveyIn grid_selection.py
(one PR for this block):
# pragma: no cover
)Overall (as part of all these PRs???):
src/rail
as neededRenaming degradation to modification still seems like overkill to me, I think a comment in the documentation stating that some degraders simply modify or transform the data rather than "degrade" it is sufficient.
I agree with Sam here.
Noisifier and Selector are established, and 7/8 degraders have moved away from the old degrader class. After the remaining spectroscopic selection is moved, I will close this issue.
Spectroscopic selection is also refactored, close issue.
Related to LSSTDESC/rail_astro_tools#9, we're using the
Degrader
class for stages that are doing things more different thanEstimator
vs.Summarizer
, and it's making it hard to generalize the degraders we have to be flexible to support next steps. There's also functionality embedded in degraders that's more generically useful, e.g. filter conversions, that folks want to call for informer/estimator pipelines. These issues are compounded by the confusion caused by operations on data tables to all be called "degraders" when many of them are not affecting any notion of quality; the name of the class was originally meant to be for a class that modified generative models and doesn't necessarily describe what the various stages are actually doing. This issue is for refactoring the degrader stages so users and developers better know what functionality is available and how to access or extend what they need. This will affect both rail_base and rail_astro_tools.EDIT: Now with more specifics!
Related to repeated code in
spectroscopic_selections.py
(one PR for this block):ColorMaker
function in rail.core within rail_base if possibleIn
quantityCut.py
(one PR for this block):spectroscpic_selections.py
degradersspectroscopic_selections.py appears in both rail_astro_tools and rail_base (two extra lines in one of them), and it's not clear to outsiders what the difference is, in terms of where to look for which or to submit a contribution
In
spectroscopic_selections.py
(one PR for this block):SpecSelection
to its own module in rail_base__repr__
should contain the reference for the cutsQuantityCut
andSpecSuccessChecker
) for each surveyIn
grid_selection.py
(one PR for this block):# pragma: no cover
)Overall (as part of all these PRs???):
src/rail
as needed