Error when creating certain Mattsson2014 operators

[andrewwinters5000]

When one attempts to create Mattsson2014 operators with derivative_order 3 or 4 and accuracy_order=2 an error is thrown regarding an inconsistent number of DerivativeCoefficientRows and left_weights near the boundary. I believe we need to place extra ones in the left_weights vector, i.e., for the derivative_order=3 and accuracy_order=2 the weights vector would be

left_weights = SVector(T(1//2), T(1), T(1))

and for the derivative_order=4 and accuracy_order=2 the weights vector would be

left_weights = SVector(T(1//2), T(1), T(1), T(1))

For reference, here is the full error message for the fourth derivative-second order call

D4 = derivative_operator(Mattsson2014(),
                         derivative_order=4,
                         accuracy_order=2,
                         xmin=-1.0, xmax=3.0,
                         N=100)
ERROR: ArgumentError: length(left_boundary) == LeftWidth must hold. Got
length(left_boundary) => 4
LeftWidth => 1
Stacktrace:
 [1] throw_check_error(info::Any)
   @ ArgCheck ~/.julia/packages/ArgCheck/CA5vv/src/checks.jl:280
 [2] SummationByPartsOperators.DerivativeCoefficients(left_boundary::Tuple{SummationByPartsOperators.DerivativeCoefficientRow{Float64, 1, 4}, SummationByPartsOperators.DerivativeCoefficientRow{Float64, 1, 4}, SummationByPartsOperators.DerivativeCoefficientRow{Float64, 1, 5}, SummationByPartsOperators.DerivativeCoefficientRow{Float64, 1, 6}}, right_boundary::Tuple{SummationByPartsOperators.DerivativeCoefficientRow{Float64, 1, 4}, SummationByPartsOperators.DerivativeCoefficientRow{Float64, 1, 4}, SummationByPartsOperators.DerivativeCoefficientRow{Float64, 1, 5}, SummationByPartsOperators.DerivativeCoefficientRow{Float64, 1, 6}}, left_boundary_derivatives::Tuple{SummationByPartsOperators.DerivativeCoefficientRow{Float64, 1, 3}, SummationByPartsOperators.DerivativeCoefficientRow{Float64, 1, 3}, SummationByPartsOperators.DerivativeCoefficientRow{Float64, 1, 4}}, right_boundary_derivatives::Tuple{SummationByPartsOperators.DerivativeCoefficientRow{Float64, 1, 3}, SummationByPartsOperators.DerivativeCoefficientRow{Float64, 1, 3}, SummationByPartsOperators.DerivativeCoefficientRow{Float64, 1, 4}}, lower_coef::StaticArraysCore.SVector{2, Float64}, central_coef::Float64, upper_coef::StaticArraysCore.SVector{2, Float64}, left_weights::StaticArraysCore.SVector{1, Float64}, right_weights::StaticArraysCore.SVector{1, Float64}, mode::FastMode, derivative_order::Int64, accuracy_order::Int64, source_of_coefficients::Mattsson2014)
   @ SummationByPartsOperators ~/.julia/packages/SummationByPartsOperators/8VqvO/src/SBP_operators.jl:34
 [3] fourth_derivative_coefficients
   @ ~/.julia/packages/SummationByPartsOperators/8VqvO/src/SBP_coefficients/Mattsson2014.jl:746 [inlined]
 [4] derivative_operator(source_of_coefficients::Mattsson2014, derivative_order::Int64, accuracy_order::Int64, xmin::Float64, xmax::Float64, N::Int64, mode::FastMode)
   @ SummationByPartsOperators ~/.julia/packages/SummationByPartsOperators/8VqvO/src/SBP_operators.jl:689
 [5] #derivative_operator#54
   @ ~/.julia/packages/SummationByPartsOperators/8VqvO/src/SBP_operators.jl:705 [inlined]
 [6] top-level scope
   @ REPL[56]:1

[ranocha]

Thanks for the report! Your suggested fix looks correct to me. It should be fixed soon (see #209)

[andrewwinters5000]

Great! It is odd that the testing didn't throw the error above in the logs. I am not sure why this is the case because, as far as I can tell, here the second order accurate operators are created and checked for the discrete ability to differentiate polynomials.

[ranocha]

The problem is that I was lazy when setting up the tests. Since there are many sources of coefficients (=papers) not all supporting everything, I try to construct the operators first. If this throws an error, I just continue without the tests, assuming that the coefficients are just not implemented.

I am open for better ideas how to handle all the different sources of coefficients, though

[andrewwinters5000]

The problem is that I was lazy when setting up the tests. Since there are many sources of coefficients (=papers) not all supporting everything, I try to construct the operators first. If this throws an error, I just continue without the tests, assuming that the coefficients are just not implemented.

I am open for better ideas how to handle all the different sources of coefficients, though

That makes sense. Loading in all those nasty coefficients is a real pain so this strategy makes sense to me.