esa-vires/magneticmodel

Magnetic Model

This repository contains various utilities related to Earth magnetic field modelling and spherical harmonics.

The repository contains following directories:

• eoxmagmod - Collection models of the Earth magnetic field - python module
• qdipole - Quasi-Dipole apex coordinates evaluation - Fortran code compiled as a shared library (dependency of the eoxmagmod package)
• libcdf - CDF library source installation (dependency of the eoxmagmod package)

Installation from Sources

CDF

$ cd libcdf/
$ make build
$ sudo make install

By default, the library gets installed in /usr/local/cdf directory. To install it to a different path override the INSTALLDIR variable:

$ make install INSTALLDIR=<install directory>

QDIPOLE

$ cd qdipole/
$ ./configure
$ make build
$ sudo make install

EOxMagMod

Requires QDIPOLE, CDF libraries + NumPy and SpacePy Python packages to be installed. NumPy and SpacePy can be installed using pip.

$ cd eoxmagmod/
$ python ./setup.py build
$ sudo python ./setup.py install

Conda installation

The package contains the conda-build scripts allowing local conda build and installation following this procedure:

1. build the binary dependencies:

conda install conda-build
conda build ./qdipole
conda build ./libcdf
conda build purge

Tested on GNU/Linux. Possibly works on other POSIX systems. Does not work on MS Windows (primarily because of a missing Fortran compiler).

2. install the eoxmagmod in your conda environment:

conda activate <target-environment>
conda install --use-local qdipole cdf
conda install numpy scipy matplotlib h5py networkx
conda install gcc_linux-64           # spacepy and eoxmagmod require C compiler
conda install gfortran_linux-64      # spacepy requires Fortran compiler
conda deactivate
conda activate <target-environment>  # re-activation is required to update the environment variables
pip install spacepy
pip install ./eoxmagmod

The gfortran_linux-64 andgcc_linux-64 compilers work on a x86_64 GNU/Linux system. Other platforms might provide different compilers.

magneticmodel's Issues

Possibly incorrect Magnetic Local Time after 2015-01-01T00:00:00Z.

When running the the quasi dipole coordinates evaluation for dates after following warning message appears:

COFRM:  DATE 2015.139 is after the last recommended for extrapolation (2015.0)

The message is generated from the Fortran code and it is only visible when running the evaluation in console.

The error is produced by the COFRM subroutine (line 780, appex.f90). This subroutine contains embedded IGRF model coefficients whose validity ends by 2015-01-01T00:00:00Z.

The extrapolation after this date gives likely incorrect results.
The criticality of this issue ("How much incorrect the results are?") needs to be assessed.

NASA CDF library checksum changed causing conda build to halt

MagneticModel/libcdf/meta.yaml

Line 14 in 377d01f

sha256: aceb1263f1a1bf76e4adefc3a79bbe7d725e590b0938ab440bb3a64fe2f1417b

During the conda build:

 SHA256 mismatch: 'f5d7c2774d017cbb6f70d53a3b12149a52ace4fb089c1ed4ecd352aa6dca27b8' != 'aceb1263f1a1bf76e4adefc3a79bbe7d725e590b0938ab440bb3a64fe2f1417b'

It looks like https://spdf.gsfc.nasa.gov/pub/software/cdf/dist/cdf38_0/unix/cdf38_0-dist-cdf.tar.gz changed at 2020-08-28 14:52

QD-coordinates and MLT validation

Validate QD-coodinates and MLT calculation and compare with an alternative implementation.

QD-coords still calculated by the updated apex cooeficients.

Apparently the calculation of the QD coordinates is still using the old, now outdated, apex coefficients

MagneticModel/eoxmagmod/eoxmagmod/data/__init__.py

Lines 54 to 56 in 3264b9a

	APEX_2015 = join(_DIRNAME, 'apexsh_1995-2015.txt')
	APEX_2020 = join(_DIRNAME, 'apexsh_1980-2020.txt')
	APEX = APEX_2020

MagneticModel/eoxmagmod/eoxmagmod/quasi_dipole_coordinates.py

Lines 31 to 34 in 3264b9a

	from .data import APEX
	def eval_qdlatlon(gclat, gclon, gcrad, time, fname=APEX):

The deviation is not very large (angular distance < 1°) though.

Discard

Wrong MLT values.

The inspection of the calculated Magnetic Local Time (MLT) values revealed that these values are not correlated to the time of day but rather incorrectly to the fraction of year.

This bug was traced to the original QD Fortran code (make_apex subroutine) where a decimal year values is incorrectly used instead of a Modified Julian Date (MJD) value.

Higher order spline interpolation of the spherical harmonic coefficients.

Some of the magnetic models (e.g.,CHAOS-6-Core) require higher order spline interpolation of the spherical harmonic coefficients.

The magnetic model uses always linear interpolation of the coefficients which leads to small deviation from the right model values.

wrong decimal year conversions

It seems that the decimal year conversion used by the magnetic model (and VirES in general) is wrong.

VirES converts the decimal year so that the whole year value is always aligned with 00:00Z, 1st of January. This seems to be incorrect [scientific decimal time] and the conversion should be made as

MJD2000 = (decimal_year - 2000) * 365.25
decimal_year = 2000 + MJD2000 / 365.25

The small time offset in the decimal year time causes deviation of the calculated model values when compared with the reference implementation. E.g., for CHAOS-6-Core (x7):

After correcting the time conversions this deviation drops to zero: