[Bug]:Error writing cost when we have resources that are not new build and not eligible for retirement

[manarjar]

Bug description

I have a portfolio with 2 zones, first zone has no generation and has a load profile and the second zone has all generators and some of them are not new build and not eligible for retirement. The eCFix becomes a vector of type Any. This causes an error when attempting to sum an empty vector for the zone without generation. Digging deeper to this issue I found that we should add vZERO variable to the expressions similar to what we had in GenX 0.4.0 to solve this issue and make 'eCFix' a vector of type 'AffExpr'

Environment and Version

windows 11, Julia 1.10.4, GenX 0.4.1

Relevant error messages

No response

Additional context

No response

[rowry38]

I am also getting a similar issue where outputs and costs do not write even though the model solves. This was occurring after a fresh install. The example cases work but the specific inputs are creating an error it seems.

Summary
Runtime: 6138.83s
Status interior point solve: optimal
Status crossover: optimal
objective value: 7.17672660e+08
interior solution primal residual (abs/rel): 1.19e-10 / 7.93e-14
interior solution dual residual (abs/rel): 6.86e-07 / 1.40e-12
interior solution objective gap (abs/rel): 1.05e-02 / 1.46e-11
basic solution primal infeasibility: 7.64e-13
basic solution dual infeasibility: 7.44e-12
Ipx: IPM optimal
Ipx: Crossover optimal
Solving the original LP from the solution after postsolve
Model status : Optimal
IPM iterations: 115
Crossover iterations: 97509
Objective value : 7.2163545019e+08
HiGHS run time : 6148.72
LP solved for primal
Writing Output
ERROR: LoadError: MethodError: no method matching zero(::Type{Any})

Closest candidates are:
zero(::Type{Union{Missing, T}}) where T
@ Base missing.jl:105
zero(::Type{Union{}}, Any...)
@ Base number.jl:310
zero(::Type{Pkg.Resolve.VersionWeight})
@ Pkg ~/.julia/juliaup/julia-1.10.5+0.x64.apple.darwin14/share/julia/stdlib/v1.10/Pkg/src/Resolve/versionweights.jl:15
...

Stacktrace:
[1] zero(::Type{Any})
@ Base ./missing.jl:106
[2] reduce_empty(::typeof(+), ::Type{Any})
@ Base ./reduce.jl:343
[3] reduce_empty(::typeof(Base.add_sum), ::Type{Any})
@ Base ./reduce.jl:352
[4] mapreduce_empty(::typeof(identity), op::Function, T::Type)
@ Base ./reduce.jl:372
[5] reduce_empty(op::Base.MappingRF{typeof(identity), typeof(Base.add_sum)}, ::Type{Any})
@ Base ./reduce.jl:361
[6] reduce_empty_iter
@ ./reduce.jl:384 [inlined]
[7] mapreduce_empty_iter(f::Function, op::Function, itr::Vector{Any}, ItrEltype::Base.HasEltype)
@ Base ./reduce.jl:380
[8] _mapreduce(f::typeof(identity), op::typeof(Base.add_sum), ::IndexLinear, A::Vector{Any})
@ Base ./reduce.jl:432
[9] _mapreduce_dim
@ ./reducedim.jl:365 [inlined]
[10] mapreduce
@ ./reducedim.jl:357 [inlined]
[11] _sum
@ ./reducedim.jl:1015 [inlined]
[12] _sum
@ ./reducedim.jl:1014 [inlined]
[13] sum(a::Vector{Any})
@ Base ./reducedim.jl:1010
[14] write_costs(path::String, inputs::Dict{Any, Any}, setup::Dict{Any, Any}, EP::JuMP.Model)
@ GenX ~/GenX GitClone/GenX.jl/src/write_outputs/write_costs.jl:169
[15] macro expansion
@ ./timing.jl:395 [inlined]
[16] write_outputs(EP::JuMP.Model, path::String, setup::Dict{Any, Any}, inputs::Dict{Any, Any})
@ GenX ~/GenX GitClone/GenX.jl/src/write_outputs/write_outputs.jl:65
[17] macro expansion
@ ./timing.jl:395 [inlined]
[18] run_genx_case_simple!(case::String, mysetup::Dict{Any, Any}, optimizer::Type)
@ GenX ~/GenX GitClone/GenX.jl/src/case_runners/case_runner.jl:89
[19] run_genx_case!(case::String, optimizer::Type)
@ GenX ~/GenX GitClone/GenX.jl/src/case_runners/case_runner.jl:37
[20] run_genx_case!(case::String)
@ GenX ~/GenX GitClone/GenX.jl/src/case_runners/case_runner.jl:32
[21] top-level scope
@ ~/GenX/Cases/Generic/Run.jl:3
[22] include(fname::String)
@ Base.MainInclude ./client.jl:489
[23] top-level scope
@ REPL[3]:1

[cfe316]

Thanks for sending a stack trace, @rowry38 .

Looks like the problem is with this line 169 of write_costs.jl:

eCFix = sum(value.(EP[:eCFix][Y_ZONE]))

Probably could add an init term to the sum function. I think that would be preferable to adding a vZERO dummy variable.

[sambuddhac]

Thanks for raising the issue @manarjar . Could you please send us your case? We would like to run a test with the fix suggested by Jacob (and make additional fixes, if need be) on a PR. Thanks !!!

[lbonaldo]

Thanks @manarjar, for bringing this issue to our attention. It's now resolved in develop and will be included in the upcoming release.

[lbonaldo]

Closing this issue as resolved.