User Tools

Site Tools



This Chapter provides some details about di fferent data being used in VLBI analysis and how they are used in VieVS. For data used in VIE_GLOB, VIE_SCHED and VIE_SIM we refer to the according wiki pages.

Time-dependent correction and coefficients of periodic time dependencies are stored in the superstation file which can be found in VieVS/TRF/superstation.mat. Files used for the superstion fi le are stored in VieVS/TRF/create/superstation/neededFiles.

Corrections without periodic time dependencies are saved as time series. The corresponding files can be found in folders located the VieVS root directory (e.g. non-tidal atmosphere loading is saved at VieVS/ATM/ ).

Similar folders can still be found for corrections that are now saved in the superstation file. Those folders are used with older VieVS versions and are obsolete if the newest VieVS version is used.

For detailed information on the data being used in VLBI analysis we refer to the following subsections:

Observation data

Basically VieVS supports the following input data formats:

  • NGS files
  • vgosDB files
  • VSO files: simple observation file format (text file) which also supports observations to satellites

VIE_INIT distinguishes between the different observation file formats and writes the provided information to the according VieVS data structures. Since all other modules (following VIE_INIT in the processing chain) use the VieVS data structures as input, it makes no difference for them, which observation file type was loaded initially.

Observation files can be selected in the File - Set input files menu.

To select one or more sessions from NGS or VSO files go to File - Set input files and click on Browse for sessions (see Fig. below). Multiple sessions can be selected by holding the Ctrl button.

To load vgosDB files use the Browse for VGOS-DB button. A dedicated menu will show up. Please note: You have to select the complete session folders rather than separate files here!

Selected sessions show up in the process list listbox. Sessions stored in vgosDB format are tagged with the string [vgosDB] after the session name and sessions from VSO files are tagged with [VSO], respectively, as shown in the screenshot below.

Process lists can be loaded using the button Browse for process lists. All selected included sessions will then show up in the according listbox.

VieVS graphical user interface

NGS files

The observations are stored in the NGS file which is the main input file for VieVS.

NGS header

The NGS header consists more or less of stations and sources of the session, including their rough coordinates - x,y,z for stations, right ascension and declination for sources. The mounting type of the telescope is given as well.

NGS data cards

This is the main part, all observation information is stored in here.

A full description of the NGS files can be found at

VSO files

VSO (VieVS Simpe Observation files) files contain VLBI observation data and can be loaded by VieVS. The VSO format enables to distinguish between two different observation tapes: (1) observations of quasars and (2) of satellites.

VSO files are loaded in VIE_INIt by the funciton read_vso.m. Have a look at this function to get more details! If formal errors are missing in the VSO file, the default values defined in read_vso.m are taken and written to the scan structure.

Major characteristics:

  • One line per observation
  • Comments start with “%”
  • Each column provide a different parameter
  • There are various VSO file types, providing different numbers of input parameters (columns)

VSO file types

  1. Only baseline delays
  2. Baseline delay + formal error
  3. Baseline delay + formal error and Ion. delay + formal error
  4. No observations (used e.g. to calculate a priori delays in vie_mod for the correlator input model)
  5. Baseline delay + formal error, Ion. delay + formal error, cable corr
  6. Baseline delay + formal error, Ion. delay + formal error, cable corr, met. data (T, p, e) ⇒ Analog to NGS files

Detailed format description:

% 1.) ##### Baseline delay only: #####
% | Delay reference epoch            | Stat. 1 name  | Stat. 2 name  | source name | obs. type | baseline delay [nsec]/[sec] |
% | YYYY MM DD hh mm ss.ssssssssssss | <max 8 char.> | <max 8 char.> | <string>    |   s/q     |      float                  |
% 2.) ##### Baseline delay + formal error: #####
% | Delay reference epoch            | Stat. 1 name  | Stat. 2 name  | source name | obs. type | baseline delay [nsec]/[sec] | delay formal error [nsec]/[sec] |
% | YYYY MM DD hh mm ss.ssssssssssss | <max 8 char.> | <max 8 char.> | <string>    |   s/q     |      float                  |      float                      |
% 3.) ##### Baseline delay + formal error  and Ion. delay + formal error: #####
% | Delay reference epoch            | Stat. 1 name  | Stat. 2 name  | source name | obs. type | baseline delay [nsec]/[sec] | delay formal error [nsec]/[sec] | Ion delay [nsec] | Ion formal error [nsec] |
% | YYYY MM DD hh mm ss.ssssssssssss | <max 8 char.> | <max 8 char.> | <string>    |   s/q     |      float                  |      float                      |      float       |      float              |
% 4.) ##### No observationas (used e.g. to calculate a priori delays in vie_mod for the correlator input model) #####
% - If the input vso file has only 10 colums, this formati is selected automatically
% - If the second vso header line (starting with "#") contains the phrase "noDelay", all entries after colums 10 are skipped (= vso format 4 is selected)
% | Delay reference epoch            | Stat. 1 name  | Stat. 2 name  | source name | obs. type |
% | YYYY MM DD hh mm ss.ssssssssssss | <max 8 char.> | <max 8 char.> | <string>    |   s/q     |
% 5.) ##### Baseline delay + formal error, Ion. delay + formal error, cable corr: #####
% | Delay reference epoch            | Stat. 1 name  | Stat. 2 name  | source name | obs. type | baseline delay [nsec]/[sec] | delay formal error [nsec]/[sec] | Ion delay [nsec] | Ion formal error [nsec] | cable corr. stat. 1 [ns] | cable corr. stat. 2 [ns] |
% | YYYY MM DD hh mm ss.ssssssssssss | <max 8 char.> | <max 8 char.> | <string>    |   s/q     |      float                  |      float                      |      float       |      float              |  float                   |  float                   |
% 6.) ##### Baseline delay + formal error, Ion. delay + formal error, cable corr, met. data (T, p, e): #####
% | Delay reference epoch            | Stat. 1 name  | Stat. 2 name  | source name | obs. type | baseline delay [nsec]/[sec] | delay formal error [nsec]/[sec] | Ion delay [nsec] | Ion formal error [nsec] | cable corr. stat. 1 [ns] | cable corr. stat. 2 [ns] | T stat. 1 [°C] | p stat. 1 [mbar] | Rel. humidity e stat. 1 |T stat. 2 [°C] | p stat. 2 [mbar] | Rel. humidity e stat. 2 |
% | YYYY MM DD hh mm ss.ssssssssssss | <max 8 char.> | <max 8 char.> | <string>    |   s/q     |      float                  |      float                      |      float       |      float              |  float                   |  float                   | float          | float            | float                   |float          | float            | float                   |    

vgosDB files

vgosDB is a format and database to store and exchange data obtained from geodetic VLBI observations. This embeds station specific data (e.g. cable calibration data, feed rotation data, meteorological data,..) and data related to the VLBI observable (e.g. group delay observations of X and S band and ionospheric slant path data). The vgos database is not a single file like the ngs file, but rather a file system with several folders. A very small number of parameters besides header information is stored in a single file. Very often just one parameter is stored in one file. The files are netCDF files, which are binaries and which are well known in the scientific community to store data and for their fast accessibility.

From September 30, 2017 vgosDB will the sole data format for any type of exchange and long term storage. The format is in a “very good beta version”, but is is still in a beta release, the data is not available on CDDIS or other IVS data centers. Instead you can download the vgosDB data at Many institutions, including GSFC, reprocess all of the IVS sessions from scratch, starting with the initial Mark3 database. This results in different editing and ambiguity resolution depending on the institution. For example, in the /ObsEdit/ folder stores the X-band group delay observations processed by IVS, where “i” stands for institution.

VieVS is ready for vgosDB and is able to read the required data from the vgos database for VLBI analysis. Furthermore, VieVS offers a handy tool to view and plot the binary vgos database.

Select Institute

Some of the file in vgosDb refer to the institution provider. This is the case for all files of the ObsEdit folder which represents “final” data which is ambiguity corrected. To process this data VieVS needs to know which institution should be selected because there might be various institution providers. By default IVS is selected for institution (which corresponds to the official Mark4 database). If you want to process data from another institution you can create a file in the WORK folder called vgosdb_input_settings.txt and add a line with institution: <name of desired institution>. eg. institution: GSFC.

Select Frequency Band

VgosDb offers the possibility to process different types of delays. Currently VieVS supports four different types:

  • 'GroupDelayFull_bX' (final X-band group delay with ambiguity correction, corresponds to the delay in the NGS file)
  • 'GroupDelayFull_bS’ (final S-band group delay with ambiguity correction)
  • 'GroupDelay_bX' (X-band group delay without ambiguity correction)
  • 'GroupDelay_bS' (S-band group delay without ambiguity correction)

By default 'GroupDelayFull_bX' is selected for VieVS processing. If you want to select a different observable you can simply type a line in the vgosdb_input_settings.txt file with frequencyband: <name observation> e.g. frequencyband: GroupDelay_bX

Used vgosDb files in VieVS

Currently the following vgosDb files are used in VieVS:

  • sourcelist
  • CrossReference/
  • CrossReference/
  • CrossReference/
  • ObsEdit/
  • ObsEdit/
  • Observables/
  • ObsDerived/
  • Scan/
  • <Station>/
  • <Station>/
  • <Station>/

Atmospheric loading

Tidal atmosphere loading

Tidal atmosphere loading is caused by diurnal heating of the atmosphere. Three models are currently implemented in VieVS:

The tidal atmospheric loading effect can be found in the superstation file and the corresponding source folder. We refer to the given references for more detail on the implemented models.

Non-tidal atmosphere loading

Non-tidal atmosphere loading is caused by pressure changes due to air mass movements. At mid-latitude stations experience a vertical crustal displacements of up to 25 mm. Two models are currently implemented in VieVS:

Files used for the non-tidal atmospheric loading effect can be found in the ATM folder. We refer to the given references for more detail on the implemented models.

Hydrology loading

Hydrology loading is caused by non ocean water bodies (e.g. canopy water, soil moisture, snow etc.) which cause a load on the crust. The corrections are provided by the NASA GSFC VLBI group (Eriksson & MacMillan, 2014). Files used for the hydrology loading can be found in the HYDLO folder. We refer to the given reference for more detail on the implemented models.

Ocean tide loading

Ocean tide loading is caused by the redistribution of water mass due to tides. The water causes a load on the crust and therefor a deformation of up to 10 cm. 5 ocean tide loading models are implemented in VieVS:

The ocean tide loading effect can be found in the superstation file and the corresponding source folder. We refer to the given references for more detail on the implemented models.

Ocean pole tide loading

Ocean pole tide loading is generated by the centrifugal effect of polar motion on the oceans. The IERS Conv. 2010 recommends the ocean pole tide model of (Desai, 2002) which provides the ocean pole load tide coefficients. The ocean pole tide loading effect can be found in the superstation file and the corresponding source folder. We refer to the given reference for more detail on the implemented models.

Azel Files

Azel files are text-files which are created automatically as part of the daily automatic processing. For each session one .azel file is created. It contains one line for each observation and each station. The parameters written to these files are:

  • Number of scan
  • Mjd of observation
  • Year of observation
  • Day of year of observation
  • Hour, minute and second of observation
  • Stationname
  • Azimuth [rad]
  • Elevation [rad]
  • Source
  • Temperature [$^{\circ}$C]
  • Pressure [hPa]

On the basis of the azel-files the .trp (external tropospheric files) are created. The number of rows in the .azel file is therefore the same for the .trp file. This is important because the azel-files specifies if all observations are used (even those with a quality flag not equal 0).

External ionospheric files


Taken from: (Tierno Ros, 2011).

The ionosphere is a portion of the upper atmosphere; it is extended from about 60 km to 2000 km and has the characteristics that the particles there can be easily ionized by solar radiation resulting in a positive ion and a free electron. The ionospheric delay makes up a large fraction of observed VLBI group delays and it depends on the number of free electron (TEC) along the ray path. Usually, a correction can be applied by making simultaneous observations in both S- and X-band. However, this is not always possible. For such cases, there is the alternative of calculating the ionospheric correction from Global Navigation Satellite Systems (GNSS) TEC maps. (Please note that it is only recommended to use the GNSS corrections in case of not having observations in both S- and X-band, since the X/S ionosphere values are instantaneous direct measurements while the GNSS values suffer from low spatial and temporal resolution, Gordon, 2010).

GNSS TEC maps are representing the TEC values over the whole globe determined from GNSS observations. The routine generation of these Global Ionosphere maps (GIMs) is currently done at four analysis centers of the International GNSS Service (IGS), more details about the different techniques they use can be found in Schaer (1999); Feltens (1998); Mannucci et al. (1998) and Hernández-Pajares et al. (1999). The analysis centers transmit their products to the IGS Ionosphere Product Coordinator, who produces a weighted combined product (Hernández-Pajares et al.,2009). The accuracy of the maps is between 2 to 8 TECU. Such maps exist since 1998 and have a latitude/longitude resolution of 2.5/5.0 degrees.

External ionospheric file

The figure below shows how an external ionospheric file looks like. The header contains information about the creation date of the file, the VLBI-session which corresponds to the file, the type of GIM used and the coordinates of the stations participating in the session.

Fragment of an external ionospheric file

The file body is divided in columns:

  1. VLBI-Session that corresponds with the file
  2. Number of scan
  3. Date and time of the observation in YYY.MM.DD-hh:mm:ss.s
  4. VLBI-station observing
  5. Azimut (in degrees) of the observation
  6. Elevation angle (in degrees) of the observation
  7. Atmospheric pressure at surface (mbars)
  8. Temperature
  9. Ionospheric slant path delay (in seconds)

How to create an external ionospheric file

In order to create an external ionospheric file you should follow these instructions: (Please note that before creating it, VIE_INIT and VIE_MOD should have been executed for the sessions for which you want to create the external files)

  1. A new GUI should open. Screenshot GUI creating external ionospheric file Here you can specify which ionospheric map you want to use (CODE or IGS), for which sessions you want to create the external ionospheric file and optionally the name of the directory where the external file will be saved (default is VIEVS/ION/FILES, specification of sub-directories possible). In the Figure you can see an example of how the GUI looks after you selected the parameters. Example of screenshot GUI creating external ionospheric file. You can also select multiple sessions stored in process lists. For now, the only possibility to loaf VSO files (per default located at /DATA/VSO/) is via a process list. The very left panel only lists NGS files.
  2. Click on the button create files
  3. Now the creation of the external file starts. The following steps are carried necessary:
    1. Definition of the reference frequency (default = 8400.00 MHz for standard X band observations). Please note, that the effective frequency has to be entered here which calculates as weighted combination of the reference frequencies of all individual channels within the frequency band. This option also provides the possibility e.g. to derive ion. corrections for L-band observations of GNSS satellites, etc.
    2. Loading the antenna structure of the session from the /DATA/LEVEL1/ directory. If multiple structures were found, one has to be selected in the Command Window. Note: To generate the antenna structure the session has to be processed with VIE_MOD before!
    3. Loading AZEL file. If no AZEL file for this session was found at /OUT/AZEL/, a new AZEL file is created automatically.
    4. The CODE/IGS (according to your selection) ionospheric maps will be automatically downloaded from the corresponding CODE/IGS server (depending on the session 1 or 2 maps are needed), if it doesn't already exist.
    5. In case the file has to uncompressed, the program stops and asks you to manually do manually uncompress it with the software of your choice (TEC maps are located at /ION/MAPS/IGS/yyyy/). You can delete the compressed file.
    6. Continue by entering “y” in the CW.
    7. Finally, the ionospheric delays are calculated and saved in an /ION/FILES/<sub-dir> file.


The files containing the ephemerids are described here.

Terrestrial reference frames - Superstation file

The superstation file is a .mat file containing all static station-dependent data, e.g. TRF, loading data, discontinuities, eccentricities, furhter antenna information. The Table below provides a summary of all realizations/models which are included by default.

Type of data Included Own
TRF ITRF2005, ITRF2008, ITRF20014, VTRF2008, VTRF2014, ivsTRF2014b, VieTRF13, vievsTrf (Backup) x
Tidal ocean loading FES2004, GOT00, EOT08a, TPXO72, AG06 x
Ocean pole tide loading by S. Desai x
Tidal atmosphere loading Vienna, GSFC, VanDam x
Additional Antenna information, eccentricities, equipment, horizon mask, discontinuities -

Create a superstation file

In Models - Reference frames there is a button Create file. This button runs the createsuperstationsFile.m function which is a interface for creating the superstation file (Fig. below). This function as well as all needed data for the superstation file are located in /TRF/create/superstation/ .

Screenshot GUI creating superstation files

The four menu buttons in the GUI let you specify filenames of the shown textfiles. In Main/Info files data like general antenna information, horizon masks and equipment data can be found. The menu button TRF lets the user specify up to six different terrestrial reference frames. The two most-right menu items ask the user to input loading correction data. If the files are located in /TRF/create/superstation/neededFiles/ , the button Search for files on the right of the interface searches for those files and writes the correct file names (including paths) to the textboxes. The textbox at the bottom specifies the output file name (requires a .mat file), the button Create runs the program and creates the superstation file.

Requird input data for the superstation file

:!: This list is not complete ⇒ Please add information here!

Datum definition

If station coordinates are estimated, some conditions need to be applied in order to avoid singularity - e.g. No net translation (NNT) and No net rotation (NNR). If a station has bad a priori coordinates (or after an earthquake, when coordinates are wrong), this antenna should be removed from the NNT/NNR(/NNS) condition. The rest of the paragraph gives instructions on how to exclude a station from the given conditions. If an official TRF (i.e. all but vievsTrf) is chosen in Models - Reference frames and a station is found there (coordinates exist for an appropriate break), this station is taken as datum station. If the station does not exist or has no appropriate break (i.e. backup coordinates are taken from vievsTrf), the station is excluded from NNT/NNR. If vievsTrf is chosen as a priori reference frame (and only then), the ones and zeros in the vievsTrf-textfile indicate if a station is treated as datum station.

Own data

User can introduced an additional TRF. The text format of the TRF file is shown in the Fig. below:

Format of the user own TRF file Comment lines start with '%', data lines start with a station name, followed by x, y and z coordinates and the velocities in x, y and z direction. The three last columns are epoch, start- and end-break (this specifies the time for which the coordinates and velocities are valid). Each column has to be separated by at least one blank; the columns don't have to be aligned with each other.

The additional TRF can be a matlab structure file and has the next fields:

ivsname x y z mjd
1×8 char double double double double

and extra (double, could not exist in structure):

vx vy vz start end

The tidal ocean loading, ocean pole tide loading and tidal atmosphere loading can be added by user to the superstation file. Each file has to be specified in the proper panel.

The structure can be used for ocean loading and has to consist of:

ivsname load
1×8 char 6x(ntides) double

where coefficient order:


Usually, ntides = 11 as follows: M$_2$, S$_2$, N$_2$, K$_2$, K$_1$, O$_1$, P$_1$, Q$_1$, Mf, Mm, Ssa.

The user defined atmosphere loading file should have the same format as the 'original' files given by the corresponding models (see Fig. below). A data line starts with an eight-character station name. The required 12 values (in the same order as ocean loading for S$_1$ and then S$_2$) must start from position (column) 35 (more blank is allowed). Format of the user own atmosphere loading file

The user defined ocean pole tide loading file should have the same format as the 'original' file. The file provides all values on a longitude/latitude grid. A screenshot of this structure is shown in below: Format of the user own ocean pole tide loading file

Celestial reference frames - Supersource fi le

Similar to the superstation file, there is also one file containing all static information about sources (i.e. name representations and catalog positions). The .mat file can be found in VieVS/CRF/supersource.mat. The most complete list of sources can be found in the ASCII file VieVS/CRF/create/neededFiles/vievsCrf.txt. There, the user can also add new/own sources.

Create supersource file

To create a supersource file, go to Models - Reference frames and click on Create file in the Celestial reference frame panel. In the appearing GUI set the paths to all required files (all but user crf are required) and save the supersource file.

VieVS automatically reads the default file (supersource.mat in VieVS/CRF/ ) at the start of VieVS. If you want to load another one, select Chose file in Models - Reference frames in the CRF panel.

Add a new source to the supersource file

If a source is not included in the supersource file then it has to be added to the text file VieVS/CRF/create/supersource/neededFiles/vievsCrf.txt. The necessary information comes from the NGS file, for instance. Add the new source in the same format as the other sources, that is:

IVS source name (8 characters), right accession (hh mm ss.ssss), declination (+/-dd mm as.ssss), epoch (yyyy.y), source file where the source coordinates are taken from (if it is from a NGS file please write the name of the session here), number to define if coordinates are taken in NNR condition if vievsCRF selected or not (1 or 0). For instance:

 2235-556   22 39  6.034360 -55 25  59.411800 2000.0 0.0 14JUL21XA    0

ATTENTION! If the declintion of the source is negative and has only a single digit it is written as follows in the NGS file: “- 4”. This can not be read properly in VieVS, please remove the space or fill it with a zero, e.g.: “-4” or “-04”.

As a next step the new source must be added to the supersource.mat file in order to be available in VieVS:

  1. open VieVS
  2. go to Models - Reference Frame - Celestial Reference Frame and click Create file
  3. set the paths to all required files
  4. specify the directory for VieVS/CRF/supersource.mat and click Create.

ATTENTION! In the NGS header IVS source names are used but we use IERS names as reference (because the ICRF catalogues, e.g. ICRF1, ICRF2,… contain only the IERS names!). In most cases these are identical but sometimes they differ. You may check the translation table (CRF/create/supersource/neededFiles/IVS_SrcNamesTable.txt) provided by the Goddard VLBI group to find the IERS name. The checking is done automatically while creating the supersource file. In case an IVS name is missing in this table or there is no IERS name given for the particular source, a dummy IERS name is created in a form VIE_xxxx and stored in the supersource file.

Thus, the new supersource.mat file is generated and replaces the previous version, now containing also the newly added source.

public/vievs_manual/data.txt · Last modified: 2018/01/12 11:15 by dlandskr