* How to test clean selection and cube definition
without actually running clean all the way through
* Juergen's idea:(old version - go up and find the microsoft for the new version) [[Proposal on a new definition scheme
* Remy's warning/admonitions from previous discussion:
- make sure that all calculations work if the MS has positive or negative labels, if spw2 has lower freq than spw1, width<0, vel mode, etc.
- write down all possibilities in pseudocode before deciding on a policy, so we don't get bitten later
- as of 3.0.2, cleanhelper will 1. select according to spw. multi-spw with chan selection allowed 2. sort the resulting chan freqs into positive order 3. attempt to determine default start/width/nchan according to mode
- in chan mode, non-intuitive behaviour is more likely. two examples that i think are "correct" in terms of advertised behaviour but non-ideal - spw="2:30~50", start=0, chan mode: results in a 50chan cube with the first 30 blank. this is the problem with a default of 0, as opposed to a default of null or "" for start in chan mode, that I've been harping on endlessly. - spw2 freqs < spw1 freqs, chan mode, default start=0: again, start=0 is advertised to be the freq of the "0th (unselected) chan of the first selected spw"- that means that in this case you can end up with spw2 not represented in the output at all, because spw1 is the "first selected".
Comments from Dirk:
In response to Juergen's proposal [[Proposal on a new definition scheme
]] , I would like to propose two alternatives:
* Proposal A: = Juergens proposal "light"
This proposal would mostly keep the present regridding parameters of clean and cvel as they are now except for the following:
- Additional optional parameter
"center" sets the center of the output spectral window.
If center is not an empty string, it overrides whatever the value of start is.
In channel mode, center would mean that the center frequency of the channel number "center" is taken
and the channels are constructed around it.
If the number of channels nchan is even, the center frequency is the edge between the output channels
(nchan/2-1) and (nchan/2) (integer division, 0-based).
If nchan is odd, it is the center frequency of the output channel nchan/2 (integer division, 0-based).
In velocity and frequency mode, "center" is respectively the center frequency or velocity of the
output spectral window and nchan plays the same role as described above
in channel mode.
- Furthermore, in channel mode, the start parameter is the first channel to use in the regridding, not the center of
the first output channel.
Thus unwanted extension of the output spw beyond the range of the actual data becomes impossible.
- Finally, in channel mode (the default), not setting any parameters (i.e. leaving them at their default
values) leads to no regridding at all. The grid is just copied from the input MS even if it is not equidistant.
* Proposal B: Juergen's proposal slightly modified
Follow all suggestions in Juergens proposal, but add a "width" parameter in channel mode such
that the resolution in the output SPW can be reduced if desired (and imaging be sped up for first-look analysis).
Additional comment: cvel is able to handle non-equidistant input grids and can produce corresponding
non-equidistant output grids. We might try and transfer this feature also to clean.
Attempt to clarify some implementation details
NOTE: cleanhelper as Dirk and I rewrote the function already takes the output of all MSSelect, specifically makes a list of the freqs of selected channels across all spws, sorts it, determines minmax and bandwidth for use later in the function.
here are some unspecified important details that need answers, and an attempt to write it out more thoroughly (RI):
* mode=vel or freq
- parse center as quantity (Hz or km/s). assume this is in outframe, with restfreq as user-parameter, or if not, as specified in MS.
- use freq of this index chan as center of output. Is this in the first selected spw? does it pay attention to chan selection in spw param?
- center on the range of selected frequencies.
- parse as quantity. remember, can be<0.
- width of 0'th channel? diff between 0 and 1? selected or unselected? for S/N reasons in vel mode, it should default to the diff b/w the highest two freq channels.
- presumably, the int times the previously decided default (that's how I wrote cleanhelper this time). Do we allow float? 1.5-chan output chans? no real reason not to once the rest is resolved IMO.
- nchan: default is relatively easy - span the data. What about int>0? put half on each side of center? It'd be nice to retain nchan here, since otherwise the user has to do a test run with a small #chans in spw, then change spw to do their full run, which adds options for errors and reduces the utility of a test run.
- I think we have to retain width. Users should be able to make an output cube that has output width=Nx input chan, without doing lots of calculations. then we have to make the same decisions about it as above - pos/neg? allow strings=quantities? fractional # channels?
- with width retained, nchan becomes more intuitive and not coupled to nchan in potentially complex ways.
- overlapping spw are gridded onto extensions of the grid defined at the center of the band? i.e. the attempt is made to match the MS channelization as closely as possible at the center freq of the selected spw and chans, and then propagate in +/- direction with even channel widths, until you run out of data and/or get up to nchan?