[daip] 回复: Re: AIPS---fitld warning message

[Eric Greisen]

童锋贤 wrote:
>  
>  > This is a bit curious - FITLD builds the initial calibration table (CL
>  > version  1) from iinformation in the MC and IM tables.  This message 
>  > says that there are times in the CL table  for which there was no MC 
>  > table data within 1 minute.  You could try PRTAB on the CL table and 
>  > examine the clock and atmosphere columns.  I suspect that normally they 
>  > contain only zeros and, if so, this message contains nothing 
>  > significant.  If they are not zero, then it might be good to find the 
>  > relevant times and fix up the CL table manually.
>  
>  
> Thank you!
>  
> I have tried to use "PRTAB" to print 'CL' table, and the values of clock 
> and atmosphere columns were zeros. I set the values of 'clock' and 
> 'atmosphere' to zeros in 'MC' and 'IM' tables in my fits file. As you 
> say "I suspect that normally they  contain only zeros and, if so, this 
> message contains nothing significant.", that mean only the value of 
>  'clock' and 'atmosphere' columns in "CL" table which did not get clock 
> and atmosphere, were zeros and nothing significant?
>  
>  
> But, I use 'FITLD' (AIPS version '31DEC13' )to load fits file, sometimes 
> there were no warnings at all (just like 'no_warning.FITS' in attachment),
> sometimes I got some warnings "MC2CL: WARNING 8 CL RECORDS DID NOT GET 
> CLOCK AND ATMOSPHERE" (just like 'have_warnings.FITS' in attachment). 
> The fits files in attachment were created by me, maybe there're some 
> bugs in my fits files.
>  
> I'm wondering how the 'MC2CL' work ,and which information do the 'MC2CL' 
> use in the 'MC' and 'IM' tables.

MC2CL simply copies the clock and atmosphere corrections that were
applied by the correlator into the CL table.  In general, these
corrections are not known at correlation time and so are zero in the MC
table and thus in the CL table.

Your example FITS file did however expose an error in the handling of
the MC table (and potentially the IM table).  The fact that your MC
table records were separated by < 2 seconds caused the fetching routine
to fail to find the records which were present in the MC table.  I have
corrected the code and, if you run a MNJ on Tuesday in 31DEC14, you will
get the corrected version.  Note that there is no error since the data
to be fetched was all zero.

The IM2CL routine gets the geometric delay and dispersion terms applied
by the correlator.  The former are not zero, the latter are usually
zero.  Fortunately, the similar error for IM tables was only triggered
by IM records closer than 1 second and so did not occur with your data.

Thanks you for following up on this matter

Eric Greisen