Setting environment variable KAPPA_VERBOSE to 1 will give more
indication of why the NDFs cannot be accessed.
On 4 June 2012 13:14, Edward Chapin <[log in to unmask]> wrote:
> I have a file created by SMURF with a huge number of extensions representing
> iterations of the map-maker (900 to be exact!) The problem is using an rsync
> of 32-bit starlink from the JAC:
> rsync -avz --delete --exclude=local --exclude=lost+found
> starlink.jach.hawaii.edu::starlink.i386/ star/
> Checking the time stamps on bin/smurf it looks pretty recent:
> -rwxr-xr-x 1 echapin users 16993 Jun 2 06:17 jcmtstate2cat
> I find that SMURF:STACKFRAMES, and even KAPPA:NDFCOPY all fail to open even
> one of the extensions, e.g.
> [echapin@xmmwl6 data]$ ndfcopy
> m17_bright_extended_half2_600.more.smurf.itermaps.CH00I001 map1
> !! Cannot access
> ! Please give a new value for parameter IN
> However, HDSTRACE lists all 900 of them (e.g. hdstrace
> m17_bright_extended_half2_600.more.smurf.itermaps), and I can even HCOPY
> them out:
> hcopy m17_bright_extended_half2_600.more.smurf.itermaps.CH00I600 map600
> Gaia also works, i.e. gaia
> m17_bright_extended_half2_600.more.smurf.itermaps.CH00I900 loads up the full
> set of 900 extensions in the selector window, and plots the 900th for me.
> This is a huge file (7 gigs or so), but I can put it somewhere if needed.
> Presumably it would be easy to make a test file locally with a large number
> of (small!) extensions to test this out.
> I have another file with 108 extensions and don't have any problem (so the
> magic number is between 109 and 900...).
> I also have a bleeding-edge 64-bit build, and it does not exhibit this
> ---- Starlink User Support list For list configuration, including
> subscribing to and unsubscribing from the list, see
Starlink User Support list
For list configuration, including subscribing to and unsubscribing from the list, see