[Difx-users] ITRF realisations {External}

Mon Jul 7 21:06:21 EDT 2025

I don't see any need to deviate from what is currently available (linear
motion within a date range), I think it is just a case of adding a text
field that includes some metadata on where that comes from, and passing
that through to vex and onwards to FITS via difx2fits.

Leonid: the position that is in the vex file can always be overridden in
vex2difx if a different station position is desired for correlation, and
I'm not suggesting additional positions/keywords. As you suggested,
post-processing is the place to do anything meticulous. I view this as
simply ensuring that the origin of the coordinates used for correlation can
be more easily ascertained when one has the FITS file.

Cheers,
Adam

On Tue, 8 Jul 2025 at 02:50, Jay Blanchard via Difx-users <
difx-users at listmgr.nrao.edu> wrote:

> SCHED is currently maintained enough to put in a little bit of work if
> more metadata on the frame used is requested in the VEX.
> I don't envisage us being able to put in the work to do anything super
> complicated (non-linear etc).
> We'd need a clear idea of how/where though :)
>
> Jay
>
> On 7/7/25 10:30, R. Craig Walker via Difx-users wrote:
> > SCHED locations.dat file has date ranges.  SCHED uses the appropriate
> > entry.  This allows accounting for steps (earthquakes), but nothing
> > more complicated.  For example, there are three entries for MK-VLBA
> > with different date ranges.
> >
> > Cheers
> > Craig
> >
> >
> > On 7/7/25 5:08 AM, Leonid Petrov via Difx-users wrote:
> >> Adam,
> >>
> >>   Vex schedule has some positions, although these are not necessarily
> >> the positions actually used for scheduling. Sched (as as three other
> >> scheduling programs) has no mechanism to account for non-linear site
> >> motion, which in case of Japanese station may reach a meter level.
> >>
> >>   We have section ARRAY_GEOMETRY with a keyword STABXYZ.
> >> Do you suggest to have two keywords for station positions?
> >>
> >> Leonid
> >> 2025.07.07_07:06:00
> >>
> >>
> >>> On 2025-07-06 23:32, Adam Deller wrote:
> >>> 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
> >>> !=============================================================!
> >>
> >> _______________________________________________
> >> 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
>
> _______________________________________________
> 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/20250708/96d744e6/attachment.html>