[daip] Re: CL table gripe

[Craig Walker]

The starting message of this discussion was not forwarded, so I'm not
completely sure of the topic.  But I'll throw in my 2 cents anyway.
It sounds like this relates to what CLCAL does with input CL data outside
the region of the data in the input SN table data or of the input selection
parameters.  I see two cases:

1.  You want to run CLCAL separately for different parts of the data.
This is the only scheme that really works for applying APCAL data because
of scan boundary issues (which in principle could be fixed by other schemes,
but that is a different story).  In this case, you would prefer CLCAL
to only pass forward the selected data in the input SN table.  It also
should insert the output into the output table if that table already 
exists, writing over anything that was already there for the selected
data.  

2.  You only want to modify a subset of the whole table, but want all of
it there in the output.  This can be done if CLCAL copies through the
unmodified input data.  But in that case, the situation above is difficult.
If CLCAL only passes the modified data, but inserts it in a preexisting
CL table as case 1 above, case 2 can be handled with a TACOP followed
by CLCAL.

So, unless the behavior is user settable, I'd recommend that CLCAL only
pass data that it has worked on, but that it overwrite the corresponding
output records in any preexisting CL table.  Corresponding should probably
mean any meeting the input selection criteria, not just ones for which
there is new data, to avoid having some residual old records when the
new SN has more flags than were there before.  If I remember correctly,
this is what it does now.

Craig

By the way, that issue with the APCAL data could be handled if there
were a 2pt option that didn't interpolate across scan boundaries.  Better
yet would be one that extrapolated to the scan boundary using the slope
of the last 2 (more?) points in the scan.  With the current scheme you
either get steps all through low elevation scans if you use "self" or
you get awful interpolation effects at the scan boundaries if you use
"2pt".





On 2002.11.22 09:30 Eric Greisen wrote:
> Amy:
> 
> can you look at this CL table inquiry?  I suppose a CL table with
> entries for only 1 scan would be expanded outward without difficulty.
> It would encounter no blanked entries or anything...
> 
> Everybody:
> 
> I have always thought that the real problem is that CLCAL can make a
> CL table containing only a tiny part of the info in its input CL
> table.  Is there any good reason for this?  Or should CLCAL copy the
> input CL table to the output entirely (if the output is not
> pre-existing) and then update the entries that need updating.
> 
> Eric
> 

---------------------------------------------------------------------
    R. Craig Walker            Array Operations Center
    cwalker at nrao.edu           National Radio Astronomy Observatory
    Phone  505 835 7247        P. O. Box O
    Fax    505 835 7027        Socorro NM 87801   USA
---------------------------------------------------------------------