Closed ghost closed 9 years ago
Dear @bak2, thank you for the report. I believe that the e8a9564 fixed the problem.
To test it, I had to modify your drh file as follows.
//Vars
[0, 10.0] time;
[0, 10.0] tau;
[-15,15] x;
[-15,15] y;
// start modes
// running
{
mode 1;
invt:
flow:
d/dt[x] = y;
d/dt[y] = (1.0 - x * x) * y - x;
d/dt[tau] = 1.0;
jump:
// end running
}
// end modes
init:
@1 (and (x = 1.0) (y = 0.5) (tau = 0.0));
goal:
@1 (and (x = 0) (tau > 5));
The changes are:
tau
to give constraint on it.x
and y
to [-15, 15]
It gives SAT result with the following visualization:
To test it, please delete build/external
directory if you have any, then rebuild dReal.
Hello @soonhokong, thanks for the change; it seems to work.
A few questions:
Thanks!!
Dear @bak2,
The variable tau and constraint tau > 5 was introduced just to show find the counter-example later time, right? Is there another reason for this?
That is correct. It's just to generate a similar counterexample that you shared with us.
Limiting the ranges of the variables is just to improve performance, correct? It wouldn't be wrong to use [-1000,1000], just slow?
Yes, just for the performance issues.
The visualization you gave a is a .png image. Is there a way to generate these directly in the tool (as an alternative to the JSON output)?
For now, dReal only generates a .json
file which is used to visualize a counterexample (details are explained in this link).
dReal is giving an unsat result for a satisfiable set of constraints.
Consider the van der pol oscillator system with dynamics x'=y, y'=(1-xx) \ y - x, with reach time 10, from the initial state x=1, y=0.5, and goal state x=0. The goal state is reachable, as can be seen from the following matlab plot:
This system corresponds to the following drh file:
which produces the following .smt2 file:
When running this in dReal, the result unsat is produced, which is incorrect.
When running with the
-debug
flag, I notice the computation is proceeding in inner_loop_forward, until a TaylorHOE Error occurs, as shown in this log snippet:I believe this corresponds to around time ~= 1.878 and state x ~= 0.0001, y ~= -1.72, which is consistent with the matlab simulation. After the TaylorHOE Error occurs, the result of EXCEPTION becomes UNSAT, which propagates to be the final result the tool outputs.
Looking at the code, in
src/dsolvers/ode_solver.cpp
, in functionode_solver::solve_forward
around line 557, we have this code, which we can relate to the log:In this case, the second condition of the if statement is true, and
prune_bucket
is called. In turn,prune_bucket
can only return SAT or UNSAT, which is where the result gets changed to UNSAT.