Error Bulletin for the NAG C Library 
This document contains a list of errors that affect various Marks of the NAG C Library.
Some of these errors 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 problem is provided wherever possible.
To find the Mark and point release number of your library, call NAG routine a00aac( ).
Synopsis:  Overflow may occur if the routine attempts to scale the polynomial coefficients 
Description:  In rare circumstances overflow may be observed if scale = Nag_TRUE. 
Severity:  Noncritical 
Problem since Mark:  07.0 
Workaround:  Set parameter scale = Nag_FALSE. 
Synopsis:  Multilevel wavelets cannot handle periodic end extension 
Description:  When mode = Nag_Periodic and wtrans = Nag_MultiLevel the multilevel wavelet transform routines do not work properly if n is not a power of 2. 
Severity:  Noncritical 
Problem since Mark:  09.0 
Fixed in Mark:  23.0 
Workaround:  The option combination of a multilevel wavelet transform using a periodic end extension is disallowed; a call to the initialization routine c09aac with this combination will return with an error code. For multilevel analysis of periodic data, you are advised to experiment with 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:  Stack size or thread safety problems may be observed with some d06 routines. 
Description:  d06aac, d06abc and d06acc contain large local arrays that may cause stack size and/or thread safety problems. 
Severity:  Critical 
Problem since Mark:  07.0 
Fixed in Mark:  23.3 
Workaround:  Do not use these routines in a multithreaded environment. For serial execution, set stack size limit to 10MB or greater. 
Synopsis:  e04dgc returns wrong gradient values in g 
Description:  e04dgc prints gradient values correctly, but returns the wrong values in argument g. 
Severity:  Noncritical 
Problem since Mark:  07.0 
Fixed in Mark:  25.0 
Workaround:  In objfun, when g is set, push these values into the 'user' structure. Following the call to e04dgc the correct values for g can then be obtained from 'user'. 
Synopsis:  Internal buffer overflow in e04fcc 
Description: 
When the grade of the optimisation problem drops to zero, an internal buffer overflow occurs. This destroys some of the internal state of the optimiser, typically causing it to stop prematurely
Scope of the problem: If the grade of the optimisation problem is nonzero on exit from e04fcc, then the bug is not triggered and the optimisation is unaffected. If the grade is zero on exit, then the optimisation is affected in all supported CL marks. How the problem manifests:
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 e04fcc significantly. 
Severity:  Noncritical 
Problem since Mark:  08.0 
Fixed in Mark:  24.2 
Workaround:  There is no practical workaround 
Synopsis:  In very rare cases, the algorithm used by e04lbc may become trapped in an infinite loop 
Description:  The routine might loop unnecessarily and finish with NW_TOO_MANY_ITER 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 
Problem since Mark:  07.0 
Fixed in Mark:  25.0 
Workaround:  Unfortunately there is no convenient workaround. 
Synopsis:  Internal file overflow. 
Description:  If you set a New Basis File in e04nqc, e04vhc or e04wdc and your total problem size (n + m, n + nf or n + nclin + ncnln, respectively) is greater than 80 you will experience an internal buffer overflow and possible program crash. 
Severity:  Critical 
Problem since Mark:  09.4 
Fixed in Mark:  23.0 
Workaround:  Unfortunately there is no convenient workaround. The only way to avoid this crash is to not specify a New Basis File or to have a small enough problem. 
Synopsis:  A possible buffer overflow in the printing of the derivative checker of e04unc. 
Description:  If options.verify_grad is set to a full check of the objective function and/or the constraints (Nag_CheckObj, Nag_CheckObjCon, Nag_CheckCon, ...) and options.print_deriv=Nag_D_Full and the checked function has zero elements in the derivatives, internal buffer might overflow which might lead to a crash. 
Severity:  Critical 
Problem since Mark:  07.0 
Fixed in Mark:  26.0 
Workaround:  To avoid the problem, use options.print_deriv=Nag_D_Sum or options.print_deriv=Nag_D_NoPrint. 
Synopsis:  Information about the last constraint might not be printed. 
Description:  If the problem has a nonlinear objective function without a linear part and objrow<nf, the last constraint is not printed in the final information about the solution (Rows section). 
Severity:  Noncritical 
Problem since Mark:  08.0 
Fixed in Mark:  26.26 
Workaround:  None. 
Synopsis:  Usersupplied character strings containing spaces may cause garbled error messages 
Description:  Some routines produce error messages containing char data that has been supplied through the argument list by the user. An example is e04vhc, where the xnames or fnames 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 
Problem since Mark:  09.0 
Fixed in Mark:  23.0 
Workaround:  Make sure userprovided char data is without spaces 
Synopsis:  An unhelpful error exit is returned if e05ucc is called with incorrectly initialized optional argument arrays iopts and opts 
Description:  Function e05ucc returns NE_INTERNAL_ERROR if e05ucc is called without previously having called e05zkc with argument 'Initialize = e05ucc'. 
Severity:  Noncritical 
Problem since Mark:  23.0 
Fixed in Mark:  24.0 
Workaround:  Call e05zkc with argument 'Initialize = e05ucc' before calling e05ucc 
Synopsis:  f16rbc and f16ubc return 0 if kl or ku is 0, instead of the correct norm. pdab is incorrectly forced to be at least m when m == n 
Description:  f16rbc and f16ubc mistakenly make a quick return if kl or ku is 0, instead of computing the correct value for the requested norm. Also, pdab is incorrectly forced to be at least m when m == n. 
Severity:  Critical 
Problem since Mark:  09.1 
Fixed in Mark:  23.0 
Workaround:  If kl or ku is 0, use the general matrixnorm routines f16rac or f16uac, with the input matrix in full storage. If m == n, make sure that pdab >= m 
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 rndm. 
Severity:  Critical 
Problem since Mark:  23.0 
Fixed in Mark:  25.0 
Workaround:  Ensure that blocks without subject variables appear in 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 E04LB (modified Newton method). In very rare cases the solver might get into an infinite loop. 
Severity:  Critical 
Problem since Mark:  09.0 
Fixed in Mark:  25.0 
Workaround:  The bug can be avoided by switching to the other optimizer (SQP method E04UC, iopt[4]=1). 
Synopsis:  Returns incorrect results when ntau > 1 and user supplied initial values for b are being used 
Description:  If ntau > 1, the optional argument 'Calculate Initial Values = No' is set, and the rows of array b are not all identical, then the results returned by g02qgc are incorrect. 
Severity:  Critical 
Problem since Mark:  23.0 
Fixed in Mark:  24.0 
Workaround:  Rather than call the routine once with ntau > 1, call the routine multiple times with ntau = 1, analysing a different value of tau on each call. 
Synopsis:  The wrong value for p is returned when aa2 is large 
Description:  In g08ckc and g08clc the value returned for the upper tail probability p is wrong when the calculated AndersonDarling test statistic aa2 is large. In the case of g08ckc, when aa2 > 153.4677 the returned value of p should be p = 0.0; in the case of g08clc, when aa2 > 10.03 the returned value of p should be <= exp(14.360135). 
Severity:  Critical 
Problem since Mark:  23.0 
Workaround:  Workaround for g08ckc:
g08ckc(...); if (aa2 > 153.4677) p = 0.0;Workaround for g08clc: g08clc(...); if (aa2 > 10.03) p = exp(14.360135); 
Synopsis:  The methods Nag_3RSSH and Nag_4253H were implemented in reverse. 
Description:  g10cac implements two methods of smoothing, named Nag_3RSSH and Nag_4253H. Unfortunately they were implemented in reverse, so if you ask for Nag_3RSSH you get NAG_4253H and vice versa. 
Severity:  Critical 
Problem since Mark:  07.0 
Fixed in Mark:  25.0 
Workaround:  Use method = Nag_3RSSH if you want results for Nag_4253H, and vice versa. 
Page generated on 31March2015
