Closed pjaap closed 3 weeks ago
I think it works, if one removes the Function in the struct parameter type and in the constructor.
The problem is another one: if the kernel of a LinearOperator depends on input, this input refers not to the evaluations of the test function (these are multiplied with the result of the kernel), but to the evaluations of the argument. However, the [id(u)] above refers to the operators that should be applied to the testfunctions, hence the constructor thinks you want to have a LinearOperator that does not depend on additional arguments. In this case the kernel has the signature (result, qpinfo).
So, after fixing the constructor of LinearOperator as suggested: To use the foo as defined above you could define
LinearOperator(foo, [id(u)], [grad(u)])
meaning that the input of the kernel contains the gradient evaluation of u.
To use the LinearOperator as defined above you need to change the foo definition to
(foo:Foo)(result, qpinfo) = nothing
Thanks @chmerdon for the clarification. I'll try to port your suggestion to my not-so-academic script :) Issue is resolved for me.
The following academic code does work with a
NonlinearOperator
but not with aLinearOperator
:This happens due to a strict dispatch with the type annotation
Function
in https://github.com/WIAS-PDELib/ExtendableFEM.jl/blob/5df206cb699df1424d62b637dca09227eebdf02a/src/common_operators/linear_operator.jl#L106 and https://github.com/WIAS-PDELib/ExtendableFEM.jl/blob/5df206cb699df1424d62b637dca09227eebdf02a/src/common_operators/linear_operator.jl#L14However, this cannot be simply removed since it causes wrong dispatching in the subsequent assembly loops.