de431t.bsp file handling error

(Please excuse my English)

When I execute spicey_error.py with de431t.bsp ephemeris data file, the below error is occured. No error is occurred with other de43*t.bsp. So I think there is a problem SpiceyPy handling de431t.bsp. The size of de431t.bsp is about 3.4GB. The problem may be related to large file handling.

Error :

Traceback (most recent call last):
  File "\myCode\jpl\spicey_error.py", line 9, in <module>
    state, lightTimes = spice.spkez(ID, et, 'J2000', 'NONE', SSB_ID)
  File "\home\anaconda3\lib\site-packages\spiceypy\spiceypy.py", line 102, in with_errcheck
    check_for_spice_error(f)
  File "\home\anaconda3\lib\site-packages\spiceypy\spiceypy.py", line 87, in check_for_spice_error
    raise stypes.SpiceyError(msg)
spiceypy.utils.support_types.SpiceyError:
================================================================================

Toolkit version: N0066

SPICE(DAFBEGGTEND) --

Beginning address (352432997) greater than ending address (352432996).

spkez_c --> SPKEZ --> SPKGEO --> SPKPVN --> SPKR02 --> DAFGDA

================================================================================

spicey_error.py :

import spiceypy as spice

spice.furnsh("./de431t.txt")

SSB_ID = 0
ID = 1
tdb = '2020-07-01 00:00:00 TDB'
et = spice.str2et(tdb)
state, lightTimes = spice.spkez(ID, et, 'J2000', 'NONE', SSB_ID)
print(state, lightTimes)

de431t.txt :

\begindata
KERNELS_TO_LOAD=(
   'naif0012.tls',
   'de431t.bsp',
)
\begintext

Environments :

win10 pro x64 conda 4.8.3 python 3.7.6 spiceypy 3.0.2

[AndrewAnnex]

@pdh0710 @jdiazdelrio after communicating with the NAIF, I have learned that this is a known issue with the 64bit Windows CSPICE library, and that the library is limited to kernels no bigger than 2.1 GB. This is not a bug with how SpiceyPy or the conda-forge feedstock that builds cspice for conda users. The underlying issue is due to the 32bit long issue I noted and simply changing it to a 64bit long (long long) may be in conflict with constraints from ANSI C. As such, I won’t consider writing a patch to the c code, as there may cause unintentional errors elsewhere.

I think the only solution for you @pdh0710 would be to use the spkmerge to make a smaller kernel file or to use some of the smaller files provided by SSD/NAIF. Again, it primarily depends on how big of a time range you need to do your work, so if you really needed the full time span then using spkmerge would be my recommendation. Otherwise using a Linux or macOS system would not share the same limitation.

I will leave this issue open for a day or two and then I will close it.

[jdiazdelrio]

Yes. Here’s the output:

BRIEF -- Version 4.0.0, September 8, 2010 -- Toolkit Version N0066
 

Summary for: de431t.bsp
 
Bodies: MERCURY BARYCENTER (1)  SATURN BARYCENTER (6)   MERCURY (199)
        VENUS BARYCENTER (2)    URANUS BARYCENTER (7)   VENUS (299)
        EARTH BARYCENTER (3)    NEPTUNE BARYCENTER (8)  MOON (301)
        MARS BARYCENTER (4)     PLUTO BARYCENTER (9)    EARTH (399)
        JUPITER BARYCENTER (5)  SUN (10)                1000000001
        Start of Interval (ET)              End of Interval (ET)
        -----------------------------       -----------------------------
        13201 B.C. MAY 06 00:00:00.000      17191 MAR 15 00:00:00.000

Right now it downloads at 350Mbps.