Giter Club home page Giter Club logo

chuffed's Introduction

Chuffed, a lazy clause generation solver

Geoffrey Chu, Peter J. Stuckey, Andreas Schutt, Thorsten Ehlers, Graeme Gange, Kathryn Francis

Data61, CSIRO, Australia

Department of Computing and Information Systems University of Melbourne, Australia

Usage

The easiest way to use Chuffed is as a backend to the MiniZinc constraint modelling language. Compiling Chuffed using the instructions below will create the fzn-chuffed executable that can interpret MiniZinc's FlatZinc solver language.

You can also use Chuffed directly from C++. Take a look at the files in the examples folder to get started.

Assumption interface

Chuffed has FlatZinc hooks to the internal assumption handling. By adding an assume(array [int] of var bool) annotation to a solve item, the specified Booleans will be treated as assumptions. This annotation can be used when chuffed's solver specific definitions are included (i.e., by adding include "chuffed.mzn"; to your MiniZinc model).

If the resulting problem is unsatisfiable (or the optimum is found), the solver will print a valid -- though not necessarily minimal -- nogood in terms of assumptions (and, for optimization instances, an objective bound).

Integration with CP Profiler

The CP Profiler, integrated into the MiniZincIDE, can be used with Chuffed to visualise the search trees and analyse the nogoods that Chuffed explores when solving a problem. In order to enable profiling support, Chuffed includes profiler connection code. This has been included as a git subtree in thirdparty/cp-profiler-integration. To pull the newest version of the integration code, use the following command in the repository root.

git subtree pull --prefix thirdparty/cp-profiler-integration https://github.com/MiniZinc/cpp-integration.git master --squash

Compilation

Chuffed can be compiled on Windows, macOS and Linux.

Prerequisites

You need a recent C++ compiler that supports C++11 (e.g. Microsoft Visual Studio 2013, gcc 4.8, clang), as well as the CMake build tool (at least version 3.1). To automatically format the Chuffed source code, the clang-format executable must be available.

CMake & Co

To initialize the CMake build environment, using build as the build directory, use the following command:

cmake -B build -S .

To then build the fzn-chuffed executable run:

cmake --build build

To install fzn-chuffed run the following command:

cmake --build build --target install

The installation directory can be chosen by appending -DCMAKE_INSTALL_PREFIX=$LOCATION with the chosen location to the initial CMake command.

To build the C++ examples:

cmake --build build --target examples

To format the Chuffed source files

cmake --build build --target format

Description

Chuffed is a state of the art lazy clause solver designed from the ground up with lazy clause generation in mind. Lazy clause generation is a hybrid approach to constraint solving that combines features of finite domain propagation and Boolean satisfiability. Finite domain propagation is instrumented to record the reasons for each propagation step. This creates an implication graph like that built by a SAT solver, which may be used to create efficient nogoods that record the reasons for failure. These nogoods can be propagated efficiently using SAT unit propagation technology. The resulting hybrid system combines some of the advantages of finite domain constraint programming (high level model and programmable search) with some of the advantages of SAT solvers (reduced search by nogood creation, and effective autonomous search using variable activities).

The FD components of Chuffed are very tightly integrated with a SAT solver. For "small" variables (|D| <= 1000), SAT variables representing [x = v] or [x >= v] are eagerly created at the start of the problem. Channelling constraints are natively enforced by the variable objects in order to keep the FD solver and the SAT solver's view of the domains fully consistent at all times. For "large" variables (|D| > 1000), the SAT variables are lazily generated as needed. Every propagator in Chuffed has been instrumented so that all propagation can be explained by some combination of the literals in the SAT solver. An explanation is of the form a_1 /\ ... /\ a_n -> d, where a_i represent domain restrictions which are currently true, and d represents the domain change that is implied. e.g. Suppose z >= x + y, and we have x >= 3, y >= 2. Then the propagator would propagate z >= 5 with explanation clause x >= 3 /\ y >= 2 -> z >= 5.

The explanations for each propagation form an implication graph. This allows us to do three very important things. Firstly, we can derive a nogood to explain each failure. Such nogoods often allow us to avoid a very large amount of redundant work, thus producing search trees which are orders of magnitude smaller. Secondly, nogoods allow us to make informed choices about non-chronological back-jumping. When no literal from a decision level appears in the nogood, it is indicative of the fact that the decision made at that level was completely irrelevant to the search. Thus by back-jumping over such decisions, we retrospectively avoid making such bad decisions, and hopefully make good decisions instead which drive the search towards failure. Thirdly, by analysing the conflict, we can actively gain some information about what good decision choices are. The Variable State Independent Decaying Sum (VSIDS) heuristic is an extremely effective search heuristic for SAT problems, and is also extremely good for a range of CP problems. Each variables has an associated activity, which is increased whenever the variable is involved in the conflict. Variables with the highest activity is chosen as the decision variable at each node. The activities are decayed to reflect the fact that the set of important variables changes with time.

Although Chuffed implements lazy clause generation, which is cutting edge and rather complex, the FD parts of Chuffed are relatively simple. In fact, it is quite minimalistic. Chuffed only supports 3 different propagator priorities. Chuffed implements a number of global propagators (alldiff, inverse, minimum, table, regular, mdd, cumulative, disjunctive, circuit, difference). It also only supports two kinds of integer variables. Small integer variables for which the domain is represented by a byte string. And large integer variables for which the domain is represented only by its upper and lower bound (no holes allowed). All boolean variables and boolean constraints are handled by the builtin SAT solver.

Great pains have been taken to make everything as simple and efficient as possible. The solver, when run with lazy clause generation disabled, is somewhat comparable in speed with older versions of Gecode. The overhead from lazy clause generation ranges from negligible to perhaps around 100%. The search reduction, however, can reach orders of magnitude on appropriate problems. Thus lazy clause generation is an extremely important and useful technology. The theory behind lazy clause generation is described in much greater detail in various papers.

chuffed's People

Contributors

adgold avatar aekh avatar aiceste avatar cyderize avatar ddeunagomez avatar dekker1 avatar dependabot[bot] avatar ed-lam avatar fwinter90 avatar gkgange avatar guidotack avatar msgmaxim avatar raphaelboudreault avatar samclou avatar schutta avatar waywardmonkeys avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

chuffed's Issues

About Chuffed with Caching

Hi,

I come across this paper: Chu, Geoffrey, Maria Garcia De La Banda, and Peter J. Stuckey. "Exploiting subproblem dominance in constraint programming." Constraints 17.1 (2012): 1-38.

The paper said that the chuffed solver "can be run as a naive CP solver, as a CP solver with caching and as a lazy clause generation solver." I know how to run the solver with/without lazy clause generation, but I wonder whether the subproblem caching option is still available in the latest version of Chuffed? If so, what configuration should I make to test the solver with this option?

Thanks!

Allen

Chuffed Timelimit

I would really appreciate if anybody help me with Timelimit problem of Chuffed.

When i run Chuffed solver using MiniZinc IDE, the solver ends solving problems in 30 minutes. whereas i need more time to give me the right answer of the problem

[Feature Request] Parallel version of Chuffed as discussed in Ehlers, Stuckey (2016)

One thing that seems to be missing from Chuffed, as far as I can tell, is multiprocessing support. There's a 2016 paper from the maintainers/authors of Chuffed discussing a parallel version of Chuffed with promising results.

Yet, this extension isn't part of this repo. Is that due to resource constraints? Is it intended to be included at some point?

Thanks for all your work, providing a good open source solver and making Constraint Programming easily accessible through the whole MiniZinc project.

Edit: I realised that there is a module named "Parallel", so maybe the code is already there. I'm just not sure how to use it. Is there an example using multi-processing somewhere? Is it as simple as adding a command line option?

Building the tests on the "develop" branch fails

On the develop branch dated "Mon Sep 20 14:13:57 2021 +1000"

When running

$ cmake --build . --target examples

we get:

[ 61%] Building CXX object CMakeFiles/nurse.dir/chuffed/examples/nurse.cpp.o
nurse.cpp:18:10: fatal error: mdd/circ_fns.h: No such file or directory
   18 | #include <mdd/circ_fns.h>

/opt/MiniZincIDE-2.2.1-bundle-linux/bin/fzn-chuffed crash (Ubuntu 16.04 LTS)

dna.zip

matsc@teterev:~/MZN$ /opt/MiniZincIDE-2.2.1-bundle-linux/bin/fzn-chuffed dna.fzn
Segmentation fault (core dumped)
matsc@teterev:~/MZN$ /opt/MiniZincIDE-2.1.6-bundle-linux-x86_64/fzn-chuffed dna.fzn
x = array2d(1..20, 1..8, [0, 0, 0, 0, 10, 10, 10, 10, 0, 0, 0, 0, 11, 11, 11, 11, 0, 0, 1, 1, 10, 10, 11, 11, 0, 0, 1, 1, 11, 11, 10, 10, 0, 0, 10, 10, 0, 0, 10, 10, 0, 0, 10, 10, 1, 1, 11, 11, 0, 0, 10, 10, 10, 10, 0, 0, 0, 0, 10, 11, 0, 10, 1, 11, 0, 0, 10, 11, 1, 11, 0, 10, 0, 0, 10, 11, 10, 0, 11, 1, 0, 0, 10, 11, 11, 1, 10, 0, 0, 0, 11, 10, 0, 10, 11, 1, 0, 0, 11, 10, 1, 11, 10, 0, 0, 0, 11, 10, 10, 0, 1, 11, 0, 0, 11, 10, 11, 1, 0, 10, 0, 1, 0, 1, 10, 11, 10, 11, 0, 1, 0, 1, 11, 10, 11, 10, 0, 1, 1, 0, 10, 11, 11, 10, 0, 1, 1, 0, 11, 10, 10, 11, 0, 1, 10, 10, 0, 11, 0, 11]);

----------

wrong answer (MZN 2.1.6) resp. crash (MZN 2.2.1)

bug.zip

I have a model that contains constraints of the form:

    forall(t1 in 0..MAXT) (r[t1] in generic_temp_domain(t1))

where generic_temp_domain(t1) is typically a somewhat sparse set.

Chuffed is giving me solutions where this constraint does not hold:

With MiniZinc 2.1.6:

$ mzn-chuffed bug.mzn bug.dzn
FALSE: r[161] in {-1,0,8,16,24,32,40,48,56,64,72,80,88,96,104,112,120,648,1120,1128,1136,1144,1152} where r[161] = 656
FALSE: r[209] in {0,8,16,24,32,40,56,64,72,80,88,96,104,112,120,1260,1264,1268,1272,1276,1280,1284,1288,1292,1296,6608,6612,6616,6620,6624,6628,6632,6636,6640} where r[209] = 656
FALSE: r[210] in {0,8,16,24,32,40,56,64,72,80,88,96,104,112,120,1120,1128,1136,1144,1152} where r[210] = 656
FALSE: r[221] in {-1,0,8,16,24,32,40,48,56,64,72,80,88,96,104,112,120,648,1120,1128,1136,1144,1152} where r[221] = 656
FALSE: r[229] in {0,8,16,24,32,40,56,64,72,80,88,96,104,112,120,1120,1128,1136,1144,1152} where r[229] = 656
FALSE: r[250] in {-1,0,8,16,24,32,40,48,56,64,72,80,88,96,104,112,120,1260,1264,1268,1272,1276,1280,1284,1288,1292,1296,6608,6612,6616,6620,6624,6628,6632,6636,6640} where r[250] = 656
FALSE: r[280] in {0,8,16,24,32,40,56,64,72,80,88,96,104,112,120,1260,1264,1268,1272,1276,1280,1284,1288,1292,1296,6608,6612,6616,6620,6624,6628,6632,6636,6640} where r[280] = 656
FALSE: r[281] in {0,8,16,24,32,40,56,64,72,80,88,96,104,112,120,1120,1128,1136,1144,1152} where r[281] = 656
FALSE: r[309] in {-1,0,8,16,24,32,40,48,56,64,72,80,88,96,104,112,120,648,1200,1208} where r[309] = 656
FALSE: r[364] in {-1,0,8,16,24,32,40,48,56,64,72,80,88,96,104,112,120,648,1160,1168,1176,1184,1192} where r[364] = 656
FALSE: r[401] in {0,8,16,24,32,40,56,64,72,80,88,96,104,112,120,1160,1168,1176,1184,1192} where r[401] = 656
----------

With MiniZinc 2.2.1:

$ minizinc --solver chuffed -c --fzn bug.fzn bug.mzn bug.dzn
$ fzn-chuffed bug.fzn
Segmentation fault (core dumped)

Unclear format of statistics output

Hallo,

I'm running chuffed via the minizinc interface for an optimization problem and include the '-s' option to obtain statistics:
$ mzn-chuffed <model.mzn> -s
Output: 200,21,865,3,0,0,4412,201,0.00,0.01

How is this string to be read?
I can identify the first value to be the optimization objective, but afterward, I have to start guessing.

Suggestions for improvement:
a) Maybe adapt to the format used by other solvers (e.g. gecode):

Runtime: x
Solutions: y
...

or b) document the string format somewhere.

Thanks,
Helge

On Windows, calling fzn-chuffed programmatically doesn't always have an output

Working on a Julia binding to Chuffed through its FlatZinc parser, I'm getting an awkward situation where, at random, fzn-chuffed does not output anything to stdout when called from Julia. Running again the exact same command usually yields the right output. I can quite reliably reproduce this by running the test suite from Chuffed.jl.

It's likely that it's just a flushing issue when writing the results to stdout. I suppose that adding a call like std::cout << std::flush at the end of main in fzn-chuffed.cpp should do the trick.

Related issues: #81, JuliaConstraints/ConstraintProgrammingExtensions.jl#24.

Segfault on Ubuntu 18.04

Hi,
The attached .fzn causes a seg fault on a completely plain new installation of Ubuntu 18.04, using the default compiler g++ 7.3.0

Seg fault occurs whether it's a static build or not.

carseq-fzn.zip

Segmentation Fault (MiniZinc 2.2.1)

This issue was one of the reported ones in #32 and has been transferred to here in order to seperate them.

=====

bug.zip

Chuffed crashes on the model when using MiniZinc 2.2.1.

$ minizinc --solver chuffed -c --fzn bug.fzn bug.mzn bug.dzn
$ fzn-chuffed bug.fzn
Segmentation fault (core dumped)

Some more information about Mats' solving environment.

matsc@teterev:~/Downloads$ ls -lt /opt/MiniZincIDE-2.2.1-bundle-linux/bin/minizinc
-rwxr-xr-x 1 matsc matsc 23231384 Sep  6 07:02 /opt/MiniZincIDE-2.2.1-bundle-linux/bin/minizinc

matsc@teterev:~/Downloads$ gdb /opt/MiniZincIDE-2.2.1-bundle-linux/bin/minizinc
GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /opt/MiniZincIDE-2.2.1-bundle-linux/bin/minizinc...(no debugging symbols found)...done.
(gdb) r bug.fzn
Starting program: /opt/MiniZincIDE-2.2.1-bundle-linux/bin/minizinc bug.fzn
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
bug.fzn:19982.12-61:
MiniZinc: type error: no function or predicate with this signature found: `table_int(array[int] of var int,array[int] of int)'
[Inferior 1 (process 25340) exited with code 01]

If you need more info, please tell me what to type.

Improve message when receiving unbounded IntVal

(Issue from MiniZinc repository: MiniZinc/libminizinc#404)

The model from this StackOverflow answer (attached at the end also) using a mod constraints and works fine using Gecode.

When running with Chuffed it gives the following error

Compiling number_concatenation.mzn
Running number_concatenation.mzn
Command line:
/Applications/MiniZincIDE.app/Contents/Resources/bin/fzn-chuffed -s -v "/private/var/folders/m_/gb3wycb17b169222h13sdftr0000gn/T/MiniZinc IDE (bundled)-mROmzz/number_concatenation.fzn"
int-var.cpp:116: Cannot initialise vals in unbounded IntVar
Finished in 222msec
Process finished with non-zero exit code 6
Finished in 2s 146msec

I'm assuming that these happen because the integer variables involved have non-specific domains? No matter the actual reason, both failures could be improved to at least point the user in the right direction of what variable the problem is with.

include "globals.mzn";

%
% Problem data
%

% The set of allowed values
set of int: Values = {1, 10, 20, 40, 100, 200};

% The number of value to concatenate
int: n = 4;


%
% Derived data
%

% The available values as an index set
set of int: Index = 1..card(Values);
% The values as an array
array[Index] of int: values = [v | v in Values];
% The length of values in decimal notation
array[Index] of int: lengths = [ceil(log10(v+1)) | v in Values];
% A mapping table from values to the widths of the numbers
array[Index, 1..2] of int: value_to_widths = array2d(Index, 1..2, [
    [values[i], 10^lengths[i]][v_or_w] 
    | i in Index, v_or_w in 1..2]);
% The numbers as an index set
set of int: N = 1..4;


%
% Variables
%

% The numbers to choose
array[N] of var Values: numbers;
% The widths of the numbers
array[N] of var int: widths;
% The factors to use for concatenation
array[1..n] of var int: factors;
% The concatenation of the numbers
var int: concatenation;


%
% Constraints
%

% For each number, find the widths of it using the mapping table
constraint forall (i in N) (
    table([numbers[i], widths[i]], value_to_widths) 
);

% Find the factors to multiply numbers with for the concatenation
constraint factors[n] == 1;
constraint forall (i in 1..n-1) (factors[i] == widths[i+1] * factors[i+1]);

% Concatenate the numbers using the factors
constraint concatenation == sum(i in N) (numbers[i] * factors[i]);

% Problem constraint, the concatenation should be evenly divisible by 13
constraint concatenation mod 13 == 0;


%
% Solve and output
%

% Find solutions using standard search
% 636 failures to find all solutions using Gecode 6.1.1
%solve satisfy;

% Find solution by setting the least significant number first
% 121 failures to find all solutions using Gecode 6.1.1
solve :: int_search(reverse(numbers), input_order, indomain_min) satisfy;

% Find the smallest concatenation using the numbers
%solve minimize concatenation;

% Find the largest concatenation using the numbers
%solve maximize concatenation;

% Output both data and variables
output [
  "values=", show(values), "\n",
  "lengths=", show(lengths), "\n",
  "v_to_w={ "] ++ [show(value_to_widths[i, 1]) ++ "->" ++ show(value_to_widths[i, 2]) ++ " "|i in Index] ++ ["}\n",
  "numbers=", show(numbers), "\n",
  "widths=", show(widths), "\n",
  "factors=", show(factors), "\n",
  "concatenation=", show(concatenation), "\n",
];

Problems with bool2int

Hi,

I'm currently working on minimization problems by writing a FlatZinc file and attempt to solve this using different solvers. Chuffed is one solver I'm really interested in, but I came across a problem when using Chuffed.
I think I have narrowed the problem down to the use of bool2int, but I'm not 100% sure. Is bool2int not supported in Chuffed?

An small example:

var bool: v1 :: output_var;
var bool: v2 :: output_var;
var 0..1: v1_int :: is_defined_var;
var 0..1: v2_int :: is_defined_var;
var int: p :: output_var :: is_defined_var;
var 0..20: obj :: output_var :: is_defined_var;
constraint bool_not(v1,v2);
constraint bool2int(v1,v1_int) :: defines_var(v1_int);
constraint bool2int(v2, v2_int) :: defines_var(v2_int);
constraint int_lin_eq([-1,1,1], [p,v1_int,v2_int], 0) :: defines_var(p);
constraint int_lin_eq([-1,10],[obj, p],0) :: defines_var(obj);
solve minimize obj;

Chuffed gives the following error:

Error: Unknown character in line no. 7
Error: Unknown character in line no. 13
=====ERROR=====

While other solvers (gecode, yuck and ortools) solves it just fine.

Replacing the bool2int constraints with:

constraint int_eq_reif(v1_int, 1, v1) :: defines_var(v1_int);
constraint int_eq_reif(v2_int, 1, v2) :: defines_var(v2_int);

does not change anything.

EDIT I should add that Chuffed is able to solve it using solve satisfy; and removing solve minimize obj;.

Can anyone tell me why this is happening?

Thanks!

performance issue => solved

Hi,
I see a much worse performance with the version of chuffed that I recompile compared to the version provided in MiniZincIDE-2.1.7-bundle-linux-x86_64. A small model tested on ubuntu server is 4 times slower with recompiled chuffed (with cmake 3.11.0 and gcc 5.4).

I also tried to recompile on a centOS with gcc 6.3, it's the same thing.

Do you have an idea of the source of the problem ?

Best,
Hélène

About priority_search and backjumps

Hi! I'm currently working with MiniZinc and Chuffed to solve an industrial scheduling problem. The use of priority_search has made a huge improvement on the solving time, specifying a specific intelligent search heuristic for our problem.

That said, I was experimenting some search heuristics with priority_search, and encountered a strange behavior. Given an array X[1..n] of int variables, these two heuristics lead to completely different results:

int_search(X, smallest, indomain_min, complete);
priority_search(X, [int_search([X[i]], input_order, indomain_min, complete) | i in 1..n], smallest, complete);

I was suprised to observe a difference, since the idea is the same in the two cases, select the variable with the smallest value in its domain, and branch on the smallest possible value for that variable. Logicly, I would have expected the same behavior.

Looking closer to the search tree and Chuffed source code, the difference happens when a conflict/backjump occurs. When it happens, the choice of the branching group is not reevaluated given the variable selection (smallest in this case). Thus, it is possible to make the decision X[i] = v where, in fact, there exists another variable in X with a possible value smaller than v. This case doesn't happen with the int_search heuristic, since there is only one branching group.

In short, is this the correct behavior for the priority_search? If not, the "fix" I propose would be to make PriorityBranchGroup a BranchGroup with terminal = true, since we want the search to re-evaluate the branch group selection everytime.

EDIT : Thinking about it a little more, the "fix" I propose would work only for this special case. The re-evaluation should only be performed on a conflict. (?)

Segfault on CVRP instance

Hi,

I built fzn-chuffed (current master branch) on MacOS X Catalina using the default clang compiler.

The attached instance causes a seg fault. I have deleted hundreds of the constraints in an attempt to narrow down to a single propagator, however the crash seems to involve more than one constraint. Some of the constraints have a "% mark" comment on them, these are ones that I found to contribute to the seg fault (i.e. if I remove them then chuffed runs normally and finds a solution). The instance has not been reduced fully -- I thought you might have something that could do the reduction automatically since I have been doing it manually and it is very laborious.

eil13.eprime-param.fzn.txt

Thanks,
Peter

Assertion failure in engine when solving certain problems

I'm evaluating chuffed and implementing a rudimentary (and most likely very poorly performing) Sudoku solver.

Throw this into the examples folder and compile it like any other example:

#include <cstdio>
#include <cassert>
#include <chuffed/core/engine.h>
#include <chuffed/core/propagator.h>
#include <chuffed/branching/branching.h>
#include <chuffed/vars/modelling.h>
#include <iostream>
#include <vector>

// hardest puzzles taken from https://github.com/dimitri/sudoku/blob/master/hardest.txt
static const char * const hardest[] = {
	"85...24..72......9..4.........1.7..23.5...9...4...........8..7..17..........36.4.",
	"..53.....8......2..7..1.5..4....53...1..7...6..32...8..6.5....9..4....3......97..",
	"12..4......5.69.1...9...5.........7.7...52.9..3......2.9.6...5.4..9..8.1..3...9.4",
	"...57..3.1......2.7...234......8...4..7..4...49....6.5.42...3.....7..9....18.....",
	"7..1523........92....3.....1....47.8.......6............9...5.6.4.9.7...8....6.1.",
	"1....7.9..3..2...8..96..5....53..9...1..8...26....4...3......1..4......7..7...3..",
	"1...34.8....8..5....4.6..21.18......3..1.2..6......81.52..7.9....6..9....9.64...2",
	"...92......68.3...19..7...623..4.1....1...7....8.3..297...8..91...5.72......64...",
	".6.5.4.3.1...9...8.........9...5...6.4.6.2.7.7...4...5.........4...8...1.5.2.3.4.",
	"7.....4...2..7..8...3..8.799..5..3...6..2..9...1.97..6...3..9...3..4..6...9..1.35",
	"....7..2.8.......6.1.2.5...9.54....8.........3....85.1...3.2.8.4.......9.7..6....",
	nullptr
};

static void renderBoard(std::ostream &os, const char *board) {
	for (int y = 0; y < 9; y++) {
		if (y == 0) {
			os << "┌─────┬─────┬─────┐" << std::endl;
		} else if (y % 3 == 0) {
			os << "├─────┼─────┼─────┤" << std::endl;
		}

		for (int x = 0; x < 9; x++) {
			if (x % 3 == 0) {
				os << "";
			} else {
				os << " ";
			}

			char c = board[y * 9 + x];
			if (c == '.') c = ' ';
			os << c;
		}

		os << "" << std::endl;
	}

	os << "└─────┴─────┴─────┘" << std::endl;
}

class Sudoku : public Problem {
public:
	// Core variables

	std::vector<vec<IntVar*>> rows;
	std::vector<vec<IntVar*>> cols;
	std::vector<vec<IntVar*>> tiles;

	Sudoku(const char * const board) : rows(9), cols(9), tiles(9) {
		renderBoard(std::cout, board);

		for (int i = 0; i < 9; i++) {
			createVars(rows[i], 9, 1, 9);
			all_different(rows[i]);
			branch(rows[i], VAR_INORDER, VAL_MIN);
		}

		for (int c = 0; c < 9; c++) {
			cols[c].growTo(9);
			for (int r = 0; r < 9; r++) {
				cols[c][r] = rows[r][c];
			}
			all_different(cols[c]);
		}

		for (int t = 0; t < 9; t++) {
			tiles[t].growTo(9);
			int tx = t % 3;
			int ty = t / 3;
			for (int cell = 0; cell < 9; cell++) {
				int cx = cell % 3;
				int cy = cell / 3;
				int row = tx * 3 + cx;
				int col = ty * 3 + cy;
				tiles[t][cell] = rows[row][col];
			}
			all_different(tiles[t]);
		}

		for (int y = 0; y < 9; y++) {
			for (int x = 0; x < 9; x++) {
				char c = board[y * 9 + x];
				if (c != '.') {
					rows[y][x]->setVal(c - '0');
				}
			}
		}
	}

	void print(std::ostream& os) {
		char str[81];
		for (int i = 0; i < 81; i++) {
			str[i] = rows[i / 9][i % 9]->getVal() + '0';
		}

		renderBoard(os, str);
	}
};

int main() {
	const char * const *cur = hardest;
	while (*cur) {
		engine.solve(new Sudoku((cur++)[0]));
	}
	return 0;
}

It correctly solves the first two:

┌─────┬─────┬─────┐
│8 5  │    2│4    │
│7 2  │     │    9│
│    4│     │     │
├─────┼─────┼─────┤
│     │1   7│    2│
│3   5│     │9    │
│  4  │     │     │
├─────┼─────┼─────┤
│     │  8  │  7  │
│  1 7│     │     │
│     │  3 6│  4  │
└─────┴─────┴─────┘
┌─────┬─────┬─────┐
│8 5 9│6 1 2│4 3 7│
│7 2 3│8 5 4│1 6 9│
│1 6 4│3 7 9│5 2 8│
├─────┼─────┼─────┤
│9 8 6│1 4 7│3 5 2│
│3 7 5│2 6 8│9 1 4│
│2 4 1│5 9 3│7 8 6│
├─────┼─────┼─────┤
│4 3 2│9 8 1│6 7 5│
│6 1 7│4 2 5│8 9 3│
│5 9 8│7 3 6│2 4 1│
└─────┴─────┴─────┘

----------
┌─────┬─────┬─────┐
│    5│3    │     │
│8    │     │  2  │
│  7  │  1  │5    │
├─────┼─────┼─────┤
│4    │    5│3    │
│  1  │  7  │    6│
│    3│2    │  8  │
├─────┼─────┼─────┤
│  6  │5    │    9│
│    4│     │  3  │
│     │    9│7    │
└─────┴─────┴─────┘
┌─────┬─────┬─────┐
│1 4 5│3 2 7│6 9 8│
│8 3 9│6 5 4│1 2 7│
│6 7 2│9 1 8│5 4 3│
├─────┼─────┼─────┤
│4 9 6│1 8 5│3 7 2│
│2 1 8│4 7 3│9 5 6│
│7 5 3│2 9 6│4 8 1│
├─────┼─────┼─────┤
│3 6 7│5 4 2│8 1 9│
│9 8 4│7 6 1│2 3 5│
│5 2 1│8 3 9│7 6 4│
└─────┴─────┴─────┘

----------

but chokes on the third one:

../chuffed/core/engine.cpp:419: Not yet supported
[1]    47394 abort      ./sudoku

What exactly isn't supported? Looks like not declaring output variables but I'm not entirely sure what those are in terms of chuffed.

Segfault on a 2013 Challenge instance

Hi, I get the error Error: Registry: Constraint diffn not found in line no. 427

when running the current develop branch on a 2013 Challenge instance with the current develop of MZN:

mzn-fzn -v -s -a -G chuffed --solver fzn-chuffed --fzn-flags -f /home/bg/Documents/prj/Monash/2015_LinearMZN/MZN_BENCH/TEST_TEMPLATES/20150626_LinLin0_4_10_withCarSeq/challenge_makespan_vs_tardiness/mznc13-problems/cargo/cargo_coarsePiles.mzn '/home/bg/Documents/prj/Monash/2015_LinearMZN/MZN_BENCH/TEST_TEMPLATES/20150626_LinLin0_4_10_withCarSeq/challenge_makespan_vs_tardiness/mznc13-problems/cargo/challenge04_1s_626.dzn'
BTW the error message only shows in the Debug executable.

Chuffed ignores alldifferent on large domain variables

This is most likely related to issue #10 which is about chuffed ignoring alldiff on unbound (var int) variables.

In the following golumb ruler model chuffed gives the solution

 ruler = array1d(1..7, [0, 0, 0, 0, 0, 0, 0]);
----------
==========

despite the alldifferent(ruler).

The bug seems to be for all n >= 7 and the model works fine for smaller n.

include "globals.mzn";
int: n = 7;

array[1..n] of var 0..sum(1..n*n): ruler; % this, not so good, upperbound seems to trigger the bug.

constraint alldifferent(ruler);
constraint increasing(ruler); % this constraint has no impact on the bug
constraint alldifferent([abs(ruler[i]-ruler[j]) | i, j in 1..n where i < j]);

solve minimize ruler[n];

How to Cite Your Tool?

Dear Chuffed developer team,

Hope you are fine. How to cite your tool if we are using it in our publications?

Kind regards,
Hosein

array_int_element vs. gecode's element

Is there a preferred way to do an array lookup with Chuffed? When I use array_int_element I get enormous memory usage that I don't see on Gecode using element.

multithread support

Thanks for your efficient solver, i would really appreciate if anybody tell me how to increase the thread o Chuffed solver. In the configuration tab, as i increase the thread option, there is an error that says :" Unknown error while executing minizinc interpretor".

Best solution so far is not output after interruption

See MiniZinc/libminizinc#397.

I believe chuffed outputs the current best solution when its own -t timeout occurs, but it doesn't do this when interrupted (it handles this, but only gives statistics, not a solution).

Sometimes chuffed's own timeout takes much longer than expected (especially when there are a lot of solutions, which is potentially something else to investigate). MiniZinc then fallsback to killing chuffed, and then the unknown status is given.

Bad optimal solution reported

I'm running the attached program for the MT10x10 job shop. CPLEX finds the optimal solution at 930, Chuffed stops at 954 and reports it as optimal. If you set the upper bound to 930 instead of 1000, Chuffed finds a solution with cost 930 and says it is optimal as well.

include "globals.mzn";
int:nrJobs=10;
int:nrRes=10;

set of int: J=1..nrJobs;
set of int: R=1..nrRes;

array[J,R] of int:taskUse = [|
   0, 1, 2, 3, 4, 5, 6, 7, 8, 9|
   0, 2, 4, 9, 3, 1, 6, 5, 7, 8|
   1, 0, 3, 2, 8, 5, 7, 6, 9, 4|
   1, 2, 0, 4, 6, 8, 7, 3, 9, 5|
   2, 0, 1, 5, 3, 4, 8, 7, 9, 6|
   2, 1, 5, 3, 8, 9, 0, 6, 4, 7|
   1, 0, 3, 2, 6, 5, 9, 8, 7, 4|
   2, 0, 1, 5, 4, 6, 8, 9, 7, 3|
   0, 1, 3, 5, 2, 9, 6, 7, 4, 8|
   1, 0, 2, 6, 8, 9, 5, 3, 4, 7 |];
   		
array[J,R] of int:taskDuration= [|
   29, 78,  9, 36, 49, 11, 62, 56, 44, 21|
   43, 90, 75, 11, 69, 28, 46, 46, 72, 30|
   91, 85, 39, 74, 90, 10, 12, 89, 45, 33|
   81, 95, 71, 99,  9, 52, 85, 98, 22, 43|
   14,  6, 22, 61, 26, 69, 21, 49, 72, 53|
   84,  2, 52, 95, 48, 72, 47, 65,  6, 25|
   46, 37, 61, 13, 32, 21, 32, 89, 30, 55|
   31, 86, 46, 74, 32, 88, 19, 48, 36, 79|
   76, 69, 76, 51, 85, 11, 40, 89, 26, 74|
   85, 13, 61,  7, 64, 76, 47, 52, 90, 45 |];
   								

int:ub =1000;


array[J,R] of var 0..ub:start;
var 0..ub:objective;

constraint forall(j in J) 
  (objective >= start[j,nrRes]+taskDuration[j,nrRes]);
constraint forall(j in J, r in 1..nrRes-1)
 (start[j,r+1] >= start[j,r]+taskDuration[j,r]);
 constraint forall (r in R)
   (cumulative([start[j,k]|j in J, k in R where taskUse[j,k]+1=r],
                           [taskDuration[j,k]|j in J, k in R where taskUse[j,k]+1=r],
                           [1|j in J, k in R where taskUse[j,k]+1=r],1)
   );
  
 solve minimize objective;

Originally filed in the MiniZinc repository: MiniZinc/libminizinc#460

Chuffed Timelimit problem in MiniZinc

I would really appreciate if any body help me figure out my issue
As I run any problem in MiniZinc IDE using Chuffed solver, the solvers ends its execution in only 30 minutes.
Whereas i need the solver to continue its execution....

chuffed_maximum_arg_bool not following MiniZinc interpretation

When compiling the following MZN file with MiniZinc 2.5.5 and Chuffed MZN library, the arg_max is transformed into chuffed_maximum_arg_bool.

include "arg_max.mzn";

array[1..2] of var bool: x;
var int: t;

constraint not x[1] /\ not x[2];
constraint t = arg_max([x[i] | i in 1..2]);

This model gives UNSAT when run with Chuffed from the 2.5.5 MiniZinc bundle. However, the interpretation of the arg_max function following the MiniZinc handbook should allow a vector formed of only false boolean variables, with the returned index for t equals to 1. The main reason seems to be that Chuffed forces at least one variable from the vector to be true. In comparison, the behavior is the expected one using Gecode or OR-tools.

Chuffed crashes due to bug in branching

Hi,
there is a bug in chuffed which causes it to crash in some cases, for example in the following case:

var -1..0: v;

solve :: int_search([v], input_order, indomain_reverse_split, complete) satisfy;

The problem comes from the branching in vars/int-var.c (and also vars/int-var-ll.c if a lazy literal is used), where the branching value is computed as x=(min+max)/2 (in this case, x=0).
Then, in vars/int-var.h it is tried to branch v>=x+1, which crashes in this case.

Manual of Chuffed

Hello,

I'm a Ph.D student at ENAC (Aeronautical University) in France, working
on cooperation between different solvers applied to Civil Aviation
combinatorial optimization problems.

I'm very interested in Chuffed as it has proven to be a very efficient
CP solver in nogood learning, particularly for a conflict resolution
problem I'm currently working on. In order to make a cooperation with
other algorithm possible, I'd like to know whether there is a manual for
the C++ API of Chuffed?

If not, what I'm trying to achieve is a communication with other
processes during the search, i.e. sending/receiving information on the
current state of the resolution, at regular intervals. Which part of the
C++ API code should I target?

Chuffed outputs no solution when using timeout

When I run chuffed with a timeout (-t flag) such that it does find a solution but is unable to prove optimality, it output no solution at all. I know that chuffed does find something if I include the -a flag - it's just that when only using -t it output nothing.

Is this intended behavior? Gecode does not behave this way (it outputs the best solution found).

strange learnt nogood

MiniZinc 2.3.0.
I ran a model instance with --learnt-stats-nogood and obtained the learnt nogood:

X_INTRODUCED_12645_<=479 >=12 X_INTRODUCED_12664_<=599 X_INTRODUCED_2433_<=0

What does that mean? What's >=12 doing there?

Add script to run chuffed examples to ascertain whether compilation produced something acceptable

I have finally managed to compiled chuffed on Linux, not without some problems.

I also compiled the examples. Note that the examples segfault if not provided with the right (number of) parameters, which is strong stuff. Compiling with the "debug" option helps a lot as you then see at least assertions on argc that are failing.

Now, I have scant indication on how to run the examples, what they are supposed to be doing or even what their output should be. Shouldn't there a minimal script to perform a test run to see whether chuffed indeed works "as compiled"?

Example where chuffed fails. Commit 45e778bf7e8be02887ba89c527828e672a877c2e Jan 17 2019

Fails after about half-hour on Debian 9.6 with MZN fe9a7640bf55760ad58beca9226505cadf1ebecb, see the model input.mzn on MZN Forum from 21.02.2019 https://groups.google.com/d/msg/minizinc/70PIE5zjG-Y/a56hJyPoBAAJ

$ minizinc -v -s --solver chuffed input.mzn
MiniZinc to FlatZinc converter, version 2.2.3
Copyright (C) 2014-2019 Monash University, NICTA, Data61
Parsing file(s) input.mzn' ...
processing file '/home/bg19/Documents/prj/minizinc/00/share/minizinc/std//stdlib.mzn'
processing file '/home/bg19/Documents/prj/minizinc/00/share/minizinc/std//builtins.mzn'
processing file '/home/bg19/Documents/prj/minizinc/00/share/minizinc/std//redefinitions-2.2.1.mzn'
processing file '/home/bg19/Documents/prj/minizinc/00/share/minizinc/std//redefinitions-2.1.1.mzn'
processing file '/home/bg19/Documents/prj/minizinc/00/share/minizinc/std//redefinitions-2.1.mzn'
processing file '/home/bg19/Documents/prj/minizinc/00/share/minizinc/std//redefinitions-2.0.2.mzn'
processing file '/home/bg19/Documents/prj/minizinc/00/share/minizinc/std//redefinitions-2.0.mzn'
processing file '/usr/local/share/chuffed/mznlib//redefinitions.mzn'
processing file '/home/bg19/Documents/prj/minizinc/00/share/minizinc/std//flatzinc_builtins.mzn'
processing file './input.mzn'
done parsing (0.15 s)
Flattening ...
CompilePass: Flatten with '/home/bg19/Documents/prj/minizinc/00/share/minizinc//' library ...
MIP domains ... done (0.35 s)
Optimizing ... done (0.38 s)
Converting to old FlatZinc ... done (0.51 s)
done (0.51 s)
done (0.66 s), max stack depth 25
Generated FlatZinc statistics:
Paths: 0
Variables: 15278 bool, 1208 int
Constraints: 9948 bool, 5797 int
This is a minimization problem.
Maximum memory 55 Mbytes.
Flattening done, 0.66 s
% SOLVING PHASE
FZN solver plugin, compiled Feb 19 2019 13:19:03
Using FZN solver /usr/local/bin/fzn-chuffed for solving, parameters: -s -v
=====ERROR=====
Done (overall time 1256.97 s).

Subsets and lazy arrays resulting in error

Example code that fails on Chuffed 0.10.4:

set of int: edges = {1, 2, 3};
array[1..3] of set of edges: adj_list = [{3}, {}, {2}];
array[1..3] of var edges: path;

constraint forall(t in 1..3 where t < 3)(
    (path[t + 1] in adj_list[path[t]])
);

solve satisfy;

This same model works on Gecode 6.1.1. The following error output is printed to stdout when run:

MiniZinc: flattening error: 
/home/stran/Dropbox/Uni/FIT2082/Optimised Solver/test.mzn:5:
  in call 'forall'
  in array comprehension expression
    with t = 2
/home/stran/Dropbox/Uni/FIT2082/Optimised Solver/test.mzn:6:
  in binary 'in' operator expression
  in array access
/opt/minizinc/share/minizinc/std//builtins.mzn:2360:
  in if-then-else expression
  in let expression
/opt/minizinc/share/minizinc/std//builtins.mzn:2362:
  in call 'element_t'
/opt/minizinc/share/minizinc/std//builtins.mzn:2344:
  in let expression
/opt/minizinc/share/minizinc/std//builtins.mzn:2347:
  in call 'array_var_set_element_nonshifted'
/opt/minizinc/share/minizinc/std//redefinitions-2.0.2.mzn:45:
  in call 'array_var_set_element'
/opt/minizinc/share/minizinc/std//builtins.mzn:1930:
  in call 'array_set_element'
/opt/minizinc/share/minizinc/std//nosets.mzn:307:
  in let expression
/opt/minizinc/share/minizinc/std//nosets.mzn:314:
  in binary 'subset' operator expression
  cannot find matching declaration

Process finished with non-zero exit code 1

Expected output is:

Compiling test.mzn
Running test.mzn
path = array1d(1..3, [1, 3, 2]);
----------
Finished in 38msec

Compilation errors when compiling for parallel mode

Hi,

When compiling for parallel solving (with #define PARALLEL), I get the following compilation errors:
chuffed/parallel/master.cpp: In member function ‘void Master::initMPI()’:
chuffed/parallel/master.cpp:36:96: error: ‘ERROR’ was not declared in this scope
if (so.num_threads > MAX_SLAVES) ERROR("Maximum number of slaves (%d) exceeded!\n", MAX_SLAVES);

chuffed/parallel/slave.cpp: In member function ‘void Slave::receiveLearnts()’:
chuffed/parallel/slave.cpp:222:38: error: ‘class SAT’ has no member named ‘level’
if (sat.value(x) != l_True || sat.level[var(x)] != 0) {
^
chuffed/parallel/slave.cpp: In member function ‘void SAT::convertToSClause(Clause&)’:
chuffed/parallel/slave.cpp:248:31: error: ‘struct ChannelInfo’ has no member named ‘vid’
int vid = c_info[var(c[i])].vid;
^
chuffed/parallel/slave.cpp:251:43: error: ‘struct ChannelInfo’ has no member named ‘v’
temp_sc->data[j++] = c_info[var(c[i])].v ^ sign(c[i]);
^
chuffed/parallel/slave.cpp: In member function ‘void SAT::addLearnt()’:
chuffed/parallel/slave.cpp:284:16: error: ‘level’ was not declared in this scope
int hlevel = level[var(c[0])]; j = 0;
^
chuffed/parallel/slave.cpp:297:16: error: ‘level’ was not declared in this scope
int hlevel = level[var(c[1])]; j = 1;
^

Best,
Broes

Feature request: diffn

High on my wish list is a diffn propagator for Chuffed.
Mainly for preventing memory from blowing up for models using diffn.
While you're at it, please support both versions, strict and nonstrict. I mostly have use for nonstrict.

Multiple problems with conversion from "Cost-Regular" to "weighted-MDD"

Multiple problems with conversion from Cost-Regular to weighted-MDD

There are a few problems with the current implementation of the wmdd_cost_regular constraint:

Constructing the transitions

Array indices

When constructing the transitions (in these lines of mddglobals.cpp), there is an index array that should change with the loop iterations, but is set to a fixed number:

  for(int qi = 0; qi < q; qi++)
  {
    vec<int>& d_q(d[q]);
    vec<int>& w_q(w[q]);

This should change into:

  for(int qi = 0; qi < q; qi++)
  {
    vec<int>& d_q(d[qi]);
    vec<int>& w_q(w[qi]);

Initialization order

Right after that, the transition structure (WDFATrans) is initialized in the wrong order:

    WDFATrans t = { d_q[vi], w_q[vi] };

The correct initialization would be:

    WDFATrans t = { w_q[vi], d_q[vi] };

Conversion to layered graph

Initial state

The wmdd_cost_regular constraint allows the user to specify the initil state. The conversion function wdfa_to_layergraph does not take this value as an argument, and assumes that the initial state is always zero.

Offset

These comments precede the definition of the wmdd_cost_regular function:

// x: Vars | q: # states | s: alphabet size | d[state,symbol] -> state | q0: start state | f: accepts
// States range from 1..q (0 is reserved as dead)
// offset -> alphabet symbols are 1..s
//   (0..s-1 otherwise)

First, this function does not have an offset argument. Second, the assumption that states and alphabet start from one is violated in a few places. For example, here:

  for(int ai = 0; ai < accepts.size(); ai++)
  {
    layers[curr][accepts[ai]] = EVLayerGraph::EVTrue;
  }

which should change into:

  for(int ai = 0; ai < accepts.size(); ai++)
  {
    layers[curr][accepts[ai]-1] = EVLayerGraph::EVTrue;
  }

another example is in these lines:

      for(int xi = 0; xi < dom; xi++)
      {
        // Compute the corresponding transition
        int tidx = soff + xi;
        const WDFATrans& trans(T[tidx]);
        EVLayerGraph::NodeID dest = layers[prev][trans.dest];
        if(dest != EVLayerGraph::EVFalse)
        {
          EVLayerGraph::EInfo edge = { xi, trans.weight, layers[prev][trans.dest] };
          edges.push(edge);
        }
      }

which needs these changes to work as expected:

    EVLayerGraph::NodeID dest = layers[prev][trans.dest-1];

and

     EVLayerGraph::EInfo edge = { xi+1, trans.weight, layers[prev][trans.dest-1] };

I have implemented a fix that resolves these issues. I can submit a pull request, if that's okay.

fzn-chuffed gives bad exit code when finding all solutions for a problem with exactly one solution

I'm having a problem with the following MiniZinc model:

% test.mzn
var 1..3: x;
constraint x mod 2 = 0;
solve satisfy;

Running minizinc -a --solver chuffed test.mzn gives

x = 2;
----------
=====ERROR=====

And using the generated flatzinc directly with minizinc -c --output-to-stdout --solver chuffed test.mzn | fzn-chuffed.exe -a gives

x = 2;

----------

But with a bad exit code (-1073741819 on Windows).

The problem goes away if there are zero or more than one solution, or if -a isn't used.

Examples do not compile

Hi All,

I complied Chuffed on Ubuntu 16.04. However, when I tried to compile examples I got the following error message (please see below). Any advice will be very much appreciated.

[ 64%] Linking CXX static library libchuffed.a
[ 64%] Built target chuffed
[ 65%] Generating lexer.yy.cpp
[ 66%] Generating parser.tab.cpp, chuffed/flatzinc/parser.tab.h
Scanning dependencies of target chuffed_fzn
[ 66%] Building CXX object CMakeFiles/chuffed_fzn.dir/parser.tab.cpp.o
[ 67%] Building CXX object CMakeFiles/chuffed_fzn.dir/chuffed/flatzinc/registry.cpp.o
[ 68%] Building CXX object CMakeFiles/chuffed_fzn.dir/chuffed/flatzinc/flatzinc.cpp.o
[ 69%] Building CXX object CMakeFiles/chuffed_fzn.dir/lexer.yy.cpp.o
[ 69%] Linking CXX static library libchuffed_fzn.a
[ 69%] Built target chuffed_fzn
Scanning dependencies of target rcpsp
[ 69%] Building CXX object CMakeFiles/rcpsp.dir/chuffed/examples/rcpsp.cpp.o
[ 70%] Linking CXX executable rcpsp
libchuffed.a(engine.cpp.o): In function Engine::search(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)': engine.cpp:(.text+0x2c07): undefined reference to typeinfo for FlatZinc::FlatZincSpace'
engine.cpp:(.text+0x2c68): undefined reference to FlatZinc::FlatZincSpace::printDomains(std::ostream&)' engine.cpp:(.text+0x2f0e): undefined reference to typeinfo for FlatZinc::FlatZincSpace'
engine.cpp:(.text+0x2f45): undefined reference to `FlatZinc::FlatZincSpace::getDomainsStringabi:cxx11'
collect2: error: ld returned 1 exit status
CMakeFiles/rcpsp.dir/build.make:96: recipe for target 'rcpsp' failed
make[3]: *** [rcpsp] Error 1
CMakeFiles/Makefile2:892: recipe for target 'CMakeFiles/rcpsp.dir/all' failed
make[2]: *** [CMakeFiles/rcpsp.dir/all] Error 2
CMakeFiles/Makefile2:668: recipe for target 'CMakeFiles/examples.dir/rule' failed
make[1]: *** [CMakeFiles/examples.dir/rule] Error 2
Makefile:383: recipe for target 'examples' failed
make: *** [examples] Error 2


Thanks!

nina

Error: unknown integer variable X_INTRODUCED_2_ in line no. 7

The offsensive code sample is:

% mzn_file: .../examples-2.1.5/mzn/level_0/golomb_check.mzn
% globals: std
int: X_INTRODUCED_2_ = 6;
array [1..4] of int: mark = [0,1,4,6];
array [1..6] of var int: differences = [1,4,6,3,5,2];
var int: my_optimum_result :: output_var = X_INTRODUCED_2_;
solve :: int_search(mark,input_order,indomain,complete) minimize X_INTRODUCED_2_;

The error is :

Error: unknown integer variable X_INTRODUCED_2_ in line no. 7

The file is parsed by flatzinc and a number of other fzn solvers.

Bad optimal solution reported (Cumulative constraint)

Similarly to #70, but by forcing the use of Chuffed's cumulative constraint in the attached model, Chuffed stops at 938 and reports it as optimal. If you set the upper bound to 930 instead of 1000, Chuffed finds a solution with cost 930 and says it is optimal as well. If the upper bound is still set to 1000 and the ttef_filt annotation is set to false instead, Chuffed also finds a solution with cost 930 and says it is optimal.

include "fzn_cumulative.mzn";
int:nrJobs=10;
int:nrRes=10;

set of int: J=1..nrJobs;
set of int: R=1..nrRes;

array[J,R] of int:taskUse = [|
   0, 1, 2, 3, 4, 5, 6, 7, 8, 9|
   0, 2, 4, 9, 3, 1, 6, 5, 7, 8|
   1, 0, 3, 2, 8, 5, 7, 6, 9, 4|
   1, 2, 0, 4, 6, 8, 7, 3, 9, 5|
   2, 0, 1, 5, 3, 4, 8, 7, 9, 6|
   2, 1, 5, 3, 8, 9, 0, 6, 4, 7|
   1, 0, 3, 2, 6, 5, 9, 8, 7, 4|
   2, 0, 1, 5, 4, 6, 8, 9, 7, 3|
   0, 1, 3, 5, 2, 9, 6, 7, 4, 8|
   1, 0, 2, 6, 8, 9, 5, 3, 4, 7 |];
   		
array[J,R] of int:taskDuration= [|
   29, 78,  9, 36, 49, 11, 62, 56, 44, 21|
   43, 90, 75, 11, 69, 28, 46, 46, 72, 30|
   91, 85, 39, 74, 90, 10, 12, 89, 45, 33|
   81, 95, 71, 99,  9, 52, 85, 98, 22, 43|
   14,  6, 22, 61, 26, 69, 21, 49, 72, 53|
   84,  2, 52, 95, 48, 72, 47, 65,  6, 25|
   46, 37, 61, 13, 32, 21, 32, 89, 30, 55|
   31, 86, 46, 74, 32, 88, 19, 48, 36, 79|
   76, 69, 76, 51, 85, 11, 40, 89, 26, 74|
   85, 13, 61,  7, 64, 76, 47, 52, 90, 45 |];
   								

int:ub = 1000;


array[J,R] of var 0..ub:start;
var 0..ub:objective;

constraint forall(j in J) 
  (objective >= start[j,nrRes]+taskDuration[j,nrRes]);
constraint forall(j in J, r in 1..nrRes-1)
 (start[j,r+1] >= start[j,r]+taskDuration[j,r]);
 constraint forall (r in R)
   (fzn_cumulative([start[j,k]|j in J, k in R where taskUse[j,k]+1=r],
                           [taskDuration[j,k]|j in J, k in R where taskUse[j,k]+1=r],
                           [1|j in J, k in R where taskUse[j,k]+1=r],1) :: tt_filt(true) :: ttef_check(true) :: ttef_filt(true)
   );
  
 solve minimize objective;

README.md e.g. typo

In the README.md there is

Suppose z >= x + y, and we have x >= 3, y >= 2. Then the propagator would propagate x >= 5 with explanation clause x >= 3 /\ y >= 2 -> z >= 5

Shouldn't it be [...] propagate z >= 5 [...]?

Feature request: priority search

First of all, thank you for your work on creating such an amazing solver! For my problem domain, I have found that Chuffed excels at finding many solutions and doing it quickly.

I have recently found this paper Priority Search with MiniZinc that would be helpful for our modelling. Essentially we would like to prioritize different parts of the objective function, and it seems like this would be a fairly straightforward way to implement that.

I'm not sure what the roadmap Chuffed development is, but if this could be implemented it would certainly help us. Also, any pointers/warnings would be appreciated in case we decide to implement it ourselves.

Thank you,
Cole

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.