[daip] clcal bug

[Cormac Reynolds]

hi,

after reading the help files a little more carefully, I found that I
got the behaviour I wanted by setting the desired GAINUSE explicitly,
instead of setting to 0 and allowing it to default to a new table. The
help file does explain that if you set gainuse=0, the old table is
first copied before being filled, which explains why CLCAL behaved the
way it did.

So this is not a bug after all, but I do wonder if the difference in
operation between setting gainuse explicitly or leaving as 0 is so
desirable. I would have thought that the 'CALP' option should provide
this functionality, but perhaps there is a good reason why it works
how it does.

regards,
Cormac.

2008/6/24 Cormac Reynolds <cormac.reynolds at gmail.com>:
> hi,
>
> I notice what looks like a small bug in clcal (if I understand how it
> should work correctly). I fringed a subset of the antennas in a
> dataset (using the 'ANTENNAS' keyword to select the antennas). As
> expected, there were no entries in the SN table for the antennas that
> I had not selected. I then ran clcal on the resulting SN table. I was
> expected to see no entries in the CL table for the antennas that were
> not selected, but the CL table had the entries from the parent CL
> table passed through unchanged. I thought that this behaviour was what
> would happen if OPCODE='CALP', but I had definitely selected
> OPCODE='CALI'.
>
> I've included the full list of inputs to CLCAL at the bottom of this
> message, in case it is useful.
>
> thanks,
> Cormac.
>
>
> ----------------------------------------------------------------------------------------