Longitude and altitude swapped

[mauro835]

The signature of pygtd7d in msis00f.py is

def pygtd7d(day, utsec, z, lat, lon, sfluxavg, sflux, ap, n=None)

but the function is called in msis.py as

output = msis00f.pygtd7d(
    input_data[:, 0],
    input_data[:, 1],
    input_data[:, 2],
    input_data[:, 3],
    input_data[:, 4],
    input_data[:, 5],
    input_data[:, 6],
    input_data[:, 7:],
)

and the input data created in create_input() is

 arr = np.stack([dyear, dseconds, lons, lats, alts, f107s, f107as], -1)

so lons and alts are swapped.

[greglucas]

I think this is just the wrapper interface definition being wrong and misleading. Are you seeing different results than you expected somewhere?

See here for a fix of the wrapper definition which doesn't change any results: https://github.com/SWxTREC/pymsis/pull/25

I also don't see a def pygtd7d(day, utsec, z, lat, lon, sfluxavg, sflux, ap, n=None) anywhere in the code, so maybe you are referring to somewhere else? (There is no n=None and pygtd7d is defined as a Fortran subroutine not a python method definition, so I'm a bit confused)

[mauro835]

I did the following test:

data = msis.run(dates=[np.datetime64('2009-06-21T08:03:20')], alts=[400.0], lats=[60.0], lons=[290.0], f107s=[150.0], f107as=[150.0], aps=[[4.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]], version='0')
print(data)

Results (also the expected):

[[2.4001912e-12 1.1881953e+13 2.3703083e+11 6.7985113e+13 5.6508613e+11
  5.3249806e+10 1.3246019e+09 1.0759588e+12 2.6672712e+10           nan
  1.0982502e+03]]

Calling directly pygtd7d:

data = msis00f.pygtd7d(day=np.array([172]), utsec=np.array([29000.0]), z=np.array([400.0]), lat=np.array([60.0]), lon=np.array([290.0]), sflux=np.array([150.0]), sfluxavg=np.array([150.0]), ap=np.array([[4.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]]))
print(data)

Results:

[[3.3179362e-11 3.1855484e+14 7.4706662e+12 6.6085856e+14 1.6553475e+12
  5.1659629e+10 1.0357973e+11 1.7458336e+13 3.4439936e+07 9.9900002e-38
  1.1403545e+03]]

[greglucas]

OK, I see what is going on now. You were directly calling the subroutines with keyword arguments! I was considering those to be semi-private methods that wouldn't be used and people would go through run all the time. Thanks for reporting this use case! This should be fixed in #25 now.