[Bug]: No Method Matching add_to_expression

[wrgunther]

Bug description

Using a GenX case with Operational_reserves.csv input containing a Static_Contingency_MW >0 the run crashes while loading the Operational Reserves Core Module. This can be replicated starting from the 5_three_zones_w_piecewise_fuel example case by entering 2000 for the Static_Contingency_MW. The problem can be fixed by reverting two lines in operational_reserves.jl

Line 273 add_to_expression!(EP[:eRsvReq], EP[:eContingencyReq])
to EP[:eRsvReq] = EP[:eRsvReq] + EP[:eContingencyReq]

Line 287 add_to_expression!(EP[:eObj], eTotalCRsvPen)
to EP[:eObj] += eTotalCRsvPen

This is a low priority given the known fix but presumably there is a way to update add_to_expression.

Environment and Version

Windows 11, Julia 1.10.5, GenX 0.4.1 main

Relevant error messages

Operational Reserves Core Module
ERROR: LoadError: MethodError: no method matching add_to_expression!(::Vector{Float64}, ::Vector{Float64})

Closest candidates are:
  add_to_expression!(::JuMP.GenericQuadExpr{C, V}, ::Union{JuMP.GenericAffExpr{C, V}, V}, ::Union{Number, LinearAlgebra.UniformScaling}) where {C, V}
   @ JuMP C:\Users\GUNTHERW\.julia\packages\JuMP\6RAQ9\src\quad_expr.jl:470
  add_to_expression!(::JuMP.GenericQuadExpr{C, V}, ::V, ::JuMP.GenericAffExpr{C, V}) where {C, V}
   @ JuMP C:\Users\GUNTHERW\.julia\packages\JuMP\6RAQ9\src\quad_expr.jl:523
  add_to_expression!(::JuMP.GenericQuadExpr{C, V}, ::V) where {C, V}
   @ JuMP C:\Users\GUNTHERW\.julia\packages\JuMP\6RAQ9\src\quad_expr.jl:429
  ...

Stacktrace:
  [1] operational_reserves_core!(EP::JuMP.Model, inputs::Dict{Any, Any}, setup::Dict{Any, Any})
    @ GenX C:\GenX-0.4.1\src\model\core\operational_reserves.jl:273
  [2] operational_reserves!(EP::JuMP.Model, inputs::Dict{Any, Any}, setup::Dict{Any, Any})
    @ GenX C:\GenX-0.4.1\src\model\core\operational_reserves.jl:19
  [3] generate_model(setup::Dict{Any, Any}, inputs::Dict{Any, Any}, OPTIMIZER::MathOptInterface.OptimizerWithAttributes)
    @ GenX C:\GenX-0.4.1\src\model\generate_model.jl:138
  [4] macro expansion
    @ .\timing.jl:395 [inlined]
  [5] run_genx_case_simple!(case::String, mysetup::Dict{Any, Any}, optimizer::Type)
    @ GenX C:\GenX-0.4.1\src\case_runners\case_runner.jl:77
  [6] run_genx_case!(case::String, optimizer::Type)
    @ GenX C:\GenX-0.4.1\src\case_runners\case_runner.jl:37
  [7] run_genx_case!(case::String)
    @ GenX C:\GenX-0.4.1\src\case_runners\case_runner.jl:32
  [8] top-level scope
    @ C:\GenX-0.4.1\example_systems\5_three_zones_w_piecewise_fuel\Run.jl:3
  [9] include(fname::String)
    @ Base.MainInclude .\client.jl:489
 [10] top-level scope
    @ REPL[2]:1
in expression starting at C:\GenX-0.4.1\example_systems\5_three_zones_w_piecewise_fuel\Run.jl:3

julia>

Additional context

The bug existed in earlier versions of GenX (Dec 2023) and the relevant lines in reserves.jl were 258 and 268.

[cfe316]

Thanks for submitting this issue @wrgunther .

This has exposed a funny case where :eRsvReq can end up as a Vector{Float} and not an AbstractArray{GenericAffExpr}.
@RuaridhMacd perhaps it would be possible to cast or promote it so that it's always a GenericAffExpr ? Then it could be modified with add_similar_to_expression!.

[RuaridhMacd]

Hi @cfe316 @wrgunther

My guess is that this is happening when function must_run_vre_generation(t) is zero or constant. That's defined here

I've done a little test here:

function make_test_model()
   m = Model(HiGHS.Optimizer)
   @variable(m, x>=0)
   @variable(m, y>=0)
   @constraint(m, c1, x <= 3)
   @constraint(m, c2, y <= 4)
   @objective(m, Max, x + y)
   return m
end

This expression comes back as a Vector{Float64}, as expected, because it contains no variables:
@expression(m, eTest1[q=1:3], q * 10.0)

This comes back as Vector{AffExpr}:
@expression(m, eTest2[q=1:3], q * 10.0 * m[:x])

It looks like this creates a local Vector{AffExpr}, but the version in the model is Vector{Float64}.
eTest3 = AffExpr.(@expression(m, eTest3[q=1:3], q * 10.0))
typeof(eTest3) --> Vector{AffExpr}
typeof(m[: eTest3]) --> Vector{Float64}

add_to_expression!(m[:eTest3], m[:y]) ---> 
  ERROR: MethodError: no method matching add_to_expression!(::Vector{Float64}, ::VariableRef)

add_to_expression!(eTest3, m[:y]) ---> Works but is not named in the model

We could redefine must_run_vre_generation, but that might still leave the problem if eTotalCap is not an expression

function must_run_vre_generation(t)
        sum(
            pP_Max(y, t) * EP[:eTotalCap][y]
            for y in intersect(inputs["VRE"], inputs["MUST_RUN"]);
            init = 0)
    end

and

function must_run_vre_generation(t)
        sum(
            pP_Max(y, t) * EP[:eTotalCap][y]
            for y in intersect(inputs["VRE"], inputs["MUST_RUN"]);
            init = AffExpr(0)
        )    
end

A safe, but clunky option would be to redefine eRsvReq as AffExpr(0) and then add terms to it. Alternatively, we could use our add_similar_to_expression functions to add some validation and handle this sort of thing. What do you think @cfe316

[lbonaldo]

This is now resolved in the develop branch and will be included in the upcoming release very soon. Thanks, @wrgunther, for bringing this to our attention!