This Chapter provides some details about different 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 file 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:
Basically VieVS supports the following input data formats:
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.
The observations are stored in the NGS file which is the main input file for VieVS.
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 http://lacerta.gsfc.nasa.gov/mk5/help/dbngs_format.txt
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.
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 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 ftp://gemini.gsfc.nasa.gov/pub/vgosDB_IVS. 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, GroupDelayFull_iIVS_bX.nc 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.
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:
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:
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 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 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 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 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 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:
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).
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.
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.
The file body is divided in columns:
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)
The files containing the ephemerids are described here.
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||-|
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/ .
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.
This list is not complete ⇒ Please add information here!
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.
User can introduced an additional TRF. The text format of the TRF file is shown in the Fig. below:
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:
and extra (double, could not exist in structure):
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:
|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).
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:
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.
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.
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:
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.