LRO-NAC Calibration and web services for kernels

[ascbot]

---

Author Name: Tammy Becker (Tammy Becker)

---

https://isis.astrogeology.usgs.gov/IsisSupport/index.php/topic,3765.0.html

Hi,
I started a project requiring LROC calibrated data and ran into a bit of a snag.

The error I ran across is more of an issue now because due to some budget issues, the PDS had to delete all the CRDs from their system. Thus, many more people will be needing to calibrate the data than previously.

I had no problems using lronac2isis, spiceinit (web) and phocube; however, lronaccal failed. I am running ISIS 3.4.4.5390 with a full rsync on 5 Sep 2013.

It appears that to calibrate the NAC images, I needed to have ALL 70GB of kernels -- most unfortunate. I tried using the --exclude="kernels", but I still got the error. When I downloaded the full LRO data directory, it calibrated without issue.

As you can imagine, this creates quite a issue for the community. With the PDS not supporting the CRD (at least temporarily), every user will have to download the entire 70GB LRO directory, which is less than ideal.

Because only needed a single dark image was needed (at least that is what I am assuming), it sure would be great to have some easier options. Maybe WEB=TRUE could be added? If only darks are needed for the calibration, maybe an rsync command could be added to the lronaccal page that told you how to exclude the ck files (which are 69GB of the data)

Thanks
Eric

The error I received was:
Toolkit version: N0064

SPICE(NOSUCHFILE) --

The attempt to load
"/usr/local/isis3/isis/../data/lro//kernels/tspk/moon_pa_de421_1900-2050.bpc"
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

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.

Jeff Anderson has responded (9/7/2013):
The work around is to download only that one kernel listed in the error message. You will have to run the rsync command by hand. We will put this in our internal list of problems to try to fix.

[dbolan]

I think just ran into this issue with version 3.7.1, except for me it fails silently. Instead it comes up with a bogus value for the solar distance and as a result zeroes out all the data in the cube.
I downloaded the calibration data for the LRO, but skipped the SPICE kernels and just used the web service for spiceinit.
More details here, if needed: https://astrodiscuss.usgs.gov/t/lronaccal-zeroing-out-data/214/4

As Jeff Anderson suggested, a suitable workaround is to download all the kernels listed here:
https://github.com/USGS-Astrogeology/ISIS3/blob/dev/isis/src/lro/apps/lronaccal/main.cpp#L204
To save you some typing:

rsync -azvPh --partial isisdist.astrogeology.usgs.gov::isis3data/data/lro/kernels/pck/moon_assoc_me.tf isisdist.astrogeology.usgs.gov::isis3data/data/lro/kernels/pck/moon_080317.tf $ISIS3DATA/lro/kernels/pck
rsync -azvPh --partial isisdist.astrogeology.usgs.gov::isis3data/data/lro/kernels/tspk/moon_pa_de421_1900-2050.bpc isisdist.astrogeology.usgs.gov::isis3data/data/lro/kernels/tspk/de421.bsp $ISIS3DATA/lro/kernels/tspk

It's still a bit of a problem that current functionality is silently setting the solar distance to 2.83593680712876e-321 AU. I guess it'll be correct in a few billion years, but until then we should probably throw an error.

[krlberry]

@Kelvinrr Can this be closed?