User manual to OPA (OPerational Analysis utility)

Leonid Petrov

Abstract:

Table of contents:

1   Purpose

2   Usage

3   Overview

4   Menu operations

4.1   Help
4.2   Inquire status
4.3   Modify arc-line
4.4   Quit
4.5   Set all
4.6   Clear all
4.7   Do all set actions
4.8   Execute this action
4.9   Setting action field

5   Actions

5.1   Make superfile
5.2   Update global arc-list
5.3   Update baseline-dependent weights
5.4   Update station-dependent weights
5.5   Make EOPS solution for IVS submission
5.6   Make EOPI solution for IVS submission
5.7   Make Multi-EOP solution for IVS submission
5.8   Make SNR analysis
5.9   Make a standalone solution and keep listings
5.10   Update EOPK time series
5.11   Insert a solution listing into VDB
5.12   Submit a pair of databases to IVS
5.13   Submit EOPS solution to IVS
5.14   Submit EOPI solution to IVS
5.15   Submit EOPM solution to IVS
5.16   Submit Sinex listing to IVS

6   Format of Operation Control File

6.1   Example

7   Format of OPA configuration file

7.1   Descriptions of directives of OPA configuration file
7.2   Examples of configuration file

8   Before starting

9   Hints

10   History


1   Purpose

Program OPA provides a convenient interface to various programs of Mark-IV VLBI Analysis system Calc/Solve which are used during operational data analysis of the particular experiment after completion of the interactive stage of analysis, and after saving the new version of the database. OPA inquires the status of processing this database and displays it. The user can select one or more operations from the menu, including, by not limited: making superfile, updating global sessions list, weights files update; making EOPS, standalone solutions; database submission, eop series, listings of solutions to the IVS Data Center. After selecting the operation or a set of operations OPA executes all requested operations in an automatic mode.

2   Usage

Usage: opa [-h] -c <config_file> -d <database_name> -i <solve_initials> [-v <verbosity_level>] [-m] [-noconfirm] Options: -h -- prints a help-file to the screen with summary of OPA options. -c -- specifies configuration file for OPA. -v -- sets verbosity level. 0 -- silent mode, only error messages are printed to the screen, 1 -- normal mode (default), information progress messages are printed to the screen. -d -- database name. OPA digests two forms: without leading dollar sign and with leading dollar sign. Dollar sign should be masked by \ in the latter case. NB: the latest version is considered. OPA doesn't provide the way to analyze not the latest version. -i -- Solve user initials -m -- to retrieve the set of IVS master files to the local disk. Retrieving master files is done before any other operations if this option is specified -noconfirm -- suppresses requresting user's confirmation for data submission

3   Overview

OPA first reads the configuration file, parses it and checks the validity of keywords. If option -m is specified, then it launches program wget for automatic retrieving the full set of masters-files from the IVS Data Center. Then OPA resolves the database name: it scans the set of master files and finds the record there which corresponds to the database name for this experiment. It finds the experiment code which corresponds to this database name. Then if finds the directory which keeps information related to this experiment and searches there for the operational control file for this particular experiment. If it doesn't find this file, OPA creates and initializes the status and action fields to the "undefined" value. If it finds the operational control file but of the obsolete version it creates it anew. Later on, OPA reads the operation status and action fields and displays them at two last columns of the menu. Status codes are: "?" undefined, "-" not done, "+" done, "N" not applicable, or forbidden under these circumstances. Action codes are: "?" undefined, "-" not to execute, "+" -- execute, "D" -- not to execute since it was already executed by OPA. OPA displays on the first line of the menu the date of the OPA's last revision, the database name, the latest version of the database, the experiment name, the solve user initials. OPA displays the name of the configuration file at the second line. Session-specific options which are applied in processing this session by batch Solve, so-called arc-line, is displayed at the third line. A set of possible actions is displayed in the middle part of the screen. Each line consists of the one-letter operation code, the operation name, the current status of this operation, and the action code. The list of supported commands is presented at the bottom part of the menu. User is able to change the list of opstions in the arc-line, to change the action code, and then to execute one or more actions. As a result of processing actions the session status is changed and it is recored in the operation control file.

4   Menu operations

The user is able to inquire status of session processing, to set one or more actions and to executes actions by using main OPA menu.

4.1   Help

Contents of help--file is displayed on the screen upon heating key <?>.

4.2   Inquire status

Current status of the session is inquired upon hitting key <$>. OPA checks: 0) whether all stations and sources nominally participated in the session are in the global station and source substitution files GLO_STA_FILE and GLO_SOU_FILE, regardless whether stations and sources were used in the solution or were suppressed or deselected. If OPA finds such stations or sources it prints the error messages and terminates. 1) was the superfile for this session made and is there a record in the superfile catalogue; 2) is there a records about this database and this version in the global arc-list. OPA scans all lines in the global arc-list except comments line. The inquire is considered successful if the list contains the record with exactly the same database name and the version which corresponds to the last version of this experiment. 3) does the baseline-dependent weights file contain records for this database and this (latest) version of the database. 4) does the station-dependent weights file contain records for this database and this (latest) version of the database. 5) was the standalone solition for this experiment done. OPA build the name of the listing in the spool format and checks whether this file exists. 6) was the EOP solution made for this database, regardless of database version. OPA scans EOPB_FILE file and looks there for the field database name. Three answers are possible: "-" -- not found, "N" -- found and this session is marked as participated in generic global solution, "+" -- found and this session is marked as NOT participated in global solution. 7) was the EOPM (multi-EOP) solution made for this database, regardless of database version. OPA scans EOPM_FILE file and looks there for the field database name. Three answers are possible: "-" -- not found, "N" -- found and this session is marked as participated in generic global solution, "+" -- found and this session is marked as NOT participated in global solution. 8) was the EOPK time series of the Earth orinetation parameters produced by running the Kalman filer on EOPS or EOPI series were updated/ 9) was the SNR analysis for this database done? A) was the listing of the standalone solution inserved in the VDB database (not implemented, always returns "?"). B) was a pair of databases for X- and S-band submitted to the IVS Data Center. C) was the EOP series submitted to the IVS Data center (not implemented, always returns "?"). D) was the EOPM series submitted to the IVS Data center (not implemented, always returns "?"). E) was the listing in SINEX format for standalone solution submitted to the IVS Data center (not implemented, always returns "?"). OPA updates information about the current status and presents it at the last-by-one column of the main menu. "?" -- means undefined, "-" means no, "+" means yes, "N" means not applicable. The latter clause means that the action is not permitted. Status of action "Update EOPK time series" and "Submit EOPS" solution to IVS is not checked and OPA reports its status as it was saved in the operational control file. After successful completion of the request OPA writes the updated status into the operational control file.

4.3   Modify arc-line

The so-called arc-line contains batch control language qualifiers which are eligible to appear at the arc-line of the batch control language. Refer to solve_guide_03, section ARCS.DBNAME to learn syntax of the arc-line qualifiers. Comment line "! <session_code>" is set as default when the file is created. This qualifiers will be attached to the record for this experiment in the global arc-file. One of the possible ways of using arc-line qualifiers is to exclude one or more stations, suppress some components of eop, etc. User is requested to enter the new arc-line upon hitting key <M> in the main menu. No syntax checks is done.

4.4   Quit

Hitting key <Q> causes OPA to terminate quietly. Current actions status is saved in the operational control file.

4.5   Set all

Hitting <W> key sets status of all actions to "execute", except actions which are not applicable ("N" in the status field).

4.6   Clear all

Hitting <Z> key sets status of all actions to "not execute".

4.7   Do all set actions

Hitting <@> key forces OPA to execute all actions which have the action field set to "execute" in the order as they appear at the main menu. OPA updates the operational control file after successful processing the last action and then terminates quietly.

4.8   Execute this action

Hitting <*> key forces OPA to execute the action to which cursor is pointing provided the action field is set to "execute". OPA updates the operational control file after processing this action and asks a user to hot any key, and then it displays main menu again.

4.9   Setting action field

Action status field is toggled between "+" and "-" by either hitting action code or by hitting <blank> key when cursor is pointed to the line with action. Action status is not changed if operation status is "N" (not applicable).

5   Actions

5.1   Make superfile

Action "make superfile" transform database to the superfile format. If the superfile(s) for the previous version existed, new superfile will be added to the superfile catalogue in addition with the previous superfile. Program liptn is called for making superfiles.

5.2   Update global arc-list

Action "update global arc-list" inserts the record for this experiment in into global arc-list GLO_ARC_FILE. The record consist of three fields: database name, the latest version number, arc-line qualifiers. It is assumed that global arc-file has been sorted by experiment date and then by database suffixes among several databases of the experiments conducted at the same date. OPA inserts inserts the record in the middle of the arc-file in order to preserve the sorting order. If there were the records for the same database for the same or different version, the new record will replace the old record.

5.3   Update baseline-dependent weights

Action "update baseline-dependent weights" launches batch Solve special solution for updating baseline-dependent weights. File BAS_WEIGHT_CNT is a batch control template file fir this type of solution. This template file contains two meta-values: @weight_file@ and @arc_line@. OPA replaces @weight_file@ with temporary file and replaces @arc_line@ with the line from the global arc-file GLO_ARC_FILE which corresponds this experiment. It is important to update global arc-list before execution this action. Batch Solve will compute the weights and put them into the temporary file. Then OPA inserts this weight file into the global baseline-dependent weight file BAS_WEIGHT_FILE. It is assumed that the global weight file has been sported by experiment dates and then by database suffixes, then by database versions among several databases of the experiments conducted at the same date. OPA inserts the weights by such a manner which preserves sorting order. If there were weights records for the same database, the same version, the new records will replace the old record. If there were weights for the same database but for the previous versions, new records will be added just after the old version

5.4   Update station-dependent weights

Action "update station-dependent weights" launches batch Solve special solution for updating station-dependent weights. File STA_WEIGHT_CNT is a batch control template file fir this type of solution. This template file contains two meta-values: @weight_file@ and @arc_line@. OPA replaces @weight_file@ with temporary file and replaces @arc_line@ with the line from the global arc-file GLO_ARC_FILE which corresponds this experiment. It is important to update global arc-list before execution this action. Batch Solve will compute the weights and put them into the temporary file. Then OPA inserts this weight file into the global station-dependent weight file STA_WEIGHT_FILE. It is assumed that the global weight file has been sported by experiment dates and then by database suffixes, then by database versions among several databases of the experiments conducted at the same date. OPA inserts the weights by such a manner which preserves sorting order. If there were weights records for the same database, the same version, the new records will replace the old record. If there were weights for the same database but for the previous versions, new records will be added just after the old version

5.5   Make EOPS solution for IVS submission

Action to "make EOPS solution for IVS submission" is for updating eop series for the contribution of this session. It is assumed that a) the session has at least three baselines and session duration was 24 hours (or at least 18 hours ) b) the global generic solution which estimated eop series has been done previously. c) eop series were extracted from the global solution, transformed to EOPB format, and the the symbol of the records in EOPB file which corresponds to the eop estimates for the sessions participated in generic solution is set to @. d) CGM file of the generic file is saved. e) template control file for the EOPS is set in accordance with control file for generic global solution. It differs from the generic control file by 1. Value of keyword CGM is "@cgm_file@ NONE" 2. Value of keyword EARTH_ORIENTATION is "@erp_file@" 3. Value ARC_LINE keyword is "@arc_line@" f) generic control file uses either baseline-dependent or station-dependent weights which are updated by OPA. g) control file uses substitution files for station positions, velocities, and for source positions the same as in generic solution. Records with new sources/stations are added to this file after processing observations with new station/source which didn't participate in generic solution. At the same time other records must not be modified. NB: OPA prohibits to make EOPS solution for the session which participated in generic global solution, at the same time it allows to make the second EOPS solution for the session which didn't not participated in the generic solution. OPA makes two global batch solutions in COMPLETE mode with input CGM and with superfile for this session. This type of solution is mathematically equivalent to the global solution which contains all databases in the generic solution plus this one. (NB: in general it is NOT equivalent to the solution with all available databases, since databases which appeared after generic solution and before processing this session are not included). A priori eop series which were used in generic solutions are applied to all experiments, except the current experiment. Values of a priori eop saved in the database are used as the apriori for the current experiment in the first solution. OPA substitutes the name of the input cgm with EOPS_CGM, replaces @erp_file@ with EOPS_FILE (which is updated by OPA), replaces @arc_line@ with the record from the global arc-list GLO_ARC_FILE which corresponds to this session. OPA adds modifier NO_EOP_MOD to the arc-line, what disables eop substitutions for this session. Upon completion the global solution OPA parses spool file, extracts and extracts eop values obtained in this global solution: X pole, Y pole coordinates, UT1, UT1 rate, nutation daily offsets and correlation matrix between these parameters. It creates a records of eop values in EOPB format and inserts it in the global EOPB_FILE file. It sets the first field of this file to blank. This trick allows to distinguish records which corresponds to the experiments. Then OPA launches program eopkal which runs Goddard eop Kalman filter. This program uses EOPB timer series as the input file and produces the output file EOPK_FILE which contains eop with 1-day spacings obtained by using stochastic smoothing. Then OPA launches the second solution global solution. The difference between the first solution and the second is that a) apriori eop substitution file was updated in the first solution; b) arc-line for the second solution doesn't have NO_EOP_MOD modifier and therefore actual apriori eop series used in the second solution are the output series produced in the first solution smoothed by Kalman filter. Upon completion the second solution OPA extracts eop values from the spool file and puts them in EOPB file, then runs eop Kalman filter as it did in the first solution. But then it transforms eop series in EOPB format to the eop series in EOPS format. Since EOPB format is an extension of EOPS format, OPA actually cuts some extra fields and remove @-character from the first position of each record.

5.6   Make EOPI solution for IVS submission

Action to "make EOPI solution for IVS submission" is for updating eop series in for the contribution of this session. It is assumed that a) the observations were made at a single baseline and session duration was 1-2 hours. b) template control file for the EOPI is a valid batch control file except 1. Value of keyword EARTH_ORIENTATION is "@erp_file@" 2. Value ARC_LINE keyword is "@arc_line@" OPA makes a batch solutions in INDEPENDENT mode without input CGM and with superfile for this session. Upon completion the batch solution OPA parses spool file, and extracts all eop values obtained in this global solution, X pole, Y pole coordinates, UT1, UT1 rate, nutation daily offsets and correlation matrix between these parameters, although usually only UT1 is estimated in this type of solution. It creates a records of eop values in EOPB format and inserts it in the global EOPB_FILE file. Then it transforms eop series in EOPB format to the eop series in EOPS format. Since EOPB format is an extension of EOPS format, OPA actually cuts some extra fields and remove @-character from the first position of each record.

5.7   Make Multi-EOP solution for IVS submission

Action to "make Multi-EOP solution for IVS submission" is for updating a special Multi-EOP series for the contribution of this session. If the database contains one baseline, then the Multi-EOP-solutions is the same as the EOPI solution in the preceding section. If the database contains more than one baseline, it is processed more than once and several EOP solution is generated. Thus, more than one value of EOP is generated using the data from the VLBI experiment. First, OPA checks whether the standalone solution was run. If not, it runs the standalone solution. Then OPA examines listing of the standalone solution and extracts the list of the baselines used in the solution. Then it creates the Solve control file that requires to process the database either N_BAS times, if parameter in the configuration file EOPM_ONLY_SINGLE_BASELINE: is TRUE, or N_BAS+1 times if this parameter is FALSE. N_BAS is the number of baselines with the number of used observations equal or grater than NUM_USED_MIN. Parameter NUM_USED_MIN is defined in the configuration file. If EOPM_ONLY_SINGLE_BASELINE is FALSE, then the first time all the data in the experiment are used. Then the database is processed N_BAS times once again, and each time only data from one baseline are used. OPA assumes that a) the observations were made at a single baseline and session duration was 1-2 hours. b) template control file for the EOPI is a valid batch control file except 1. Value of keyword EARTH_ORIENTATION is "@erp_file@" 2. Value ARC_LINE keyword is "@arc_line@" OPA makes a batch solutions in INDEPENDENT mode without input CGM. Upon completion the batch solution OPA parses spool file, and extracts all eop values obtained in this solution, X pole, Y pole coordinates, UT1, UT1 rate, nutation daily offsets and correlation matrix between these parameters, although usually only UT1 is estimated in this type of solution. It creates N_BAS (or N_BAS+1) records of eop values in EOPB format and inserts it in the global EOPT_FILE file. Then it transforms the eop series in the EOPB format to the eop series in the EOPS format. Since the EOPB format is an extension of the EOPS format, OPA actually cuts some extra fields and removes @-character from the first position of each record.

5.8   Make SNR analysis

Action "Make SNR analysis" call program SNRANAL which analyzes measured fringe amplitude, compares it with the scheduled and computes observed SEFD of each participating station and the flux density of each observed source assuming the source structure model defined in the sked catalogue. Results are written in the file SESSION_DIR/<year>/<exp_code>/<exp_code>.snranal where SESSION_DIR is defined in the OPA configuration file.

5.9   Make a standalone solution and keep listings

Action "Make a standalone solution and keep listings" is for making a special solution. OPA takes the the temporary control file STANDALONE_CNT, finds there the fields "@session_dir@", "@erp_file@" and "@arc_line@". These fields are replaced with the values of SESSION_DIR, GEN_INPERP from the configuration file and the record from the global arc-list GLO_ARC_FILE which corresponds to the current session. It is assumed that the keyword SINEX is specified in the template control file according to the specifications of the batch control language and restrictions of the current implementation of Sinex listing generation are taken into account in this control file. Listing of a standalone solution in spool formats is written in SESSION_DIR/<year>/<exp_code>/<exp_code>.spl. The listing in Sinex format is written by Solve. OPA does not control where Solve is written. However, OPA expects to find it in the file SESSION_DIR/<year>/<exp_code>/<exp_code>.snx where SESSION_DIR is specified in the OPA control file. It is assumed that the template file of the standalone solution has the qualifier OUTPUT_FILE of the keyword SINEX in this form: OUTPUT_FILE @session_dir@<YYYY>/<SESSION>/<SESSION>.snx It is important to follow this convention, otherwise OPA will be unable to fulfill the action "Submit the listing in Sinex format to IVS", since it will not find the file.

5.10   Update EOPK time series

Action "Update EOPK time series" launches program eopkal. Program eopkal reads file EOPB_FILE which contains eop estimates in EOPB format obtained in the previous Solve solutions. It performs Goddard EOP Kalman filter and produces the output series with 1 day spacings in EOPK format suitable for using them as solve eop substitution files. The output series are extrapolated within 15 days beyond the date span of the input eop series and are valid for using them by Solve as a priori eop series for processing the 24 hour session with nominal start time up to 7 days after the time tag of the last eop value of the input file. NB: EOPK file is updated as a part of the action "Make EOPS solution for IVS submission", therefore if a user wants to have both eops and eopk fields updated, it is enough to execute ont the action "Make EOPS solution for IVS submission".

5.11   Insert a solution listing into VDB

Action "Insert a solution listing into VDB calls a special progam developed by John Gipson which post-processes the listing of the standalone solution. The name of this program is defined in the configuration parameter VDB_UPDATE_EXE.

5.12   Submit a pair of databases to IVS

Action "Submit a pair of databases to IVS" calls program db_submit. db_submit checks whether two databases for this experiment, with X-band and with S-band, are available in local catalogue system. If they are, then it asks user's confirmation. If user confirms the operation then db_submit compresses the files with the last versions into the specific directory and sends an e-mail to the "user" dserver at the IVS Data Center. This e-mail message activates program dserver which starts retrieving the pair of the databases to the IVS Data Center. User may receive confirmation of the request for databases submission and confirmation of putting the databases in the IVS Data center. Work of db_submit is determined by DBS_CONF control file. Refer to documentation for db_submit and dclient for details.

5.13   Submit EOPS solution to IVS

Action "Submit EOPS solution to IVS" calls program eops_submit. eops_submit checks whether eop file EOPS_FILE exists and then it asks user's confirmation of the submission. If the user confirms the operation eops_submit compressed the file into the specific directory and sends an e-mail to the "user" dserver at the IVS Data Center. This e-mail message activates program dserver which starts retrieving this compressed EOPS file. User may receive a confirmation of the request for the EOPS submission and a confirmation of putting the EOPS file in the IVS Data center. Work of eops_submit is determined by EOS_CONF control file. Refer to documentation for eops_submit and dclient for details.

5.14   Submit EOPI solution to IVS

Action "Submit EOPI solution to IVS" calls program eopi_submit. eopi_submit checks whether eop file EOPI_FILE exists and then it asks user's confirmation of the submission. If the user confirms the operation eopi_submit compressed the file into the specific directory and sends an e-mail to the "user" dserver at the IVS Data Center. This e-mail message activates program dserver which starts retrieving this compressed EOPI file. User may receive a confirmation of the request for the EOPI file submission and a confirmation of putting the EOPI ffile in the IVS Data center. Work of eopi_submit is determined by EOS_CONF control file. Refer to documentation for eopi_submit and dclient for details.

5.15   Submit EOPM solution to IVS

Action "Submit EOPM solution to IVS" calls program eopi_submit. eopi_submit checks whether eop file EOPM_FILE for Multi-EOP solutions exists and then it asks user's confirmation of the submission. If the user confirms the operation eopi_submit compressed the file into the specific directory and sends an e-mail to the "user" dserver at the IVS Data Center. This e-mail message activates program dserver which starts retrieving this compressed EOPM file. User may receive a confirmation of the request for the EOPI file submission and a confirmation of putting the EOPM ffile in the IVS Data center. Work of eopi_submit is determined by EOM_CONF control file. Refer to documentation for eopi_submit and dclient for details.

5.16   Submit Sinex listing to IVS

Action "Submit Sinex listing to IVS" calls program dclient. OPA first checks whether the Sinex listing file exists at the write place and then calls dclient. Dclient checks it again copies to the local ftp directory, gzip's and asks for user's confirmation of the submission. If the user confirms the operation then dclient sends an e-mail to the "user" dserver at the IVS Data Center. This e-mail message activates program dserver which starts retrieving this compressed file with Sinex listing. User may receive a confirmation of the request for the listing submission and a confirmation of putting the listing in the IVS Data center. Work of dclient is determined by SNX_CONF control file. Refer to documentation for dclient for details.

6   Format of Operation Control File

Operational control file keeps the status of processing the experiment. Its name is derived as SESSION_DIR/<year>/<exp_code>/<exp_code>.opc where SESSION_DIR is the directory name defined in OPA configuration file, year is a 4-digits year of the experiment, exp_code is experiment code. For example, if SESSION_DIR is defined as /data10/sessions then the file filename of the operation control file for experiment na389 will be /data10/sessions/2000/na389/na389.opc Operational control file is the ASCII file which consists of lines of variable length. Lines which starts from # character are considered as comments and ignored. The first line is OPC ver. xxxx Updated on ddddddddddddddddddd where xxxx is a four-character version identifier and dddd is a date of creation r update of operational control file. OPA compares version identifier and if it finds that the file has too old version it ignores its contents and creates it anew. Other lines are in the form <keyword:> <value>. Keyword and value are separated by one or more blanks. Keywords corresponds to the fields of the main OPA menu: Keyword Meaning of the value ------------------------------------------------- Experiment: | experiment code Database: | database name Arc_line: | arc-line modifiers Global_arclist_update: | <status-fields><blank><action_field> Superfile: | <status-fields><blank><action_field> Site_weights: | <status-fields><blank><action_field> Baseline_weights: | <status-fields><blank><action_field> EOP_solution: | <status-fields><blank><action_field> Standalone_solution: | <status-fields><blank><action_field> EOPK_series: | <status-fields><blank><action_field> Database_submission: | <status-fields><blank><action_field> EOP_submission: | <status-fields><blank><action_field> SINEX_submission: | <status-fields><blank><action_field> Status-field is a one-character status code, one of "N", "-", "+" or "?", action code is a one-character action code, one of "-", "+", "?", "D" or "N".

6.1   Example

OPC ver. 2.0 Updated on 2002.06.11-15:04:23 # Experiment: r1020 Database: 02MAY20XA Arc_line: ! r1020 # Global_arclist_update: + ? Superfile: + ? Site_weights: + ? Baseline_weights: + ? EOP_solution: N N Standalone_solution: + D EOPK_series: ? ? SNR_analysis: + ? # Database_submission: + D EOP_submission: ? ? SINEX_submission: + D #

7   Format of OPA configuration file

Configuration file contains records of three type: 1) comments: any line which beginning from ## 2) directives for opa: the line which starts from # and which is not a comment line. Directive consists of three or more words separated by one or more blanks. Word1 -- symbol # -- directive attribute Word2 -- keyword Word3,4... value(s) of the keyword Configuration file should contain definition of all keywords and all variables listed in the next subsection.

7.1   Descriptions of directives of OPA configuration file

MASTER_DIR: Directory where master files are stored. When OPA is called with -m switch it puts them in this directory. URL_IVSCONTROL: URL for the root directory in the IVS Data Center the which contains database file. Value should end with letters "ivscontrol/". Since there are several IVS Data Centers user can select the Data Center to which connection is the best. IVS_DB_URL: URL for the root directory in the IVS Data Center the which contains database file. Value should end with letters "db/". Since there are several IVS Data Centers user can select the Data Center to which connection is the best. SESSION_DIR: Directory where subdirectory with operational control files reside. The first level of subdirectories located in SESSION_DIR is <year>, where year is a four-digit year. the second level is the experiment code. BAS_WEIGHT_CNT: Template batch Solve control file for making baseline-dependent weights. SIT_WEIGHT_CNT: Template batch Solve control file for making station-dependent weights. EOPS_CNT: Template batch Solve control file for making EOPS solution. STANDALONE_CNT: Template batch Solve control file for making loose solution with formatting listing in SINEX format. STANDALONE_ID: Identifier of the standalone solution for submitting to the IVS Data center. This 8-character identifier should be provided by the IVS coordinator and kept in the ac-codes.txt file kept in the IVS Data Center. EOPS_CGM: Combined global matrix (cgm) which was produced during eop generic solution and is used as the input cgm for the eops solution. GEN_INPERP: Input apriori eop series which were used for making generic solution. BAS_WEIGHT_FILE: Global baseline-dependent weights file. It is assumed that this file contains baseline-dependent weights for all experiments and OPA updates it upon processing this particular session. SIT_WEIGHT_FILE: Global site-dependent weights file. It is assumed that this file contains site-dependent weights for all experiments and OPA updates it upon processing this particular session. GLO_STA_FILE: Global station coordinates file in Solve substitution format. It is assumed that this file contains positions of all stations and if a new station appears user updates this file. OPA does not write in this file. GLO_SRC_FILE: Global source coordinates file in Solve substitution format. It is assumed that this file contains positions of all sources and if a new source appears (regardless how many used observations it has) user updates this file. OPA does not write in this file. GLO_ARC_FILE: Global file with list of all superfiles names useful for global solutions. Format of the records of this file should conform to the syntax of arc-line of batch Solve control language. arc-line contains database name with leading dollar-character, superfile version the list of modifiers (maybe empty) and comments (may be omitted). OPA may add the record in the global arc-file. SESSION_TYPE: One of DIURNAL or INTENSIVE. Eop_type DIURNAL indicates that duration of this session was about 24 hours and the Earth orientation parameters in EOPS mode should be estimated. INTENSIVE means that it is a single-baseline session of 1.5 hours duration and the Earth orientation parameters in EOPI mode should be estimated. MIN_DURATION: Minimal duration of the session in seconds. OPA will refuse to process the experiment it its nominal duration time is less than this limit. MAX_DURATION: Maximal duration of the session in seconds. OPA will refuse to process the experiment it its nominal duration time exceeds this limit. EOPB_FILE: Name of the eop file in EOPB-format. OPA uses EOPB_FILE as the input file for making EOPS file and EOPK file. OPA adds a record into this file. EOPK_FILE: Name of the eop file in EOPK-format. This is the output format which program eopkal writes and it is the input format for Solve eop substitution file. OPA creates this file when it executes action update EOPK time series and action "make EOPS solution for IVS submission". EOPS_FILE: Name of the eop file in IERS EOPS-format. This the output file of the action "make EOPS solution for IVS submission" or "make EOPI solution for IVS submission". This file is obtained by a simple conversion of EOPB_FILE. EOPT_FILE: Name of the multi-eop file in EOPB-format. OPA addes records in this file when it exectues the action "make EOPS solution for IVS submission". EOPM_FILE: Name of the multi-eop file in EOPS-format. This the output file of the action "Multi-EOP solution for IVS submission" This file is obtained by a simple conversion of EOPT_FILE. NUM_USED_MIN: The mininum number of observations at a given baseline. The action "Multi-EOP solution for IVS submission" processes the database N_BAS or N_BAS+1 times, where N_BAS is the number of baselines which has at least NUM_USED_MIN number of used observations. EOPM_ONLY_SINGLE_BASELINE: flag. May have values TRUE or FALS. If TRUE, then the action "Multi-EOP solution for IVS submission" will process the experiment N_BAS times, each time only for a subset of data at only one baseline. If the flag is FALSE, then in addition to that, OPA will process the experiment the N_BAS+1 'th times with all the data. DBS_CONF: Name of the configuration file for program db_submit, EOS_CONF: Name of the configurations file for submitting EOPS or EOPI file. EOM_CONF: Name of the configurations file for submitting EOPM file. SNX_CONF: Name of the configurations for for program dclient for submitting listing of a standalone solution in Sinex format. SKED_EXE: Full path name to program sked. Sked is not part of Solve but it is used by snranal program. SNR_PLOT: The flag whether snranal should make plots: FALSE or TRUE. (FALSE is recommended) SNR_HIST: The flag whether the snranal should make some histograms: YES or NO. (NO is recommended). TMP_DIR: Name of the temporary directory. SESUPD_LOG: Name of the log file which keeps records of the database name inserted into the global arc-list, data of the insertion and a name of the user who did it. WGET_EXE: Filename with path of program wget. Program wget should be installed before calling OPA.

7.2   Examples of configuration file

Example A: ############################################################################# ## ## ## OPA configuration file for processing 24 hours VLBI experiments in ## ## Goddard Space Flight Center (GSF). ## ## ## ## 20-JUN-2001 14:52:25 ## ## ## ############################################################################# # MASTER_DIR: /tmp/master/ # URL_IVSCONTROL: ftp://cddisa.gsfc.nasa.gov/vlbi/ivscontrol/ # IVS_DB_URL: ftp://cddisa.gsfc.nasa.gov/vlbi/ivsdata/db/ # SESSION_DIR: /data10/sessions/ # BAS_WEIGHT_CNT: /users/pet/temps/temp1/opa_bas_weight_template.cnt # SIT_WEIGHT_CNT: /users/pet/temps/temp1/opa_sit_weight_template.cnt # EOPS_CNT: /users/pet/temps/temp1/eops_template.cnt # STANDALONE_CNT: /users/pet/temps/temp1/standalone_template.cnt # STANDALONE_ID: gsfd0001 # EOPS_CGM: /box1/sol/2002b/2002b.cgm # GEN_INPERP: /box1/sol/2002b/2002b_apr.erp # BAS_WEIGHT_FILE: /data1/save_files/glo_baseline.wgt # SIT_WEIGHT_FILE: /data1/save_files/glo_site.wgt # GLO_STA_FILE: /data1/save_files/glo.sit # GLO_SRC_FILE: /data1/save_files/glo.src # GLO_ARC_FILE: /data1/save_files/glo.arc # SESSION_TYPE: DIURNAL # MIN_DIRATION: 64800 # MAX_DIRATION: 864000 # EOPB_FILE: /tmp/last.eob # EOPK_FILE: /tmp/last.erp # EOPS_FILE: /tmp/last.eops # EOPT_FILE: /tmp/last_multi.eob # EOPM_FILE: /tmp/last_multi.eops # NUM_USED_MIN: 6 # EOPM_ONLY_SINGLE_BASELINE: FALSE # DBS_CONF: /box1/mk4/local/GSFC.dbs # EOS_CONF: /box1/mk4/local/GSFC.eops # EOM_CONF: /box1/mk4/local/GSFC.eops # SNX_CONF: /box1/mk4/local/GSFC.snx # SKED_EXE: /usr/local/bin/sked # SNR_PLOT: FALSE # SNR_HIST: NO # TMP_DIR: /tmp/ # SESUPD_LOG: /data1/save_files/glo_update.log # WGET_EXE: /users/pet/bin/wget #! Example B: ############################################################################# ## ## ## OPA configuration file for processing NEOS Intensive VLBI experiments ## ## in Goddard Space Flight Center (GSF). ## ## ## ## 06-JUN-2002 08:45:31 ## ## ## ############################################################################# # MASTER_DIR: /box1/oper/master/ # URL_IVSCONTROL: ftp://cddisa.gsfc.nasa.gov/vlbi/ivscontrol/ # IVS_DB_URL: ftp://cddisa.gsfc.nasa.gov/vlbi/ivsdata/db/ # SESSION_DIR: /data10/sessions/ # BAS_WEIGHT_CNT: /users/pet/temps/temp1/int_bas_weight_template.cnt # SIT_WEIGHT_CNT: /dev/null/ # EOPS_CNT: /users/pet/temps/temp1/eopi_template.cnt # STANDALONE_CNT: /dev/null/ # EOPS_CGM: /dev/null/ # GEN_INPERP: /data1/save_files/usno_finals.erp # BAS_WEIGHT_FILE: /data1/save_files/int_baseline.wgt # SIT_WEIGHT_FILE: /dev/null/ # GLO_STA_FILE: /box1/sol/2002b/2002b_apr.sit # GLO_SRC_FILE: /box1/sol/2002b/2002b_apr.src # GLO_ARC_FILE: /data1/save_files/int03.arc # SESSION_TYPE: INTENSIVE # MIN_DIRATION: 1000 # MAX_DIRATION: 9000 # EOPB_FILE: /tmp/int_last.eob # EOPK_FILE: /tmp/int_last.erp # EOPS_FILE: /tmp/int_last.eopi # EOPT_FILE: /tmp/last_multi.eob # EOPM_FILE: /tmp/last_multi.eopi # NUM_USED_MIN: 6 # EOPM_ONLY_SINGLE_BASELINE: FALSE # DBS_CONF: /box1/mk4/local/GSFC.dbs # DBM_CONF: /box1/mk4/local/GSFC.dbs # EOS_CONF: /box1/mk4/local/GSFC_eopi_submit.cnf # EOM_CONF: /box1/mk4/local/GSFC_eopm_submit.cnf # SNX_CONF: /box1/mk4/local/GSFC.snx # SKED_EXE: /usr/local/bin/sked # SNR_PLOT: FALSE # SNR_HIST: NO # TMP_DIR: /tmp/ # SESUPD_LOG: /data1/save_files/int_sess_update.log # WGET_EXE: /users/pet/bin/wget #!

8   Before starting

Program wget should be installed before using OPA. Source code of this freeware product can be found in http://www.gnu.org/software/wget/wget.html Directory tree for sessions should be created before starting using OPA. The root session directory is referred as SESSION_DIR in OPA configuration file. The first level of branches at this tree is 4-letters experiment year number. This directory tree should be setup before processing the first session by OPA. The second level is the experiment code. This level of directories is created by OPA during procession experiments. Master files should be retrieved by using -m option of OPA. There is no need to retrieve master files each time, but if OPA complaints that it didn't find the database name in the master file it may be an indication that the copy of master file at your local disk is stale and you should update it. The following steps should be done for tuning OPA for making EOPS solutions: a) To make a good trf/crf solution. This solution will be generic solution. EOPS solutions are considered as an extension of this generic solution. Arc-file, cgm and a priori eop substitution files are saved and later referred to OPA configuration files as GLO_ARC_FILE, CGM_FILE and GEN_INPERP. b) Program getpar is run and the output .eob file is saved. c) .eob file should sorted by program sort_eob. Program sort_eob is not compiled and linked as a part of installation process. In order to compile and link it do the following: cd $MK5_ROOT/utils/opa make -f sort_eob.mak The output file of sort_eob should be saved and referred as EOPB_FILE in OPA configuration file. d) Control file for EOPS solution should be made by transforming control file used for generic solution. Refer to description of the action "make EOPS solution" for details. e) Global station coordinate substitution file and source coordinate substitution files should be created. It should contain coordinates of all stations and positions. Before updating weights file user should first create them by running batch Solve with appropriate control file. In order to be able to submit databases and/or eop series user should first set control files for db_submit end eops_submit and tune these programs.

9   Hints

Some OPA operations cannot be done in an arbitrary order since some actions requires the use of the results of the previous actions. Actions in the main menu are ordered so that they can be called successfully from the action listed at the top towards the actions listed at the bottom. User is able to redo all actions. Results of the current run of OPA replaces the result of the previous runs of OPA. OPA calls batch Solve and it writes the output combined global matrices even if the output cgm is not specified or specified NONE. In the case if it is not enough space to write down the output cgm matrix solve will stop and OPA will terminate abnormally. User should take care and to purge the output cgm matrices. This inconvenience will be eliminated in the future release of Solve. OPA calls db_submit and eops_submit for submitting databases and eop series. These programs create files which are transferred to the IVS Data Center. OPA does not remove them after their submission to the IVS Data Center. User should remove them and to provide enough space in the area where these files reside. OPA doesn't know whether files were retrieved, it knows only that the e-mail message for submission has been sent. One of the possible solutions is to remove files in the submission areas (specified in configuration files for db_submit and eops_submit) which are 7 days old and older. Setting the option in configuration files for eos_submit and db_submit to request confirmation of arriving data to the IVS Data Center helps to figure out whether IVS Data Center successfully handled the request for data submission.

10   History

2000.08.14 L. Petrov Beginning of work. 2000.10.06 L. Petrov Release of the first version. 2000.10.31 L. Petrov Release of the first version of this document 2000.12.04 L. Petrov version 1.1 . Support of the qualifier INTENSIVE of the keyword EOP_TYPE was added. New operations "make EOPI solution for IVS submission" and "Submit EOPI solution to IVS" were added. 2001.05.23 L. Petrov version 1.3 . Forced opa to lift protection for the local copy of master files by setting a protection mask which allows to everyone to read/write these files. This trick prevents failure if a previous user set default mask which prevented for the next user to update this files since he/she does not have write permission. 2002.01.06 L. Petrov version 1.4 . SNRANAL actions is added. 2002.06.06 L. Petrov version 2.0 . Added actions to make a standalone solution and to submit solution listing in Sinex format. Changed format of EOPS/EOPI format according to the IVS Analysis meeting in 2002 in Tsukuba. 2007.09.28 L. Petrov version 2.1 . Added actions a) to make a multi-EOP solution for intenstive VLBI experiments b) to submit multi-EOP solution. Added support of four additional configuration parameters fro this option. c) added 5 new configuration parameters for support of the multi-EOP solutions: # EOPT_FILE: <file_name> # EOPM_FILE: <file_name> # NUM_USED_MIN: <integer_value> # EOPM_ONLY_SINGLE_BASELINE: <true|false> # EOM_CONF: <file_name>



Questions and comments about this guide should be sent to:

Leonid Petrov ( lpetrov@leo.gsfc.nasa.gov )


Last update: 2007.09.28