[daip] How to flag the bad data using uvflg

[Eric Greisen]

On 6/22/2020 2:38 AM, Aiyuan Yang via Daip wrote:
> My question is that do we need to flag the stokes of “RL” and “LR”, as 
> the there are bad in stokes R?
> Thanks a lot!
>
> Cheers,
> Aiyuan
>
>> On 21 Jun 2020, at 18:16, Aiyuan Yang <ayyang at mpifr-bonn.mpg.de 
>> <mailto:ayyang at mpifr-bonn.mpg.de>> wrote:
>>
>> Dear AIPS helpdesk staff,
>> Hope this email finds you well.
>> I am new to use AIPS to do calibration and now I need to flag the bad 
>> data using uvflg.
>> But I am confused by the example in the section 2.2 error recognition 
>> of AIPS guidelines, which said the bad data is antenna 11, IF 2, and 
>> stokes R and the example of flag commands are as below :
>> "antenna 11 0
>> timerang 0 10 20 20 0 14 0
>> stokes 'rr'
>> bif 2
>> eif 2
>> inp please always check your input
>> go"
>> *
>> *
>> I am wondering why the stokes were being set to ‘rr’ but the bad 
>> stokes is R?
>> So how can I set my flag commands if my bad data are in stokes R, as 
>> shown in the figure?
>> <PastedGraphic-5.png>
>>
>> Thank you very much in advance.


If the R polarization data are in fact bad, then one flags RR, RL, and 
LR.  The delay solutions you show suggest that something has gone wrong 
with the R solutions and you should examine the RR data closely to see 
why rather than deleting all your polarization data and half of the 
rest.  In fact each R solution looks like the others which means that 
the delay correction (R(ant 1) - R(ant 2)) would in fact be zero.  
Something has simply gone wrong so there may be a much smaller amount of 
data which could be deleted to fix this problem - perhaps some channels 
affected by RFI?  POSSM or SPFLG would be good ways to look at the data 
to find this issue.

Eric Greisen




-- 
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listmgr.nrao.edu/pipermail/daip/attachments/20200622/16b344bf/attachment.html>