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.
- Is there a trial version of the Bernese GNSS Software available?
- What should we consider if we setup a new computer to use the Bernese GNSS Software?
- Are there any differences between the Windows and Unix/Linux version of the Bernese GNSS Software? What system do you recommend?
Questions concerning the installation/update procedure
- Windows: If I click on the "Bernese 5.4" icon on my desktop the menu is not launched.
- 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?
- I get the message "### Executable CRX2RNX is missing" even though the compilation went without problems. What can I do?
- 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?
Questions concerning messages issued by the software
- Cannot open INP file ${P}/EXAMPLE/GEN/SESSIONS.SES
- SATELLITE NOT FOUND
- NEQCKDIM: DIMENSION TOO SMALL
- GETPOL: NO SUITABLE EPOCHS IN POLE FILE
- OPNERR: OPEN FAILED (${MODEL}/DE421.EPH)
- JEPEPH: Error return from call to JESTAT "Epoch out of range"
- READSIN: SOLUTION/STATISTICS Block incomplete for SINEX file
- CKOPTL: A character string is expected for keyword "AGENCY"
- HELMTR: TOO MANY PARAMETERS TO ESTIMATE
NUMBER OF PARAMETERS: 3
NUMBER OF STATIONS: 0 - CHKMAX: Dimension for parameter "MAXzzz" exceeded
CHKMAX: Unusual big number of parameter "MAXzzz" detected - GETSTAF: COORDINATES NOT FOUND
- ARSTR3: RECEIVER TYPE COULD NOT BE ASSIGNED TO A RECEIVER GROUP
- UNIX: we cannot launch BPE scripts in our queuing system because it does not accept Perl scripts. It requires sh-scripts.
- 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? - 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?
Questions concerning distributed processing examples
- How can I use Vienna Mapping Function (VMF1 or VMF3) for the data processing?
- Why satellites with accuracy code 0 are excluded in ORBGEN?
- How can I reconfigure the example BPEs to process data in IGS20/ITRF20?
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:
- 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).
- The campaign was not selected. Select the active campaign with your session table using "Menu >Campaign >Select active campaign".
- 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.
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.
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.fHere, 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:
- Download the VMF grid files from the TU Vienna server to your DATAPOOL area.
- 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). - 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 - 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
- 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.