GAMIT/GLOBK Known Issues

Here we present a list of known issues with GAMIT/GLOBK, in general and due to problems on Ubuntu, Debian, openSUSE and Fedora Linux operating systems and macOS.

General

• When processing data from 2025 and beyond using higher order ionospheric terms (i.e. Ion model = GMAP in sestbl.), one may see a processing error such as:
  
  STATUS :250106:1020:13.0 MODEL/model: Begin processing
  ***** Error *****
  DATE = 2025.008 - out of range
  
  Solution: Update the source code to include the latest IGRF magnetic field model by downloading and compiling GAMIT/GLOBK 10.71 with the 20250106 or more recent incremental updates, then set Mag field = IGRF14 in sestbl. Alternatively, switch off higher order ionospheric terms by setting Ion model = NONE but beware of differences with previous processing strategies.


• Recent versions of curl, using OpenSSL version 3, will not connect to the CDDIS server to download data and products, resulting in failed processing runs due to missing files. This appears to be a server-side (CDDIS) issue.
  
  Solution: The ultimate solution appears to be for CDDIS to upgrade their server's security protocols, over which we have no control. In the meantime, a change of the client-side (local) OpenSSL (version 3) settings described here circumvents the recent security updates. CDDIS's own recommendation of adding a --ciphers DEFAULT@SECLEVEL=1 option (e.g. Question 17 at their Archive Download FAQ web page) does not appear to work for this issue.


• Recent versions of gfortran (10 and greater) require the addition of a compiler option which is not valid in prior versions. If using gfortran 10 and greater without this addition, one may see a compilation error such as:
  
  gfortran -c -O3 -Wuninitialized -fno-f2c -ffast-math -fno-automatic -fno-backslash -m64 -mcmodel=large lread.f
  lread.f:616:53:
  
  616 | call read_line( line,indx,'I4',ioerr,idate(i),string )
  |
  ......
  718 | call read_line( line,indx,'CH',ioerr,rvalue,string )
  | 2
  Error: Type mismatch between actual argument at (1) and actual argument at (2) (INTEGER(4)/REAL(8)).
  lread.f:634:53:
  
  634 | call read_line( line,indx,'I4',ioerr,idate(i),string )
  | 1
  ......
  718 | call read_line( line,indx,'CH',ioerr,rvalue,string )
  | 2
  Error: Type mismatch between actual argument at (1) and actual argument at (2) (INTEGER(4)/REAL(8)).
  make: *** [Makefile:325: gamit_lib.a(lread.o)] Error 1
  Failure in make_gamit -- install_software terminated
  
  Solution: When using gfortran 10 or greater, uncomment the definition of "FFLAGS" in libraries/Makefile.config and gamit/solve/Makefile.generic that includes the -fallow-argument-mismatch option in the current version of those files, or add the -fallow-argument-mismatch option to "FFLAGS" in prior versions of those files, then recompile.


• We sometimes see basic numerical problems in scripts due to local computer settings regarding language and handling of numbers (the "locale" setting), specifically for languages that use a comma rather than a dot as the decimal separator. For example, when running sh_link_rinex, either directly or through sh_gamit, one might see an output line like
  Looking for rinex files which have data between: 2018/04/05 0:00 and 2018/04/05 0:00 and have a minimum span of 0.1 hrs
  which suggests that sh_link_rinex is not properly adding 24 hours to the start time of the session (the first and last epochs are the same).
  
  Solution: Set a separate environment variable for numbers (LC_NUMERIC) to "C", e.g. for sh/bash shells (in ~/.bashrc, ~/.profile or ~/.bash_profile):
  LC_NUMERIC='C'; export LC_NUMERIC
  or for csh/tcsh shells (in ~/.cshrc or ~/.tcshrc):
  setenv LC_NUMERIC 'C'
  See the note about this in the fifth paragraph of the top-level README file (/updates/README on our chandler FTP server).


• When compiling GLOBK, the programs tssum and tsfit fail to compile with errors such as:
  ./tslib.a(tsutil.o): In function `tsread_eqfile_':
  tsutil.f:(.text+0x14fe): relocation truncated to fit: R_X86_64_32S against symbol `tf_ch_' defined in COMMON section in ./tslib.a(tsutil.o)
  etc.
  
  With the GNSS implementations in GAMIT/GLOBK, and general growth of networks and the amount of data available, many programs have grown in size. The tssum/tsfit/tscomp programs need 7 GB of memory so that they can handle decades of time series with the thousands of stations that are now available.
  
  Solution: You will need a 64-bit machine with several GB of RAM. Otherwise edit the include file ~/gg/kf/blsum/tssum.h to reduce the maximum sizes of arrays (e.g. "max_ent") to one of the previous values in the comments, then recompile GLOBK.

Ubuntu

• We have had several reports from users that the installation process fails, immediately after compiling the SOFA libraries, with an error similar to the following:
  
  ar: creating libsofa.a
  
  *** Now type 'make test' to install the library and run tests ***
  
  cp libsofa.a ../../../../libsofa.a
  Segmentation fault (core dumped)
  Failure in make_gamit -- install_software terminated
  
  We are able to recreate this error ourselves, with multiple different versions of the gcc/gfortran compilers available on Ubuntu 24.04, but we do not yet understand why the error is occurring.
  
  Solution: Do not use GAMIT/GLOBK on Ubuntu 24.04 because this issue appears to be specific to that version of Ubuntu. Use a previous release of Ubuntu, e.g. 22.04, or upgrade to 24.10.


• The inclusion of the "-mcmodel=large" option for gfortran (see libraries/Makefile.config) since GAMIT/GLOBK 10.70 appears to cause compilation to fail when using gfortran version 7. However, this option is required to build the large arrays used nowadays in GAMIT/GLOBK.
  
  Solution: Change to another version of gfortran, e.g. 4, 5, 6 or 8, which do not appear to cause this compilation error, e.g. sudo apt install gfortran-8, then define the Fortran compiler correspondingly in libraries/Makefile.config, e.g. FTN = gfortran-8, in the appropriate OS block and re-run install_software.


• The GMT 5 installation available through the Ubuntu repository for Ubuntu 16.04 is incomplete. See GMT installation guide for more information. Importantly, "psvelo" is missing and therefore sh_plotvel and other scripts that plot vectors do not produce results as expected.
  
  Solution: Upgrade to another version of the Ubuntu operating system or build GMT from source.

Debian

• The GMT 5 installation available through the Debian repository for Debian 9 is incomplete. See GMT installation guide for more information. Importantly, "psvelo" is missing and therefore sh_plotvel and other scripts that plot vectors do not produce results as expected.
  
  Solution: Upgrade to another version of the Ubuntu operating system or build GMT from source.

openSUSE

• The inclusion of the "-mcmodel=large" option for gfortran (see libraries/Makefile.config) since GAMIT/GLOBK 10.70 appears to cause compilation to fail when using gfortran version 7. However, this option is required to build the large arrays used nowadays in GAMIT/GLOBK.
  
  Solution: Change to another version of gfortran, e.g. 4, 5, 6 or 8, which do not appear to cause this compilation error, e.g. sudo zypper install gfortran-8, then define the Fortran compiler correspondingly in libraries/Makefile.config, e.g. FTN = gfortran-8, in the appropriate OS block and re-run install_software.

Fedora

• The inclusion of the "-mcmodel=large" option for gfortran (see libraries/Makefile.config) since GAMIT/GLOBK 10.70 appears to cause compilation to fail when using gfortran version 7. However, this option is required to build the large arrays used nowadays in GAMIT/GLOBK.
  
  Solution: Change to another version of gfortran, e.g. 4, 5, 6 or 8, which do not appear to cause this compilation error, e.g. sudo yum install gfortran-8, then define the Fortran compiler correspondingly in libraries/Makefile.config, e.g. FTN = gfortran-8, in the appropriate OS block and re-run install_software.

macOS

• Using macOS 12 (Monterey) on a Mac with an Intel processor results in files not being written completely unless an explicit "close" statement is included in the Fortran source, which is not always the case in GAMIT/GLOBK (and many other codes), or when redirecting standard output and error. This discussion forum suggests that this appears to be due to a problem with the operating system, not gfortran, so the same issue may also arise when using other Fortran compilers.
  
  Solution: Set the environment variable "GFORTRAN_UNBUFFERED_ALL" to "1". For example, if using sh, bash or zsh, add the following lines to ~/.bashrc (or ~/.bash_profile on Mac) for sh or bash, or to ~/.zshenv for zsh:
  GFORTRAN_UNBUFFERED_ALL=1; export GFORTRAN_UNBUFFERED_ALL
  Or, if using csh or tcsh, add the following lines to ~/.cshrc:
  setenv GFORTRAN_UNBUFFERED_ALL 1


• The transition to Apple Silicon ("AArch64" architecture) from Intel ("x86_64" architecture) processors currently means that several GLOBK programs (kf/blsum/tscomp.f, kf/blsum/tscon.f, kf/blsum/tsfit.f, kf/blsum/tssum.f, kf/svpos/svsp3.f, kf/svpos/modear.f and kf/track/track.f) cannot be compiled on the newer M1 chips, resulting in an failed installation. We are not sure of the exact reason but it appears to be associated with the memory required by some libraries and these executables being larger than 4 GB, which is reported to be the maximum allowed (currently) using gfortran and the native Command Line Tools for Xcode. We anticipate that these issues will become resolved once further development and debugging of gfortran and the Command Line Tools is undertaken and completed. Our recommendation for a near-complete installation of GAMIT/GLOBK, as of the last update of this web page, is described below.
  
  Solution: First, install and use the latest version of gfortran 12 available from the gfortran maintainers through the GCC Wiki. Edit kf/blsum/tssum.h to reduce the size of the resulting libraries and executables, e.g. near the top of the file change
  parameter ( max_ent = 40000000 )
  to
  parameter ( max_ent = 22571599 )
  or a smaller number if this still does not work (this is the largest number of time series entries found to be successful during compilation in testing on the M1 MacBook Pro we have available). This solves the compilation issues with kf/blsum/{tscomp,tscon,tsfit,tssum}.f. Then edit kf/track/Makefile.generic to prevent the track executable from being compiled (it will not be available to run as a result), e.g. change
  #LABELS: track:track:NONE:track
  to
  # LABELS: track:track:NONE:track
  Also edit kf/svpos/Makefile.generic to prevent the svsp3 and modear executables from being compiled (they will also not be available to run as a result), e.g. change
  #LABELS: svsp3:svsp3:NONE:svsp3
  #LABELS: modear:modear:modear_lib:modear
  to
  # LABELS: svsp3:svsp3:NONE:svsp3
  # LABELS: modear:modear:modear_lib:modear
  Finally compile GAMIT/GLOBK using com/install_software, or GLOBK only using com/make_globk, as normal.