This document is essential reading for every user of the NAG Library implementation specified in the title. It provides implementation-specific detail that augments the information provided in the NAG Mark 30.1 Library Manual (which we will refer to as the Library Manual). Wherever that manual refers to the "Users' Note for your implementation", you should consult this note.

In addition, NAG recommends that before calling any Library routine you should read the following reference material from the Library Manual (see Section 5):

(a)How to Use the NAG Library
(b)Chapter Introduction
(c)Routine Document

2 Supplementary Information

Please check the following URL:

https://support.nag.com/doc/inun/nl30/l6i1bl/supplementary.html

for details of any new information related to the applicability or usage of this implementation.

3 General Information

This implementation of the NAG Library provides static and shareable libraries that use the Intel ® Math Kernel Library for Linux (MKL), a third-party vendor performance library, to provide Basic Linear Algebra Subprograms (BLAS) and Linear Algebra PACKage (LAPACK) routines (except for any routines listed in Section 4). It also provides static and shareable libraries that use self-contained NAG reference versions of these routines (referred to as the self-contained libraries). This implementation has been tested with version 2021.0.4 of MKL, which is supplied as a part of this product. Please see the Intel website for further information about MKL (https://software.intel.com/content/www/us/en/develop/tools/oneapi/components/onemkl.html). For best performance, we recommend that you use one of the variants of the NAG Library which is based on the supplied MKL vendor Library, i.e. libnag_mkl.a or libnag_mkl.so, in preference to using one of the self-contained NAG libraries, libnag_nag.a or libnag_nag.so.

This implementation includes libraries (and associated files) for use with both 32-bit integers (denoted by lp64) and 64-bit integers (denoted by ilp64).

The NAG AD Library is also included as the variant add-on libraries: libnag_nag_ad.a, libnag_nag_ad.so, libnag_mkl_ad.a and libnag_mkl_ad.so. In the nag_mkl_ad variants, symbolic matrix calculus is used for computing derivatives more efficiently for a number of core level-3 BLAS routines. Only for Fortran users: if using the above libraries from Fortran, libnag_dcof.a must be linked in addition.

Note that the NAG Library is carefully designed so that any memory used can be reclaimed – either by the Library itself or, for C routines, by the user invoking calls of NAG_FREE(). However, the Library does itself depend on the use of compiler run-time and other libraries which may sometimes leak memory, and memory tracing tools used on programs linked to the NAG Library may report this. The amount of memory leaked will vary from application to application, but should not be excessive and should never increase without limit as more calls are made to the NAG Library.

If you intend to use the NAG Library within a multithreaded application please refer to the document CL Interface Multithreading or FL Interface Multithreading (as appropriate) for more information.

Further information about using the supplied Intel MKL libraries with threaded applications is available at https://software.intel.com/content/www/us/en/develop/documentation/onemkl-linux-developer-guide/top/managing-performance-and-memory/improving-performance-with-threading.html.

The NAG AD Library is thread safe. However, please note that if you compile your code with the pre-processor macro DCO_NO_THREADLOCAL defined, this may no longer hold.

The libraries supplied with this implementation do not contain OpenMP or any other threading mechanisms. However, the MKL vendor Library is OpenMP threaded. See Section 3.1.1 for more information on how to control this threading.

Intel have introduced a conditional bitwise reproducibility (BWR) option in MKL. Provided a user's code adheres to certain conditions (see https://software.intel.com/content/www/us/en/develop/documentation/onemkl-linux-developer-guide/top/obtaining-numerically-reproducible-results/reproducibility-conditions.html), BWR can be forced by setting the MKL_CBWR environment variable. See the MKL documentation for further details. It should be noted, however, that many NAG routines do not adhere to these conditions. This means that for a given NAG library built on top of MKL, it may not be possible to ensure BWR for all NAG routines across different CPU architectures by setting MKL_CBWR. See Section 8.1 of How to Use the NAG Library for more general information on bitwise reproducibility.

3.1 Accessing the Library

In this section we assume that the Library has been installed in the directory [INSTALL_DIR]. By default [INSTALL_DIR] (see Installer's Note (in.html)) is $HOME/NAG/nll6i301bl; however it could have been changed by the person who did the installation, in which case you should consult that person. Note that the environment variable LD_LIBRARY_PATH must be set correctly at link time and run time to point to the appropriate library locations underneath [INSTALL_DIR]. See below for how to do this.

The NAG Library is a combined replacement for users of both the NAG C Library and the NAG Fortran Library (including the C wrappers to the Fortran Library interfaces). To help with calling the different libraries included with this implementation the scripts nagvars.sh and nagvars.csh are included to set NAG-specific environment variables to assist with compiling and linking applications that call any of the NAG routines. They also amend the standard environment variables PATH and LD_LIBRARY_PATH so that NAG executable programs and libraries can be found at compile, link and run time.

The nagvars scripts are designed to be used as follows:

   . [INSTALL_DIR]/scripts/nagvars.sh [-help] [-unset] [-quiet] [-ifx] [-gnu] \
     {int32,int64} {vendor,nag} {static,dynamic}

   source [INSTALL_DIR]/scripts/nagvars.csh [-help] [-unset] [-quiet] [-ifx] [-gnu] \
          {int32,int64} {vendor,nag} {static,dynamic}

where:

•nagvars.sh should be used for Bourne, Bash or equivalent shells (note: not Dash, which is available on some Debian-derived distributions of Linux such as Ubuntu) and nagvars.csh should be used for Csh, Tcsh or equivalent shells.
•{int32,int64} specifies the default size for integer arguments and variables within NAG routines.
•{vendor,nag} specifies whether to use the set of NAG libraries that depend upon the supplied MKL Library for BLAS and LAPACK (option vendor), or to use the self-contained NAG libraries (option nag). For best performance, option vendor is recommended.
•{static,dynamic} specifies whether to link to static or dynamic (shared) versions of the NAG libraries.

No default values are used, so all three options must be set. The order of specifying them is not important. The optional nagvars script arguments are as follows:

•-help prints information about the script.
•-unset clears the NAG-specific environment variables and tries to remove all references to material from this NAG implementation only from the standard environment variables PATH and LD_LIBRARY_PATH.
•-quiet suppresses output to stdout.
•-gnu is explained at the end of this section.

Thus, an example of using the nagvars script to set the environment in Bash is:

   source [INSTALL_DIR]/scripts/nagvars.sh int64 vendor dynamic

The NAG-specific environment variables set are:

•NAGLIB_CC - The C compiler used in the creation of this NAG Library.
•NAGLIB_CXX - The C++ compiler used in the creation of this NAG Library.
•NAGLIB_F77 - The Fortran compiler used in the creation of this NAG Library.
•NAGLIB_CFLAGS - Necessary or recommended C compiler flags.
•NAGLIB_CXXFLAGS - Necessary or recommended C++ compiler flags.
•NAGLIB_FFLAGS - Necessary or recommended Fortran compiler flags.
•NAGLIB_INCLUDE - Include paths to NAG C header and/or Fortran module files.
•NAGLIB_CLINK - Libraries needed for linking to regular NAG (and optionally vendor BLAS and LAPACK) routines using the C compiler.
•NAGLIB_CXXLINK - Libraries needed for linking to regular NAG (and optionally vendor BLAS and LAPACK) routines using the C++ compiler.
•NAGLIB_FLINK - Libraries needed for linking to regular NAG (and optionally vendor BLAS and LAPACK) routines using the Fortran compiler.
•NAGLIB_AD_LINK - Additional library needed for NAG AD routines, which should be linked before NAGLIB_CLINK, NAGLIB_CXXLINK or NAGLIB_FLINK.

To use the NAG Library and the supplied Intel MKL libraries (if desired), you may then link in the following manner:

For C programs:

   ${NAGLIB_CC} ${NAGLIB_CFLAGS} ${NAGLIB_INCLUDE} program.c ${NAGLIB_AD_LINK} \
   ${NAGLIB_CLINK}

if NAG AD routines are required, otherwise

   ${NAGLIB_CC} ${NAGLIB_CFLAGS} ${NAGLIB_INCLUDE} program.c ${NAGLIB_CLINK}

or for C++ programs:

   ${NAGLIB_CXX} ${NAGLIB_CXXFLAGS} ${NAGLIB_INCLUDE} program.cpp ${NAGLIB_AD_LINK} \
   ${NAGLIB_CXXLINK}

if NAG AD routines are required, otherwise

   ${NAGLIB_CXX} ${NAGLIB_CXXFLAGS} ${NAGLIB_INCLUDE} program.cpp ${NAGLIB_CXXLINK}

or for Fortran programs:

   ${NAGLIB_F77} ${NAGLIB_FFLAGS} ${NAGLIB_INCLUDE} program.f90 ${NAGLIB_AD_LINK} \
   ${NAGLIB_FLINK}

if NAG AD routines are required, otherwise

   ${NAGLIB_F77} ${NAGLIB_FFLAGS} ${NAGLIB_INCLUDE} program.f90 ${NAGLIB_FLINK}

Note that you may also need to set LD_LIBRARY_PATH to point at other items such as compiler run-time libraries, for example if you are using a newer version of the compiler.

If you are using a different compiler, or indeed a different version of the Intel Compiler, you may need to link against the Intel Compiler run-time libraries provided in [INSTALL_DIR]/rtl/lib/intel64. This may be facilitated by adding

  [INSTALL_DIR]/rtl/lib/intel64

to LD_LIBRARY_PATH.

To call from Intel icx or ifx compilers, simply substitute icx or ifx for icc or ifort respectively (but see the note below regarding static linking with ifx). The easiest way to do this is to use the -ifx option to the nagvars.sh and/or nagvars.csh scripts. Using this option will modify the NAG-specific environment variables to use the Intel ifx, icx or icpx compiler (as appropriate).

It is a known issue that static linking with some more recent Intel Fortran compilers (ifort or ifx) produces link errors due to multiple definitions. With the slightly older version of ifort used to build the Library, some Intel run-time libraries were statically included into the static variants of the library to keep static linking simpler since these run-times were not linked automatically by ifort. With more recent Fortran compilers, these run-times are now linked automatically, and, on Linux, these default libraries cannot be individually deactivated during linking (as they can on Windows). The workaround for Linux is to use one of the shared variants of the NAG Library instead. This also happens to be the recommended form of linking since it results in no significant loss in performance and produces executables of much smaller size.

This version of the NAG Library can be called from the GNU gcc and g++ compilers, using at least the versions of gcc mentioned in the Supplementary Information page on our website. The easiest way to do this is to use the -gnu option to the nagvars.sh and/or nagvars.csh scripts. Using this option will modify the NAG-specific environment variables to use GNU gcc and g++ (as appropriate).

Note that GNU gfortran is not supported, so the Fortran-related NAG environment variables will continue to reference the Intel ifort compiler. Also note that linking with MKL will continue to use the Intel compiler OpenMP run-time, for consistency with any OpenMP routines present in the NAG Library.

3.1.1 Setting the Number of Threads to Use

MKL makes use of OpenMP to implement threading in some of the Library routines. The number of threads that will be used at run time can be controlled by setting the environment variable OMP_NUM_THREADS to the appropriate value.

In the C shell, type:

  setenv OMP_NUM_THREADS N

In the Bourne shell, type:

  OMP_NUM_THREADS=N
  export OMP_NUM_THREADS

where N is the number of threads required. The environment variable OMP_NUM_THREADS may be re-set between each execution of the program, as desired.

Multiple levels of OpenMP parallelism may be present in some MKL routines, and you may also call these multithreaded routines from within an OpenMP parallel region in your own application. By default, OpenMP nested parallelism is disabled, so only the outermost parallel region will actually be active, using N threads in the example above. The inner level(s) will not be active, i.e. they will run on one thread. You can check if OpenMP nested parallelism is enabled and choose to enable/disable it by querying and setting the OMP_NESTED OpenMP environment variable. If OpenMP nested parallelism is enabled, the above example will create N threads at each parallel region for each thread at a higher level, thus N*N threads in total if there are two levels of OpenMP parallelism, etc. To provide more detailed control of nested parallelism, the environment variable OMP_NUM_THREADS can be set to be a comma-separated list to specify the number of threads desired at each level.

In the C shell, type:

  setenv OMP_NUM_THREADS N,P

In the Bourne shell, type:

  OMP_NUM_THREADS=N,P
  export OMP_NUM_THREADS

This will create N threads for the first level of parallelism, and then P threads for each outer level thread when an inner level of parallelism is encountered.

Note: If the environment variable OMP_NUM_THREADS is not set, the default value can vary from compiler to compiler, and for different vendor libraries, usually to either be 1 or else equal to the maximum number of cores available on your system. The latter could be an issue if you are sharing the system with other users, or are running a higher level of parallelism within your own application. Thus it is recommended that you always set OMP_NUM_THREADS explicitly to your desired value.

In general, the maximum number of threads you are recommended to use is the number of physical cores on your shared memory system. However, most Intel processors support a facility known as Hyperthreading, which allows each physical core to support up to two threads at the same time and thus appear to the operating system as two logical cores. It may be beneficial to make use of this functionality, but this choice will depend on the particular algorithms and problem size(s) used. You are advised to benchmark performance-critical applications with and without making use of the additional logical cores, to determine the best choice for you. This can normally be achieved simply by an appropriate choice for the number of threads to use, via OMP_NUM_THREADS. Completely disabling Hyperthreading normally requires setting the desired choice in the BIOS on your system at boot time.

The supplied Intel MKL libraries include additional environment variables to allow greater control of the threading within MKL. These are discussed at https://www.intel.com/content/www/us/en/docs/onemkl/developer-guide-linux/2023-0/onemkl-specific-env-vars-for-openmp-thread-ctrl.html. Many NAG routines make calls to routines within MKL, thus the MKL environment variables may indirectly affect the operation of the NAG Library as well. The default settings of the MKL environment variables should be suitable for most purposes, thus it is recommended that you do not explicitly set these variables. Please contact NAG for further advice if required.

3.2 Fortran Interface Blocks

The NAG Library interface blocks define the type and arguments of each user-callable NAG Library Fortran routine. While they are not essential to calling the NAG Library from Fortran programs, their use is highly recommended, and they are essential if the supplied examples are used.

Their purpose is to allow the Fortran compiler to check that NAG Library routines are called correctly. The interface blocks enable the compiler to check that:

(a)subroutines are called as such;
(b)functions are declared with the right type;
(c)the correct number of arguments are passed; and
(d)all arguments match in type and structure.

The NAG Library interface block files are organised by Library chapter. They are aggregated into one module named

  nag_library

The modules are supplied in compiled form (.mod files) for the Intel Classic Fortran Compiler. They can be accessed by specifying the -Ipathname option on each compiler invocation, where pathname ([INSTALL_DIR]/lp64/nag_interface_blocks or [INSTALL_DIR]/ilp64/nag_interface_blocks) is the path of the directory containing the compiled interface blocks for the required integer size.

The .mod module files were compiled with the Fortran compiler shown in Section 2.2 of the Installer's Note. Such module files are compiler-dependent, so if you wish to use the NAG example programs, or use the interface blocks in your own programs, when using a compiler that is incompatible with these modules, you will first need to recompile the interface blocks with your own compiler version. A recompiled set of interface blocks can be created in a separate directory (e.g. nag_interface_blocks_alt) using the supplied script command

  [INSTALL_DIR]/scripts/nag_recompile_mods {int32,int64} nag_interface_blocks_alt

from the [INSTALL_DIR] directory. This script uses the version of the Intel Classic Fortran compiler from your PATH environment; to specify an alternative version it is safest to first run any Intel Classic Fortran compiler environment scripts for that version prior to running [INSTALL_DIR]/scripts/nag_recompile_mods.

To make the new set of compiled modules the default set, it is first recommended that you generate a new set of modules for both integer sizes using both options {int32,int64} in separate calls to [INSTALL_DIR]/scripts/nag_recompile_mods. Then you may use the following commands (with [INSTALL_DIR] substituted by the actual directory path as appropriate) to change both default sets:

  mv [INSTALL_DIR]/lp64/nag_interface_blocks [INSTALL_DIR]/lp64/nag_interface_blocks_original
  mv [INSTALL_DIR]/lp64/nag_interface_blocks_alt [INSTALL_DIR]/lp64/nag_interface_blocks
  mv [INSTALL_DIR]/ilp64/nag_interface_blocks [INSTALL_DIR]/ilp64/nag_interface_blocks_original
  mv [INSTALL_DIR]/ilp64/nag_interface_blocks_alt [INSTALL_DIR]/ilp64/nag_interface_blocks

You should now be able to use the newly compiled module files in the usual way.

Currently it is not possible for users to recompile the interface blocks for the AD routines. If this is required, please contact NAG for support (see Section 7 for contact details).

3.3 Example Programs

The example results distributed were generated at Mark 30.1 using the software described in Section 2.2 of the Installer's Note. These example results may not be exactly reproducible if the example programs are run in a slightly different environment (for example, a different C or Fortran compiler, a different compiler run-time library, or a different set of BLAS or LAPACK routines). The results which are most sensitive to such differences are: eigenvectors (which may differ by a scalar multiple, often -1, but sometimes complex); numbers of iterations and function evaluations; and residuals and other "small" quantities of the same order as the machine precision.

The distributed example results are those obtained with the 32-bit integer static library libnag_mkl.a (i.e. using the MKL BLAS and LAPACK routines). Running the examples with NAG BLAS or LAPACK may give slightly different results.

The distributed NAG AD example results are those obtained with the 32-bit integer static libraries libnag_mkl.a and libnag_mkl_ad.a.

Note that the example material has been adapted, if necessary, from that published in the Library Manual, so that programs are suitable for execution with this implementation with no further changes. The distributed example programs should be used in preference to the versions in the Library Manual wherever possible. The example programs are most easily accessed by using the script nag_example, which is located in the directory [INSTALL_DIR]/scripts.

This script will provide you with a copy of an example program (and its data and options file, if any), compile the program and link it with the appropriate libraries. Finally, the executable program will be run (with appropriate arguments specifying data, options and results files as needed), with the results being sent to a file and to the command window. By default nag_example selects to use 32-bit integers and static linking to the self-contained libnag_nag.a library. These choices can be changed by optional switches -int64, -shared and -vendor respectively. The -quiet option may be specified to minimize printing of both comments and the commands being executed at each of the stages described above. Run

nag_example -help

to display a list of the available options.

The nag_example script demonstrates use of the nagvars script discussed in Section 3.1, but note that it does not alter the environment in the calling shell.

The example program concerned is specified by the argument to the command, e.g. for a NAG C routine

nag_example e04ucc

will copy the example program and its data and options files (e04ucce.c, e04ucce.d and e04ucce.opt) into the current directory, compile and link the program and run it to produce the example program results in the file e04ucce.r.

Similarly, for a NAG Fortran routine

nag_example e04nrf

will copy the example program and its data and options files (e04nrfe.f90, e04nrfe.d and e04nrfe.opt) into the current directory, compile and link the program and run it to produce the example program results in the file e04nrfe.r.

To run one of the examples for the NAG AD routines, the -ad flag must be added, e.g.

nag_example -ad s01ba_a1w_hcpp

Note that a few of the AD examples have a dependency on the file dco.hpp which is not shipped with this Library. Please contact NAG if you are interested in using these examples (see Section 7 for contact details).

If you already have the dco.hpp file and other dco/c++ files on your system, the environment variable DCODIR may be set to point to their location; if this has been done when the nagvars script is run, the DCODIR directory will be added to the include paths used in the compile commands.

3.4 Maintenance Level

The maintenance level of the Library can be determined by compiling and executing the example that calls a00aaf or a00aac, or you could call the nag_example script with the argument a00aaf or a00aac. See Section 3.3. This example prints out details of the implementation, including title and product code, compiler and precision used, mark and maintenance level.

3.5 C Data Types

In this implementation, libraries for both 32-bit and 64-bit integers are included.

For the 32-bit integer libraries (located in directory [INSTALL_DIR]/lp64/lib) the NAG C types Integer and Pointer are defined as follows:

NAG Type	C Type	Size (bytes)
Integer	int	4
Pointer	void *	8

For the 64-bit integer libraries (located in directory [INSTALL_DIR]/ilp64/lib) the NAG C types Integer and Pointer are defined as follows:

NAG Type	C Type	Size (bytes)
Integer	long	8
Pointer	void *	8

The values for sizeof(Integer) and sizeof(Pointer) are also given by the a00aac example program. Information on other NAG data types is available in Section 3.1.1 of the NAG CL Interface Introduction component of the Library Manual (see Section 5 below).

3.6 Fortran Data Types and Interpretation of Bold Italicised Terms

This implementation of the NAG Library includes libraries for both 32-bit integers (located in directory [INSTALL_DIR]/lp64/lib) and 64-bit integers (located in directory [INSTALL_DIR]/ilp64/lib).

The NAG Library and documentation use parameterized types for floating-point variables. Thus, the type

      REAL(KIND=nag_wp)

appears in the documentation of all NAG Library routines, where nag_wp is a Fortran KIND parameter. The value of nag_wp will vary between implementations, and its value can be obtained by use of the nag_library module. We refer to the type nag_wp as the NAG Library "working precision" type, because most floating-point arguments and internal variables used in the Library are of this type.

In addition, a small number of routines use the type

      REAL(KIND=nag_rp)

where nag_rp stands for "reduced precision" type. Another type, not currently used in the Library, is

      REAL(KIND=nag_hp)

for "higher precision" type or "additional precision" type.

For correct use of these types, see almost any of the example programs distributed with the Library.

For this implementation, these types have the following meanings:

      REAL (kind=nag_rp)      means REAL (i.e. single precision)
      REAL (kind=nag_wp)      means DOUBLE PRECISION
      COMPLEX (kind=nag_rp)   means COMPLEX (i.e. single precision complex)
      COMPLEX (kind=nag_wp)   means double precision complex (e.g. COMPLEX*16)

In addition, the FL Interface section of the Manual has adopted a convention of using bold italics to distinguish some terms. See Section 2.5 of the NAG FL Interface Introduction for details.

3.7 Calling NAG Fortran Routines from C/C++

With care, the Fortran routines in the NAG Library may be used from within a C, C++ or compatible environment. Using the Fortran routines in this manner may be preferable to calling the C routines, either to access a legacy Fortran routine for which a C routine equivalent is not available, or to have a lower level C interface, using only elementary C data types, which may be more convenient for use from other languages. To assist the user make the mapping between Fortran and C types, a description of the Fortran interface from a C perspective (the C Header Interface) is included in each Fortran routine document. C/C++ header files ([INSTALL_DIR]/lp64/include/nag.h for 32-bit integers and [INSTALL_DIR]/ilp64/include/nag.h for 64-bit integers) are also provided. It is recommended that users wishing to use a NAG Fortran routine in this manner #include the appropriate header file in their application.

A document, alt_c_interfaces.html, giving advice on calling the Fortran routines in the NAG Library from C and C++ is also available. (In previous Marks of the NAG Library, this document was called techdoc.html.)

3.8 C declarations for LAPACK, BLAS, etc.

The NAG C/C++ header files include declarations for the LAPACK, BLAS and BLAS Technical Forum (BLAST) routines included in the NAG Library. Users may prefer to get these definitions from the C include files associated with other libraries, e.g. the supplied Intel MKL. In these circumstances, to avoid clashes between the different C header declarations, the NAG declarations of these routines may be disabled by adding the compile flags:

  -DNAG_OMIT_LAPACK_DECLARATION -DNAG_OMIT_BLAS_DECLARATION -DNAG_OMIT_BLAST_DECLARATION

to the C or C++ compile statements described in Section 3.1. Declarations for the alternative NAG F01, F06, F07 and F08 routine names will remain.

4 Routine-specific Information

Any further information which applies to one or more routines in this implementation is listed below, chapter by chapter.

(a)F06, F07, F08 and F16
In Chapters F06, F07, F08 and F16, alternative routine names are available for BLAS and LAPACK derived routines. For details of the alternative routine names please refer to the relevant Chapter Introduction. Note that applications should reference routines by their BLAS/LAPACK names, rather than their NAG-style names, for optimum performance.

Many LAPACK routines have a "workspace query" mechanism which allows a caller to interrogate the routine to determine how much workspace to supply. Note that LAPACK routines from the MKL Library may require a different amount of workspace from the equivalent NAG reference versions of these routines. Care should be taken when using the workspace query mechanism.
In this implementation, calls to BLAS and LAPACK routines in the non-self-contained NAG libraries are implemented by calls to MKL, except for the following routines:
```
blas_damax_val  blas_damin_val  blas_daxpby     blas_ddot       blas_dmax_val
blas_dmin_val   blas_dsum       blas_dwaxpby    blas_zamax_val  blas_zamin_val
blas_zaxpby     blas_zsum       blas_zwaxpby
dbdsvdx dgesvdx dgesvj  dsbgvd  zgejsv  zgesvdx zgesvj  zhbgvd
```

(b)S07 - S21

The behaviour of functions in these Chapters may depend on implementation-specific values.

General details are given in the Library Manual, but the specific values used in this implementation are as follows:

s07aa[f] (nag[f]_specfun_tan)
    F_1 = 1.0e+13
    F_2 = 1.0e-14

s10aa[fc] (nag[f]_specfun_tanh)
    E_1 = 1.8715e+1
s10ab[fc] (nag[f]_specfun_sinh)
    E_1 = 7.080e+2
s10ac[fc] (nag[f]_specfun_cosh)
    E_1 = 7.080e+2

s13aa[fc] (nag[f]_specfun_integral_exp)
    x_hi = 7.083e+2
s13ac[fc] (nag[f]_specfun_integral_cos)
    x_hi = 1.0e+16
s13ad[fc] (nag[f]_specfun_integral_sin)
    x_hi = 1.0e+17

s14aa[fc] (nag[f]_specfun_gamma)
    ifail = 1 (NE_REAL_ARG_GT) if x > 1.70e+2
    ifail = 2 (NE_REAL_ARG_LT) if x < -1.70e+2
    ifail = 3 (NE_REAL_ARG_TOO_SMALL) if abs(x) < 2.23e-308
s14ab[fc] (nag[f]_specfun_gamma_log_real)
    ifail = 2 (NE_REAL_ARG_GT) if x > x_big = 2.55e+305

s15ad[fc] (nag[f]_specfun_erfc_real)
    x_hi = 2.65e+1
s15ae[fc] (nag[f]_specfun_erf_real)
    x_hi = 2.65e+1
s15ag[fc] (nag[f]_specfun_erfcx_real)
    ifail = 1 (NW_HI) if x >= 2.53e+307
    ifail = 2 (NW_REAL) if 4.74e+7 <= x < 2.53e+307
    ifail = 3 (NW_NEG) if x < -2.66e+1

s17ac[fc] (nag[f]_specfun_bessel_y0_real)
    ifail = 1 (NE_REAL_ARG_GT) if x > 1.0e+16
s17ad[fc] (nag[f]_specfun_bessel_y1_real)
    ifail = 1 (NE_REAL_ARG_GT) if x > 1.0e+16
    ifail = 3 (NE_REAL_ARG_TOO_SMALL) if 0 < x <= 2.23e-308
s17ae[fc] (nag[f]_specfun_bessel_j0_real)
    ifail = 1 (NE_REAL_ARG_GT) if abs(x) > 1.0e+16
s17af[fc] (nag[f]_specfun_bessel_j1_real)
    ifail = 1 (NE_REAL_ARG_GT) if abs(x) > 1.0e+16
s17ag[fc] (nag[f]_specfun_airy_ai_real)
    ifail = 1 (NE_REAL_ARG_GT) if x > 1.038e+2
    ifail = 2 (NE_REAL_ARG_LT) if x < -5.7e+10
s17ah[fc] (nag[f]_specfun_airy_bi_real)
    ifail = 1 (NE_REAL_ARG_GT) if x > 1.041e+2
    ifail = 2 (NE_REAL_ARG_LT) if x < -5.7e+10
s17aj[fc] (nag[f]_specfun_airy_ai_deriv)
    ifail = 1 (NE_REAL_ARG_GT) if x > 1.041e+2
    ifail = 2 (NE_REAL_ARG_LT) if x < -1.9e+9
s17ak[fc] (nag[f]_specfun_airy_bi_deriv)
    ifail = 1 (NE_REAL_ARG_GT) if x > 1.041e+2
    ifail = 2 (NE_REAL_ARG_LT) if x < -1.9e+9
s17dc[fc] (nag[f]_specfun_bessel_y_complex)
    ifail = 2 (NE_OVERFLOW_LIKELY) if abs(z) < 3.92223e-305
    ifail = 4 (NW_SOME_PRECISION_LOSS) if abs(z) or fnu+n-1 > 3.27679e+4
    ifail = 5 (NE_TOTAL_PRECISION_LOSS) if abs(z) or fnu+n-1 > 1.07374e+9
s17de[fc] (nag[f]_specfun_bessel_j_complex)
    ifail = 2 (NE_OVERFLOW_LIKELY) if AIMAG(z) > 7.00921e+2
    ifail = 3 (NW_SOME_PRECISION_LOSS) if abs(z) or fnu+n-1 > 3.27679e+4
    ifail = 4 (NE_TOTAL_PRECISION_LOSS) if abs(z) or fnu+n-1 > 1.07374e+9
s17dg[fc] (nag[f]_specfun_airy_ai_complex)
    ifail = 3 (NW_SOME_PRECISION_LOSS) if abs(z) > 1.02399e+3
    ifail = 4 (NE_TOTAL_PRECISION_LOSS) if abs(z) > 1.04857e+6
s17dh[fc] (nag[f]_specfun_airy_bi_complex)
    ifail = 3 (NW_SOME_PRECISION_LOSS) if abs(z) > 1.02399e+3
    ifail = 4 (NE_TOTAL_PRECISION_LOSS) if abs(z) > 1.04857e+6
s17dl[fc] (nag[f]_specfun_hankel_complex)
    ifail = 2 (NE_OVERFLOW_LIKELY) if abs(z) < 3.92223e-305
    ifail = 4 (NW_SOME_PRECISION_LOSS) if abs(z) or fnu+n-1 > 3.27679e+4
    ifail = 5 (NE_TOTAL_PRECISION_LOSS) if abs(z) or fnu+n-1 > 1.07374e+9

s18ad[fc] (nag[f]_specfun_bessel_k1_real)
    ifail = 2 (NE_REAL_ARG_TOO_SMALL) if 0 < x <= 2.23e-308
s18ae[fc] (nag[f]_specfun_bessel_i0_real)
    ifail = 1 (NE_REAL_ARG_GT) if abs(x) > 7.116e+2
s18af[fc] (nag[f]_specfun_bessel_i1_real)
    ifail = 1 (NE_REAL_ARG_GT) if abs(x) > 7.116e+2
s18dc[fc] (nag[f]_specfun_bessel_k_complex)
    ifail = 2 (NE_OVERFLOW_LIKELY) if abs(z) < 3.92223e-305
    ifail = 4 (NW_SOME_PRECISION_LOSS) if abs(z) or fnu+n-1 > 3.27679e+4
    ifail = 5 (NE_TOTAL_PRECISION_LOSS) if abs(z) or fnu+n-1 > 1.07374e+9
s18de[fc] (nag[f]_specfun_bessel_i_complex)
    ifail = 2 (NE_OVERFLOW_LIKELY) if REAL(z) > 7.00921e+2
    ifail = 3 (NW_SOME_PRECISION_LOSS) if abs(z) or fnu+n-1 > 3.27679e+4
    ifail = 4 (NE_TOTAL_PRECISION_LOSS) if abs(z) or fnu+n-1 > 1.07374e+9

s19aa[fc] (nag[f]_specfun_kelvin_ber)
    ifail = 1 (NE_REAL_ARG_GT) if abs(x) >= 5.04818e+1
s19ab[fc] (nag[f]_specfun_kelvin_bei)
    ifail = 1 (NE_REAL_ARG_GT) if abs(x) >= 5.04818e+1
s19ac[fc] (nag[f]_specfun_kelvin_ker)
    ifail = 1 (NE_REAL_ARG_GT) if x > 9.9726e+2
s19ad[fc] (nag[f]_specfun_kelvin_kei)
    ifail = 1 (NE_REAL_ARG_GT) if x > 9.9726e+2

s21bc[fc] (nag[f]_specfun_ellipint_symm_2)
    ifail = 3 (NE_REAL_ARG_LT) if an argument < 1.583e-205
    ifail = 4 (NE_REAL_ARG_GE) if an argument >= 3.765e+202
s21bd[fc] (nag[f]_specfun_ellipint_symm_3)
    ifail = 3 (NE_REAL_ARG_LT) if an argument < 2.813e-103
    ifail = 4 (NE_REAL_ARG_GT) if an argument >= 1.407e+102

(c)X01

The values of the mathematical constants are:

x01aa[fc] (nag[f]_math_pi)
     = 3.1415926535897932
x01ab[fc] (nag[f]_math_euler)
     = 0.5772156649015328

(d)X02

The values of the machine constants are:

The basic parameters of the model

x02bh[fc] (nag[f]_machine_model_base)
     = 2
x02bj[fc] (nag[f]_machine_model_digits)
     = 53
x02bk[fc] (nag[f]_machine_model_minexp)
     = -1021
x02bl[fc] (nag[f]_machine_model_maxexp)
     = 1024

Derived parameters of the floating-point arithmetic

x02aj[fc] (nag[f]_machine_precision)
     = 1.11022302462516e-16
x02ak[fc] (nag[f]_machine_real_smallest)
     = 2.22507385850721e-308
x02al[fc] (nag[f]_machine_real_largest)
     = 1.79769313486231e+308
x02am[fc] (nag[f]_machine_real_safe)
     = 2.22507385850721e-308
x02an[fc] (nag[f]_machine_complex_safe)
     = 2.22507385850721e-308

Parameters of other aspects of the computing environment

x02ah[fc] (nag[f]_machine_sinarg_max)
     = 1.42724769270596e+45
x02bb[fc] (nag[f]_machine_integer_max)
     =          2147483647 (for 32-bit integer libraries)
     = 9223372036854775807 (for 64-bit integer libraries)
x02be[fc] (nag[f]_machine_decimal_digits)
     = 15

(e)X04
Fortran routines: The default output units for error and advisory messages for those routines which can produce explicit output are both Fortran Unit 6.
(f)X06
Chapter X06 routines do not change the behaviour of MKL threading in this implementation of the Library.

5 Documentation

The Library Manual is accessible via the NAG website at NAG Library Manual, Mark 30.1.

The Library Manual is supplied in HTML5, a fully linked version of the manual using HTML and MathML. These documents can be accessed using your web browser.

Advice on viewing and navigating the documentation can be found in Guide to the NAG Library Documentation.

In addition the following are provided:

in.html – Installer's Note
un.html – Users' Note (this document)
alt_c_interfaces.html – Advice on calling the Fortran routines in the NAG Library from C and C++

6 Support from NAG

Please see

NAG Technical Support Service

for information about the NAG Technical Support Service, including details of the NAG Technical Support Service contact points. We would also be delighted to receive your feedback on NAG's products and services.