[Difx-users] On delay modelling

Mon Apr 24 03:19:54 EDT 2017

Hi Adam,

Thank you so much for the clarifications.

Regards,

Mugundhan

On Mon, Apr 24, 2017 at 12:44 PM, Adam Deller <adeller at astro.swin.edu.au>
wrote:

> Hi Mugundhan,
>
> Since the x axis of the ITRF is nominally aligned with longitude 0 on the
> Earth, if you want to think of things in terms of hour angles then yes the
> hour angle will be GMST.  You don't then make any further adjustment for
> the latitude and longitude of the observing stations.  To be properly
> precise, though, you will have to take into account precession and nutation
> as well as polar offset (orientation of the Earth in space c.f. the best
> model including precession and nutation) and UT1-UTC (Earth's rotational
> phase c.f. "average").  They are changing the tilt and rotation of the xyz
> ITRF frame with respect to the J2000 positions, which you can "undo" by
> offsetting the hour angle and declination of the source very slightly.
>
> Cheers,
> Adam
>
> On 24 April 2017 at 14:41, Mugundhan vijayaraghavan <
> v.vaishnav151190 at gmail.com> wrote:
>
>> Dear Adam,
>>
>> Thank you for your clarifications.
>>
>> One more question:
>> The unit vector \hat(s) originates from the center of the earth, in this
>> case, the hour angles of the sources will have to be calculated as GMST-RA
>> ? In this case, do we have to offset the obtained hour angles and the
>> declination by the lat and long of the observing stations ?
>>
>> Thank you,
>>
>> Mugundhan
>>
>> On Mon, Apr 24, 2017 at 6:10 AM, Adam Deller <adeller at astro.swin.edu.au>
>> wrote:
>>
>>> Hi Mugundhan,
>>>
>>> On 21 April 2017 at 15:30, Mugundhan vijayaraghavan <
>>> v.vaishnav151190 at gmail.com> wrote:
>>>
>>>> Dear All,
>>>>
>>>> I have a few queries about how delay modelling is carried out in VLBI
>>>> for compensating the same.
>>>>
>>>> 1.) The geometric delay is calculated as tg=*b.s*, where *b *is the
>>>> baseline vector and *s *is the source vector. Lets say I have two
>>>> antennas, both located about 100 kms apart. How do standard VLBI delay
>>>> modelling software calculate this delay ? Based on some preliminary reading
>>>> I understood that the baseline distance are first calculated referenced to
>>>> the earth center, if this is done, are delays estimated assuming the earth
>>>> center to be the phase reference ? How is this earth centered reference
>>>> then transformed to the celestial frame ? because both *b *and *s *must
>>>> be in the same coordinate system for carrying out a dot product operation,
>>>> right ?
>>>>
>>>
>>> VLBI delay modeling is very complicated, involving considerably more
>>> than just a *b.s* operation.  Other propagation effects are taken into
>>> account too, and the length of the baseline *b* is changing with time
>>> due to tidal forces and what-not, plus the whole system is wobbling around
>>> due to the changing earth orientation.
>>>
>>> But stripping it back to the minimum: yes, the Earth centre is usually
>>> used as the reference.  Look up the International Terrestrial Reference
>>> Frame (ITRF) to see the definition of the axes.  Then you obviously need to
>>> know the *time* (and the Earth orientation parameters) to figure out
>>> where the unit vector \hat(s) that points at the direction of the source is
>>> pointing in this reference frame.  For each telescope, we then compute the
>>> station-based delay from the telescope back to the geocentre at the desired
>>> instant of time, and each telescope's data stream is delayed by the
>>> computed amount (rather than shifting only one data stream by the
>>> difference between \tau_a and \tau_b).  That's what it means to use the
>>> geocentre as the reference.
>>>
>>>
>>>>
>>>> 2.) In some books/articles i find a reference to a RA and Dec of
>>>> Baseline ? What does this physically mean ? I'm not able to visualize this
>>>> clearly. any help will be greatly appreciated !
>>>>
>>>
>>> Like I said above, it makes more sense to figure out where the source
>>> unit vector is pointing relative to a telescope coordinate system.  You can
>>> equivalently rotate the telescope coordinates and keep the source unit
>>> vector fixed, but that is (I think) less intuitive.
>>>
>>>
>>>>
>>>> 3.) In the complete delay model, tm, which is the sum of geometric
>>>> delay+clock delay+ionospheric/atmospheric delay+fixed delays due to analog
>>>> component, the fastest varying component will be geometric delay only, once
>>>> this is compensated, if the other quantities are contributing to some
>>>> excess time varying delay, this will be seen as a residual fringe. Now, for
>>>> clock delay, is this estimated using the allan deviation of the clock being
>>>> used? Lets say my clock loses 10^-9 seconds in 30 minutes, and if I sample
>>>> my signal at 16 MHz which is ~ 62.5 ns, will I be able to integrate the
>>>> data without any degradation due to clock upto 30 minutes ?
>>>>
>>>>
>>> The sampling time is irrelevant.  It's the sky frequency that determines
>>> the visibility phase.  Your signal might only be 16 MHz wide, but if you
>>> were observing at 100 GHz then a change of 1 nanosecond translates to 100
>>> turns of phase.  So in that example you could only integrate for maximally
>>> a fraction of a second.  Normally VLBI clock drifts are monitored to a
>>> level of at worst a few ns/day or so. If they are unknown then a test
>>> correlation is performed to determine the clock offset and drift, and then
>>> the observation is recorrelated having applied the best available clock
>>> model.
>>>
>>>
>>>> 4.) There is also an associated baseline velocity component which will
>>>> lead to a time difference between the wavefronts received at both the
>>>> antennas. Is this baseline velocity the same as the orbital velocity of the
>>>> earth ? Or is this modelled differently ?
>>>>
>>>>
>>> By delay tracking to the geocentre, this problem is naturally taken into
>>> account. When you use the geocentre, you are automatically forced to
>>> account for the rotation of the reference frame between the time the signal
>>> is received at the antenna and the time that it would pass through the
>>> geocentre.  So you've corrected for the velocity of both of the stations,
>>> rather than their difference.  The process is known as retarded baseline
>>> correction.
>>>
>>> Unfortunately the documentation for VLBI delay packages is not
>>> extensive.  You can look up CALC (https://lupus.gsfc.nasa.gov/s
>>> oftware_calc_solve.htm) or VTD (http://astrogeo.org/vtd/) but neither
>>> have an excellent explanation of the theory.
>>>
>>> Cheers,
>>> Adam
>>>
>>>
>>>> I would greatly appreciate if the experts here clarify my doubts.
>>>> Kindly do point me to references that may lead to clarification of these
>>>> doubts too !
>>>>
>>>> Thanking you,
>>>> With best regards,
>>>>
>>>> Mugundhan V.
>>>>
>>>>
>>>> _______________________________________________
>>>> Difx-users mailing list
>>>> Difx-users at listmgr.nrao.edu
>>>> https://listmgr.nrao.edu/mailman/listinfo/difx-users
>>>>
>>>>
>>>
>>>
>>> --
>>> !=============================================================!
>>> Dr. Adam Deller
>>> ARC Future Fellow, Senior Lecturer
>>> Centre for Astrophysics & Supercomputing
>>> Swinburne University of Technology
>>> John St, Hawthorn VIC 3122 Australia
>>> phone: +61 3 9214 5307 <+61%203%209214%205307>
>>> fax: +61 3 9214 8797 <+61%203%209214%208797>
>>>
>>> office days (usually): Mon-Thu
>>> !=============================================================!
>>>
>>
>>
>>
>> --
>> the giver of moksha
>>
>
>
>
> --
> !=============================================================!
> Dr. Adam Deller
> ARC Future Fellow, Senior Lecturer
> 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
> !=============================================================!
>

-- 
the giver of moksha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listmgr.nrao.edu/pipermail/difx-users/attachments/20170424/979b4b06/attachment-0001.html>