Bernese.gif Bernese GNSS Software
AIUB ¦ CODE ¦ IGS

[ Introduction ] [ General ] [ Installation ] [ Messages ] [ BPE ] [ Examples ] [ AIUB's FTP site ] [ Programs ]



Introduction


With version 5.4 we will publish answers to questions from users to the Bernese user support on this web page if we have the feeling that the question is of a wider interest (of course fully anonymous with respect to the person who has sent the question).

We hope that we can establish in this way a collection of frequently asked questions (FAQ) providing brief answers to many common questions with respect to using the Bernese GNSS Software (e.g., error messages during processing, warnings, etc.).

Please, check this FAQ for answers before sending your question by e-mail to the support.



General questions


Questions concerning the installation/update procedure


Questions concerning messages issued by the software


Questions concerning BPE


Questions concerning distributed processing examples


Questions concerning file on the AIUB's ftp site


Questions concerning processing programs











Is there a trial version of the Bernese GNSS Software available?


No. Even if we try to keep the software as user friendly as possible, the Bernese GNSS Software remains a high-end product. We believe that it is not possible to obtain optimal results simply in a "trial and error" mode (apart from the option that you spend a lot of time in studying the complete documentation).
We recommend to all potential customers who are not sure whether the software fits their needs to attend the introductory course. Here you will learn how to use the software and get some theoretical background information. You have the opportunity to use the software for standard applications with the personal support of our experts.
If you decide to buy the software after participating in a course the price for the package will of course be reduced by the course fee.










What should we consider if we setup a new computer to use the Bernese GNSS Software?


A computer with a big disk to host your GNSS data is important. At least for the location of the processing campaigns a quick access to the disk is essential for the performance.
If you do not have access to a cluster of computers you should consider a multi-core machine because the number of cores gives the number of jobs you can run in parallel in the BPE. Of course, if you are in a Unix/Linux cluster environment you can increase the number by including other computing nodes. Here a quick network connection to the location of the data is beneficial.
In general a 64-bit architecture is preferable compared to a 32-bit architecture if a proper compiler is available. For Windows systems we distribute 64-bit executables.










Are there any differences between the Windows and Unix/Linux version of the Bernese GNSS Software? What system do you recommend?


The source code, the provided scripts and the examples are identical for Windows and Unix/Linux.
For Windows platforms, a set of executables for the programs as well as the GUI is provided, whereas for Unix/Linux (or Mac) these must be compiled by the user. Note that you will get the full source code regardless of which system you have chosen.
Concerning the BPE (which e.g. allows execution of individual jobs on remote CPUs) the Bernese GNSS Software is currently better prepared to use this feature under Linux, than under Windows.
Strictly technically spoken, this is, however, also possible on Windows platforms. Out of the box, the BPE under windows executes all jobs locally.










Windows: If I click on the "Bernese 5.4" icon on my desktop the menu is not launched.


Check first whether all setup wizards have been installed. You should find, apart from the "Bernese 5.4" icon/shorcut, also the "GPSUSER54", "CAMPAIGN54", "DATAPOOL", and "SAVEDISK" ones. If not, this is an indication that you did not run all the setup wizards.
If all icons are available, you should check the "User Variables" for your account to control that the Bernese-specific variables are defined. You have to remember that the setup wizard establishes these variables only for the currently active user. If the wizards have been executed by the "administrator" (instead of the user that shall use the Bernese GNSS Software), the variables are not listed in your "User Variables" area. Please inspect the README_INSTALL.TXT file (either in the BERN54\SUPGUI\DOC directory or on your installation CD-ROM) for instructions on how to proceed: either reinstall the software for your account or establish a multi-user environment.










After compilation, I find two directories with executables (e.g. EXE_GNU and EXE_GNUc) with different sizes of the executables. What is the purpose, and which of them should I use?


The The Makefile.template in $(EXE) is prepared to run two compilations: a speed-optimized (creating the executables in the directory EXE_${F_VERS} and a debugging version (in the directory EXE_${F_VERS}c ). If the environment variable ${F_DEBUG} is blank or set to YES, both versions are created. If you set ${F_DEBUG} to NO, only the speed optimzed versions are created. The debug executables run slower, but contain more debug output, which might be helpful in case of problems. Pay attention that the variable ${XG} is set to the directory containing the executables you actually want to use.










I get the message "### Executable CRX2RNX is missing" even though the compilation went without problems. What can I do?


The CRX2RNX and the RNX2CRX programs are external programs to Hatanaka decompress/compress RINEX files. Please see the README_INSTALL file to find out where to obtain the source and the executables of these programs. The executables must be placed in a directory which is listed in your PATH environment variable, so they can be called from anywhere without having to specify the path.










UNIX:The menu is not created and I find the message "/usr/bin/ld: .obj/release/menutils.o: undefined reference to symbol uncompress " in the MENUCOMP.log file. How can I solve this?


You can edit the file ${C}/MENU/menu.pro and deactivate the line 46 by adding a # at the beginning
#QMAKE_LIBS += -lz
Then you can recompile the menu. If the error persists, please contact us for support, providing the MENUCOMP.log file.












Cannot open INP file ${P}/EXAMPLE/GEN/SESSIONS.SES


The message indicates that the session table is not available. Potential reasons are:

  1. The campaign directory tree has not been created yet. Use "Menu >Campaign >Create new campaign" to establish the campaign directory tree (which will contain a default session table).
  2. The campaign was not selected. Select the active campaign with your session table using "Menu >Campaign >Select active campaign".
  3. The session table in the actual campaign has a different name than in your previous one. Use dialogue "Menu >Configure >Set session/compute date" to define the name of the session table.









SATELLITE NOT FOUND


Very likely the used satellite file is not up-to-date. Download the current satellite information file (SATELLIT_xxx.SAT) and the satellite problem file (SAT_xxxx.CRX) from our ftp site.










NEQCKDIM: DIMENSION TOO SMALL


The expected dimension of the input or resulting combined normal equation as specified in the input option "Maximum number of parameters in combined NEQ" in panel "ADDNEQ2 3.1: Options 1" is too small. The number must be adjusted to the size of the normal equations.










GETPOL: NO SUITABLE EPOCHS IN POLE FILE


The reason of this error message is probably that a wrong pole file was selected or that the selected pole file does not fully cover the interval of the standard orbit in the processing. Note that the epochs in the pole files are interpolated while the requested epochs may also be outside the interval of the processed data. If a proper pole file is selected it should work as usual.
It can also happen that you have specified an unintended time interval for your processing or for the orbit generation, so please check also this aspect.










OPNERR: OPEN FAILED (${MODEL}/DE421.EPH)


The reason is a missing DE421.EPH ephemeris file in your ${CONFIG} (%CONFIG% on Windows) directory. The DE421-ephemerides are needed to run the examples of Bernese GNSS Software Version 5.4. README_JPL_EPH.TXT in ${DOC} (%DOC% on Windows) gives detailed instructions on how to generate a new ephemeris file.










JEPEPH: Error return from call to JESTAT "Epoch out of range"


This error message indicates that the ephemeris file DE421.EPH in ${CONFIG} does not contain data for the requested epoch. README_JPL_EPH.TXT in ${DOC} (%DOC% on Windows) gives detailed instructions on how to generate a new ephemeris file. In order to expand the validity of the ephemeris file, you will have to get the appropriate ascii-data file from JPL, covering the period of the requested epoch.










READSIN: SOLUTION/STATISTICS Block incomplete for SINEX file


The VARIANCE FACTOR value in your SINEX file is too big. It is expected that the value is within the range of 0.1 and 10. It indicates that something is going wrong in the solution creation.










CKOPTL: A character string is expected for keyword "AGENCY"


An empty string is not allowed for input option "Agency running program" in a RINEX utility. Enter the name of the agency/institution creating the RINEX files for this option. This information then will be included in the header of each RINEX file.










HELMTR: TOO MANY PARAMETERS TO ESTIMATE
NUMBER OF PARAMETERS: 3
NUMBER OF STATIONS: 0


For standard regional GNSS network analysis at least one reference station (with known ITRF coordinates) is needed. Either add further observation files of such stations to your analysis or adjust your FIX/CRD file accordingly.
The output can also result from the "outlier rejection" procedure implemented in the HELMR1 program: if one of the stations has an exceptionally wrong coordinate, the residuals for all stations may exceed the thresholds specified in panel "HELMR1 3: Outlier Rejection". Typically this station can easily be identified by inspecting the program output. Exclude the station from the datum definition and rerun the program on the remaining sites.










CHKMAX: Dimension for parameter "MAXzzz" exceeded
CHKMAX: Unusual big number of parameter "MAXzzz" detected


The dimensions of the main arrays are adjusted from the input files and input options. This way, the memory used by the program during the run-time is reduced to a minimum.
The size of most of the arrays is critical in terms of amount of memory needed by the program for execution. Therefore, the adjusted values are limited by built-in default settings (file ${I}/P_GPSEST.f90 or ${I}/M_MAXDIM.f90 in BSW 5.2, in BSW 5.4 located in ${LG}) to avoid unintentional program runs (e.g., with a huge number of epoch parameters if those were not pre-eliminated epoch-wise).
If these limits are exceeded, a message is issued. Up to a value of two times of the built-in limit the corresponding program run is executed (the message shall indicate that it is an extreme run which will need an exceptional amount of resources regarding memory and/or computing time). If the value exceeds the hard limit of two times of the built-in default setting the program will stop, assuming that the program run is not useful anymore. You should review your program settings carefully and, if necessary, you may split the network into clusters.










GETSTAF: COORDINATES NOT FOUND


The reason for this message is very likely that the renaming of the stations in the station information file (.STA) was missed by RXOBV3 or the RINEX header does not fit in the search pattern of the STA file. Because as the corresponding station is used in your observation file, it needs also be added to the .CRD, .KIN and .STA files.










ARSTR3: RECEIVER TYPE COULD NOT BE ASSIGNED TO A RECEIVER GROUP


The reason for this error message is the fact that teh receiver type is not known to the ambiguity resolution subroutine ARSTR3. Depending on the receiver architecture, ambiguity resolution may be done differently. The predefined receiver types are given in the suboutine 

$LG/ARSTR3.f
Here, you find some definitions: 
C GENERAL DEFINITION OF VARIOUS RECEIVER GROUPS:
                  IF (RECSTR(I)(1:3).EQ.'ASH') RECSTR(I)='@TRI'
                  IF (RECSTR(I)(1:3).EQ.'CHC') RECSTR(I)='@CHC'
                  IF (RECSTR(I)(1:3).EQ.'JAV') RECSTR(I)='@JNS'
                  IF (RECSTR(I)(1:3).EQ.'JPS') RECSTR(I)='@JNS'
                  IF (RECSTR(I)(1:3).EQ.'LEI') RECSTR(I)='@LEI'
                  ...
Because your receiver type is not listed here, you get the error message.
You have the possibility to either change the receiver name in the original RINEX file (and/or the station information file) to a name which at least correspond to the first three characters of an already defined receiver type in the group table. Then, restart the processing from the beginning. If that is not an option, you may add your receiver type to the subroutine. Please add a new line.
If you know that your receiver uses the receiver technology similiar to a Leica receiver, then please assign it to '@LEI'.
If you know that your receiver uses the receiver technology similiar to a Trimble receiver, then please assign it to '@TRI'.
If you are not sure, you can assign it to a new receiver group (with identical three characters after the '@' (as e.g. 'CHC').
A wrong assignment may result in a degraded or wrong ambiguity fixing. To activate your changes you have to recompile the software: 'CBERN GPSEST' ('perl %EXE%\cbern.pl GPSEST' on Windows).












UNIX: we cannot launch BPE scripts in our queuing system because it does not accept Perl scripts. It requires sh-scripts.


To run a BPE from the menu you only need to replace RUNBPE.pm by RUNBPE.sh as the Client script in the first panel of menu >BPE >Start BPE processing. The RUNBPE.sh is also located in the ${BPE}-directory and simply starts RUNBPE.pm as a Perl script with all arguments.
If you want to run BPEs within scripts using the ${BPE}/startBPE.pm module, you need to replace 

$$self{BPE_CLIENT} = '${BPE}/RUNBPE.pm';

by 

$$self{BPE_CLIENT} = '${BPE}/RUNBPE.sh';

in the startBPE::_init method.










Parallel running programs crash from time to time or produce incomplete program output files. The log-file (BPE/{TASKID}yyssss_{PID}_{SUBPID}.LOG) contains a message like: 

LOGFILE_HEADER
lockFile: file
.../OUT/GPSEST.J cannot be locked
What can I do?


The default name of the program output file follows the structure GPSEST.Lxx, where xx is a counter managed by the file GPSEST.J (in the OUT-directory of the campaign). To allow several program runs in parallel a locking mechanism is needed for the file GPSEST.J, which is realized by a special lock file GPSEST.J_lk
If the lock file cannot be released for any reason all parallel running GPSEST will use the same program output in the file GPSEST.XXX which can cause one or more of the parallel running programs to crash.
To reset the file locking mechanism you can remove all *.J_lk files in the OUT-directory in your campaign. It is furthermore recommended not to use the default filename in parallel running BPE scripts to prevent this situation.










Windows and Unix: The BPE starts, but does not finish the first PID of my PCF. No error message is issued, no PRT or LOG files are in the campaign BPE directory. How can I fix this?


This is usually an indication that perl is not available on your system, or it is not correctly installed. Type perl -v on the console, and you should get a version information of the perl available. If not, then please install perl on your system (windows users: get perl for free from activestate).












How can I use Vienna Mapping Function (VMF1 or VMF3) for the data processing?


In the configuration of the processing examples the Global Mapping Function (GMF) is selected. For technical reasons there is no variable in the PCFiles available to select the troposphere model.

Nevertheless you might be interested to change the troposphere model in the program options. General information on how to use the VMF with the Bernese GNSS Software is given in the ${HLP}/README_VMF.html file (accessible via menu >Help >Readme: VMF correction from TU Vienna).

To include the VMF corrections to the processing examples you have to:

  1. Download the VMF grid files from the TU Vienna server to your DATAPOOL area.
  2. Modify the copy script of your BPE (PPP_COP, R2S_COP, and/or CLK_COP in ${U}/SCRIPT directory depending in which of the BPEs you want to use the VMF) to copy the grid files from the datapool into your processing campaign.
    You need five files to cover a full day. For an hourly processing scheme you have to select the grid files according to your cmenu >current session and the number of hourly included in the processing (BPE variables V_HOURLY).
  3. Because the access to the grid files needs some computing resources we recommend to run the pre-processing steps still on GMF. You have to modify the GPSEST input files in the BPE option directories of the following BPE scripts using menu >BPE >Edit PCF program input files:
    PPP.PCF 322 TIMEST_P PPP_FIN
    523 TIMEST_P PPP_KIN
    543 TIMEST_P PPP_TRP
    RNX2SNX.PCF 502 GPSCLU_P R2S_FIN
    CLKEST.PCF 502 TIMEST_P CLK_RES
    In the corresponding program input panels for GPSEST you have to
    • add the file name of the "Gridded VMF coefficients" in panel GPSEST 1.1
    • select DRY_VMF2 for the "ZPD model and mapping function" in panel GPSEST 3.2
    • select WET_VMF2 for the "Mapping function" in panel GPSEST 6.1.1
  4. If you introduce a solution troposphere file via BPE variable V_FIXTRP to the clock estimation example (CLKDET.PCF) that was generated using VMF troposphere corrections you have to include the "Gridded VMF coefficients" in panel GPSEST 1 to all GPSEST runs where this file is introduced:
    CLKEST.PCF 412 TIMEST_P CLK_ED0
    452 TIMEST_P CLK_EDT
    502 TIMEST_P CLK_RES

Important remark for operational processing:
The use of the VMF requires external gridded information from TU Vienna. In general these files are available in time. In case of an outage of this external data source or if your download of the gridded information fails for any reason your processing will stop with an error.










Why satellites with accuracy code 0 are excluded in ORBGEN?


The accuracy code 0 used in the SP3 files indicate satellites with less than three contributing analysis centers. Due to several changes it may happen that uncertain orbits from unhealthy satellites obtained from one-day arcs may by included (in particular marginally observed unhealthy satellites benefit from multi-day arcs).

To get complete orbits for all active GNSS satellites, you should, e.g., use the CODE orbit products.










How can I reconfigure the example BPEs to process data in IGS20/ITRF20?


Model and Configuration changes in the CODE products since the switch to IGS20/ITRF20 can be found in the BSWmail 393, where also changes in naming conventions of product files are described.
A detailed table with necessary changes in the Example PCFs to process data (not only the example data) in IGS20/ITRF20 is available here: Table Example BPEs.












There is no entry for a specific antenna/radome combination in the phase center correction file ANTENNA_Ixx.PCV in the BSWUSER54/REF directory of our ftp site.


The IGSxx.ATX in its latest version contains only antennas that are used within the IGS network. For our processing in the frame of the IGS and EPN we at CODE extract those antennas that we are using for our processing according to our network configuration. This extraction results in the file ANTENNA_Ixx.PCV that is posted to out ftp site.
This file is only intended as a basis for your processing and must be extended using the program ATX2PCV of the software by further antenna phase center corrections from IGSxx.ATX or from other sources. The basis for the included antenna/radome combinations and GNSS-related corrections is the station information file you are specifiying in ATX2PCV.












What is the meaning of *MARK* in program SATMRK?


"Marking" of observations means that a flag is added to the observation file. The processing programs do not use these flagged measurements. With a pre-processing program (like MAUPRP) such flags can also be removed again and the observation may become valid again. In contrast, the "ELIMINATE" option removes the data from the observation files and cannot be recovered.


 

















 


















Quick Links

Version 5.2
 
 
 

Page maintained by Pierre Fridez - Last update: 21-Feb-2024 11:58:32 CET