You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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
inExtendableFEM.jl/src/common_operators/linear_operator.jl
Line 106 in 5df206c
ExtendableFEM.jl/src/common_operators/linear_operator.jl
Line 14 in 5df206c
However, this cannot be simply removed since it causes wrong dispatching in the subsequent assembly loops.
The text was updated successfully, but these errors were encountered: