Menu
▾
▴
Re: [tulip-control-users] Errors in running TuLip
|
From: Ioannis F. <jfi...@gm...> - 2018-01-25 23:00:51
|
1. The message about MOSEK is an informational log message. MOSEK will be used only
if requested, or if the user changes the variable `polytope.solvers.default_solver`.
I am not familiar with MOSEK's performance, it may improve the runtime.
Changing the logging level near the script's top can reduce the number of messages.
2. The continuous abstraction in TuLiP can be incomplete. The discrete synthesis in TuLiP is
complete with respect to the discrete specification (so wrt the output of the abstraction).
I run the modified version you sent, also with input bound increased to 10, but the problem
remains unrealizable. removing the conditional from the last `plot_partition` statement
shows that the system is restricted to a relatively narrow diagonal band.
The module `tulip.abstract.plot` contains functions that can be useful for visualizing the
transitions found. You could also try the function `tulip.abstract.plot.plot_abstraction_scc`
to see the strongly connected components of the abstraction. If there are none, or too small,
then this indicates how the system cannot maneuver, or where the abstraction may need refinement.
3. Indeed, as the dimensions increase in number, the abstraction computation quickly increases
in duration. You could try to increase the value of the keyword argument `min_cell_volume`,
which would lead to a coarser partition. There have been cases with around 4-6 dimensions
where the discretization can take many hours. It may be worth dumping the result to a pickle
file, so that you can resume from the point after the abstraction has completed.
Also, `cvxopt` with GLPK installed is appropriate for this kind of problem (instead of `scipy`).
The `polytope` package uses these instead of `scipy`, if it finds them installed.
ioannis
On 1/25/18 12:46 PM, Mathur, Umang wrote:
> Thanks a lot. That was helpful.
>
> I would like to ask couple of more questions :
>
> 1. When I run the examples, I get a warning about MOSEK not installed. Is the MOSEK solver required (or is expected to give better performance) for the kind of problem (reach avoid controller synthesis) that I am trying to solve ?
> 2. I am attaching a slightly modified version of the previous model.
> With a different approach (that I have), I am able to synthesis a controller (also attaching a pictorial representation).
> However, TuLip reports that the spec is unrealizable. I understand that TuLip does not guarantee completeness. However, I would still like to check if there is any obvious error that I might be making that might have resulted into an "unrealizable" answer. It would be treat if you could take a quick look.
> 3. I tried to analyze a 4 dimensional system with TuLip. However, I could not get an answer within 30 minutes (after which I forced the program to terminate). The program was still computing a discretization of the system at that point.
> Again, is there something that I might be missing. And, are there any known tricks/parameter values that can be tweaked to speedup the analysis
>
> Thanking you in anticipation.
>
> - Umang
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *From:* Ioannis Filippidis [jfi...@gm...]
> *Sent:* Thursday, January 25, 2018 5:56 AM
> *To:* Mathur, Umang
> *Cc:* tu...@tu...; Fan, Chuchu; tulip-control-users; Scott C. Livingston; Necmiye Özay
> *Subject:* Re: Errors in running TuLip
>
> A sidenote about the specification: When using `solver='omega'` for synthesis (the default option),
> the environment safety assumption can be written also as:
>
> ```
> env_safe = {
> '''
> (time < 11 && (time' = time + 1)) ||
> (time = 11 && time' = time)
> '''
> }
> ```
>
> Any arithmetic formulas over integer variables are supported when using this backend.
> When written in this form, the declared range of integer values is in effect
>
> (These two specifications would be inequivalent in absence of this typeness.
> Conjoining the constraint `time \in 0..11` would yield one possible untyped version.
> Range constraints of the form `x \in a..b` with `a, b` integers are supported by later
> versions of `omega`, but not yet via this interface.)
>
> ioannis
>
> On Wed, Jan 24, 2018 at 11:21 PM, Ioannis Filippidis <jfi...@gm... <mailto:jfi...@gm...>> wrote:
>
> Hi Umang,
>
> The error is raised due to the order of arguments, and an API change since v1.3.0.
> With the following change (shown after removing trailing whitespace):
>
>
> --- continuous_reach_avoid_orig.py2018-01-24 23:06:08.110735358 -0800
> +++ continuous_reach_avoid.py2018-01-24 23:06:29.226873897 -0800
> @@ -113,10 +113,15 @@
>
> # @synthesize_section@
> # Synthesize
> -ctrl = synth.synthesize('omega', specs,
> - sys=disc_dynamics.ts, ignore_sys_init=True)
> +ctrl = synth.synthesize(
> + specs,
> + sys=disc_dynamics.ts, ignore_sys_init=True,
> + # solver='omega', # default value
> + )
>
> assert ctrl is not None, 'unrealizable'
> +ctrl.save('foo.pdf')
> +
> # @synthesize_section_end@
>
> # Simulation
>
>
> I obtain a controller after synthesis, using:
>
> - `tulip` at e3de77bc55cef15023e49363787b6c90045819c1 (current branch `master`)
>
> and the corresponding dependency versions that are installed when using `tulip`'s `setup.py`.
> I recommend using branch `master`, as you are already doing (newer versions of `networkx`
> are supported on a branch that could be merged to `master`).
>
> The API change was to make the `solver` argument a keyword (optional) argument,
> instead of the first positional argument.
>
> A graphical representation of the enumerated discrete controller is attached.
>
> Best regards,
> Ioannis Filippidis
>
> On Wed, Jan 24, 2018 at 9:46 PM, Necmiye Özay <nec...@gm... <mailto:nec...@gm...>> wrote:
>
> I meant "I am using v1.3, which is the latest release. I have not tried it with the current head of master branch.".
>
> I don't have much experience with v1.4. Ioannis or Scott would know more about the recent changes.
>
> Necmiye
>
> On Thu, Jan 25, 2018 at 12:39 AM, Mathur, Umang <uma...@il... <mailto:uma...@il...>> wrote:
>
> Thanks for the quick response.
> I am using tulip-1.4.0 .
>
> Do you recommend that I should use tulip-1.3.0 ?
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *From:* Necmiye Ozay [ne...@um... <mailto:ne...@um...>]
> *Sent:* Wednesday, January 24, 2018 11:34 PM
> *To:* Mathur, Umang
> *Cc:* tu...@tu... <mailto:tu...@tu...>; Fan, Chuchu
> *Subject:* Re: Errors in running TuLip
>
> What version of TuLiP are you using? I can run it with TuLiP version 1.3. I have not tried it with the latest release not the current head of master branch.
>
> Necmiye
>
> On Thu, Jan 25, 2018 at 12:27 AM, Mathur, Umang <uma...@il... <mailto:uma...@il...>> wrote:
>
> Hi,
>
> I am trying to run the attached file (shared by Necmiye).
> I get the following error :
>
> Traceback (most recent call last):
>
> File "continuous_reach_avoid.py", line 117, in <module>
>
> sys=disc_dynamics.ts, ignore_sys_init=True)
>
> File "/usr/local/lib/python2.7/site-packages/tulip/synth.py", line 1100, in synthesize
>
> ignore_sys_init)
>
> File "/usr/local/lib/python2.7/site-packages/tulip/synth.py", line 1205, in _spec_plus_sys
>
> _copy_options_from_ts(sys_formula, sys, specs)
>
> File "/usr/local/lib/python2.7/site-packages/tulip/synth.py", line 1234, in _copy_options_from_ts
>
> ts_spec.moore = cp.moore
>
> AttributeError: 'str' object has no attribute 'moore'
>
>
> It would be helpful to know what the problem is.
>
>
> Regards,
> Umang Mathur
> CS PhD Student, UIUC
> http://umathur3.web.engr.illinois.edu <http://umathur3.web.engr.illinois.edu>
>
>
>
>
>
|
