Known Issues for the NAG Library FL Interface
This document reflects all reported and resolved issues that affect various releases of the NAG Library FL Interface up to Mark 27.1.
Some of these issues may have been fixed at intermediate "point" releases of the Library, while other fixes are scheduled for incorporation at future releases. For library Marks where those fixes are not yet incorporated, a workaround for the known issue is provided wherever possible.
To find the Mark and point release number of your library, call NAG routine a00aaf( ).
Synopsis  Overflow may occur if the routine attempts to scale the polynomial coefficients. 
Description  In rare circumstances overflow may be observed if ${\mathbf{scal}}=\mathrm{.TRUE.}$. 
Severity  Noncritical 
Issue Since Mark  16 
Workaround  Set argument ${\mathbf{scal}}=\mathrm{.FALSE.}$. 
Synopsis  Routine c05adf exhibits unpredictable (and incorrect) behaviour. 
Description  Certain smooth and continuous test functions can cause the routine to behave in an unpredictable manner, including homing in to a zero outside the specified interval or wildly oscillating and generating NaNs. 
Severity  Critical 
Issue Since Mark  22.1 
Fixed at Mark  22.2 
Workaround  None. 
Synopsis  ${\mathbf{iflag}}$ not set on entry to ${\mathbf{fcn}}$ in c05qsf. 
Description  The argument ${\mathbf{iflag}}$ to ${\mathbf{fcn}}$ in c05qsf is never initialized internally, but its value on exit from ${\mathbf{fcn}}$ is tested to determine whether user termination has been requested. 
Severity  Critical 
Issue Since Mark  23 
Fixed at Mark  23.1 
Workaround  If you wish to continue execution, always set ${\mathbf{iflag}}$ to a positive value in ${\mathbf{fcn}}$. 
Synopsis  Multilevel wavelets cannot handle periodic end extension. 
Description  When ${\mathbf{mode}}=\text{'P'}$ and ${\mathbf{wtrans}}=\text{'M'}$ the multilevel wavelet transform routines do not work properly if $n$ is not a power of 2. 
Severity  Noncritical 
Issue Since Mark  22 
Fixed at Mark  23 
Workaround  The option combination of a multilevel wavelet transform using a periodic end extension is currently disallowed; a call to the initialization routine c09aaf with this combination will return with an error code.
For multilevel analysis of periodic data, you are advised to experiment with the alternative end conditions; the periodic property of the data can also be used to extend the data set in both directions to points that better suit the alternative end condition (e.g., extend the data to next maximum or minimum).

Synopsis  Initialization and option setting does not work when using the long name. 
Description  Initialization and option setting for the sparse grid routine d01esf (nagf_quad_md_sgq_multi_vec) using d01zkf (nagf_quad_opt_set) does not work when using the long name nagf_quad_md_sgq_multi_vec in the option string.
It does work when using the short name d01esf in the option string.

Severity  Noncritical 
Issue Since Mark  25 
Fixed at Mark  25.2 
Workaround  Initializing and setting options for d01esf (nagf_quad_md_sgq_multi_vec) via calls to d01zkf (nagf_quad_opt_set) should use option strings containing the short name d01esf rather than the long name. 
Synopsis  Segmentation faults when optional parameter ${\mathbf{Index\; Level}}$ is set to a value greater than ${m}_{q}$. 
Description  Segmentation faults or other array bound violation problems may occur if the value of ${\mathbf{Index\; Level}}$ (set via a call to d01zkf) is greater than ${m}_{q}$, the maximum level of the underlying quadrature rule. 
Severity  Critical 
Issue Since Mark  25 
Fixed at Mark  25.4 
Workaround  Do not set ${\mathbf{Index\; Level}}$ to more than 9 when using Gauss–Patterson or more than 12 when using Clenshaw–Curtis. 
Synopsis  ${\mathbf{Quadrature\; Rule}}=\mathrm{GP}$ is not accepted as a valid option. 
Description  When setting the quadrature rule for d01esf using the d01zkf option setting routine, the documented choice ${\mathbf{Quadrature\; Rule}}=\mathrm{GP}$ is not recognised as a valid option and an error is reported. 
Severity  Noncritical 
Issue Since Mark  25 
Fixed at Mark  25.4 
Workaround  The alternatives ${\mathbf{Quadrature\; Rule}}=\mathrm{GaussPatterson}\text{}\text{or}\mathrm{GPATT}$ may be used instead.
Note: GaussPatterson is the default choice for the quadrature rule in d01esf, so in general it will not be necessary to specify this option.

Synopsis  Stack size or thread safety problems may be observed with some d06 routines. 
Description  d06aaf, d06abf and d06acf contain large local arrays that may cause stack size and/or thread safety problems. 
Severity  Critical 
Issue Since Mark  20 
Fixed at Mark  24 
Workaround  Do not use these routines in a multithreaded environment. For serial execution, set stack size limit to 10MB or greater. 
Synopsis  Although the documented constraint on ${\mathbf{nvmax}}$ is ${\mathbf{nvmax}}\ge {\mathbf{nvb}}+{\mathbf{nvint}}$, the actual required minimum for ${\mathbf{nvmax}}$ is ${\mathbf{nvb}}+{\mathbf{nvint}}+12$.
For some small scale problems, setting ${\mathbf{nvmax}}={\mathbf{nvb}}+{\mathbf{nvint}}$ will give unpredictable results and could produce a segmentation fault.

Description  Although the documented constraint on ${\mathbf{nvmax}}$ is ${\mathbf{nvmax}}\ge {\mathbf{nvb}}+{\mathbf{nvint}}$, the actual required minimum for ${\mathbf{nvmax}}$ is ${\mathbf{nvb}}+{\mathbf{nvint}}+12$.
For some small scale problems, setting ${\mathbf{nvmax}}={\mathbf{nvb}}+{\mathbf{nvint}}$ will give unpredictable results and could produce a segmentation fault.
The problem is remedied by setting ${\mathbf{nvmax}}={\mathbf{nvb}}+{\mathbf{nvint}}+12$ and ensuring that the arrays ${\mathbf{coor}}$ and ${\mathbf{conn}}$ are correspondingly large enough.

Severity  Critical 
Issue Since Mark  20 
Fixed at Mark  26 
Workaround  Set ${\mathbf{nvmax}}\ge {\mathbf{nvb}}+{\mathbf{nvint}}+12$; declare or allocate the arrays ${\mathbf{coor}}$ and ${\mathbf{conn}}$ using this value of ${\mathbf{nvmax}}$; increase the lengths of the work arrays ( ${\mathbf{rwork}}$ and ${\mathbf{iwork}}$) to account for the increase in the value of ${\mathbf{nvint}}$. 
Synopsis  d06abf, d06acf and d06baf may crash if ${\mathbf{itrace}}>1$. 
Description  Setting argument ${\mathbf{itrace}}>1$ in calls of any of d06abf, d06acf and d06baf causes failure with a runtime error due to record overflow  values are written into a string which is not big enough. 
Severity  Critical 
Issue Since Mark  22.1 
Fixed at Mark  22.2 
Workaround  Argument ${\mathbf{itrace}}$ is used to get printed information about a generated grid. The only workaround is to use values of ${\mathbf{itrace}}\le 1$. 
Synopsis  d06abf and d06acf array bound violation. 
Description  Calls to d06abf and d06acf could, potentially, perform memory overwrites leading to unpredictable behaviour. This is due to the possibility of writes to the array argument ${\mathbf{coor}}$ of d06abf and d06acf outside of its declared bounds; this could occur when the argument ${\mathbf{nvmax}}$ is set to a value less than ${\mathbf{nvb}}+{\mathbf{nvint}}+12$ for calls to d06abf or to a value less than ${\mathbf{nvb}}+{\mathbf{nvint}}+13$ for calls to d06acf. 
Severity  Critical 
Issue Since Mark  22 
Fixed at Mark  22.1 
Workaround  Increase the value of ${\mathbf{nvmax}}$ to be at least ${\mathbf{nvb}}+{\mathbf{nvint}}+12$ when calling d06abf and to be at least ${\mathbf{nvb}}+{\mathbf{nvint}}+13$ when calling d06acf. This will ensure that no array bound violations for ${\mathbf{coor}}$ are possible. 
Synopsis  The algorithm underlying interpolation routines e01sgf, e01shf, e01tgf and e01thf was modified at Mark 26 and Mark 26.1; different results will be obtained when using these routines than previously. 
Description  The algorithm underlying interpolation routines e01sgf, e01shf, e01tgf and e01thf was modified at Mark 26 to improve perceived deficiencies. In particular, at earlier library Marks the evaluation routines would not attempt to return any useful result if an evaluation point was not close enough to any of the original data points, and this issue was addressed at Mark 26.
At Mark 26.1 further work was done on the routines because they had been found not to work well on gridded data sets (as opposed to the random data sets that they are primarily intended for).
It should be noted that because of the various underlying changes to the routines, the precise results returned from Mark 26 onwards will not usually be identical to those before Mark 26.

Severity  Noncritical 
Issue Since Mark  26 
Fixed at Mark  26.1 
Workaround  Not applicable. 
Synopsis  e01shf will occasionally incorrectly identify a point as being outside the region defined by the interpolant. 
Description  e01shf will occasionally incorrectly identify a point as being outside the region defined by the interpolant. This leads to the function value being extrapolated rather than interpolated and can lead to incorrect results. 
Severity  Noncritical 
Issue Since Mark  26.0 
Fixed at Mark  27.1 
Workaround  None. 
Synopsis  Incorrect computation and potential illegal memory read may occur with ${\mathbf{start}}=10\text{}\text{or}11$ and ${\mathbf{xord}}=1$. 
Description  When using ${\mathbf{start}}=10\text{}\text{or}11$ and ${\mathbf{xord}}=1$, if any abscissae are outside the valid section of the spline (i.e., ${\mathbf{ixloc}}<4$ or ${\mathbf{ixloc}}>{\mathbf{ncap7}}3$) and the ordering of the segment groups of abscissae is insufficient, some valid abscissae will not be evaluated and the evaluation of some invalid abscissae will be attempted. Specifically, if there are NLOWER abscissae with ${\mathbf{ixloc}}<4$ and NUPPER abscissae with ${\mathbf{ixloc}}>{\mathbf{ncap7}}3$, then all abscissae with index $i$ satisfying $\mathrm{NLOWER}<i\le {\mathbf{nx}}\mathrm{NUPPER}$ will be evaluated, and all other abscissae will not be evaluated. Hence if (the provided or computed) ${\mathbf{ixloc}}$ is not ordered as $\left[{\mathbf{ixloc}}<4,4\le {\mathbf{ixloc}}\le {\mathbf{ncap7}}3,{\mathbf{ixloc}}>{\mathbf{ncap7}}3\right]$, i.e., any lower invalid points are at the start and any invalid upper points are at the end, then some incorrect computation will be performed. If any lower invalid points are not at the start, then an illegal data read of ${\mathbf{c}}$ before its first element will be performed. 
Severity  Critical 
Issue Since Mark  24 
Fixed at Mark  25 
Workaround  Either order the abscissae so that any lower invalid points are at the start and any upper invalid points are at the end, or do not use ${\mathbf{xord}}=1$ with ${\mathbf{start}}=10\text{}\text{or}11$. 
Synopsis  Illconditioned data sets may cause e02gaf to get stuck in an infinite loop. 
Description  Certain illconditioned data sets could cause e02gaf to get stuck in an infinite loop. 
Severity  Critical 
Issue Since Mark  16 
Fixed at Mark  26 
Workaround  As a workaround, it may be possible to avoid the infinite loop by reordering the points in the input data. 
Synopsis  No check that a mandatory call to the initialization routine has been made. 
Description  Whilst it is necessary to call initialization routine e04wbf prior to calling the named e04 routines, no software check is made to ensure that this has happened. 
Severity  Noncritical 
Issue Since Mark  20 
Workaround  Ensure that initialization routine e04wbf has been called. 
Synopsis  Internal buffer overflow in e04fcf. 
Description  When the grade of the optimization problem drops to zero, an internal buffer overflow occurs. This destroys some of the internal state of the optimizer, typically causing it to stop prematurely.
Scope of the problem:
If the grade of the optimization problem is nonzero on exit from e04fcf, then the bug is not triggered and that particular optimization is unaffected. If the grade is zero on exit, then the optimization is affected in all supported FL marks. (Note: the grade can be observed by setting ${\mathbf{iprint}}=1$ and using e04fdz).
How the problem manifests:
Optimization terminates prematurely, usually with ${\mathbf{ifail}}={\mathbf{3}}$. Note: an exit with ${\mathbf{ifail}}={\mathbf{3}}$ does not on its own indicate that an optimization is affected by the bug.
Severity:
Since the solver is typically close to convergence when the grade drops to zero, the returned solution is usually pretty good. The bug fix is unlikely to improve the results of e04fcf significantly.

Severity  Noncritical 
Issue Since Mark  16 
Fixed at Mark  24.5 
Workaround  There is no practical workaround. 
Synopsis  In very rare cases, the algorithm used by e04lbf may become trapped in an infinite loop. 
Description  The routine might lock itself in an infinite loop when a variable lying on the boundary is cyclically added and removed to/from free variables. This can happen only at points with indefinite Hessian and very small projected gradients when one variable is lying on the boundary and another one is very close to it. 
Severity  Critical 
Issue Since Mark  16 
Fixed at Mark  25 
Workaround  Unfortunately there is no convenient workaround. 
Synopsis  ${\mathbf{stats}}$ and ${\mathbf{rinfo}}$ were not correctly filled by the presolver. 
Description  The arrays ${\mathbf{stats}}$ and ${\mathbf{rinfo}}$ were not correctly filled when the problem was entirely solved by the presolver. It now returns the correct values.
The optional parameter ${\mathbf{Print\; Solution}}$ now correctly writes the linear constraints dual variables when no bounds are defined on the variables.

Severity  Noncritical 
Issue Since Mark  26.1 
Fixed at Mark  27 
Workaround  Don't rely on ${\mathbf{rinfo}}\left(1\right),{\mathbf{rinfo}}\left(2\right)$ to hold the primal and dual objective in this case and recompute it as ${c}^{\prime}x$ and $by$, respectively. 
Synopsis  e04mtf does not report the correct solution when $3$ or more columns are proportional to each other in the constraint matrix. 
Description  e04mtf does not report the correct solution when $3$ or more columns are proportional to each other in the constraint matrix. In such a case, the solution reported may be infeasible. 
Severity  Noncritical 
Issue Since Mark  26.1 
Fixed at Mark  27 
Workaround  A workaround is to disable the more complex presolve operations by setting the optional parameter ${\mathbf{LP\; Presolve}}=\mathrm{BASIC}$. This may slow down the solver depending on the problem. 
Synopsis  In some very rare cases, the solution reported presents big violations on a small number of linear constraints. 
Description  In some very rare cases, the solution reported presents big violations on a small number of linear constraints. 
Severity  Noncritical 
Issue Since Mark  26.1 
Fixed at Mark  27.1 
Workaround  A workaround is to deactivate the more complex presolver operations with the optional parameter ${\mathbf{LP\; Presolve}}=\mathrm{BASIC}$. 
Synopsis  Infeasible bounds defined by e04rjf of a variable are ignored and infeasibility is not reported. 
Description  When infeasible bounds are defined by e04rjf for a variable, instead of reporting problem infeasibility, the bounds are overridden and wrong solution may be reported. 
Severity  Noncritical 
Issue Since Mark  26.1 
Fixed at Mark  27.1 
Workaround  A workaround is to deactivate the more complex presolver operations with the optional parameter ${\mathbf{LP\; Presolve}}=\mathrm{BASIC}$ for e04mtf and ${\mathbf{SOCP\; Presolve}}=\mathrm{BASIC}$ for e04ptf. 
Synopsis  Insufficient estimates of problem size might lead to crash. 
Description  In some circumstances when calling e04mxf not in query mode, internal memory overwrites may occur, possibly causing program crash. 
Severity  Critical 
Issue Since Mark  24 
Fixed at Mark  25 
Workaround  Call e04mxf in query mode first to get good upper estimates of the problem size. 
Synopsis  Actual array size required is underestimated. 
Description  Sometimes the suggested array size returned in parameter ${\mathbf{miniz}}$ is underestimated. 
Severity  Critical 
Issue Since Mark  22 
Fixed at Mark  24 
Workaround  Increase the size of array ${\mathbf{iz}}$ and the value of ${\mathbf{leniz}}$ accordingly. 
Synopsis  Internal file overflow. 
Description  If you set a ${\mathbf{New\; Basis\; File}}$ in e04nqf, e04vhf and e04wdf and your total problem size ( ${\mathbf{n}}+{\mathbf{m}}$, ${\mathbf{n}}+{\mathbf{nf}}$ or ${\mathbf{n}}+{\mathbf{nclin}}+{\mathbf{ncnln}}$, respectively) is greater than 80 you will experience an internal buffer overflow and possible program crash. 
Severity  Critical 
Issue Since Mark  22.3 
Fixed at Mark  23 
Workaround  Unfortunately there is no convenient workaround. The only way to avoid this crash is to not specify a ${\mathbf{New\; Basis\; File}}$ or to have a small enough problem. 
Synopsis  Optional parameters ${\mathbf{List}}$ and ${\mathbf{Nolist}}$ are not handled correctly. 
Description  Routines e04nrf, e04vkf and e04wef do not handle optional parameters ${\mathbf{List}}$ and ${\mathbf{Nolist}}$ correctly. Specifying ${\mathbf{List}}$ does not alter the behaviour of subsequent routines in the suite, and specifying ${\mathbf{Nolist}}$ erroneously reports an error. 
Severity  Noncritical 
Issue Since Mark  8 
Fixed at Mark  27.3 
Workaround  Routine e04nsf should be used instead to set optional parameters ${\mathbf{List}}$ or ${\mathbf{Nolist}}$. 
Synopsis  ${\mathbf{List}}$ option does not work. 
Description  Call e04nsf('List',cw,iw,rw,ifail) fails to cause the options subsequently set to be echoed. 
Severity  Noncritical 
Issue Since Mark  23 
Fixed at Mark  23.2 
Workaround  Unfortunately there is no convenient workaround. 
Synopsis  Wrong Intent for ${\mathbf{cpuser}}$ argument in NAG Ipopt solver. 
Description  The explicit Fortran interface blocks for e04stf and its associated user procedures mistakenly advertise their ${\mathbf{cpuser}}$ argument as Intent (Inout).
The argument should be Intent (In): you may modify any data for which you are using ${\mathbf{cpuser}}$ as a handle, but you must not change the handle itself.

Severity  Noncritical 
Issue Since Mark  26 
Fixed at Mark  26.1 
Workaround  In user procedures supplied to e04stf that have explicit interfaces, change ${\mathbf{cpuser}}$ to have Intent (In). 
Synopsis  e04stf returns Lagrangian multipliers in the wrong order. 
Description  The Lagrangian multipliers returned in ${\mathbf{u}}$ are in the wrong order:

Severity  Noncritical 
Issue Since Mark  26 
Fixed at Mark  26.1 
Workaround  The order described in the documentation is now used. 
Synopsis  Insufficient space in ${\mathbf{work}}$ array might lead to a crash. 
Description  Insufficient space in ${\mathbf{work}}$ array might lead to a crash, this is particularly likely if ${\mathbf{lwork}}<{\mathbf{n}}+{\mathbf{ncnln}}+2$. 
Severity  Noncritical 
Issue Since Mark  18 
Fixed at Mark  26.1 
Workaround  Provide sufficient size as recommended in the documentation. 
Synopsis  When the objective function has no separated linear part, using userdefined names for variables and constraints might lead to a crash. 
Description  When the objective function only has the nonlinear part defined without a separated linear part, the solver might crash when trying to read userdefined names for variables and constraints. 
Severity  Critical 
Issue Since Mark  21 
Fixed at Mark  27.1 
Workaround  Unfortunately there is no convenient workaround. The only way to avoid this crash is to not specify names for variables and constraints. 
Synopsis  Information about the last constraint might not be printed. 
Description  If the problem has a nonlinear objective function without a linear part and ${\mathbf{objrow}}<{\mathbf{nf}}$, the last constraint is not printed in the final information about the solution (Rows section). 
Severity  Noncritical 
Issue Since Mark  21 
Fixed at Mark  26 
Workaround  None. 
Synopsis  Setting the optional parameters ${\mathbf{List}}$ or ${\mathbf{Nolist}}$ for e04vhf (using e04vlf) or for e04wdf (using e04wff) results in an erroneous exit flag and, potentially, undefined behaviour. 
Description  Enabling or disabling echoing of optional parameters to e04vhf as they are set, by specifying
Call e04vlf('List',iw,rw,ifail)or Call e04vlf('Nolist',iw,rw,ifail)results in an internal exit flag being set. This erroneous, undefined, error flag is then returned as an ${\mathbf{ifail}}$ by e04vhf. 
Severity  Noncritical 
Issue Since Mark  23 
Fixed at Mark  23.2 
Workaround  Unfortunately there is no convenient workaround using NAG Fortran Library routines, but it is possible to set an element of the ${\mathbf{iw}}$ array to enable or disable listing. To enable listing (equivalent to setting ${\mathbf{List}}$) set ${\mathbf{iw}}\left(502\right)=1$ and to disable listing ( ${\mathbf{Nolist}}$) set ${\mathbf{iw}}\left(502\right)=0$. 
Synopsis  Usersupplied character strings containing spaces may cause garbled error messages. 
Description  Some routines produce error messages containing character data that has been supplied through the argument ${\mathbf{List}}$ by the user. An example is e04vhf, where the ${\mathbf{}}$ or ${\mathbf{}}$ can be referred to in error messages. Having spaces in these strings confuses the internal errormessage splitter, which splits on spaces. Thus, error messages returned by the routine may be garbled. 
Severity  Noncritical 
Issue Since Mark  22 
Fixed at Mark  23 
Workaround  Make sure userprovided character data is without spaces 
Synopsis  Attempt to write too many characters to a record in a routine called by e04xaf/e04xaa. 
Description  Call e04xaf/e04xaa with ${\mathbf{msglvl}}=2$ and a compiler runtime error may occur. 
Severity  Critical 
Issue Since Mark  22.1 
Fixed at Mark  22.2 
Workaround  Don't call e04xaf/e04xaa with ${\mathbf{msglvl}}=2$. 
Synopsis  Arrayoutofbounds error in routine called by e05jbf. 
Description  When using initialization method ${\mathbf{iinit}}=4$ with infinite bounds ${\mathbf{bl}}$ and ${\mathbf{bu}}$, and when the number of randomlygenerated initialization points (which will always be between 3 and ${\mathbf{sdlist}}$) is greater than ${\mathbf{n}}$, NaNs may be created in the initialization data, which makes the initializer enter into an infinite loop. 
Severity  Critical 
Issue Since Mark  22 
Fixed at Mark  22.1 
Workaround  Use finite bounds when ${\mathbf{iinit}}=4$. 
Synopsis  Crash may occur when the real value does not contain a decimal point, e.g., when 1E5 is passed as the real value. 
Description  When setting a real valued optional parameter using either e05jcf or e05jdf, if the real value contained in the string is in exponential format without a decimal point (for example 1E5 as opposed to 1.0E5), an unrecoverable crash may occur. 
Severity  Critical 
Issue Since Mark  23 
Fixed at Mark  23.1 
Workaround  Real values contained in the optional parameter string should always include a decimal point. 
Synopsis  Gradient check is incorrect and will fail or enter infinite loop. 
Description  Error in ${\mathbf{objfun}}$ gradient checking when using either e05saf or e05sbf in conjunction with e04dgf/e04dga or e04kzf as the local minimizer. 
Severity  Critical 
Issue Since Mark  23 
Fixed at Mark  23.1 
Workaround  Simply disabling gradient checking will allow the algorithm to continue unhindered. Alternatively, using e04ucf/e04uca as the local minimizer will test the gradients provided in ${\mathbf{objfun}}$ correctly. 
Synopsis  Optional parameter values can be set incorrectly. 
Description  If optional parameter ${\mathbf{Local\; Interior\; Iterations}}=0$ is set then this will also, incorrectly, disable local exterior iterations. 
Severity  Noncritical 
Issue Since Mark  23 
Fixed at Mark  23.2 
Workaround  If no internal local minimization is required, set optional parameter ${\mathbf{Local\; Interior\; Iterations}}=1$. 
Synopsis  Unpredictable behaviour if e05sbf is called with ${\mathbf{ncon}}\ge {\mathbf{ndim}}+2$. 
Description  Attempting to solve nonlinearly constrained problems where the number of constraints is greater than the number of dimensions may lead to unpredictable behaviour. 
Severity  Critical 
Issue Since Mark  23 
Fixed at Mark  23.2 
Workaround  Increasing ${\mathbf{ndim}}$ to be greater than ${\mathbf{ncon}}$, and setting all additional box bounds to equality will prevent the error. This will unfortunately come at a cost of efficiency in the routine. 
Synopsis  Crash may occur when the real value does not contain a decimal point, e.g., when 1E5 is passed as the real value. 
Description  When setting a real valued optional parameter using e05zkf, if the real value contained in the string is in exponential format without a decimal point (for example 1E5 as opposed to 1.0E5), an unrecoverable crash may occur. 
Severity  Critical 
Issue Since Mark  23 
Fixed at Mark  23.1 
Workaround  Real values contained in the optional parameter string should always include a decimal point. 
Synopsis  Parsing an optional parameter string may incorrectly identify a token as numeric. 
Description  e05zkf may incorrectly identify strings, that may be numeric in exponential format, as numeric when they should be interpreted as strings. The exact circumstance under which this error may occur cannot be defined and it is unlikely to occur in practice. 
Severity  Critical 
Issue Since Mark  23 
Fixed at Mark  23.1 
Workaround  Avoid using optional parameter strings that contain substrings such as ‘E05’, ‘+D01’, ‘.E15’, …, as input. 
Synopsis  An error message issued by the routine may be garbled. 
Description  When called with data which is incompatible with the matrix factorized by the previous call of f01brf, f01bsf will return ${\mathbf{ifail}}={\mathbf{5}}$, but the associated printed message may be garbled. 
Severity  Noncritical 
Issue Since Mark  19 
Fixed at Mark  25 
Workaround  Avoid supplying incompatible data to f01bsf. 
Synopsis  Multithreaded versions of the routines f11bef, f11bsf, f11gef and f11gsf may produce slightly different results when run on multiple threads. 
Description  Multithreaded versions of the routines f11bef, f11bsf, f11gef and f11gsf may produce slightly different results when run on multiple threads, e.g., the number of iterations to solution and the computed matrix norms and termination criteria reported by the associated monitoring routines. A bug affecting f11bef and f11gef has been fixed, and parallel vector dot products have been modified in all routines to improve consistency of results. 
Severity  Noncritical 
Issue Since Mark  19 
Fixed at Mark  27.1 
Workaround  None. 
Synopsis  f16rbf and f16ubf return $0$ if ${\mathbf{kl}}$ or ${\mathbf{ku}}$ is $0$, instead of the correct norm. ${\mathbf{ldab}}$ is incorrectly forced to be at least ${\mathbf{m}}$ when $m=n$. 
Description  f16rbf and f16ubf mistakenly make a quick return if ${\mathbf{kl}}$ or ${\mathbf{ku}}$ is $0$, instead of computing the correct value for the requested norm. Also, ${\mathbf{ldab}}$ is incorrectly forced to be at least ${\mathbf{m}}$ when $m=n$. 
Severity  Critical 
Issue Since Mark  23 
Fixed at Mark  27.3 
Workaround  None. 
Synopsis  The returned matrix is not a valid correlation matrix. 
Description  The algorithm computes an incorrect value for ${\mathbf{alpha}}$. Thus the returned matrix is not positive definite as stated, and is not a valid correlation matrix. 
Severity  Critical 
Issue Since Mark  25 
Fixed at Mark  25.3 
Workaround  Unfortunately there is no convenient workaround. 
Synopsis  Incorrect results are returned when performing a Mallows type regression. 
Description  Incorrect results are returned when performing a Mallows type regression, averaging over residuals. 
Severity  Noncritical 
Issue Since Mark  16 
Fixed at Mark  26.1 
Workaround  None. 
Synopsis  Segmentation fault caused by access past the end of an array. 
Description  An error can occur when there are multiple blocks of random variables, at least one with a subject variable and at least one without. The error can only occur when the block with the subject variable occurs first in ${\mathbf{rndm}}$. 
Severity  Critical 
Issue Since Mark  23 
Fixed at Mark  25 
Workaround  Ensure that blocks without subject variables appear in ${\mathbf{rndm}}$ before those with subject variables. 
Synopsis  In very rare cases, the routine may become trapped in an infinite loop. 
Description  The routine was affected by a bug in the underlying solver e04lbf (modified Newton method). In very rare cases the solver might get into an infinite loop. 
Severity  Critical 
Issue Since Mark  23 
Fixed at Mark  25 
Workaround  The bug can be avoided by switching to the other optimizer (SQP method e04ucf/e04uca, ${\mathbf{iopt}}\left(5\right)=1$). 
Synopsis  A segmentation fault is likely to occur if a model with multiple random statements is supplied to the routine, where at least one of those statements does not have a ${\mathbf{Subject}}$ term. 
Description  A segmentation fault is likely to occur if a model with multiple random statements is supplied to the routine, where at least one of those statements does not have a ${\mathbf{Subject}}$ term.
For example, a model specified using:
V1 + V2 / SUBJECT = V3 V4 + V5 / SUBJECT = V6would not trigger the error, but one specified using: V1 + V2 V4 + V5 / SUBJECT = V6would. The error is not triggered when there is only a single random statement, so a model specified using just
V1 + V2will not trigger the error. 
Severity  Critical 
Issue Since Mark  27 
Fixed at Mark  27.1 
Workaround  A workaround to this issue is to always supply a ${\mathbf{Subject}}$ term. If the required model is of the form:
V1 + V2 V4 + V5 / SUBJECT = V6then you can specify an equivalent model by using: V1 + V2 / SUBJECT = DUMMY V4 + V5 / SUBJECT = V6where the variable 
Synopsis  Returns incorrect results when ${\mathbf{ntau}}>1$ and user supplied initial values for ${\mathbf{b}}$ are being used. 
Description  If ${\mathbf{ntau}}>1$, the optional parameter ${\mathbf{Calculate\; Initial\; Values}}=\mathrm{NO}$ is set, and the rows of array $B$ are not all identical, then the results returned by g02qgf are incorrect. 
Severity  Critical 
Issue Since Mark  23 
Fixed at Mark  24 
Workaround  Rather than call the routine once with ${\mathbf{ntau}}>1$, call the routine multiple times with ${\mathbf{ntau}}=1$, analysing a different value of ${\mathbf{tau}}$ on each call. 
Synopsis  When run on multiple threads, the Mersenne Twister generator present in g05saf and other associated g05 routines may not give the expected sequence on the second and subsequent calls (after initialization) to the routine. 
Description  The NAG Mersenne Twister pseudorandom number generator is used within g05saf and other g05 routines. The size, ${\mathbf{lstate}}$, of the ${\mathbf{state}}$ array used by this generator is 633 as a minimum and 1260 if the skipahead functionality is desired. See the document for g05kff for further details.
When using the Mersenne Twister generator in a multithreaded version of the NAG Library and running on multiple threads, if ${\mathbf{lstate}}<1260$, the ${\mathbf{state}}$ array was not being initialized correctly inside the code for g05saf. Thus on a second and subsequent call to any of the NAG pseudorandom number routines after initialization the sequence produced could be different from that expected from the Mersenne Twister algorithm, and if the entire calculation was repeated, different from run to run.

Severity  Noncritical 
Issue Since Mark  23 
Fixed at Mark  26 
Workaround  The problem can be avoided by either:

Synopsis  Inconsistent random number sequences when running g05sgf in parallel. 
Description  When running the parallelized version of g05sgf in the NAG Library for SMP & Multicore on multiple threads, the random number sequence generated may be inconsistent from run to run, and may not conform to the algorithmic properties expected from this routine. This is most likely to occur when the number of random numbers to be generated is small. 
Severity  Critical 
Issue Since Mark  23 
Fixed at Mark  24.5 
Workaround  It is recommended that users do not call this routine in parallel, which can be achieved either by setting the environment variable OMP_NUM_THREADS to 1 (affecting the entire program) or using the OpenMP runtime library routine OMP_SET_NUM_THREADS to set the number of threads to 1 before calling g05sgf and then using OMP_SET_NUM_THREADS again to reset the number of threads to the desired value for subsequent calls to other parallelized routines or the users own OpenMP parallelized code. 
Synopsis  The wrong value for ${\mathbf{p}}$ is returned when ${\mathbf{aa2}}$ is large. 
Description  In g08ckf and g08clf the value returned for the upper tail probability ${\mathbf{p}}$ is wrong when the calculated AndersonDarling test statistic ${\mathbf{aa2}}$ is large. In the case of g08ckf, when ${\mathbf{aa2}}>153.4677$ the returned value of ${\mathbf{p}}$ should be zero; in the case of g08clf, when ${\mathbf{aa2}}>10.03$ the returned value of ${\mathbf{p}}$ should be $\text{}\le \mathrm{exp}\left(14.360135\right)$. 
Severity  Critical 
Issue Since Mark  23 
Workaround  Workaround for g08ckf:
Call g08ckf(...) If (aa2 > 153.4677d0) p = 0.0d0Workaround for g08clf: Call g08clf(...) If (aa2 > 10.03d0) p = exp(14.360135d0) 
Synopsis  g13faf may return a negative value as the estimate of the last $\beta $ parameter (i.e., ${\beta}_{p}$) for a subset of models. 
Description  g13faf can result in a negative value for the estimate of the last $\beta $ parameter (i.e., ${\beta}_{p}$) or, if $p=0$, the last $\alpha $ parameter (i.e., ${\alpha}_{q}$).
This issue only affects a subset of models that have normally distributed errors and do not include an asymmetry term.
If the routine did not return a negative value as the estimate of the last $\beta $ parameter (or, if $p=0$, the last $\alpha $ parameter), then that particular model was not affected by the issue.

Severity  Critical 
Issue Since Mark  20 
Fixed at Mark  27 
Workaround  None 
Synopsis  When ${\mathbf{what}}=\text{'V'}$ the information returned in ${\mathbf{plab}}$ and/or ${\mathbf{vinfo}}$ may be incorrect. 
Description  The information returned in ${\mathbf{plab}}$ and/or ${\mathbf{vinfo}}$ may be incorrect in cases where ${\mathbf{what}}=\text{'V'}$ and the underlying linear mixed effects regression model has a random variable, with a single level (so either binary or continuous), that only takes the value zero. 
Severity  Noncritical 
Issue Since Mark  27.0 
Workaround  The work around is to drop the term from the model, as it does not contribute. For example, if the random part of your model was specified as: V1 + V2 / SUBJECT=V3 and the variable V2 was a continuous variable, that only takes a value of zero in the data, then this is equivalent to respecifying the model using: V1 / SUBJECT=V3. 
Synopsis  Misleading error associated with an undocumented error exit can be produced. 
Description  A puzzling error message may be produced with an undocumented error exit ${\mathbf{ifail}}={\mathbf{11}}$ if workspace sizes are not sufficiently large to accommodate an internal partition of the workspace that meets the requirements of the problem. 
Severity  Noncritical 
Issue Since Mark  22 
Fixed at Mark  24 
Workaround  Increase the size of workspace arrays ${\mathbf{iwork}}$ and ${\mathbf{rwork}}$ and their dimensions ${\mathbf{liwork}}$ and ${\mathbf{lrwork}}$. 
Synopsis  Minimum lengths of real workspace displayed in errors messages from h02cbf/h02cba are incorrect. 
Description  If you provide too little real workspace to h02cbf/h02cba the minimum value required will be displayed in the error message (if messaging is enabled). The value is too small by $4\times {\mathbf{mdepth}}+{\mathbf{n}}$. The documented values are correct. 
Severity  Noncritical 
Issue Since Mark  22.3 
Fixed at Mark  22.4 
Workaround  Add $4\times {\mathbf{mdepth}}+{\mathbf{n}}$ to the minimum ${\mathbf{lwrk}}$ described in error messages, or use the values from the documentation. 
Synopsis  Calls of LAPACK routines with incorrect arguments may cause program crash. 
Description  (This error report applies to 32bit Windows library FLDLL244M/L only).
In some circumstances, a call to an LAPACK routine from the FLDLL244M_mkl variant of the NAG library may cause a program crash. The crash can occur if your program calls any LAPACK routine with faulty arguments (for example, if you call LAPACK routine DGETRF with argument ${\mathbf{n}}<0$). In normal circumstances, MKL should issue an error message, but a problem with the LAPACK error handling routine XERBLA in the version of MKL distributed with Mark 24.1 of the NAG library leads to a crash instead of an error message.

Severity  Noncritical 
Issue Since Mark  24.1 
Fixed at Mark  24.1.1 
Workaround  A workaround is simply to link to the allNAG library FLDLL244M_nag where the problem does not exist. Once you are confident that you have no argument errors in your calls to LAPACK routines, you can revert to calling FLDLL244M_mkl. 
Synopsis  The constraint on argument ${\mathbf{s}}$ is incorrectly checked. 
Description  The documented constraint on argument ${\mathbf{s}}$ is correct, but the constraint was incorrectly checked. This made it impossible to use a value of ${\mathbf{s}}$ less than 1.0. 
Severity  Noncritical 
Issue Since Mark  22 
Fixed at Mark  22.1 
Workaround  None. 