[AstroPy] Reading JPL ephemeris files on 64-bit architecture
Tom Kuiper
kuiper at jpl.nasa.gov
Thu Dec 29 13:16:07 EST 2011
I'm trying to get pynovas to work under Linux-AMD64 and have run into a
problem reading the JPL ephemeris file. I encountered this previously
with Rick Fisher's jplephem but I think I have more of an insight now.
The problem, I think, lies in this structure in ephem_types.h:
struct recOneData { /* storage on
disk: */
char label[3][84]; /* 3*84 = 252 bytes = 31.5
words */
char constName[400][6]; /* 400*6 = 2400 = 300
words */
double timeData[3]; /* 3*8 = 24 = 3
words */
int numConst; /* 1*4 = 4 = 0.5 words,
32-bit long */
double AU; /* 1*8 = 8 = 1
words */
double EMRAT; /* 1*8 = 8 = 1
words */
int coeffPtr[12][3]; /* 12*3*4 = 144 = 18 words,
32-bit longs */
int DENUM; /* 1*4 = 4 = 0.5 words,
32-bit long */
int libratPtr[3]; /* 3*4 = 12 = 1.5 words,
32-bit long */
/* = 2856 bytes = 357 words */
};
I've annotated the original code. Also, the original 32-bit code had
longs instead of ints. Changing them to ints made no difference. The
first int, numConst, comes out the same (wrong value) either way. I've
verified this structure using the Python struct module. The question:
is there a way in C to ignore the fact that this structure doesn't
respect 64-bit word boundaries? I've considered using union but that
would involve a lot of code changes, wherever this structure is used.
One solution to all this is, I suppose, to use bin2asc (after
downloading and re-compiling the JPL ephemeris C source code) and
generate a new ASCII data file for 64-bit machines. I will if I have to
but it seems more elegant to use the ephemeris binary files as they are
given. Any suggestions?
Thanks and regards,
Tom
--
I or me? http://www.oxforddictionaries.com/page/145
More information about the AstroPy
mailing list