On 4 June 2012 13:53, Edward Chapin <[log in to unmask]> wrote:
> [echapin@xmmwl6 plots]$ export KAPPA_VERBOSE=1
> [echapin@xmmwl6 plots]$ ndfcopy
> m17_bright_extended_half2_600.more.smurf.itermaps.CH00I001 map1
> !! No files found matching
> ! 'm17_bright_extended_half2_600.more.smurf.itermaps.CH00I001'.
Odd - that message is created within ndg1_expan when no files are
found matching the supplied name (m17_bright_extended_half2_600.sdf in
your case). So this may lead you to suspect a fault in maybe
ndg1_appen.f or one_wordexp_file.c (which do the wildcard file
matching). But these functions have nothing to do with HDS - they only
look at the file names, not what's inside the file. In which case why
should varying the number of extensions inside the HDS file make any
difference? Very odd....
I do not have access to a 32 bit system locally. Tim - is there one at JAC?
David
Suggests it is caused by the use of one_wordexp_file within ndg - not
a clue how though :-(
> ! Error obtaining a group of existing NDFs using group expression
> ! "m17_bright_extended_half2_600.more.smurf.itermaps.CH00I001"
> !! Please give a new value for parameter IN
> !
>
> Ed
>
>
> On Mon, Jun 4, 2012 at 2:37 PM, David Berry <[log in to unmask]> wrote:
>>
>> HI Ed,
>>
>> Setting environment variable KAPPA_VERBOSE to 1 will give more
>> indication of why the NDFs cannot be accessed.
>>
>> David
>>
>>
>> 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
>> > 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 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
>> > problem
>> >
>> > Ed
>> >
>> > ---- Starlink User Support list For list configuration, including
>> > subscribing to and unsubscribing from the list, see
>> > https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=STARLINK
>>
>> ----
>> Starlink User Support list
>> For list configuration, including subscribing to and unsubscribing from
>> the list, see
>> https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=STARLINK
>
>
> ---- Starlink User Support list For list configuration, including
> subscribing to and unsubscribing from the list, see
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=STARLINK
----
Starlink User Support list
For list configuration, including subscribing to and unsubscribing from the list, see
https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=STARLINK
|