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
!! Cannot access m17_bright_extended_half2_600.more.smurf.itermaps.CH00I001
! 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
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 problem