Disagreement with SWARM satellite coordinate conversion

[gregstarr]

Describe the problem or ask the question
This is quite possibly not a problem with apexpy, but I thought I would ask anyway.

The SWARM satellite dataset (https://swarm-diss.eo.esa.int/#swarm%2FAdvanced%2FPlasma_Data%2F2_Hz_Langmuir_Probe_Extended_Dataset) provides geodetic coordinates for the satellites as well as various magnetic coordinates including "MLat", MLT, quasi-dipole, and AACGM. Here I am mainly concerned with QD because their MLT is calculated using the QD longitudinal difference between the satellite and subsolar point.

The problem is that when I convert their provided geodetic coordinates to QD using apexpy, it doesn't match the provided QD coordinate values.

Here is the documentation for this data:
SW-RN-IRF-GS-005_Extended_LP_Data_Probes.pdf

They say in the documentation that they use the IGRF-12 coefficients, so I'm not sure where the discrepancy is coming from.

Provide an example, if applicable
Steps to reproduce the behavior:

1. open SW_EXTD_EFIC_LP_HM_20191226T000000_20191226T235959_0102.cdf
2. See example code and screenshots:

data = io.open_swarm_file(swarm_data_fn)
converter = apexpy.Apex()
qdlat, qdlon = converter.convert(data['Latitude'], data['Longitude'], 'geo', 'qd', data['Height'])

Screenshots
latitude comparison:

longitude comparison:

Expectations
I expected the QD coordinates to be much closer

Desktop (please complete the following information):

• OS: Windows 10
• apexpy version 1.0.3
• Python version 3.7.9

Additional notes
The height is in km, but I also tried dividing it by 1000 and multiplying it by 1000 and it didn't change much.

[klaundal]

Hi,

This is concerning. I had a look at it, and I'm pretty sure that the QD coordinates provided with the Swarm data are wrong. My calculations agree with yours, and they also agree pretty well with the AACGM coordinates that are provided in the cdf - especially at high latitudes. See attached plot. My preliminary conclusion is that the problem is with the Swarm dataset. I'm sure they would appreciate it if you notify them.

The code to make the plot:

import apexpy
import matplotlib.pyplot as plt
import numpy as np
import cdflib

data = cdflib.CDF('SW_EXTD_EFIC_LP_HM_20191226T000000_20191226T235959_0102.cdf')
time = cdflib.cdfepoch.to_datetime(data.varget('Timestamp'))

a = apexpy.Apex(date = time[0].year)

qdlat, qdlon = a.geo2qd(data.varget('Latitude'), data.varget('Longitude'), data.varget('Height'))

fig, ax = plt.subplots()
ax.plot(qdlat, label = 'apexpy QD latitude')
ax.plot(data.varget('AACGMLat'), label = 'cdf AACGM lat')
ax.plot(data.varget('DipLat'), label = 'cdf QD latitude')
ax.legend(frameon = False)
plt.show()

[gregstarr]

Thanks for looking into this! I will reach out to someone involved with SWARM and will re-convert for my project.

[stephancb]

Sorry for a late input. I don't have an explanation yet for the disagreement, here just some info on our processor:

• Fortran code was downloaded 18-Aug-2015, JGR auxiliary material
• I tinkered the Fortran to keep the coefficients from MKAPXSH in memory instead of file (unlikely to be the problem, but need to check more)
• IGRF coefficients (magfld.f) were updated to IGRF13 in Jan 2020, data before were not reprocessed (I think). So the example 20191226 is probably with IGRF12. A difference in IGRF versions is unlikely to be the problem.
• apxg2all is called with a reference height of 110 km, apxg2all(it.geod.latitude, it.geod.longitude, it.geod.height, 110,...) I'm not sure whether this is good, it could explain the problem.