Question about when MiniZinc will return feasible solutions

Hi all. I have a question about the following MiniZinc model. I am able to give a feasible solution with primal_feasibility_report but nothing is found by the solver. I’m aware of the silliness of the presented model, this is a minimal example of this behavior extracted from a larger model. Thanks!

jumpmod = GenericModel{Int}(() -> MiniZinc.Optimizer{Int}("chuffed"))

x = @variable(
    jumpmod,
    x[i=1:3],
    Bin
)

@constraint(jumpmod, sum(x[[1]]) == 1)
@constraint(jumpmod, sum(x[[2]]) == 1)
@constraint(jumpmod, sum(x[[3]]) == 1)

optimize!(jumpmod)

value.(x)

primal_feasibility_report(jumpmod, Dict(x[1] => 1, x[2] => 1, x[3] => 1))
1 Like

I just tried your code and I get

julia> solution_summary(jumpmod)
* Solver : MiniZinc

* Status
  Result count       : 1
  Termination status : OPTIMAL
  Message from the solver:
  "SATISFIABLE"

* Candidate solution (result #1)
  Primal status      : FEASIBLE_POINT
  Dual status        : NO_SOLUTION
  Objective value    : 0

* Work counters
  Solve time (sec)   : 6.42982e-01


julia> value.(x)
3-element Vector{Int64}:
 1
 1
 1

What does solution_summary prints for you ?

1 Like

Thank you for helping check @blegat. For reference, I’m on JuMP v1.22.2 and MiniZinc v0.3.9. The below code is as close as possible to what is going on in my actual use case, I show the example and the result from solution_summary below.

using JuMP, MiniZinc, DataFrames

workflow = DataFrame(Step=[1,2,3],ChoiceSets=[missing,missing,missing])

jumpmod = GenericModel{Int}(() -> MiniZinc.Optimizer{Int}("chuffed"))
set_attribute(jumpmod, MOI.SolutionLimit(), 10) 

x = @variable(
    jumpmod,
    x[axes(workflow,1)],
    Bin
)

@constraint(jumpmod, sum(x[[1]]) == 1)
@constraint(jumpmod, sum(x[[2]]) == 1)
@constraint(jumpmod, sum(x[[3]]) == 1)

optimize!(jumpmod)
solution_summary(jumpmod)
value.(x)

Calling summary:

julia> solution_summary(jumpmod)
* Solver : MiniZinc

* Status
  Result count       : 0
  Termination status : OTHER_ERROR
  Message from the solver:
  "=====ERROR=====
Warning: included file "count.mzn" overrides a global constraint file from the standard library. This is deprecated. For a solver-specific redefinition of a global constraint, override "fzn_<global>.mzn" instead.

/workspace/srcdir/chuffed/chuffed/core/engine.cpp:419: Not yet supported
"

* Candidate solution (result #1)
  Primal status      : NO_SOLUTION
  Dual status        : NO_SOLUTION

* Work counters
  Solve time (sec)   : 4.46848e-01

@blegat did you have a chance to take a look at the error I was getting?

/workspace/srcdir/chuffed/chuffed/core/engine.cpp:419: Not yet supported

I can reproduce, but I assume this is a bug in Chuffed where you have a degenerate solution with x = 1 but you are asking for multiple solutions? There does’t seem to be any issue in MiniZinc.jl

1 Like

Thanks. I was curious why it was giving that error and not able to return the single feasible solution despite being degenerate. But it seems like it worked for @blegat based on his previous response?

Your first example works for me but not the second one.

If I remove from the second example set_attribute(jumpmod, MOI.SolutionLimit(), 10), it works. If I add it to the first example, it fails.

The error seems to come from chuffed which includes some count.mzn file when counting solutions.

HiGHS fails with a different error message:
minizinc: Unrecognized option or bad format –num-solutions’`

I believe that the issue is from the current artifact available for chuffed (v0.10.4): Yggdrasil/C/Chuffed/build_tarballs.jl at master · JuliaPackaging/Yggdrasil · GitHub

It should be possible to update the build_tarballs.jl to work with the latest version (0.13.2): Tags · chuffed/chuffed · GitHub

I am trying to do so: [Chuffed] Update from v0.10.4 to v0.13.2 by remi-garcia · Pull Request #9082 · JuliaPackaging/Yggdrasil · GitHub

1 Like

Thank you for the help @remi-garcia. It’s nice that this also led to finding some fixes that need to be applied in chuffed itself!

Agree that this is an upstream issue in Chuffed, and that updating to the latest version might fix it.

HiGHS fails because it doesn’t support returning multiple solutions.

New artifact is available :tada: . MiniZinc compat with chuffed is currently “=0.10.4”.

@odow Could you update the Project.toml? I don’t know which way is best for MiniZinc.jl :slight_smile:

See Update to Chuffed_jll@0.13.2 by odow · Pull Request #74 · jump-dev/MiniZinc.jl · GitHub

1 Like

It works with the last MiniZinc.jl release, @slwu89 .

julia> using JuMP, MiniZinc

julia> jumpmod = GenericModel{Int}(() -> MiniZinc.Optimizer{Int}("chuffed"))
A JuMP Model
Feasibility problem with:
Variables: 0
Model mode: AUTOMATIC
CachingOptimizer state: EMPTY_OPTIMIZER
Solver name: MiniZinc

julia> x = @variable(
           jumpmod,
           x[i=1:3],
           Bin
       )
3-element Vector{GenericVariableRef{Int64}}:
 x[1]
 x[2]
 x[3]

julia> @constraint(jumpmod, sum(x[[1]]) == 1)
x[1] = 1

julia> @constraint(jumpmod, sum(x[[2]]) == 1)
x[2] = 1

julia> @constraint(jumpmod, sum(x[[3]]) == 1)
x[3] = 1

julia> set_attribute(jumpmod, MOI.SolutionLimit(), 10)

julia> optimize!(jumpmod)

julia> solution_summary(jumpmod)
* Solver : MiniZinc

* Status
  Result count       : 1
  Termination status : OPTIMAL
  Message from the solver:
  "SATISFIABLE"

* Candidate solution (result #1)
  Primal status      : FEASIBLE_POINT
  Dual status        : NO_SOLUTION
  Objective value    : 0

* Work counters
  Solve time (sec)   : 5.46820e-01
2 Likes