Error case for sparse Jacobian creation about cppadcodegen HOT 3 CLOSED

When the value of testCoeff is set to zero, the sparsity pattern is also being changed.
When testCoeff != 0, then the jacobian spartity pattern will include an entry for variable 1 when ii = 0 and jj = 0 from the section:

testCoeff * advec((ii * dim1 + jj) * dim3 + 1) * advec((ii * dim1 + jj) * dim3 + 1)
// which is
testCoeff * advec((0 * dim1 + jj) * dim3 + 1) * advec((0 * dim1 + 0) * dim3 + 1)
// which is
testCoeff * advec(1) * advec(1)

The call to cgen.setCustomSparseJacobianElements(mappingRows, mappingCols) assumes the elements to be a subset of the full sparsity pattern.
The failure is inside ADFun<Base>::SparseJacobianReverse() which checks whether the provided elements are part of the sparsity pattern.
However, the sparsity pattern does not include the variable 1 when testCoeff = 0.

I've added some additional documentation to reflect this.

from cppadcodegen.

Ok, but by speaking about a failure do you mean that this is expected from the developer point of view or may this be considered as a bug?
From the point of view of a user, this behaviour is rather unexpected, since often you cannot foresee whether "numeric" coefficients like testCoeff will become zero or not, e.g., when you implement an error function for an optimization algorithm and respective coefficients are linear combinations of other "numeric" coefficients.

from cppadcodegen.

At the moment it is expected for the developer to provide a correct sparsity pattern (would you really want to receive constant zeros in a sparse Jacobian/Hessian?).
CppadCodeGen does not perform any additional checks regarding the sparsity provided by the user and just forwards it to CppAD which, in turn, expects the developer to provide the correct sparsity.

The common use case to define a custom sparsity is to remove some elements which are not needed.
For this, it possible to compute the sparsity using CppAD::ADFun<CGD>, remove the non-desired elements and then provide it to CppADCodeGen.
One would use the same strategy if we were just using CppAD.

CppAD now has explicit support for parameters, which will soon also be supported by CppADCodeGen (see feature/parameters ).
This will reduce the likelihood of setCustomSparseJacobianElements being needed.

from cppadcodegen.