-
-
Notifications
You must be signed in to change notification settings - Fork 38
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
Concept of longslit workflow as an example of specreduce block structure #71
base: main
Are you sure you want to change the base?
Conversation
|
||
|
||
@dataclass | ||
class CCDProc: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems to duplicate the above?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, that's an obvious duplicate. i also think that this is best left to the ccdproc
package or whatever a pipeline does to calibrate out detector-level level effects. spectroscopy-specific steps should start with a CCDImage
and go from there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops yes that's a mistake. But to clarify, I intended exactly what @tepickering said here: this should only wrap ccdproc functionality at best, and might literally just be ccdproc calls
i'll note that |
Hmm I mildly disagree that treating it as "the one slit case" makes sense. I think a lot of awkwardness in Python's past and pypeit itself stem from an unwillingness to think about "a spectrum" as an important element. That said, I see your point that having the plan allow miltislit at the outset is easier. So this is really a semantic or maybe minor syntactic distinction. I think that could be pretty straightforwardly adapted from this API |
i think we're mostly on the same page if there's an extra box for |
I agree that it makes sense to think of a long slit as a special case of MOS that just has 1 slit, though DRAGONS does not yet have such a concept, since we had to get long slit working ASAP and it's easier to deal with that first. I don't really understand @eteq's point though. In DRAGONS we only have the equivalent of I vaguely recall some discussion about We should bear in mind that the end result is not always extracted to 1D (but I don't think you intended to assume that). |
@jradavenport mentioned he updated one of the notebooks at https://github.com/jradavenport/kosmos/blob/main/notebooks/apo05workflow.ipynb |
indeed, I've updated my workflow for https://github.com/jradavenport/kosmos, but I don't think it needs to be ingested here yet (unless we want to propagate other changes to methods I've made ) |
Wavelength dependent sky subtraction will be a step done before the actual extraction (i.e. the extraction methods assume both global and sky (wavelength-dependent) subtraction has already been completed on the incoming data). @eteq did I get this right? |
Out-of-band it was pointed ouit this is missing a sky-subtraction step. I had mentally lumped this in with the extraction step, but it should be a separate step given that there's lots of different ways to do that, so should split |
Oh, hah, what @duytnguyendtn said 😉 . I wrote the above before seeing #71 (comment) |
This PR adds a "concept" file that describes a modular workflow for how we can build
specutils
-compliant workflows that we can use as interface definitions.Note that this is based heavily on the following diagram from the Astropy Coordination Meeting 2019:
This is currently for discussion, so I'm opening it as a draft, but it could get merged along side the concept notebooks if we settle on it with some revisions as a guide for future development