[Difx-users] ITRF realisations {External}

Sun Jul 6 23:32:51 EDT 2025

Hi everyone,

It sounds like there is a desire that some metadata relevant to the station
positions propagates through from the sched station catalogue through to
the vex file and thence into the FITS-IDI output. That seems a reasonable
thing to aim for, regardless of what one thinks of the provenance of said
station positions (and how one deals with the delay model that has been
generated from them and applied at the correlator).

Cheers,
Adam

On Sat, 5 Jul 2025 at 12:56, Leonid Petrov via Difx-users <
difx-users at listmgr.nrao.edu> wrote:

> Dear Chris,
>
> > but the sched catalogue as what most people use as the positions used
> > for Calc.
>
>    Pity!
>
>    Coordinates are not measurable quantities. The is is the
> essence of geodesy. Path delay is invariant to a group
> of rotations and translations. As a result, one cannot determine
> station positions using only observations. One needs to apply
> constraint equations with some arbitrary constants right hand sides.
> You can select these constants whichever way you like, for set to
> a telephone number of your spouse, but usually, these constants
> are chosen in such a way that the origin of the coordinate system
> is not too far from the place where nobody traveled -- I mean the
> geocenter, and orientation is not too different then the EOP time
> series maintained by Christian Bizouard. "Too far", "too different"
> sounds subjective. In my view, 10 cm is not too far.
>
>    Reference frame is just a synonym to station position catalogue.
> If one determines position of ATCA pad XXX with respect, say ATCA-104,
> using total station, then that geodesist uses solution gsf_2025b,
> then that guy can write: position of ATCA pad XXX in the gsfc_2025b
> reference frame is A.
>
>    ITRF is not consistent with anything. The latter versions are worse
> than the previous one. I do not recommend of using it all.
>
>    I know users AIPS got used to a concept that the correlator would
> provide them a perfect model and then they can work with residuals.
> At NASA we have never used that approach at least since 1975.
> Instead, we compute our model that is orders of magnitude more accurate
> than that the correlator used and add to theoreticals the quantity
> new_path_delay minus old_path_delay. And we do not care about
> TRF, EOP used by the correlator. I offered 5 or 6 times to the AIPS
> maintainer to add this feature to AIPS and always heard "no!".
> Personally, I have PIMA for VLBI data analysis instead of AIPS and
> I am not affected by this problem.
>
> > So what frame used likely does not matter, but for normal astronomical
> > use cases my worry is that we as a whole are not careful enough.
>
>    If you really want to have a precise theoretical model, use
> open-source
> NASA SGDASS that has station positions, source positions, EOP,
> non-linear
> station motion updated on a quarterly basis, various loading  applied,
> the ionospheric model, path delay through the atmosphere computed
> by integration of equations of wave propagation using the output of NASA
> numerical model, etc. The right place for this refined model is
> the post-processing stage, not correlation. Though, you can run difxvtd
> if you like.
>
> Leonid
> 2025.07.04_22:46:50
>
>
> > On 2025-07-04 22:26, Phillips, Chris (S&A, Marsfield) wrote:
> > Hi Leonid,
> >
> > My concern with sched was that the catalogue have no frame info
> > recorded into the positions. Sched does not do much with positions, so
> > I agree for sched it does not matter but the sched catalogue as what
> > most people use as the positions used for Calc.
> >
> > I have chatted to Cormac offline, who points out that the absolute
> > difference between frames would only affect stuff like ionospheric
> > corrections, which will make difference at all. However the different
> > frames have many cm difference between them so if inconsistent frames
> > are used in the catalogues, that *will* have an effect.
> >
> > So what frame used likely does not matter, but for normal astronomical
> > use cases my worry is that we as a whole are not careful enough.
> >
> > Cheers
> >
> > Chris
> >
> > From: Leonid Petrov <Leonid.Petrov at lpetrov.net>
> > Date: Friday, 4 July 2025 at 19:49
> > To: Phillips, Chris (S&A, Marsfield) <Chris.Phillips at csiro.au>
> > Cc: Difx-users <difx-users at listmgr.nrao.edu>
> > Subject: Re: [Difx-users] ITRF realisations {External}
> >
> > Chris,
> >
> >    I looked at sched-12.0. I found that internally it uses UTC(t)
> > function as time. It assumes UT1(t) = UTC(t), see for instance
> > schgeo.f. This can introduce an error that is equivalent to an
> > error in position of mid-latitude sites at a level of several
> > hundreds meters.
> >
> >    In that context difference in several centimeters between different
> > station catalogues is irrelevant.
> >
> > Leonid
> > 2025.07.04_08:47:11
> >
> >> On 2025-07-04 01:02, Phillips, Chris (S&A, Marsfield) via Difx-users
> >
> >> wrote:
> >> Hi all,
> >>
> >> I have just learned that ITRF (which we use as the XYZ coordinate
> >> system of our telescopes) has multiple realisations (ITRF2000,
> >> ITRF2014 etc).
> >>
> >> There was approx a 9cm change between around ITRF2005, which is
> > huge.
> >>
> >> The “Frame” detail in Sched is light on details and vex2difx
> > make
> >> no mention of frame.
> >>
> >> Does anyone know what ITRF frame Sched expects?
> >>
> >> Thanks
> >>
> >> Chris
> >> _______________________________________________
> >> 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
>

-- 
!=============================================================!
Prof. Adam Deller
Centre for Astrophysics & Supercomputing
Swinburne University of Technology
John St, Hawthorn VIC 3122 Australia
phone: +61 3 9214 5307
fax: +61 3 9214 8797
!=============================================================!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listmgr.nrao.edu/pipermail/difx-users/attachments/20250707/328c28db/attachment.html>