Resolved Issues for the naginterfaces Python Package

This page lists resolved issues that affected the performance of naginterfaces before version 30.2.0.0. It consists of issues previously from the Known Issues document that are fixed in naginterfaces 30.2.0.0 and for which the description has been rotated over into this document, for reference.

Incorrect licensing codes used in utilities in the Kusari module

Problem Since

28.3.0.0

Affected entities

Symptom

Licence keys for the 28X line issued by NAG are rejected by the utilities in the Kusari module (for example, Licence not found is reported by naginterfaces.kusari.lcheck()).

Diagnosis

A format change in the 28.3 release has not been applied in these utilities.

Workaround

A 28X key should still be recognized by the underlying algorithmic library, so it is merely a case of ignoring reports from the Kusari module or the quick_check function that something is wrong.

Solution

Use the new format for the licence code in the Kusari module.

The module can be patched as follows

@@ -131,13 +131,14 @@ from .base.info import impl_details as b_impl_details
 from . import _THE_SYSTEM

 _PRODUCT_CODE = b_impl_details()['product_code']
+_KPRODUCT_CODE = _PRODUCT_CODE[:7] + 'X' + _PRODUCT_CODE[8:]

 def _has_lic():
     """
     Return a Boolean for when klcheck reports that a licence is available.
     """
     return b_utils._capture_lcheck( # pylint: disable=protected-access
-        _PRODUCT_CODE, quiet=True,
+        _KPRODUCT_CODE, quiet=True,
     ).startswith('Licence available')

 def hostid():
@@ -151,18 +152,18 @@ def hostid():
     >>> from naginterfaces.kusari import hostid
     >>> hostid()
     KUSARI ID = ...
-    NAG Library product code = ...
+    NAG Library product licensing code = ...
     Host name = ...
     """
     # pylint: disable=superfluous-parens
-    if _PRODUCT_CODE.endswith('L'):
+    if _KPRODUCT_CODE.endswith('L'):
         print(b_utils._capture_hostid()) # pylint: disable=protected-access
     else:
         print(
             'KUSARI ID = not required, '
             'because this product is not licence managed.'
         )
-    print('NAG Library product code = ' + _PRODUCT_CODE)
+    print('NAG Library product licensing code = ' + _KPRODUCT_CODE)
     print('Host name = ' + _socket.gethostname())

 def key_gui(): # pragma: no cover
@@ -176,10 +177,10 @@ def key_gui(): # pragma: no cover
     if _THE_SYSTEM != 'Windows' and not _THE_SYSTEM.startswith('CYGWIN'): # pylint: disable=protected-access
         return

-    if not _PRODUCT_CODE.endswith('L'):
+    if not _KPRODUCT_CODE.endswith('L'):
         return

-    no_l_pcode = _PRODUCT_CODE[:9]
+    no_l_pcode = _KPRODUCT_CODE[:9]
     print(
         'For a new licence request, the request form will be prefilled with'
     )
@@ -210,7 +211,7 @@ def lcheck(quiet=False):
     >>> lcheck(quiet=True)
     Licence available; ...
     """
-    print('\n'.join(b_utils._lcheck_lines(_PRODUCT_CODE, quiet=quiet))) # pylint: disable=protected-access,superfluous-parens
+    print('\n'.join(b_utils._lcheck_lines(_KPRODUCT_CODE, quiet=quiet))) # pylint: disable=protected-access,superfluous-parens

 def _main():
     """

Fixed in Release

28.3.0.1

Requested workspace size has no effect in sparse symmetric systems setup

Problem Since

26.2.0.0

Affected Entities

Symptom

The returned communication structure always has length 120, which may be too small and can result in an ‘Unexpected error‘ NagException being raised by subsequent calls to the associated solver.

Diagnosis

The input or default lwork was mistakenly not being used when allocating the communication structure.

Workaround

None

Solution

Allocate the workspace array using the supplied lwork: in naginterfaces/base/sparse.py

@@ -12976,7 +12976,12 @@
     _lwork = utils._EngineIntScalarType(
         lwork, {'fun_name': fun_name, 'entity': 'lwork'},
     ).to_ctypes()
-    _work = utils._EngineFloat64ArrayType.empty_ctypes(120)
+    _lwork_py = utils._EngineIntScalarType.to_py(_lwork)
+    _lwork_py = max(120, _lwork_py)
+    _work = utils._EngineFloat64ArrayType.empty_ctypes(_lwork_py)
+    _lwork = utils._EngineIntScalarType(
+        _lwork_py, {'fun_name': fun_name, 'entity': 'lwork'},
+    ).to_ctypes()
     _comm_py = {}
     _comm_py['work'] = _work
     _errbuf = utils._EngineErrbuf()
@@ -14396,7 +14401,12 @@
     _lwork = utils._EngineIntScalarType(
         lwork, {'fun_name': fun_name, 'entity': 'lwork'},
     ).to_ctypes()
-    _work = utils._EngineComplex128ArrayType.empty_ctypes(120)
+    _lwork_py = utils._EngineIntScalarType.to_py(_lwork)
+    _lwork_py = max(120, _lwork_py)
+    _work = utils._EngineComplex128ArrayType.empty_ctypes(_lwork_py)
+    _lwork = utils._EngineIntScalarType(
+        _lwork_py, {'fun_name': fun_name, 'entity': 'lwork'},
+    ).to_ctypes()
     _comm_py = {}
     _comm_py['work'] = _work
     _errbuf = utils._EngineErrbuf()

Fixed in Release

27.0.2.0

Note that the major release 27.1 completely removes this lwork functionality altogether and sets up the optimal workspace internally once and for all.

Crash in Hermitian eigenvalues routine

Problem Since

26.2.0.0

Affected Entities

Symptom

Possible crash when eigenvalues-only computation mode is selected.

Diagnosis

A bug in NAG metadata means that output array isuppz is not declared big enough when jobz = 'N'.

Workaround

Use mode jobz = 'V' instead.

Solution

Array isuppz should be size 2*max(1, estimated_m) in all cases, where estimated_m = if erange in ('I', 'i') then iu - il +1 else n.

The patch is omitted because of its size. Please contact NAG if you would like more information.

Fixed in Release

27.0.1.1

Incorrect results when discontiguous rank-1 NumPy arrays are used

Problem Since

26.2.0.0

Affected Entities

Any NAG routine that takes one-dimensional array input.

Symptom

Incorrect results when a NAG routine is passed a rank-1 array which is not contiguous in either the C or the Fortran sense; for example, y in z = np.array([[42, 43], [44, 45]]); y = z[:, 0].

Diagnosis

The NAG Engine requires contiguous memory blocks but in this case the discontiguous descriptor is passed through unmodified. The NAG Engine therefore may access unanticipated parts of memory.

Workaround

Ensure all array input is contiguous. For NumPy ndarray structures this information is recorded in an instance’s flags attribute, and casting to a contiguous array can be achieved using, for example, numpy.ascontiguousarray.

Solution

Make discontiguous rank-1 arrays be contiguous before passing them to the NAG Engine: in naginterfaces/library/_utils.py

@@ -195,6 +207,14 @@
     if array is not None and not nd_cast.shape:
         nd_cast = to_ndarray_only([array])

+    if (
+            not copy and
+            len(nd_cast.shape) == 1 and
+            not nd_cast.flags.f_contiguous and
+            not nd_cast.flags.c_contiguous
+    ):
+        nd_cast = _np.ascontiguousarray(nd_cast)
+
     _check_valid_ndarray(locus, nd_cast, exp_rank, exp_shape, exp_class)

     if (

Fixed in Release

27.0.1.1

MKL crashes when some vacuous problems are passed to LAPACK routines

Problem Since

26.2.0.0

Affected Entities

Symptom

When using the MKL-enabled NAG package, attempting to solve a zero-sized problem results in an MKL error message and an ‘Unexpected error‘ NagException raised by the NAG wrapper.

Diagnosis

The implementation used by MKL for these routines contains a faulty workspace query for these vacuous problems.

Workaround

Consider avoiding calling the affected routine(s) altogether in such vacuous cases, because usally no work is actually done then anyway.

Alternatively, use the MKL-free variant of the NAG package.

Solution

Let the NAG wrapper control the workspace set up in these cases.

The patch is omitted because of its size. Please contact NAG if you would like more information.

Fixed in Release

27.0.1.1

Unable to solve some vacuous problems in certain eigenvalue routines

Problem Since

26.2.0.0

Affected Entities

Many routines in the naginterfaces.library.lapackeig submodule, for example naginterfaces.library.lapackeig.dsytrd().

Please contact NAG if you would like more information.

Symptom

Attempting to solve a zero-sized problem results in a NagShapeError exception being raised.

Diagnosis

In the example naginterfaces.library.lapackeig.dsytrd() case, when n is zero the NAG routine detects an attempt to set up the output array e with length -1.

Workaround

Consider avoiding calling the affected routine(s) altogether in such vacuous cases, because usally no work is actually done then anyway.

Solution

Set up the affected arrays to have minimum length 1.

For naginterfaces.library.lapackeig.dsytrd(), in naginterfaces/library/lapackeig.py

@@ -12128,13 +12128,13 @@
     _d = _d_cls.to_ctypes(can_reference_contents=False)
     _e_cls = utils._EngineFloat64ArrayType(
         e, {'fun_name': fun_name, 'entity': 'e'},
-        exp_shape=(_n_py-1,),
+        exp_shape=(max(1, _n_py-1),),
         check_contents=False,

The full patch is omitted because of its size. Please contact NAG if you would like more information.

Fixed in Release

27.0.1.1

Possible unexpected error from multi-integrand vectorized quadrature

Problem Since

26.2.0.0

Affected Entities

Symptom

An ‘Unexpected error‘ NagException, code -99:171,1003 or -99:191,1004 when a large amount of subdivision is required.

Diagnosis

The internal metadata used by the NAG wrapper for encoding the required lengths with which to set up the routine’s communication structure are suboptimal when subdivision is needed.

Workaround

The communication components for the integrator can be preallocated following options setting using sizes computed by naginterfaces.library.quad.dim1_gen_vec_multi_dimreq()

ni = ???
...
comm = {}
opt_set('Initialize = dim1_gen_vec_multi_rcomm', comm)
opt_set(...)
dims = dim1_gen_vec_multi_dimreq(ni, comm['iopts'], comm['opts'])
comm['icom'] = base.utils._EngineIntArrayType.empty_ctypes(dims.licmax)
comm['com'] = base.utils._EngineFloat64ArrayType.empty_ctypes(dims.lcmax)
...

Solution

Extract the maximum required array sizes internally by calling the size-query routine.

The patch is omitted because of its size. Please contact NAG if you would like more information.

Fixed in Release

27.0.1.1

Cubic spline fitter can’t be used for continued sorted vectorization

Problem Since

27.0.0.0

Affected Entities

Symptom

iwrk is returned as None under first-phase sorted vectorization (start = 0 or 1) and so cannot be propagated to a subsequent continuation call (start = 2).

Diagnosis

A bug in code generation has an incorrect condition for when iwrk contains useful information.

Workaround

Consider using start = 0 (full sorted vectorization) or 10 (unsorted vectorization). Otherwise, a patch is required.

Solution

Return None for iwrk only under unsorted vectorization: naginterfaces/library/fit.py

@@ -2112,7 +2112,7 @@
         _the_exc = _exc
         _reraise = True
     _ixloc_py = _ixloc
-    if _start_py == 2:
+    if _start_py not in (10, 11):
         _iwrk_py = _iwrk
     else:
         _iwrk_py = None

Fixed in Release

27.0.1.0

Monitoring the solution may fail in rectangular second-order PDE solver

Problem Since

26.2.0.0

Affected Entities

Symptom

The structure of sol in monitr is not correct.

Diagnosis

The internal expression used for computing the size of sol based on entries in lsol is not correct.

Workaround

Perform no monitoring.

Solution

Set the size expression correctly: in naginterfaces/base/pde.py

@@ -29327,7 +29327,7 @@
             )
             _sol_monitrh = utils._EngineFloat64ArrayType.from_pointer(
                 sol,
-                (utils._EngineIntArrayType.get_element(lsol, {'fun_name': cb_monitr_name, 'entity': 'lsol'}, (_nlev_monitrh-1,), validate=False)+_npde_monitrh*utils._EngineIntArrayType.get_element(ngpts, {'fun_name': cb_monitr_name, 'entity': 'ngpts'}, (_nlev_monitrh-1,), validate=False),),
+                (utils._EngineIntArrayType.get_element(lsol, {'fun_name': cb_monitr_name, 'entity': 'lsol'}, (0,), validate=False)+_npde_monitrh*utils._EngineIntArrayType.get_element(ngpts, {'fun_name': cb_monitr_name, 'entity': 'ngpts'}, (0,), validate=False),),
             )
             _ierr_monitrh = utils._EngineIntScalarType.to_py(ierr.contents)
             if data is not None:

Fixed in Release

27.0.1.0

Univariate summary combinator fails for row-ordered input

Problem Since

26.2.0.0

Affected Entities

Symptom

When called with a valid but row-ordered mrcomm the routine raises NagValueError that the structure is not in the expected format.

Diagnosis

A bug in code generation sets the lead dimension for this array incorrectly when it is row ordered.

Workaround

Supply mrcomm as a column-ordered array.

Solution

Set ldmrcomm using the get_nd utility: in naginterfaces/base/stat.py

@@ -2735,7 +2738,7 @@
     _b = utils._EngineIntScalarType(
         b, {'fun_name': fun_name, 'entity': 'b'},
     ).to_ctypes()
-    _ldmrcomm_py = utils._EngineFloat64ArrayType.get_shape(mrcomm, {'fun_name': fun_name, 'entity': 'mrcomm'}, exp_rank=2)[0]
+    _ldmrcomm_py = utils._EngineFloat64ArrayType.get_nd(mrcomm, {'fun_name': fun_name, 'entity': 'mrcomm'}, exp_rank=2, sorder=_m_sorder, dim_type='l')
     _ldmrcomm = utils._EngineIntScalarType(
         _ldmrcomm_py, {'fun_name': fun_name, 'entity': '_ldmrcomm'},
     ).to_ctypes()

Fixed in Release

27.0.1.0

Cannot set up reference vector for pseudorandom integers

Problem Since

26.2.0.0

Affected Entities

Symptom

When running with Python 2 the first three raise TypeError: ‘can’t multiply sequence by non-int of type ‘float’’.

With Python 2 or 3, naginterfaces.library.rand.int_negbin() also raises TypeError but with message ‘’float’ object is not callable‘.

Diagnosis

The expression to set up the length of the reference vector r involves ceil, which for the first three routines is missing a subsequent cast to int.

In naginterfaces.library.rand.int_negbin() a typo in code generation omits a / operator.

Workaround

For the first three, use Python 3, where ceil returns integer values.

Or, use mode = 3 to generate variates without using the reference vector.

Solution

Add the missing cast to int and / operator: in naginterfaces/base/rand.py

@@ -12790,7 +12790,7 @@
             allow_none=True,
         )
         if _mode_py != 3:
-            _r_dim1 = 22 + 20*ceil(sqrt(_m_py*_p_py*(1.-_p_py)))
+            _r_dim1 = 22 + 20*int(ceil(sqrt(_m_py*_p_py*(1.-_p_py))))
         else:
             _r_dim1 = 1
         _r = utils._EngineFloat64ArrayType.empty_ctypes(_r_dim1)
@@ -14054,7 +14054,7 @@
             allow_none=True,
         )
         if _mode_py != 3:
-            _r_dim1 = 28 + 20*ceil(sqrt((_ns_py*_m_py*(_np_py-_m_py)*(_np_py-_ns_py))/_np_py**3))
+            _r_dim1 = 28 + 20*int(ceil(sqrt((_ns_py*_m_py*(_np_py-_m_py)*(_np_py-_ns_py))/_np_py**3)))
         else:
             _r_dim1 = 1
         _r = utils._EngineFloat64ArrayType.empty_ctypes(_r_dim1)
@@ -14725,7 +14725,7 @@
             allow_none=True,
         )
         if _mode_py != 3:
-            _r_dim1 = 30 + 20*ceil(sqrt(_m_py*_p_cls.get_max(0, _k_py-1)*(1.-_p_cls.get_max(0, _k_py-1))))
+            _r_dim1 = 30 + 20*int(ceil(sqrt(_m_py*_p_cls.get_max(0, _k_py-1)*(1.-_p_cls.get_max(0, _k_py-1)))))
         else:
             _r_dim1 = 1
         _r = utils._EngineFloat64ArrayType.empty_ctypes(_r_dim1)
@@ -15106,7 +15106,7 @@
             allow_none=True,
         )
         if _mode_py != 3:
-            _r_dim1 = 28 + int(ceil((20*sqrt(_m_py*_p_py)+30*_p_py)(1.-_p_py)))
+            _r_dim1 = 28 + int(ceil((20*sqrt(_m_py*_p_py)+30*_p_py)/(1.-_p_py)))
         else:
             _r_dim1 = 1
         _r = utils._EngineFloat64ArrayType.empty_ctypes(_r_dim1)

Fixed in Release

27.0.1.0

Crash in integer-constrained NLP solver when no linear constraints

Problem Since

26.2.0.0

Affected Entities

Symptom

Spurious NagShapeError raised for some valid arrays when there are no linear constraints (and a is not supplied).

Diagnosis

The number of variables, n, is inferred from a and hence is considered to be zero when a is omitted.

Workaround

None. A patch is required.

Solution

Infer n from the mandatory x: in naginterfaces/library/mip.py

@@ -4202,11 +4202,17 @@
         ((_a, 'a'),),
         spiked_sorder=spiked_sorder,
     )
+    _x = _utils._to_ndarray(
+        {'fun_name': fun_name, 'entity': 'x'},
+        x,
+        copy=True,
+    )
+    _n_py = _b_utils._EngineFloat64ArrayType.get_shape(_x, {'fun_name': fun_name, 'entity': 'x'}, exp_rank=1)[0]
+    _n = _b_utils._EngineIntScalarType(
+        _n_py, {'fun_name': fun_name, 'entity': '_n'},
+    ).to_ctypes()
     if a is None:
         _a = None
-    _n = _b_utils._EngineIntScalarType(
-        0 if a is None else _b_utils._EngineFloat64ArrayType.get_shape(_a, {'fun_name': fun_name, 'entity': 'a'}, exp_rank=2, allow_none=True)[1], {'fun_name': fun_name, 'entity': '_n'},
-    ).to_ctypes()
     _nclin = _b_utils._EngineIntScalarType(
         0 if a is None else _b_utils._EngineFloat64ArrayType.get_shape(_a, {'fun_name': fun_name, 'entity': 'a'}, exp_rank=2, allow_none=True)[0], {'fun_name': fun_name, 'entity': '_nclin'},
     ).to_ctypes()
@@ -4235,11 +4241,6 @@
         varcon,
         copy=False,
     )
-    _x = _utils._to_ndarray(
-        {'fun_name': fun_name, 'entity': 'x'},
-        x,
-        copy=True,
-    )
     _b_utils._check_callable(confun, {'fun_name': fun_name, 'entity': 'confun'}, allow_none=True)
     _confun = None if confun is None else cb_confun
     _ncnln = _b_utils._EngineIntScalarType(
@@ -4249,7 +4250,6 @@
     _c = _b_utils._EngineFloat64ArrayType.empty_ndarray(
         (_ncnln_py,),
     )
-    _n_py = _b_utils._EngineIntScalarType.to_py(_n)
     _cjac = _b_utils._EngineFloat64ArrayType.empty_ndarray(
         (_ncnln_py, _n_py),
         sorder=_m_sorder,

Fixed in Release

27.0.0.1

Crash calculating lower-tail probabilities from mv normal distribution

Problem Since

26.2.0.0

Affected Entities

Symptom

NagShapeError raised for b when a is not supplied (lower-tail probabilities).

Diagnosis

The dimension measure, n, is inferred from a and hence is considered to be zero when a is omitted.

Workaround

None. A patch is required.

Solution

Infer n from the mandatory xmu: in naginterfaces/library/stat.py

@@ -4385,6 +4385,15 @@

     fun_name = 'naginterfaces.library.stat.prob_multi_normal'

+    _xmu = _utils._to_ndarray(
+        {'fun_name': fun_name, 'entity': 'xmu'},
+        xmu,
+        copy=False,
+    )
+    _n_py = _b_utils._EngineFloat64ArrayType.get_shape(_xmu, {'fun_name': fun_name, 'entity': 'xmu'}, exp_rank=1)[0]
+    _n = _b_utils._EngineIntScalarType(
+        _n_py, {'fun_name': fun_name, 'entity': '_n'},
+    ).to_ctypes()
     _a = _utils._to_ndarray(
         {'fun_name': fun_name, 'entity': 'a'},
         a,
@@ -4391,9 +4400,6 @@
         copy=False,
         allow_none=True,
     )
-    _n = _b_utils._EngineIntScalarType(
-        0 if a is None else _b_utils._EngineFloat64ArrayType.get_shape(_a, {'fun_name': fun_name, 'entity': 'a'}, exp_rank=1, allow_none=True)[0], {'fun_name': fun_name, 'entity': '_n'},
-    ).to_ctypes()
     _b = _utils._to_ndarray(
         {'fun_name': fun_name, 'entity': 'b'},
         b,
@@ -4400,11 +4406,6 @@
         copy=False,
         allow_none=True,
     )
-    _xmu = _utils._to_ndarray(
-        {'fun_name': fun_name, 'entity': 'xmu'},
-        xmu,
-        copy=False,
-    )
     _sig = _utils._to_ndarray(
         {'fun_name': fun_name, 'entity': 'sig'},
         sig,

Fixed in Release

27.0.0.1

Continuation mode crashes in VARMA mv time series realizer

Problem Since

26.2.0.0

Affected Entities

Symptom

If run with mode = 3 and the communication structure comm correctly set up by a previous call then NagValueError, code 11:11,11, is raised claiming that the communication structure is incompatible.

Diagnosis

The NAG wrapper mistakenly treats mode = 3 as a setup call, contrary to the expectations of the underlying algorithmic library.

Workaround

Use one of the other (non-continuation) modes.

Solution

Treat mode = 3 the same as mode = 1: in naginterfaces/base/rand.py

@@ -3968,7 +3968,7 @@
         mutual_sorder=_m_sorder,
     ).to_ctypes()
     _mode_py = utils._EngineIntScalarType.to_py(_mode)
-    if _mode_py == 1:
+    if _mode_py in (1, 3):
         utils._check_comm(
             comm, {'fun_name': fun_name, 'entity': 'comm'},
             req_keys=('r',),

Fixed in Release

27.0.0.1

Output matrices always returned by LMM fit routine

Problem Since

27.0.0.0

Affected Entities

Symptom

Arrays cxx, cxz and czz are always returned, and of full shape, even when wantc = False.

Diagnosis

A bug in code generation means that these arrays are always declared internally and then returned.

Workaround

None.

Solution

Don’t allocate or return these arrays when wantc = False.

The patch is omitted because of its size. Please contact NAG if you would like more information.

Fixed in Release

27.0.0.1

Communication objects from LMM routines unusable with option getter

Problem Since

27.0.0.0

Affected Entities

Symptom

NagKeyError raised when using the communication structure from these routines with naginterfaces.library.correg.optget(), for accessing metadata such as the number of fixed effects for the dataset.

Diagnosis

A bug in NAG routine internal annotations means that the communication structures used by these routines are not recognized by the option getter.

Workaround

The values for nff and nrf can be obtained from the shapes of the returned cxx and czz, respectively, from naginterfaces.library.correg.lmm_fit() when wantc = True. For other parameters, a patch is required.

Solution

Use internal keys 'opts' and 'iopts' for the communication data in these routines.

The patch is omitted because of its size. Please contact NAG if you would like more information.

Fixed in Release

27.0.0.1

UnboundLocalError raised by cubic spline fitter

Problem Since

27.0.0.0

Affected Entities

Symptom

Under first-phase sorted vectorization (start = 0 or 1), the routine raises UnboundLocalError for local variable _liwrk_py.

Diagnosis

A bug in code generation mistakenly omits type normalization for this internal artifact.

Workaround

Consider using start = 10 or 11 (unsorted vectorization). Otherwise, a patch is required.

Solution

Normalize the internal _liwrk to Python data: in naginterfaces/library/fit.py

@@ -2076,6 +2076,7 @@
         _liwrk = _b_utils._EngineIntScalarType(
             3+3*_nx_py, {'fun_name': fun_name, 'entity': '_liwrk'},
         ).to_ctypes()
+        _liwrk_py = _b_utils._EngineIntScalarType.to_py(_liwrk)
     else:
         _liwrk_py = _b_utils._EngineIntArrayType.get_shape(_iwrk, {'fun_name': fun_name, 'entity': 'iwrk'}, exp_rank=1, allow_none=True)[0]
         _liwrk = _b_utils._EngineIntScalarType(

Fixed in Release

27.0.0.1

Unexpected error -6 from sparse complex equations solver

Problem Since

26.2.0.0

Affected Entities

Symptom

The solver exits with an ‘Unexpected error‘ NagException, code -99:-6,99999, when insufficiently-sized workspace had been created by naginterfaces.library.sparse.complex_gen_basic_setup().

Diagnosis

The error exit in the solver for trapping this insufficient size is mistakenly omitted from the NAG wrapper.

Workaround

Ensure that the setup routine is called with lwork at least as big as the setup routine itself requests via its lwreq return argument.

Solution

Reinstate the error exit: in naginterfaces/base/sparse.py

@@ -2143,10 +2149,21 @@
         _err_class = utils._EngineNoErrorExit()
     else:
         _ifmt, _eb_data = utils._EngineState._handle_global_errors(fun_name, _errbuf, _ierr_py)
-        if _ierr_py == -1 and _ifmt == 99909:
+        if _ierr_py == -6 and _ifmt == 99999:
             _err_class = utils._EngineErrorExit(
                 fun_name=fun_name,
                 msg_lines=[
+                    'On entry, lwork = {:s}.'.format(
+                        utils._STR_FMT_INT.format(_lwork_py),
+                    ),
+                    'Constraint: lwork >= lwreq, where lwreq is returned by complex_gen_basic_setup.',
+                ],
+                errcodes=(_ierr_py, _ierr_py, _ifmt),
+            )
+        elif _ierr_py == -1 and _ifmt == 99909:
+            _err_class = utils._EngineErrorExit(
+                fun_name=fun_name,
+                msg_lines=[
                     'On intermediate re-entry, irevcm = {:s}.'.format(
                         utils._STR_FMT_INT_AS_STR.format(_eb_data[1]),
                     ),

Fixed in Release

27.0.0.1

Note also that the 27.1.0.0 release enhances the usability of this group of routines in such a way as to set up the optimal workspace internally once and for all. After that, this error exit becomes legitimately redundant.

Spurious exception from sparse complex equations diagnostic

Problem Since

26.2.0.0

Affected Entities

Symptom

NagTypeError raised when querying the shape of the complex-valued communication array.

Diagnosis

These routines are mistakenly attempting to validate these arrays as user data.

Workaround

None. A patch is required.

Solution

These arrays don’t need validation because they have been set up and populated entirely by the NAG wrappers: in naginterfaces/base/sparse.py

@@ -2376,7 +2376,7 @@
         req_keys=('work',),
     )
     _work = comm['work']
-    _lwork_py = utils._EngineComplex128ArrayType.get_shape(comm['work'], {'fun_name': fun_name, 'entity': 'comm[\'work\']'}, exp_rank=1)[0]
+    _lwork_py = utils._EngineComplex128ArrayType.get_shape(comm['work'], {'fun_name': fun_name, 'entity': 'comm[\'work\']'}, exp_rank=1, validate=False)[0]
     _lwork = utils._EngineIntScalarType(
         _lwork_py, {'fun_name': fun_name, 'entity': '_lwork'},
     ).to_ctypes()
@@ -14397,7 +14397,7 @@
         comm, {'fun_name': fun_name, 'entity': 'comm'},
         req_keys=('work',),
     )
-    _lwork_py = utils._EngineComplex128ArrayType.get_shape(comm['work'], {'fun_name': fun_name, 'entity': 'comm[\'work\']'}, exp_rank=1)[0]
+    _lwork_py = utils._EngineComplex128ArrayType.get_shape(comm['work'], {'fun_name': fun_name, 'entity': 'comm[\'work\']'}, exp_rank=1, validate=False)[0]
     _lwork = utils._EngineIntScalarType(
         _lwork_py, {'fun_name': fun_name, 'entity': '_lwork'},
     ).to_ctypes()

Fixed in Release

27.0.0.1

Exceptions raised on internal access to complex communication arrays

Problem Since

26.2.0.0

Affected Entities

Symptom

AttributeError raised when a wrapper attempts to retrieve an element of a complex-valued communication array.

Diagnosis

Type resolution for these complex arrays is not taking into account the underlying compound data type correctly.

Workaround

None. A patch is required.

Solution

Don’t try to use the value attribute of the underlying scalar: in naginterfaces/base/utils.py

@@ -2969,10 +2969,17 @@
                 data_el = data_el.decode(encoding='ascii')

         return (
-            data_el.value if isinstance(
-                data_el, (
-                    cls._underlying_scalar.c_type,
-                    _ctypes.c_int, _ctypes.c_long, _ctypes.c_longlong,
+            data_el.value if (
+                isinstance(
+                    data_el, (
+                        cls._underlying_scalar.c_type,
+                        _ctypes.c_int, _ctypes.c_long, _ctypes.c_longlong,
+                    )
+                ) and
+                not isinstance(
+                    data_el, (
+                        _EngineComplex64Structure, _EngineComplex128Structure,
+                    )
                 )
             )
             else data_el

Fixed in Release

27.0.0.1

Licence-check utility crashes if non-ASCII characters in name of licence file

Problem Since

26.2.0.0

Affected Entities

Symptom

UnicodeEncodeError when this function is called under Python 3 if the environment variable NAG_KUSARI_FILE is set to a file path that contains non-ASCII characters.

Note that the operation of licensing within the compiled Library itself is unaffected.

Diagnosis

Internal processing of the captured output is trying to decode to ASCII.

Workaround

Store the licence file in a location that has only ASCII characters in its name.

Solution

Decode using the default 'utf-8' encoding: in naginterfaces/base/utils.py

@@ -858,10 +858,12 @@
         cmd_list.append('-quiet')

     cmd_list.append(pcode)
+    cmd_output = _subprocess.check_output(cmd_list)

-    lcheck_txt = _EngineCharScalarType.to_py(
-        _subprocess.check_output(cmd_list)
-    ).splitlines()
+    lcheck_txt = (
+        cmd_output.decode() if _sys.version_info >= (3,)
+        else cmd_output
+    ).rstrip().splitlines()

     for lcheck_i, lcheck_line in enumerate(lcheck_txt):

Fixed in Release

27.0.0.1

Contradictory output from licence-check utility

Problem Since

26.2.1.1

Affected Entities

Symptom

When called with quiet=False and a licence is available, the output first claims that a licence could not be found before giving further text that says one was located.

Note that the operation of licensing within the compiled Library itself is unaffected.

Diagnosis

Some internal processing of the captured output is not looking in the correct place for hook text saying 'Licence available'.

Workaround

Call lcheck with quiet=True, where the abbreviated output is accurate.

Solution

Look for 'Licence available' anywhere in the captured output, in naginterfaces/base/utils.py

@@ -886,7 +886,7 @@
     Return a list of lines forming a licensing message.
     """
     l_line = _capture_lcheck(pcode, quiet=quiet)
-    if l_line.startswith('Licence available'):
+    if 'Licence available' in l_line:
         return [l_line]
     lc_lines = [
         'The NAG Library for Python on this platform uses',

Fixed in Release

27.0.0.1

Lagrange multipliers may be inaccessible in the LP IPM solver

Affected Entities

Symptom

The returned u is None when the input u is None.

Diagnosis

Attributes on u for code generation mistakenly mean that it being None on input causes the output u to be suppressed.

Workaround

Supply an empty array of the correct size (nnzu) for u on input to retrieve the populated output u.

Solution

Make u a keyword argument with default None. Query the problem handle to extract the correct value for nnzu when u is None on input.

This requires an API extension in the compiled NAG Engine, so there is no solution that can be applied only to the Python code in the package.

Fixed in Release

27.0.0.0

Problems with default callbacks when storage is row-major

Affected Entities

Symptom

Possible incorrect results when input data uses row-major storage and None is supplied for

or

Diagnosis

The default callbacks used internally in these situations operate only in column-major order.

Workaround

Supply input in column-major order.

Alternatively, for naginterfaces.library.mip.iqp_dense() and naginterfaces.library.opt.qp_dense_solve() supply the input quadratic term h as a full symmetric matrix.

Solution

Make the callbacks operate correctly in row-major order.

This is a bug in the compiled NAG Engine, so there is no solution that can be applied only to the Python code in the package.

Fixed in Release

27.0.0.0

Workspace problems when using sparse matrix algebra in DAE solvers

Affected Entities

Symptom

The solver raises an ‘Unexpected error’ NagException and displays output saying that supplied integer or real workspace is too small, when sparse matrix methods are selected (laopt = 'S').

Diagnosis

The workspaces in questions are set up in the routine’s comm argument in its first call, but the sizes used may not be sufficient in advance.

Workaround

Once the sufficient sizes are known for the problem in question, from the displayed message output, set up comm explicitly. You may wish to use some of the internal utilities to make this slightly easier

lrsave = big_enough_value_r
lisave = big_enough_value_i
# Instead of comm = {} for the first call:
comm = {
    'rsave': base.utils._EngineFloat64ArrayType.empty_ctypes(lrsave),
    'isave': base.utils._EngineIntArrayType.empty_ctypes(lisave),
    'cwsav': base.utils._EngineCharArrayType.empty_ctypes(10, chrlen=80),
    'lwsav': base.utils._EngineLogicalArrayType.empty_ctypes(100),
    'iwsav': base.utils._EngineIntArrayType.empty_ctypes(505),
    'rwsav': base.utils._EngineFloat64ArrayType.empty_ctypes(1100),
}
...
dae_solver(..., comm, ...)

Solution

Allow lisave and lrsave to be supplied in the call, as keyword arguments, in case the computed defaults are too small.

Programmatic access to the sufficent sizes requires a change in the compiled NAG Engine.

Fixed in Release

27.0.0.0

Row-major input not accepted by first-order stiff ODE interpolators

Affected Entities

Symptom

Spurious exceptions raised if an array supplied for argument ysav is stored in row-major (C contiguous) order (which is the NumPy default).

Diagnosis

A bug in the Mark 26.2 NAG Library Engine treats row-ordered ysav incorrectly.

Workaround

Supply ysav in column-major (Fortran contiguous) order. The utility numpy.asfortranarray may be of use.

Note that if these interpolators are called from the monitr callback in one of the associated ODE solvers, the array ysav supplied by the callback will be in row-major order. It must thus be converted to column-major order for communication to the interpolator.

Solution

The array ysav is for the purposes of NAG communication only, so should be entered into a comm structure. The array will then be treated uniformly as column ordered without any interaction required by the caller.

Fixed in Release

27.0.0.0

Unhelpful monitoring output from some optimizers during query mode

Affected Entities

Symptom

Superfluous monitoring output about invalid input parameters when monitoring/printing has been enabled. For naginterfaces.library.mip.iqp_sparse(), naginterfaces.library.opt.qpconvex1_sparse_solve() and naginterfaces.library.opt.nlp1_sparse_solve() this is during a user-requested ‘workspace size query’ call. For the other functions in the list it is any time that monitoring is on.

Diagnosis

When monitoring is on and supplied workspace lengths are too short the underlying optimizers in the NAG Library Engine always print a monitoring header and a message that input is invalid. For the routines in the list that do not have a user-controllable query mode the query is still requested and managed internally by the routine.

Workaround

Monitoring output of this nature can safely be ignored.

Solution

This is a bug in the compiled NAG Engine, so there is no solution that can be applied only to the Python code in the package. In the fix, monitoring is disabled if a workspace query is underway.

Fixed in Release

27.0.0.0

Type-check failures in some circumstances now alleviated

Affected Entities

Potentially any.

Symptom

The package incorrectly raises NagTypeError claiming an incorrectly-typed numpy.ndarray was supplied.

Diagnosis

Certain data types constructed on the fly by NumPy appear invalid to the package’s type checker.

Workaround

Explicitly converting to a valid type can help; i.e., instead of

nag_call(x, ...)

try

nag_call(x.astype(int), ...)

for integer input.

Solution

Consider numeric types to be invalid by direct comparison rather than by using numpy.issubdtype.

The patch is omitted. Please contact NAG if you would like more information.

Fixed in Release

27.0.0.0

Unintuitive handling of spiked arrays in further situations

Affected Entities

Any function that does not take multidimensional array input but which has callback arguments that return multidimensional arrays, such as naginterfaces.library.glopt.bnd_pso() (monmod:x).

Symptom

When all multidimensional arrays returned from a callback are ‘spiked’ (that is, with unit extent in all but one dimension, or with total size 1) and these are viewed as dually Fortran and C contiguous by NumPy (which is the case for NumPy from version 1.12 onward), an exception is raised, claiming that storage orders mismatch.

Diagnosis

The NAG function uses a default storage order of C contiguous because it has no multidimensional array input, but infers a storage order of Fortran contiguous (for performance) for the spiked arrays returned by the callback.

Workaround

None.

Solution

Make the affected routines accept the spiked_sorder argument.

The patch is omitted because of its size. Please contact NAG if you would like more information.

Fixed in Release

26.2.2.4

Internal communication arrays mistakenly exposed in ODE interpolator

Affected Entities

Symptom

Usability problems in supplying correct values for arrays ysav and rwork.

Diagnosis

These arrays should be unpacked internally from the comm stucture without it being the caller’s responsibility to do so.

Workaround

The two-dimensional array ysav can be extracted from comm via

ysav = np.array(comm['ysav'][:]).reshape((neq, sdysav))

It must be created to use C-contiguous storage order, as above.

The one-dimensional rwork can be extracted merely as comm['rwork'].

Having done this, the internal computations of _ldysav and _sdysav must also be corrected throughout the suite.

Please contact NAG if you would like more information.

Solution

By classifying ysav and rwork correctly during code generation these arguments will be suppressed for the caller.

The problematic form

ivp_stiff_interp(tsol, m, neq, ysav, rwork, comm)

becomes

ivp_stiff_interp(tsol, m, neq, comm)

The patch is omitted because of its size. Please contact NAG if you would like more information.

Fixed in Release

26.2.2.4

Missing product code for use with licence GUI on Windows

Affected Entities

Symptom

The New Licence Request form has a required Product Code field, but how to choose the value to enter is not described anywhere.

Diagnosis

Display of the required product code used by the underlying compiled library is mistakenly omitted on Windows.

Workaround

The licence-managed 26.2 release line on Windows uses CLW6I262EL as its product code.

Solution

Display the output of naginterfaces.kusari.lcheck() before launching the key GUI: in naginterfaces/kusari.py

@@ -199,10 +206,10 @@
     if lcheck_str.startswith('Licence available'):
         lcheck(quiet=True)
         return
+    lcheck()
     if _THE_SYSTEM == 'Windows' or _THE_SYSTEM.startswith('CYGWIN'): # pylint: disable=protected-access
         key_gui() # pragma: no cover
     else:
-        lcheck()
         print(b_utils._capture_hostid()) # pylint: disable=protected-access,superfluous-parens

 if __name__ == '__main__':

Fixed in Release

26.2.2.3

Unintuitive handling of spiked arrays in callback functions

Affected Entities

Any function that takes multidimensional array input and which has callback arguments that return multidimensional arrays, such as naginterfaces.library.glopt.nlp_multistart_sqp() (a and confun:cjsl, respectively).

Symptom

When all multidimensional arrays are ‘spiked’ (that is, with unit extent in all but one dimension, or with total size 1), and when these are viewed as dually Fortran and C contiguous by NumPy (which is the case for NumPy from version 1.12 onward), and when spiked_sorder='F' is requested, the NAG wrapper incorrectly raises NagTypeError claiming a storage mismatch has occurred.

Diagnosis

Checking of storage order after calling user-supplied functions does not take into account the setting of spiked_sorder.

Workaround

Use spiked_sorder='C' (the default).

Solution

Take into account the setting of spiked_sorder.

The patch is omitted because of its size. Please contact NAG if you would like more information.

Fixed in Release

26.2.2.3

Unusable initializer for general nonlinear boundary-value ODEs

Affected Entities

Symptom

The routine raises an ‘Unexpected error’ NagException, code (-99:1,99988).

Diagnosis

Sizes used internally for setting up the comm data are incorrect.

Workaround

None.

Solution

The underlying routine in the NAG Engine has a ‘size query’ facility, which should be used instead.

The patch is omitted because of its size. Please contact NAG if you would like more information.

Fixed in Release

26.2.2.2

Unintuitive handling of spiked arrays in some situations

Affected Entities

Any function that takes multidimensional array input and which has callback arguments that return multidimensional arrays, such as naginterfaces.library.glopt.nlp_multistart_sqp() (a and confun:cjsl, respectively).

Symptom

When all multidimensional input arrays are ‘spiked’ (that is, with unit extent in all but one dimension, or with total size 1) and these are viewed as dually Fortran and C contiguous by NumPy (which is the case for NumPy from version 1.12 onward), returning default-ordered multidimensional arrays from callback functions passed to the NAG routine causes an exception to be raised, claiming that storage orders mismatch.

Diagnosis

The NAG function infers a storage order of Fortran contiguous when all multidimensional input arrays are spiked, which is for performance reasons. The same storage order is then required for multidimensional arrays returned by callbacks because of the compatibility enforced by the NAG interfaces.

Workaround

Declare the multidimensional arrays returned by the callbacks to use Fortran storage order.

Solution

In the fixed version, for better usability the affected routines now take an additional optional argument spiked_sorder to control the storage order that you wish the NAG Engine to infer from the spiked arrays. The default for the new argument is C-contiguous storage as with NumPy. For performance reasons supplying spiked_sorder='F' may be preferable, after which you must ensure that the arrays in the associated callbacks are initialized to use Fortran-contiguous storage.

The patch is omitted because of its size. Please contact NAG if you would like more information.

Fixed in Release

26.2.2.2

Rank-1 NumPy arrays can be wrongly accepted when rank > 1 is expected

Affected Entities

Any function that takes multidimensional array input, such as naginterfaces.library.correg.quantile_linreg().

Symptom

Possible undesirable runtime behaviour or crashes.

Diagnosis

The logic in a shape-checking utility is faulty for rank-1 NumPy arrays.

Workaround

Take care to supply multidimensional array data as having the correct rank. Note in particular that the design of this package requires that ‘spiked’ arrays be supplied with full rank; i.e., an argument requiring shape (n, 1) must not be supplied a rank-1 argument of length n.

Solution

Require full equality between the shape of a NumPy array and its associated expected-shape tuple: in naginterfaces/base/utils.py

@@ -3426,21 +3426,18 @@
             return

         if isinstance(self.data, _np.ndarray):
-            actual_shape_or_len = self.data.shape

-            if self.data.ndim == 1:
-                actual_shape_or_len = actual_shape_or_len[0]
-                bad_shape = actual_shape_or_len != self.exp_shape[0]
-            else:
+            if (
+                    self.data.size == 0 and
+                    any(extent == 0 for extent in self.exp_shape)
+            ):
+                return

-                if (
-                        self.data.size == 0 and
-                        any(extent == 0 for extent in self.exp_shape)
-                ):
-                    return
-
-                bad_shape = actual_shape_or_len != self.exp_shape
-
+            bad_shape = self.data.shape != self.exp_shape
+            actual_shape_or_len = (
+                self.data.shape[0] if self.data.ndim == 1 else
+                self.data.shape
+            )
         elif len(self.exp_shape) == 1:
             actual_shape_or_len = len(self.data)
             bad_shape = actual_shape_or_len != self.exp_shape[0]

Fixed in Release

26.2.2.0

Incorrect labels returned by the submodel utility for model fitting

Affected Entities

Symptom

When labels are requested, the routine issues a NagAlgorithmicWarning that elements in the returned plab array are too short, and the labels returned are essentially all empty.

Diagnosis

The output array plab is not initialized by the NAG wrapper correctly. Some of the metadata for this array stored to be used in NAG code generation is incorrect.

Workaround

None, although the function is still usable if labels are not required.

Solution

The array plab must be allocated with the correct character length. This length is not known in advance, so a new optional argument lenlab is provided with a reasonable default value. The routine will continue to issue an errno 81 NagAlgorithmicWarning if any of your labels are longer than this default,

The patch is omitted because of its size. Please contact NAG if you would like more information.

Fixed in Release

26.2.1.2

Malfunctioning dendrogram routine

Affected Entities

Symptom

The routine raises NagValueError when used, claiming that elements in c are too short.

Diagnosis

The output array c is not initialized by the NAG wrapper correctly. Some of the metadata for this array and for lenc stored to be used in NAG code generation is incorrect.

Workaround

None.

Solution

The array c must be allocated with the correct character length. In the fixed version, argument lenc is also removed because the size required by c is known on input based on the values of other parameters.

The patch is omitted because of its size. Please contact NAG if you would like more information.

Fixed in Release

26.2.1.2

Inoperable NAG-supplied default monitoring in a shooting BVP solver

Affected Entities

Symptom

When monlev is 1 and monit is None (i.e., monitoring is enabled and is to use the NAG-supplied default facility), TypeError is raised, reporting 'NoneType' object is not callable.

Diagnosis

The NAG wrapper is missing special handling of monit being None and incorrectly attempts to invoke None as a user-supplied procedure for the monitoring function.

Workaround

Disable monitoring or supply an explicit monitoring function.

Solution

Add special handling for monit being None to the internal helper function for monit.

The patch is omitted because of its size. Please contact NAG if you would like more information.

Fixed in Release

26.2.1.2

Logging incompatible with pytest in some situations

Affected Entities

Any functions that capture printing from the underlying NAG Engine (e.g. for monitoring) which is being sent to the default advisory or error units, when run through the pytest framework under Python 3.

Symptom

An internal NagException is raised saying ‘could not initialize record to write’.

Diagnosis

The pytest module captures output by swapping out the OS-level standard output and error streams with a special EncodedFile class. The cases covered by the naginterfaces output handler do not anticipate being supplied one of these entities.

Workaround

Use one of the pytest mechanisms to disable its output capturing (e.g. by running using pytest -s).

Or, configure the I/O manager in the NAG call to send advisory and error output to non-default streams of your choosing. (See also naginterfaces.base.utils.FileObjManager.)

Solution

Relax part of the recognition of the input I/O file object in naginterfaces/base/utils.py

@@ -5295,7 +5295,7 @@
         rec_to_write = rec_to_write.rstrip() + b'\n'
     elif (
             logger is not None or
-            isinstance(this_fo, _io.TextIOBase)
+            not isinstance(this_fo, (_io.BufferedIOBase, _io.RawIOBase))
     ):
         rec_to_write = _EngineCharScalarType.to_py(rec)

Fixed in Release

26.2.1.2

Reverse-communication best subset function unusable in a certain edge case

Affected Entities

Symptom

In the pathological case where m (the number of features in the full feature set) equals ip (the number of features in the subset of interest) on input, the routine terminates with a warning message about insufficiently-sized communication arrays.

Diagnosis

The communication arrays are set up internally by the NAG wrapper. The expressions for their sizes are missing a max term to ensure that part of the expression is at least 1 when m and ip are equal.

Workaround

None.

Solution

Add missing max occurrences in naginterfaces/base/mip.py

@@ -8890,9 +8890,9 @@
     _mincnt_py = utils._EngineIntScalarType.to_py(_mincnt)
     if _comm_needs_init:
         if _mincnt_py == 0:
-            _icomm_dim1 = 2*max(_nbest_py, _m_py)+_m_py*(_m_py+2)+(_m_py+1)*(_m_py-_ip_py)+27
+            _icomm_dim1 = 2*max(_nbest_py, _m_py)+_m_py*(_m_py+2)+(_m_py+1)*max(_m_py-_ip_py, 1)+27
         else:
-            _icomm_dim1 = 2*max(_nbest_py, _m_py)+_m_py*(_m_py+3)+(2*_m_py+1)*(_m_py-_ip_py)+25
+            _icomm_dim1 = 2*max(_nbest_py, _m_py)+_m_py*(_m_py+3)+(2*_m_py+1)*max(_m_py-_ip_py, 1)+25
         _icomm = utils._EngineIntArrayType.empty_ctypes(_icomm_dim1)
         comm['icomm'] = _icomm
     else:
@@ -8903,9 +8903,9 @@
     ).to_ctypes()
     if _comm_needs_init:
         if _mincnt_py == 0:
-            _rcomm_dim1 = 9+_nbest_py+_m_py*(_m_py-_ip_py)
+            _rcomm_dim1 = 9+_nbest_py+_m_py*max(_m_py-_ip_py, 1)
         else:
-            _rcomm_dim1 = 8+_m_py+_nbest_py+_m_py*(_m_py-_ip_py)
+            _rcomm_dim1 = 8+_m_py+_nbest_py+_m_py*max(_m_py-_ip_py, 1)
         _rcomm = utils._EngineFloat64ArrayType.empty_ctypes(_rcomm_dim1)
         comm['rcomm'] = _rcomm
     else:

Fixed in Release

26.2.1.2

Inaccessible suggested values in the factorial ANOVA function

Affected Entities

Symptom

If mterm (the maximum number of terms in the ANOVA table) or maxt (the maximum number of treatment means to be computed) are too small the suggested values computed by the routine cannot be retrieved, because a full exception is raised.

Diagnosis

The exit cases for these input errors are incorrectly categorized as serious errors requiring an exception.

Workaround

The required values can still be computed manually using the advice at

https://www.nag.com/numeric/nl/nagdoc_latest/flhtml/g04/g04caf.html#fcomments

Solution

Downgrade the relevant exit cases to warnings in naginterfaces/base/anova.py

@@ -1959,7 +1959,7 @@
                 errcodes=(_ierr_py, _ierr_py, _ifmt),
             )
         elif _ierr_py == 2 and _ifmt == 99992:
-            _err_class = utils._EngineErrorExit(
+            _err_class = utils._EngineWarningExit(
                 fun_name=fun_name,
                 msg_lines=[
                     'On entry, mterm = {:s}'.format(
@@ -1972,7 +1972,7 @@
                 errcodes=(_ierr_py, _ierr_py, _ifmt),
             )
         elif _ierr_py == 2 and _ifmt == 99993:
-            _err_class = utils._EngineErrorExit(
+            _err_class = utils._EngineWarningExit(
                 fun_name=fun_name,
                 msg_lines=[
                     'On entry, maxt = {:s}'.format(

Fixed in Release

26.2.1.2

Usability barriers in the NAG optimization suite handle reader/writer

Affected Entities

Symptom

The routine is difficult to use and in particular a read-mode call unnecessarily requires the caller to have knowledge of the expected size of the output, read, array.

Diagnosis

The Python API specification for this function as initially devised is defective.

Workaround

The routine can be used in read mode by studying any raised exceptions for information on how long the read array should be.

Solution

The interface has been improved.

From the defective call sequence

rarr_read = naginterfaces.library.opt.handle_set_get_real(
    handle, cmdstr, ioflag, rarr=rarr_write,
)

argument ioflag has been removed, its value now being inferred from the input rarr_write being None or not.

The fixed call for write mode is now

lrarr, _ = naginterfaces.library.opt.handle_set_get_real(
    handle, cmdstr, rarr=rarr_write,
)

in which the returned lrarr acts as a ‘size query’ facility in case the supplied rarr_write was too short.

The fixed call for read mode is now

_, rarr_read = naginterfaces.library.opt.handle_set_get_real(
    handle, cmdstr,
)

The patch is omitted because of its size. Please contact NAG if you would like more information.

Fixed in Release

26.2.1.1

Missing callbacks not diagnosed by the interior point optimizer

Affected Entities

Symptom

The routine runs to completion but produces unhelpful results in some cases when one of its procedure arguments is supplied as None instead of as a defined function.

Diagnosis

There are various situations in which one of the routine’s procedure arguments must not be None - for example, objgrd must be supplied as a user function when there is a nonlinear objective. An error in the classification of these callbacks during NAG’s code generation process means that code for identifying when dummy (None) callbacks were being supplied is wrongly omitted.

Workaround

Use the documentation of the solver to check carefully that your procedure arguments are only None when absolutely permitted.

Solution

The patch is omitted because of its size. Please contact NAG if you would like more information.

Fixed in Release

26.2.1.1

Internal error from setup routine for implicit ODE/DAE solver in Python 3

Affected Entities

Symptom

When running using Python 3, NagTypeError is raised during an internal calculation for a communication array’s length (_lcom).

Diagnosis

The calculation of the array’s length mistakenly uses single-slash division between integer quantities. In Python 3 the result of such an operation is a floating-point value.

Workaround

Use Python 2.

Solution

Use double-slash integer division in function dae_dassl_setup in naginterfaces/base/ode.py

@@ -12706,9 +12706,9 @@
     _comm_py['icom'] = _icom
     _maxord_py = utils._EngineIntScalarType.to_py(_maxord)
     _lcom = utils._EngineIntScalarType(
-        40+(_maxord_py+4)*_neq_py+(2*(_neq_py-1)+(_neq_py-1)+1)*_neq_py+2*(_neq_py/((_neq_py-1)+(_neq_py-1)+1)+1), {'fun_name': fun_name, 'entity': '_lcom'},
+        40+(_maxord_py+4)*_neq_py+(2*(_neq_py-1)+(_neq_py-1)+1)*_neq_py+2*(_neq_py//((_neq_py-1)+(_neq_py-1)+1)+1), {'fun_name': fun_name, 'entity': '_lcom'},
     ).to_ctypes()
-    _com = utils._EngineFloat64ArrayType.empty_ctypes(40+(_maxord_py+4)*_neq_py+(2*(_neq_py-1)+(_neq_py-1)+1)*_neq_py+2*(_neq_py/((_neq_py-1)+(_neq_py-1)+1)+1))
+    _com = utils._EngineFloat64ArrayType.empty_ctypes(40+(_maxord_py+4)*_neq_py+(2*(_neq_py-1)+(_neq_py-1)+1)*_neq_py+2*(_neq_py//((_neq_py-1)+(_neq_py-1)+1)+1))
     _comm_py['com'] = _com
     _errbuf = utils._EngineErrbuf()
     _ierr = utils._EngineIntScalarType.empty_ctypes()

Fixed in Release

26.2.0.2

Missing constraint checks in LAPACK wrappers

Affected Entities

Numerous. Please contact NAG for the full list.

Two affected routines, for example, are naginterfaces.library.lapacklin.dgesvx() (where r must be positive in certain circumstances) and naginterfaces.library.lapackeig.dstein() (where iblock must be in ascending order).

Symptom

When using the MKL-enabled naginterfaces package an error message is issued by MKL about an invalid LAPACK argument, followed by the package raising a generic ‘Unexpected error’ NagException.

When using the variant of the package that is based on NAG-supplied LAPACK, an error message is issued by the NAG Engine about an invalid LAPACK argument, followed by a hard stop of the Python process.

Diagnosis

The code generation for these functions is mistakenly omitting conditional and loop-based constraint checks from the code and from the Raises sections of the documentation. These constraints must be checked by the Python wrappers to avoid them being processed un-Pythonically by the underlying compiled libraries.

Workaround

Ensure that valid input is always supplied, and if in doubt about what is valid please check against the main Library Manual at

https://www.nag.com/numeric/nl/nagdoc_latest/flhtml/frontmatter/manconts.html

or contact NAG.

Solution

The patch is omitted because of its size. Please contact NAG if you would like more information.

Fixed in Release

26.2.0.2

Reallocation mode impractical in stream quantiles routines

Affected Entities

Symptom

As an intended convenience for the programmer, both of these routines have communication arrays packed into a single communication dict (argument comm).

Function naginterfaces.library.stat.quantiles_stream_arbitrary() may request (by returning ind = 2) that you need to extend the arrays in size.

Function naginterfaces.library.stat.quantiles_stream_fixed() similarly has a ‘query’ mode (ind = 0 on entry) where the required sizes for the communication arrays are returned to you, after which you can make adequate declarations for the arrays.

These operations are impractical in their current form because of the arrays being packed away in comm (as ctypes arrays).

Diagnosis

Since you may need to interact directly with the communication arrays they need to remain as unpacked separate arguments in the argument list rather than being packed into a dict.

Workaround

None. A patch is required.

Solution.

The patch is omitted because of its size. Please contact NAG if you would like more information.

Fixed in Release

26.2.0.1

Column-ordered arrays not supported by sum of squares optimizer

Affected Entities

Symptom

NagTypeError raised when array a is stored in column order.

Diagnosis

Two-dimensional output arrays are declared by the wrapper to always use row ordering, and this mismatch triggers the exception.

Workaround

Only use row-major (C contiguous) input arrays (which is the NumPy default).

Solution

The patch is omitted because of its size. Please contact NAG if you would like more information.

Fixed in Release

26.2.0.1

Incorrect shape expression for bicubic spline coefficients

Affected Entities

Symptom

TypeError raised when the routine is called.

Diagnosis

The shape expression used in the function for the returned arrays dl and c is incorrectly a scalar instead of a tuple.

Workaround

None. A patch is required, or naginterfaces.library.fit.dim2_spline_sctr() could be used for the fit instead.

Solution

A patch for function dim2_spline_panel in naginterfaces/library/fit.py is

@@ -2833,10 +2833,10 @@
         _npoint_py, {'fun_name': fun_name, 'entity': '_npoint'},
     ).to_ctypes()
     _dl = _b_utils._EngineFloat64ArrayType.empty_ndarray(
-        (_px_py-4)*(_py_py-4),
+        ((_px_py-4)*(_py_py-4),),
     )
     _c = _b_utils._EngineFloat64ArrayType.empty_ndarray(
-        (_px_py-4)*(_py_py-4),
+        ((_px_py-4)*(_py_py-4),),
     )
     _return_scalars = b_dim2_spline_panel(
         _m,

Fixed in Release

26.2.0.1