[Difx-users] Handling lin-pol data with difx2fits

[Adam Deller]

I would add to this discussion that I am not sure how well AIPS would cope
with polarisations labelled H and V.  I suppose this could be worked around
with a patch to FITLD that converted X/Y to H/V upon loading, if that was
what AIPS wanted to live with.  But that is another potential issue.

I second Chris's note that X/Y labels seem to be getting propagated
correctly via the FITS-IDI file to AIPS at the moment in DiFX-produced
files.  But I suppose that the data may be stored in multiple places in the
FITS-IDI file, and it is entirely possible that one place is correct and
another is not!

Cheers,
Adam

On Thu, 11 Apr 2019 at 17:38, harro verkouter <hverkouter at gmail.com> wrote:

> Dear Leonid, DiFX users,
>
> I would avoid applying this specific patch because it introduces a subtle
> bug, which may result in a segmentation fault at best and producing
> incorrect polarization label for polarization B without crashing at worst.
>
> This specific piece of the code exposes a subtlety in the C/C++ languages.
> The effect is that the second
> +       if ( D->nPolar == 1 )
> +       {
> +             polTypeA = D->polPair[0];
> +             polTypeB = '?'; /* Mark missing polarization */
> +        }
> Note the missing "else" here. The is syntactically valid C/C++ but the the
> net effect is that, because there is no "else" keyword, the following piece
> of code:
> +        {
> +             polTypeA = D->polPair[0];
> +             polTypeB = D->polPair[1];
> +        }
>
> will be executed *unconditionally*. Syntactically speaking, the compiler
> only sees the open/close braces as starting a new, temporary, context,
> without any conditions. All statements inside the block are executed.
> Thus, if D->nPolar is, in fact, just 1 (single polarization) then the
> variable polTypeB will be unconditionally overwritten with whatever
> D->polPair[1] contains.
>
> If you're lucky D->polPair is length one in that case and you're
> addressing outside array bounds and *maybe* get a segmentation violation.
> But chances are better than average that that memory location is not
> initialized or contains unknown content which is unconditionally
> transferred to polTypeB.
>
> Cheers,
> h
>
>
>
> On Thu, 11 Apr 2019 at 05:41, Leonid Petrov <Leonid.Petrov at lpetrov.net>
> wrote:
>
>> Dear colleagues,
>>
>>   DiFX has a bug and does not propagate polarization labels to the
>> output FITS-IDI. The fix is rather trivial.
>>
>>   However when I discussed this issue with Rick Perley, he pointed out
>> that another fix is needed as well. According to famous AIPS 114 memo,
>> page 8, horizontal and vertical polarizations shall be labeled X and Y:
>>
>> X Horizontal linear
>> Y Vertical linear
>>
>> i.e. fixed in the topo-centric, site-dependent coordinate system.
>>
>>   This is contrary to the IAU 1976 resolution that defines X polarization
>> along direction to the Northern Pole and Y polarization along the
>> right ascension axis (East), i.e. rotating in the topo-centric,
>> site-dependent coordinate system.
>>
>>   I suggest to rename the polarizations recorded at the VLBI stations as
>>
>> H Horizontal linear
>> V Vertical linear
>>
>>   and reserve X and Y labels for space telescopes.
>>
>>   In addition to just complying with the IAU nomenclature, it reduces
>> chances
>> of misunderstanding in communication with station personnel: who knows
>> which
>> polarization a station guy considers as "X", but unless he is operating
>> an
>> orbiting VLBI telescope, horizontal and vertical polarizations are
>> unambiguous.
>>
>>   Any objections? Other thoughts?
>>
>>   Since we only started using FITS-IDI data with lin-pol, this change will
>> be relatively painless.
>>
>> Leonid
>> 2019.04.10_23:34:51
>>
>> ------------------------------------ Patch
>> ---------------------------------
>>
>> --- applications/difx2fits/src/fitsAN.c~        2019-04-06
>> 21:14:14.733263707 -0400
>> +++ applications/difx2fits/src/fitsAN.c 2019-04-06 21:44:13.932896491
>> -0400
>> @@ -106,8 +106,22 @@
>>         stop  = D->mjdStop  - (int)D->mjdStart;
>>
>>         arrayId1 = 1;
>> -       polTypeA = 'R';
>> +       polTypeA = 'R'; /* Default */
>>         polTypeB = 'L';
>> +       if ( D->nPolar == 1 )
>> +       {
>> +             polTypeA = D->polPair[0];
>> +             polTypeB = '?'; /* Mark missing polarization */
>> +        }
>> +        {
>> +             polTypeA = D->polPair[0];
>> +             polTypeB = D->polPair[1];
>> +        }
>> +        if ( polTypeA == 'X' ) { polTypeA = 'H'; } /* Rename linear
>> polarizations */
>> +        if ( polTypeA == 'Y' ) { polTypeA = 'V'; }
>> +        if ( polTypeB == 'X' ) { polTypeB = 'H'; }
>> +        if ( polTypeB == 'Y' ) { polTypeB = 'V'; }
>> +
>>         time = 0.5 * (stop + start);
>>         timeInt = stop - start;
>>         for(bandId = 0; bandId < nBand; ++bandId)
>>
>> _______________________________________________
>> Difx-users mailing list
>> Difx-users at listmgr.nrao.edu
>> https://listmgr.nrao.edu/mailman/listinfo/difx-users
>>
> _______________________________________________
> Difx-users mailing list
> Difx-users at listmgr.nrao.edu
> https://listmgr.nrao.edu/mailman/listinfo/difx-users
>


-- 
!=============================================================!
A/Prof. Adam Deller
ARC Future Fellow
Centre for Astrophysics & Supercomputing
Swinburne University of Technology
John St, Hawthorn VIC 3122 Australia
phone: +61 3 9214 5307
fax: +61 3 9214 8797

office days (usually): Mon-Thu
!=============================================================!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listmgr.nrao.edu/pipermail/difx-users/attachments/20190411/36086e02/attachment-0001.html>