[daip] IMAGR queries/suggestions/confusions
Michael Rupen
mrupen at aoc.nrao.edu
Thu Mar 23 14:29:56 EST 2000
To: daip
Subject: IMAGR requests
Dear daip,
I've been doing some deep 20cm wide-field imaging (A+B configurations),
and have run across a number of minor limitations and confusions in IMAGR.
None of these are show-stoppers, so feel free either to dismiss the
suggestions as impractical or to put them off until a more convenient time.
Suggestions:
* it would be nice to be able to set a pixel range during interactive
CLEANing, rather than relying on the IMAGR defaults. Those defaults can be
rather weird -- e.g. the pix. range for a field sometimes depends on the
history of which fields were previously displayed.
* it would be useful to have a "status bar" across the bottom, reminding
you which field you're currently displaying -- when you have >100
it can be really annoying to box one & then realize that you don't
know whether you had just finished with field 4 or 24. Ideally this
line would also give the offsets (a la rashift, decshift) of the field
that's being displayed, so you know roughly where you are. If you
want to be very cute as long as you're at it, it would be cool to give
the total flux cleaned from this map as well...
[I realize this is printed to the message screen, but I often fiddle
or box with an image, and lose the message off the top of the screen.
In any case it's not very obvious in the reams of other messages.]
* Currently with overlap=2 and DOTV=1, you can either look at the field
IMAGR magically selects, or remake *all* the fields and then choose
which to display. It would often be useful to be able instead to select
a particular field to remake & display, without having to remake all of
them.
Confusion (mine, from reading the help file :):
* FORCE A FIELD actually does two things -- displays the field, and
(by default) makes it the next field for CLEANing. Should probably
say something about the 1st action in the HELP file -- currently it
concentrates entirely on the 2nd. I would like to see this 1st function
at least be allowed in interactive CLEANing even with DOWAIT=-1, if
that's possible.
* What exactly does OVERLAP do?
If I understand things,
OVERLAP=1 will subtract CCs correctly from overlapping fields
OVERLAP=2 chooses the order of CLEANing in some clever fashion,
and allows interactive control.
So, why would I ever used OVERLAP=1, if OVERLAP=2 is more clever?
If I want to run non-interactively, is OVERLAP=2 still a good idea?
If I do run with OVERLAP=1, am I correct in assuming that the result
will be accurate, but take longer than OVERLAP=2? or is there more to it?
* For VLA data, how are the two IFs treated?
- Are the data gridded separately for the two frequencies? There
were some rumours that this was not done correctly a while back.
- When you set IMAGRPRM(1)=24.5 (for VLA data -- I hope this is right!
and it would be nice to have that in the documentation as well),
what exactly is done? The EXPLAIN file says
If IMAGRPRM(1) is larger than 0 then a correction is made in the
subtraction to remove the effects of the frequency dependence of the
primary beam. The primary beam is assumed to be a uniformly illuminated
disk of diameter IMAGRPRM(1) meters. This correction is made out to
the 5% power point of the beam with a flat correction further out.
Note: this correction is only for the relative primary beam to
correct to a common frequency and DOES NOT correct for the primary beam
pattern at this frequency.
Lovely, we correct to a common frequency...but which frequency? I
hope it's the same frequency assumed in PBCOR, i.e. the one which is
output as the freq. in the header of the resulting image.
Bugs:
* HELP file for IMAGR lists IMGRPRM twice (in the HELP section).
* I think the line under TV DISPLAY in the EXPLAIN file, saying
clear that multiple fields are accessible during that TV display session
should be
clear when multiple fields are accessible during that TV display session
i.e. "that" should be "when"
* Also, in the line
other if the verb FILEBOX in AIPS.
"if" should be "is"
Cheers, and thanks,
Michael
More information about the Daip
mailing list