From efomalon@nrao.edu Mon Apr 5 14:20:15 2004 Date: Sun, 04 Apr 2004 13:34:24 -0400 From: Ed Fomalont To: George Moellenbrock Cc: John Hibbard , aips2-naug@zia.aoc.nrao.edu Subject: Re: [Aips2-naug] Comments on Data Selection Hi George, etal I have just become aware of the MS_selection document. I hope these comments are useful. Cheers, Ed TIME: ---I think scan should be a separate parameter. ---Time ranges, which are very common, are generated by using the '-' between times. If you use this symbol, then you can never use a negative number for a time designation. A negative time might be useful sometimes. Like, couldn't time = '-00:00:10' mean 10 seconds before the previous day. Perhaps, use a different symbol for range. But, I guess '-' is too imbedded as a range. (this comes up later.) ---Can a blank be used between parts of the time, rather than a ':', at least betweem the hours, min and sec. This saves typing and 3% of the time I hit a ';' instead. It's hard to see, sometimes (yes, I know old eyes). ---If you type 2003/11/07/12:00:00, then 01/12:20:20 do you get 2003/11/07 or 2003/11/01 or 2003/11/08 (the next day)? ---I assume that time always refers to UTC. Conversions from LST, Julian day, etc are available if needed. FIELD: ---I noticed (so did John Hibbard), the you put zero-bases counting in field (field = 0-3) is first four fields. Would prefer one-based counting. ---Should field and code be separated into two things? It's a little confusing. If the field is contained in quotes, then it can be a field or a code. If it is a number, then it can only be a field (as defined by its number in the MS_SOURCE subtable. So, you could not used source numbers and codes at the same time. Could I do field 3C555 code P, and field 3c666 code Q without getting lots of P codes and Q codes. ---Why is there a concept of a field.code anyway? Can't you put any reasonable substring in the name and implicitly define it as a usable code? Then, you only have to deal with field.name and not field.name and field.code. ANTENNA: ---Looks okay. Similar to AIPS convention where the antennas before the & are the AIPS ANTENNA, and the antennas after & are the BASELINE. ---The combination of antenna number or name with polarization state is good, rather than a separate polarization. ---I didn't see the difference between antenna = '5:R' and antenna = '5:R & *' UVDIST: ---As with John, not so keen on the '%' distance. ---I would not put UVDIST in the 'primary' quantities. It is not a very good baseline selection because the baselines and antennas change with time, depending on the foreshortening, and I think this could be a mess in calibration as antennas come and go. You might want to pick out a UVDIST, but on the ground array directly, so the subarray doesn't change with time. I suppose you could do this with some antenna syntax, like all antennas with 5 km of the center of the Wye, all antennas within 2000 km from Pie Town. SPW: ---Okay, but what does 'strided' mean? Averaging? I think that any spw averaging, hanning etc should be handled separately from selection. However, averaging channels is so common, maybe this could be an exception, but it really doesn't belong in selection. ---I see you get into the negative values confusion with the range, as mentioned above with the time. The symbol '-' is used for so many things, maybe range should use something else. What about '_' for range? CORRELATION: ---This basically tells how to combine the two polarization inputs from each pair of antennas. If correlation 'must' be the same as that observed, then antenna = '5R & 7L,*R' does anything correlatiion produce you might want? But, it you observe with circulars, but want XX, XY, YX and YY out, then you need correlation since it is a combination of the basic polarization/antenna observations. ---But, my guess is that this should NOT be a selection specification, but a processing of the data. ANY OTHERS: ---You've hit the obvious antenna primary selection parameters (with UVDIST and CORRELATION perhaps not needed). TAQL: Below I discussed about the use of TAQL. It is useful for complex specifications, but you don't want the nominal user to bother with it. Could there be a primary TAQL add to the above keywords which stands on its own in case it is needed. This could apply generally to most tool, as a TAQL function like in the MS tool. ---------------------------------------------------------------------- FURTHER SUGGESTIONS (many of which are obvious): CALIB.SETDATA and others: use the SPW syntax instead of nchan, start and step as separate functions. Also, mstart and mstep not needed. table, tablein, tableout: okay, but maybe table should always be replaced by tablein, even if no tableout is needed. CALIB.SETAPPLY: remove select and put in above adverbs. CALIB.SETDATA: remove msselect and put in above adverbs. Several: fldsin and fldsout. Since field is used, why not use fieldin and fieldout instead. I can't remember if field and its derivatives are field or fields, sometimes. CALIB.PLOTCAL: timeslot should be replace by time as above. tablename should be replaced by table(in). Should antenna and polarization be combined, as suggested in the primary keywords? IMAGER: A good time to rearrange the function groups. Some alternatives discussed over a year ago. IMAGER.OPEN: thems?? Does this mean open another ms, not that attached to IMAGER. Maybe newms or msnew, or msfile IMAGER.SETJY: fieldid replaced by field IMAGER.CLEAN: default for model should be clean.model IMAGER.FILTER: Needs specifications in lambda or km also. IMAGER.SETDATA: Use primary keywords. IMAGER.SETIMAGE: Use primar keywords. FLAG.FILTER and IMAGER.CLIPVIS. Different syntax for threshold. I would suggest changing threshold (used in IMAGER.CLEAN for something else) to CLIPLEVS (upper and lower level), or some like this. FLAG.QUACK. replace delta with time. I am not sure if begin and end could be incorporated in time. They are sort of like scanbeginning + begin, scanend - end. But, quack is pretty specific, so maybe you have to keep what you have, but only replace delta FLAG.lots of things like setantennas, setbaselines, etc. could all be put in one general FLAG.SELECTION to include appropriate data using primary keywords. FLAG has a more complicated set of functions and then goes away go do something. Could this be streamlined? MS.CONCATENAT: Some confusion about what is added to what. The ms attached to the MS tool is appended to the msfile. So msfile is enlarged from input msfile to input msfile + tool file. The msfile name can perhaps be changed to reflect this. I think it would be more simple to have attach ms to a file ms msinfile = file to add msoutfile = file with ms+msinfile or, if msoutfile is blank msoutfile = file with ms+msinfile --> ms MS.GETDATA: Very confusing about what this is doing. How does it overlap with SELECTCHANNEL, SELECTPOLARIZATION, SELECTTAQL (which also should be removed. TAQL in general: TAQL is very general and it would be useful to keep it around for the user in order to specify keywords with all sorts of options. For all 'reasonable' specifications, it should never be needed. XXX.TAQL: Maybe something like these is needed for many tool names, as it is in MS.SELECTTAQL. Available if needed, but removed from the normal data selection functions. _______________________________________________ Aips2-naug mailing list Aips2-naug@listmgr.cv.nrao.edu http://listmgr.cv.nrao.edu/mailman/listinfo/aips2-naug