!spiceinit web=yes not working

[harryshewin]

ISIS 8.0.1

I am trying to generate a HiRISE DEM using HRSC images from UAHiRISE following this tutorial:
https://www.lpi.usra.edu/lunar/tools/dems/Ohman_2013_ISIS-ASP-ArcMap_workflow.pdf

I am having issues running spiceinit web=yes, where I receive the error response:
ERROR The server sent an unrecognised response
[I have attached my print log below]

As I only have limited storage on my computer, I must unfortunately use the SPICE Web Service. Any help with my issue will be greatly appreciated!

Additionally, please do let me know if there are any 'better' methods to produce DEMs than the one outlined in Ohman's tutorial.
Thanks!

print.prt.pdf

[lwellerastro]

See #5223 for an explanation of why the spice server has been disabled to work with HRSC images (changes were only recently implemented). Unfortunately you will have to download mex specific kernels (and possibly base kernels, not sure) in order to run spiceinit on your HRSC images. There does not appear to be a work around.

[harryshewin]

See #5223 for an explanation of why the spice server has been disabled to work with HRSC images (changes were only recently implemented). Unfortunately you will have to download mex specific kernels (and possibly base kernels, not sure) in order to run spiceinit on your HRSC images. There does not appear to be a work around.

I see, thanks for your reply. I have just tried the same method but with CTX images this time and received the same error [attached]! Is there a workaround for this?

Additionally, how should I go about downloading mex specific kernels? How do I know which ones are the right ones?

print.prt.txt

[lwellerastro]

Hi @harryshewin, see https://github.com/DOI-USGS/ISIS3?tab=readme-ov-file#partial-download-of-isis-base-data on how to partially download the ISIS data area. You will need to download the entire mex data area, no need to try and figure out which kernels are necessary (and don't forget the base area or things still won't work). The mex area alone appears to be about 142G, so still chunky (base <30G on my end). If you want to work with HRSC data it seems you will have to download that area as the server does not work properly for those data (when it's not experiencing problems).

It looks like there is a general problem with the spiceinit web based service. We will try and reproduce the problem here. The only workaround is to download kernels.

Update: I have confirmed the spice server is down:

  Group = Error
    Program = spiceinit
    Code    = 1
    Message = "The server sent an unrecognized response"
    File    = SpiceClient.cpp
    Line    = 588
  End_Group

Running isis8.0.1 on local machine and setting web=true

[Kelvinrr]

Try the newer endpoint: #5327

Seems to work for me.

(isis8.1.0):~ krodriguez$ spiceinit from=cubes/mroctx.small.cub web=true url=https://astrogeology.usgs.gov/apis/ale/v0.9.1/spiceserver/
Group = Kernels
  NaifFrameCode             = -74021
  LeapSecond                = $base/kernels/lsk/naif0012.tls
  TargetAttitudeShape       = $mro/kernels/pck/pck00008.tpc
  TargetPosition            = (Table, $base/kernels/spk/de430.bsp,
                               $base/kernels/spk/mar097.bsp)
  InstrumentPointing        = (Table,
                               $mro/kernels/ck/mro_sc_psp_070605_070611.bc,
                               $mro/kernels/fk/mro_v16.tf)
  Instrument                = Null
  SpacecraftClock           = $mro/kernels/sclk/MRO_SCLKSCET.00112.65536.tsc
  InstrumentPosition        = (Table,
                               $mro/kernels/spk/mro_psp3_ssd_mro110c.bsp)
  InstrumentAddendum        = $mro/kernels/iak/mroctxAddendum005.ti
  ShapeModel                = $base/dems/molaMarsPlanetaryRadius0005.cub
  InstrumentPositionQuality = Reconstructed
  InstrumentPointingQuality = Reconstructed
  CameraVersion             = 1
End_Group

[harryshewin]

Thanks for your help @lwellerastro and @Kelvinrr.

I have decided that due to the aforementioned storage issues, I'll only be using CTX instead of HRSC as the web service is essential for me!

I have had a look at #5327 and tried it out, unfortunately receiving a few error messages [full log below].

(isis8.1.0) spiceinit from=G05_020121_1412_XN_38S247W.cub web=true url=https://astrogeology.usgs.gov/apis/ale/v0.9.1/spiceserver/

print.prt.txt

[acpaquette]

@harryshewin It seems like the molaMarsPlanetaryRadius0005.cub file doesn't exist in /Users/harrysherwin/Ames_Stereo_Pipeline/HiRISE/base/dems. What dems are in that directory?

If it doesn't matter that the image has a more accurate shapemodel you can always add shape=ellipsoid to your spiceinit command.

Resulting in:

spiceinit from=G05_020121_1412_XN_38S247W.cub web=true url=https://astrogeology.usgs.gov/apis/ale/v0.9.1/spiceserver/ shape=ellipsoid

[acpaquette]

The easiest way to grab that one DEM is through the following command:
downloadIsisData base $ISISDATA --no-kernels --exclude="{dems/**, kernelTesting/**, examples/**}" --include="{dems/molaMarsPlanetaryRadius0005.cub}"

I know there have been a number of fixes to the downloadIsisData script but give it a try under 8.0.1

[Kelvinrr]

The default server should be back up now.

[acpaquette]

@harryshewin Has the issue been resolved?

[astrostu]

I have been having issues with all CTX images from U16* onwards (the last 5 Earth Months' of data that are on PDS). Downloading kernels didn't work, and web=true didn't work, either (error was that the camera model wasn't found).

Fortunately, I found this Issue and I can say that including "url=https://astrogeology.usgs.gov/apis/ale/v0.9.1/spiceserver/" in the SPICEINIT command does solve the issue, at least in my random testing of some U16 and U18 images.

So, @acpaquette— There is definitely something still wonky with the kernels for at least MRO, and the above fix does solve the issue, but clearly the root cause should be fixed.

[Kelvinrr]

@astrostu I suspect that when the default server went down (which is on prem), some kernels were probably lost and need to be re-downloaded. https://astrogeology.usgs.gov/apis/ale/v0.9.1/spiceserver/ is cloud provisioned so doesn't have this issue. We can look into whether or not the kernels were updated on the default, on prem, version. But I would still encourage using the new URL.

[astrostu]

@Kelvinrr— Two notes on that. First, I am perhaps one of those rare people these days who actually download all the kernels so I don't have to keep pulling from the internet when I process a lot of data. The download script, at least the one included with ISIS 8.0.1 (I didn't upgrade to .0.2 yet since .1.0 is in the works), is not downloading from the new URL. The average user (e.g., me!) won't know what's going on. Similarly, second, I don't think the average user is going to know they can specify a url= in SPICEINIT, much less know where to point it. So, I think something still needs to be fixed so this is as seamless as it's been for years.

If your response was that you agree this is an issue and the above is a bandage for now, great. But in case your response was implying that this is going to be how it is, I don't think that's good for the average end-user.

[Kelvinrr]

@astrostu I think there has been some confusion? I plan to look into the default URL since that is the default with our support hours. This has nothing to do with the download script, it's a new instance of the spiceserver. That original server has had uptime issues for as long as I have known which is why we moved it to the cloud. You can read more in the discussion post. We will most likely move it to be the default server in the next major release.

[chkim-usgs]

Hi @harryshewin, as this issue is closely related to #5327 mentioned above, we will close this issue. Issue #5327 is on the board for this upcoming sprint. Thanks!