[evlatests] WIDAR baselines, and time offsets

[George Moellenbrock]

Guys-

>> conjugation does not, in general,  change the phase by 180 degrees
>
> agreed.  it's the sign of the phase, not the sign of the imaginary part,
> that's at issue (and is what the "sign convention" here refers to).  i'm
> wondering how the CBE could get that sign wrong...
>

Changing the sign of the phase and changing the sign of the imaginary part 
(conjugation) are the same thing.  The imaging reversal noted by Rick is 
NOT a change of 180 deg in the phase, but rather a rotation of the whole 
image about the phase center by 180 deg.  It would probably be more 
precise to say that the image is "reflected through the phase center".

There are no 180 deg phase flips here, other than the occasional sporadic 
ones which close (I think), and so have no effect on the imaging.  These
are unrelated to the image orientation effect.

As I noted last week, one way the phase sign can be bungled is in the 
sorting of the antennas (and thus baselines) into antenna number order. 
This requires baseline reversal and phase-sign reversal on _some_ 
baselines (not all), and if done incorrectly, would punish overall closure 
of the ensemble (i.e., poor dynamic range).  It wouldn't necessarily 
completely frustrate calibration, but it would certainly bias it in
ways that make it a little harder to figure out where the errors are....

-George






>>
>>>    While making the comparisons noted above, I noticed that the two
>>> databases are not precisely identical in their time axes.  Michael R.
>>> noted some time delay between the arrays while the data were taken.  I
>>> can confirm this, based on the index files of the two (supposedly)
>>> parallel sets:  The VLA dataset is 32 seconds behind the WIDAR dataset.
>>> In other words, all scans in the VLA dataset start and stop 32 seconds
>>> later than those in the WIDAR dataset.
>>
>> I would expect 33 seconds.  Data from the VLA correlator is
>> labelled in IAT, while data from Widar seems to be labelled
>> in UTC.  I hope that the sign of IAT-UTC is consistent with
>> what you describe.
>>
>
> in fact, one would expect it to be 34 sec currently, since that's what
> the current dAT (leap seconds) is.  does this mean we've got a lurking
> definition of what the leap seconds are somewhere in the software that
> hasn't been updated in 2 years?  it'd be nice to know if this really is
> exactly 32 seconds instead of 34...
> _______________________________________________
> evlatests mailing list
> evlatests at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/evlatests
>

--