MiniZinc to FlatZinc

[Neng-Fa Zhou]

I found that the command

minizinc -c -G picat  --fzn  file.fzn file.mzn file.dzn

I used before to translate MiniZinc to FlatZinc no longer works with the latest version. It issues the following error message:

"Using the --compile (or -c) flag requires that a solver is selected explicitly using the --solver flag"

Why do I need to specify a solver even though I don't use it?

NF

[Samrat Kadge]

Not sure when you used the command last time.

You are referring to a solver "picat" through -G option, which looks for "globals" directory based at stdlib.

you can try using. --solver picat.

Check if picat is listed in supported solvers using "minizinc --help" (wher you can find -G option as well)

Why you need a solver for Flatzinc? You can read tutorial Introduction 1.1 

[Neng-Fa Zhou]

Thanks for the tips. I managed to hook Picat to minizinc as an underlying solver and solve MiniZinc models. However, I notice that Picat's FlatZinc interpreter doesn't like FlatZinc models generated with the option "-c" because they contain comments. The option "--no-output-comments" doesn't seem to work; MiniZInc gives the error 

minizinc: Unrecognized option or bad format `--no-output-comments'.

Cheers,

NF 

--
You received this message because you are subscribed to the Google Groups "MiniZinc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to minizinc+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/minizinc/28526b56-cfa4-4fe0-99ca-07066db29117n%40googlegroups.com.

[Jip Dekker]

Why do I need to specify a solver even though I don't use it?

You need to specify a solver because the FlatZinc that the MiniZinc compiler produces is solver-specific. The FlatZinc generated for a CP solver is very different to that of a MIP solver or a SAT solver.

It is generally best to just define a MiniZinc solver configuration file. I've found this even to be the most practical for a solver in development. However, if you really need a more dynamic approach, you can use "org.minizinc.mzn-fzn" as the solver, which compiles with only the standard library and options.

However, I notice that Picat's FlatZinc interpreter doesn't like FlatZinc models generated with the option "-c" because they contain comments. The option "--no-output-comments" doesn't seem to work; MiniZInc gives the error.

Comments have been part of the FlatZinc specification from the start, so there is no option to disable them. "--no-output-comments" is a flag for the solution processor to hide comments from the solver output. Since it is not activated with "-c" it throws an error.

To view this discussion visit https://groups.google.com/d/msgid/minizinc/CAFOC6HQ0iSwiyMJN9n8J84XZu5AO5PCaTeTDbDRCdv-2CCjEyQ%40mail.gmail.com.

[Neng-Fa Zhou]

That's interesting. I guess in the competition all solvers receive the same fzn models except for solver-specific definitions of global constraints.

BTW, minizinc fails to translate the train-scheduling benchmarks into flatzinc (see the error message below).

Error: syntax error, unexpected ','
converting trains18.dzn
/Users/nzhou/solvers/fzn_bench/bench24/train-scheduling/trains.mzn:47.74:
                                                 "Non symmetric line \(s1,s2)\n"));

Is this expected?

Thanks,

NF

To view this discussion visit https://groups.google.com/d/msgid/minizinc/CAA1xg1fWLEomVht1NWwQU8qKUs6Vf2NP7hnNrhOSpT2t8NO%2B_g%40mail.gmail.com.

[Jip Dekker]

That's interesting. I guess in the competition all solvers receive the same fzn models except for solver-specific definitions of global constraints.

The competition actually uses solver configuration files, so the process is the same there. MiniZinc compilation has always been part of the timed evaluation in the challenge. This assures solvers that use or require more processing of instances by MiniZinc do not gain any unfair advantages. It is up to the solver implementer to determine whether options like two-stage compilation are worthwhile for their solver.

BTW, minizinc fails to translate the train-scheduling benchmarks into flatzinc (see the error message below).

This is expected, the issue is that this output statement used string interpolation that worked by our mistake and was later fixed. \(s1,s2) was rewritten to show(s1, s2), and then didn't have the intended effect. Instead, the model was meant to contain `\((s1, s2))`, showing the tuple.

To view this discussion visit https://groups.google.com/d/msgid/minizinc/CAFOC6HRaXWKYVg_4LW5to0yxom4ZKqFw-0hew4qbdCbOmyjaQw%40mail.gmail.com.