...wavelength.
In this respect, the WCS component provides a superset of the facilities provided by the AXIS component. However, the AXIS component is retained because it has been used historically by a significant number of astronomical applications. The NDF_ library maintains consistency between these two components (to the extent that their nature allows). Thus, for example, the rectangular coordinate system defined by the AXIS component is also accessible through the WCS component.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...applied.
Note that the name ``DATA'' used by the NDF_ routines to refer to an NDF's data component differs from the actual name of the HDS object in which it is stored, which is ``DATA_ARRAY''.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...SAI__OK
The symbolic constant SAI__OK is defined in the include file SAE_PAR.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...state.
A component's state as defined by the NDF_ system should not be confused with the state of data objects as defined by the underlying data system HDS. An ``HDS-undefined'' primitive object is normally regarded as illegal by the NDF_ system and provokes an error. The ``NDF-state'' of a component is instead related to the existence or non-existence of HDS objects, although not always in an obvious fashion.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...elements.
Note that the NDF_MAP routine (together with NDF_AMAP, NDF_MAPQL and NDF_MAPZ which also obtain mapped access to arrays) will return a ``safe'' value of 1 via its EL argument under error conditions. This is intended to avoid possible run-time errors due to invalid adjustable array dimensions (see §[*]).
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...use.
To understand this fully it may be necessary to read the later section on bad pixels[*]).
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...pixels.
Note that a bad-pixel flag value of .FALSE. does not ensure that the numerical value normally used to represent bad pixels will be absent, but it does indicate that such numbers are to be interpreted literally (i.e. as ``good'' values) and not as bad pixels.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...declarations:
The use of a single include file to declare and define a statement function and its arguments is normally satisfactory. However, it sometimes makes it impossible to satisfy Fortran 77 statement order restrictions. For instance, if several such functions were defined in this way from separate subroutine libraries, it would not be possible to place all the declaration statements in front of all the function definition statements, as Fortran 77 requires. To cope with such problems, the single NDF_FUNC file may be replaced if necessary with the equivalent two separate include files NDF_FUNC_DEC and NDF_FUNC_DEF (in this order) which respectively declare and define the function.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...understand.
While the sharing of extensions between software packages and/or authors is not excluded, this is entirely the responsibility of those concerned. Since the requirements are so diverse, no specific recommendations can be made except to note that some documentary provision is normally necessary to ensure that separate authors interpret extension information in a consistent way.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...argument.
Note that an extension called `IRAS' will actually be stored in an HDS object called .MORE.IRAS but the `.MORE.' should not be included when using NDF_ routines.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...dataset.
Where there is more than one input NDF, one of them should be designated the primary input dataset and be used as the template for the output dataset. By convention, this should be the first input NDF acquired by the application and the first to be described in documentation.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...NDF_SECT.
Users familiar with HDS should note the distinction between the HDS concept of slicing, in which the pixel indices of an array slice always start at (1,1...), and the use of sections from NDFs, where the pixel indices of the original NDF are preserved in any derived section.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...order.
The pixels will be contiguously stored whenever a base NDF is partitioned into chunks. However, an NDF section may also be partitioned in the same way. In this case, the resulting ``chunked'' pixels will only be truly contiguous if they were stored contiguously in the original NDF section.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...numbers,
Here, a floating-point number is one containing a decimal point and/or an exponent. Double-precision arithmetic is used to process these values, but either double- or single-precision notation may be used when supplying them.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...whole.
There is no corresponding provision for recording any uncertainty in a pixel's width.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...follows:
If either of the neighbouring centre values does not exist (because the pixel is at the end of the array) then it is replaced by Cn(i) and the $\frac{1}{2}$ in the formula is dropped. If neither neighbour exists (because the NDF's dimension size is 1) then the width value is set to unity. Note that the default centre array values will be used if none have been defined, and this will also result in width values of unity.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...significant,
Note that the name ``CENTRE'' used by the NDF_ routines to refer to an NDF's centre component differs from the actual name of the HDS object in which it is stored, which is ``DATA_ARRAY''.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...accessed.
Under error conditions a ``safe'' value of 1 will be returned for EL, as discussed in §[*].
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...follows:
Different rules may apply when accessing foreign format datasets and these are described in SSN/20.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...above,
Note that an absolute NDF name may nevertheless still start with a container file specified using a relative file name.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...objects,
In essence it stands for the filing system of the host computer.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...upon.
Except that the USER, HOST and REFERENCE items (marked by open circles) may not always be present in history records written by applications which do not use the NDF_ library. In this case, enquiries about them will simply result in a blank value being returned.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...factors,
Such as the software environment or operating system in use, the version of the NDF_ library, and the history update mode - see §[*].
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...record,
This information is stored in the REFERENCE item - see §[*].
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...NDF__SZHMX
The NDF__SZHMX constant is defined in the include file NDF_PAR and currently has the value 200.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...NDF__SZHIS
Also defined in the NDF_PAR include file, currently to be 72 characters.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...SAI__OK,
As defined in the include file SAE_PAR.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...number.
History record numbers start at 1.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...names
Or using ``ndf.h'' in C.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...output,
The function ndfHecho (which calls the Fortran routine NDF_HECHO) is the only routine that explicitly generates output, which it does using Fortran. However, this is really just a demonstration function and is easily replaced by your own C equivalent if necessary.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

Starlink User Note 33
R.F. Warren-Smith
11th January 2000
E-mail:rfws@star.rl.ac.uk

Copyright © 2000 Council for the Central Laboratory of the Research Councils