[daip] VLBAEOPS version TST spoils phases
Eric Greisen
egreisen at nrao.edu
Fri Aug 5 11:06:38 EDT 2011
Eduardo Ros wrote:
> Dear Eric,
>
> In my former email there was a mistake. I used 'OLD' to get it working,
> did not try 'NEW' in between.
>
> On Aug 4, 2011, at 11:26 PM, Eric Greisen wrote:
>
>> Eduardo Ros wrote:
>>> Dear Eric,
>>> In the last days I was analyzing old archival data, and some weeks
>>> earlier my own data from CTA102 and I noticed that the TST version of
>>> VLBAEOPS spoiled the phases (to be seen in POSSM after running it).
>>> This does not happen in the NEW and OLD versions of aips in the
>>> MPIfR installation.
>>> Maybe you want to have a look to it. If needed I can send you some
>>> plots with the NEW and the TST versions.
>>>
>> This is curious. I have looked at the code and there is a comment in
>> it that suggests to me that there is an error - the pernicious sign of
>> the Y antenna coordinate. Unfortunately that does not explain your
>> remarks at all since the code in at least NEW and TST in CLCOR and in
>> the procedure file VLBAUTIL in NEW and TST is identical. If I had to
>> guess - they should all be bad for your data. The versions of AIPS in
>> Bonn are all current - so 31DEC09 has in it the change that made all
>> antenna files be on a right-handed coordinate system. If you run
>> PRTAN on your data set you will see a keyword stating XYZHAND='RIGHT'
>> and all 3 versions agree.
>
> This is correct. See:
>
> ^L vlb033 PRTAN(31DEC11) 720 02-AUG-2011
> 11:40:44
> Page 1
> File=BD117A X .FITLD . 1 An.ver= 1 Vol= 2 User= 720
> Array= VLBA Freq= 8412.490000 MHz Ref.date= 30-JUN-2006
>
>
> Array reference position in meters (Earth centered)
> Array BX= 0.00000 BY= 0.00000 BZ= 0.00000
> Polar X = 0.12749 Polar Y = 0.30093 arcsec
> Earth rotation rate = 360.9856449733 degrees / IAT day
> GST at UT=0 = 277.9233491584 degrees
> UT1-UTC= 0.1952600 Data time(UTC )-UTC= 0.0000000 seconds
> XYZHAND = 'RIGHT ' TFRAME = '????? '
> Solutions not yet determined for a particular FREQID
>
>
>> I have the author of the 3 places in CLCOR affected 'SUND', 'EOPS',
>> and 'ATMO' examining the code. Unfortunately, he leaves on vacation
>> after tomorrow but I hope he can provide an answer by then on whether
>> the code as it now stands - with RH By in the antenna table - is wrong
>> or not. The fix is easy.
>
>
>> This does not explain the apparent functioning in NEW and OLD. Did
>> those versions copy the data file the same way TST did? Are the CQ
>> files the same or is this the same data set simply run with version =
>> 'new'? What do the Cl tables look like before and after and what do
>> you mean by spoiled the phases using POSSM? POSSM makes a spectral
>> plot - did EOPS add a large delay component causing a big phase ramp?
>> That is what POSSM should be used to display.
>
> VLBAEOPS running:
>
> VLB047> CLCOR1: Task CLCOR (release of 31DEC10) begins
> VLB047> CLCOR1: Copied CL file from vol/cno/vers 2 1029 2 to 2 1029 3
> VLB047> CLCOR1: CL version input 2 output 3
> VLB047> CLCOR1: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> VLB047> CLCOR1: !OPTYPE=EOPS can be used only for VLBA correlator!
> VLB047> CLCOR1: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> VLB047> CLCOR1: UT1-UTC(sec), POLX, POLY(miliasec) used by correlator
> VLB047> CLCOR1: 1 -1. 0.195827 126.660 302.230
> VLB047> CLCOR1: 2 0. 0.195260 127.490 300.930
> VLB047> CLCOR1: 3 1. 0.194530 128.330 299.610
> VLB047> CLCOR1: 4 2. 0.193621 128.790 298.420
> VLB047> CLCOR1: 5 3. 0.192645 128.890 297.300
> VLB047> CLCOR1: ZTXOP2: using translated file name =
> VLB047> CLCOR1: ZTXOP2: /tmp/jplg1810.06i
> VLB047> CLCOR1: UT1-UTC(sec), POLX, POLY(miliasec) picked up from the
> USNO file
> VLB047> CLCOR1: 1********** ********************************
> VLB047> CLCOR1: 2********** ********************************
> VLB047> CLCOR1: 3********** ********************************
> VLB047> CLCOR1: 4********** ********************************
> VLB047> CLCOR1: 5********** ********************************
> VLB047> CLCOR1: 13907 Records modified
> VLB047> CLCOR1: Appears to have ended successfully
> VLB047> CLCOR1: vlb047 31DEC10 NEW: Cpu= 1.5 Real= 4 IO=
> 20
>
> Providing:
> =
> ------------------------------------------------------------------------
>
>
>
> Alternatively:
>
> VLB047> CLCOR1: Task CLCOR (release of 31DEC09) begins
> VLB047> CLCOR1: Copied CL file from vol/cno/vers 2 1029 2 to 2 1029 3
> VLB047> CLCOR1: CL version input 2 output 3
> VLB047> CLCOR1: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> VLB047> CLCOR1: !OPTYPE=EOPS can be used only for VLBA correlator!
> VLB047> CLCOR1: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> VLB047> CLCOR1: UT1-UTC(sec), POLX, POLY(miliasec) used by correlator
> VLB047> CLCOR1: 1 -1. 0.195827 126.660 302.230
> VLB047> CLCOR1: 2 0. 0.195260 127.490 300.930
> VLB047> CLCOR1: 3 1. 0.194530 128.330 299.610
> VLB047> CLCOR1: 4 2. 0.193621 128.790 298.420
> VLB047> CLCOR1: 5 3. 0.192645 128.890 297.300
> VLB047> CLCOR1: ZTXOP2: using translated file name =
> VLB047> CLCOR1: ZTXOP2: /tmp/usno_finals.erp
> VLB047> CLCOR1: UT1-UTC(sec), POLX, POLY(miliasec) picked up from the
> USNO file
> VLB047> CLCOR1: 1 2453915.5 0.195833 126.560 302.940
> VLB047> CLCOR1: 2 2453916.5 0.195264 127.440 301.310
> VLB047> CLCOR1: 3 2453917.5 0.194515 128.280 300.080
> VLB047> CLCOR1: 4 2453918.5 0.193599 128.710 298.950
> VLB047> CLCOR1: 5 2453919.5 0.192632 128.810 297.830
> VLB047> CLCOR1: 13907 Records modified
> VLB047> CLCOR1: Appears to have ended successfully
> VLB047> CLCOR1: vlb047 31DEC09 OLD: Cpu= 1.6 Real= 3 IO=
> 20
This last information is what I needed to see. 31DEC10 (= 'NEW') was
given a different text file to get the EOP parameters from and clearly
failed completely (the *****'s) while 31DEC09 (= 'OLD') was given a text
file of something like the usual name and read values from it that
differed only slightly from those used at the correlator and thus made a
sensible change to the CL table. Your error is in the files provided to
VLBAEOPS not in the AIPS code. Unfortunately, my examination of the
code has produced an apparent need to change the code. We are going to
correlate a little data here with both our best guess EOPS and with a
deliberately wrong EOPS and see what the old and the corrected code do
with it.
Eric Greisen
More information about the Daip
mailing list