The theorem proving tool z3 is taking a lot of time to solve a formula, which I believe it should be able to handle easily. To understand this better and possibly optimize m
Z3 command line tool does not have such option. Moreover, Z3 contains several solvers and pre-processing steps. It is unclear which step would be useful for you. The Z3 source code is available at https://github.com/Z3Prover/z3. When Z3 is compiled in debug mode, it provides an extra command line option -tr:<tag>
. This option can be used to selectively dump information. For example, the source file nlsat_solver.cpp
contains the following instruction:
TRACE("nlsat", tout << "starting search...\n"; display(tout);
tout << "\nvar order:\n";
display_vars(tout););
The command line option -tr:nlsat
will instruct Z3 to execute the instruction above. tout
is the trace output stream. It will be stored in the file .z3-trace
. The Z3 source is full of these TRACE
commands. Since the code is available, we can also add our own trace commands in the code.
If you post your example, I can tell you which Z3 components are used to preprocess and solve it. Then, we can select which "tags" we should enable for tracing.
EDIT (after the constraints were posted):
Your example is in the mixed integer & real nonlinear arithmetic.
The new nonlinear arithmetic solver (nlsat
) in Z3 does not support to_int
.
Thus, the Z3 general purpose solver is used to solve your problem.
Although this solver accepts almost everything, it is not even complete for nonlinear real arithmetic. The nonlinear support on this solver is based on: interval analysis and Grobner basis computations.
This solver is implemented in the folder src/smt
(in the unstable branch).
The arithmetic module is implemented in the files theory_arith*
.
A good tracing command line option is -tr:after_reduce
. It will display the set of constraints after pre-processing.
The bottleneck is the arithmetic module (theory_arith*
).
Additional Remarks:
The problem is in a undecidable fragment: mixed integer & real nonlinear arithmetic. That is, it is impossible to write a sound and complete solver for this fragment. Of course, we can write a solver that solves instances we find in practice. I believe it is possible to extend nlsat
to handle the to_int
.
If you avoid to_int
, you will be able to use nlsat
. The problem will be in the nonlinear real arithmetic fragment. I understand that this may be hard, since the to_int
seems to be a key thing in your encoding.
The code in the "unstable" branch at z3.codeplex.com is much better organized than the official version in the "master" branch. I will merge it with the "master" branch soon. You can retrieve the "unstable" branch if you want to play with the source code.
The "unstable" branch uses a new build system. You can build the release version with tracing support. You just have to use the option -t
when generating the Makefile.
python scripts/mk_make.py -t
AUTO_CONFIG=false
by default. Thus, to reproduce the behavior of "release" mode, you must provide the command line option AUTO_CONFIG=true
.