SPICE kernel loading issue

[buff-anu]

Howdy BSK Community,

I was trying to update my docker setup with fresh copy of basilisk and encountered SPICE kernel issue for EphemerisData such as leapseconds (please see below). This error occurs at the time of initializing the simulation. However, I don’t encounter this issue when I use the repo from bitbucket. Did anyone else face a similar issue or did I miss something?

I did some search about this issue and came across a solution that suggests writing a meta-kernel. I believe that there should not be any need to write a meta-kernel but I am open to suggestions.

Could some one point me in the right direction to look for the solution?

Thank you,
Anubhav

Logs

================================================================================
 
Toolkit version: N0065
 
SPICE(NOSUCHFILE) --
 
The attempt to load
"/app/basilisk/dist3/Basilisk/supportData/EphemerisData/de430.bsp" by the
routine FURNSH failed. It could not be located.
 
A traceback follows.  The name of the highest level module is first.
furnsh_c --> FURNSH --> ZZLDKER
 
================================================================================
 
================================================================================
 
Toolkit version: N0065
 
SPICE(INVALIDNODE) --
 
HEAD was 0. TAIL was 0. Valid range is 1 to 26003.
 
A traceback follows.  The name of the highest level module is first.
furnsh_c --> FURNSH --> ZZLDKER --> LDPOOL --> ZZRVAR --> ZZCLN --> LNKFSL
 
================================================================================
 
================================================================================
 
Toolkit version: N0065
 
SPICE(BADVARASSIGN) --
 
The first item following the assignment operator should be the value of a
variable or a left parenthesis '(' followed by a value for a variable. This is
not true on line 1 of the text kernel file
'/app/basilisk/dist3/Basilisk/supportData/EphemerisData/naif0012.tls'.
 
A traceback follows.  The name of the highest level module is first.
furnsh_c --> FURNSH --> ZZLDKER --> LDPOOL --> ZZRVAR
 
================================================================================
 
================================================================================
 
Toolkit version: N0065
 
SPICE(INVALIDNODE) --
 
HEAD was 0. TAIL was 0. Valid range is 1 to 26003.
 
A traceback follows.  The name of the highest level module is first.
furnsh_c --> FURNSH --> ZZLDKER --> LDPOOL --> ZZRVAR --> ZZCLN --> LNKFSL
 
================================================================================
 
================================================================================
 
Toolkit version: N0065
 
SPICE(BADVARASSIGN) --
 
The first item following the assignment operator should be the value of a
variable or a left parenthesis '(' followed by a value for a variable. This is
not true on line 1 of the text kernel file
'/app/basilisk/dist3/Basilisk/supportData/EphemerisData/de-403-masses.tpc'.
 
A traceback follows.  The name of the highest level module is first.
furnsh_c --> FURNSH --> ZZLDKER --> LDPOOL --> ZZRVAR
 
================================================================================
 
================================================================================
 
Toolkit version: N0065
 
SPICE(INVALIDNODE) --
 
HEAD was 0. TAIL was 0. Valid range is 1 to 26003.
 
A traceback follows.  The name of the highest level module is first.
furnsh_c --> FURNSH --> ZZLDKER --> LDPOOL --> ZZRVAR --> ZZCLN --> LNKFSL
 
================================================================================
 
================================================================================
 
Toolkit version: N0065
 
SPICE(BADVARASSIGN) --
 
The first item following the assignment operator should be the value of a
variable or a left parenthesis '(' followed by a value for a variable. This is
not true on line 1 of the text kernel file
'/app/basilisk/dist3/Basilisk/supportData/EphemerisData/pck00010.tpc'.
 
A traceback follows.  The name of the highest level module is first.
furnsh_c --> FURNSH --> ZZLDKER --> LDPOOL --> ZZRVAR
 
================================================================================
 
================================================================================
 
Toolkit version: N0065
 
SPICE(NOLEAPSECONDS) --
 
The variable that points to the leapseconds (DELTET/DELTA_AT) could not be
located in the kernel pool. It is likely that the leapseconds kernel has not
been loaded via the routine FURNSH.
 
A traceback follows.  The name of the highest level module is first.
str2et_c --> STR2ET --> TTRANS
 
Oh, by the way:  The SPICELIB error handling actions are USER-TAILORABLE.  You
can choose whether the Toolkit aborts or continues when errors occur, which
error messages to output, and where to send the output.  Please read the ERROR
"Required Reading" file, or see the routines ERRACT, ERRDEV, and ERRPRT.
 
================================================================================

[buff-anu]

The de430.bsp file at following path is removed

~/basilisk/supportData/EphemerisData/de430.bsp.REMOVED.git-id

This is available in the bitbucket repository and may be the cause of at least one error. I'm working on it and share update soon.

[schaubh]

Howdy Anu, did this solve your issue? Patrick, should we be adding this step to the download instructions? I have very limited internet right now and can't test.

[buff-anu]

Dr. Schaub, I tried this solution, but it didn't work for me. I did this pull inside the docker container and I don't think the setup of docker would have interfered with it. I did the replacement of the (removed) de430.bsp file with the one from NAIF and that worked smoothly for me.

[patkenneally]

Can you try deleting your repo, cloning it again, and executing the git lfs commands? I helped someone with this today and that worked for them :) . While replacing the bsp file will make everything work, it's only masking the fact that your clone isn't pulling down the git lfs file (de430).

[buff-anu]

I totally agree with you, Patrick. I ran the git lfs commands within a fresh copy of the repo. It still did not work for me. Did the person whom you assisted use docker or linux?

[gdoskey]

For what It is worth, I had similar problems and doing the git lfs pull worked for me.
In my case I had previously pointed to the bitbucket repo successfully and had git lfs already installed, switching to the github repo, fetching, pulling develop, and then rebuilding led me to the issue. 'git lfs pull' fixed all for me. However, this is not in a docker container but a virtual environment on Ubuntu 22.04
Maybe the nature of the problem is different almost a year after aerobuff had their issue, but I wanted to comment for others looking for a solution.

[buff-anu]

So, I replaced the file de430.bsp at following locations and the simulation runs error-free-
~/basilisk/supportData/EphemerisData/de430.bsp.REMOVED.git-id
~/basilisk/dist3/Basilisk/supportData/EphemerisData/de430.bsp.REMOVED.git-id

I used the file from https://naif.jpl.nasa.gov/pub/naif/generic_kernels/spk/planets/

The file may have been removed owing to the size threshold during migration. Not sure, but this might be a helpful link: https://github.com/rtyley/bfg-repo-cleaner/issues/11

@schaubh Dr. Schaub, could you or any other team member take a look at this solution?

[evansneath]

We're also experiencing this issue in the master branch.

[schaubh]

The issue is not having downloaded the large spice files. Git does this if it is lfs installed. You need to install the git lfs (large file service) tool. Here are some suggested options:

on Windows using SourceTree:

• go to Tools/Options/Authtentication. Then, select your GitHub account and instead of using OAuth authentication, select Basic. This should give a prompt for a username and password. Use your GitHub username (not email) for the username field and the personal access token for the password field.

on macOS using SourceTree:

• SourceTree might show a panel saying Git LFS: install required. Say yes and install this tool. If SourceTree does not offer to install it, use brew to install lfs for the large file service. (see https://git-lfs.github.com/). After brew installed it, from within the basilisk sourse code directly run git lfs install from the command line.
• Make a dummy branch locally and try to push to origin. It should ask you for your GitHub username (not email), and for the password you enter the token string you entered before. After pushing the dummy branch to origin successfully, you can delete both the local and repo copy.

[KetanKamat-5]

Hello Dr.Schaub,

Hope you're doing well.

I'm running into the same issue but on Linux. However, I'm not using SourceTree and Gitlab instead. What solution do you recommend to solve this in my case?

[schaubh]

I would install the lfs support from the command line. I don't have experience with the Gitlab tools.

[KetanKamat-5]

Hello Dr.Schaub,

Thank you so much,that worked!

I realized shortly after that the discussion with Anubhav was related to Docker so that's why the lfs solution wasn't working for him.