tulip-control-users — questions about using TuLiP; if you are unsure, ask here first!

Re: [tulip-control-users] polytope: inaccurate results

[Necmiye O. <nec...@gm...>]

Hello,

To get similar precision as you increase the dimension, you might want to
increase the number of samples exponentially in dimension d.

If you have a python implementation of Lasserre's recursive algorithm (or
any other polytope volume computation algorithm), we always welcome
pull-requests from contributors!

Thanks,

Necmiye

On Sat, Mar 5, 2022 at 4:14 PM lo <jam...@fr...> wrote:

> Hi,
>
>
> Thanks for your prompt answer;
>
> I cannot install the latest version because I am stuck with python 3.6;
> but sampling in 3D is likely to be inefficient for high precision;
>
> I am wondering if  Lasserre’s recursive algorithm (see
> https://hal.inria.fr/hal-03029034/file/vol_article.pdf) is not much
> faster in low dimensions. Is there plan to switch to faster algorithms ?
>
>
> regards,
>
> Laurent
>
>
> On 3/5/22 18:24, Necmiye Ozay wrote:
>
> Hi Laurent,
>
> Volume uses a sampling based approximation of the true volume. If you
> increase the second argument, nsamples, here (note the default is 500 for
> 2d polytopes):
>
>
> https://github.com/tulip-control/polytope/blob/beadd1263adda6093c8ced3db1afd1a6ceeb069c/polytope/polytope.py#L1517
>
> the variance will reduce.
>
> Best,
>
> Necmiye
>
> On Sat, Mar 5, 2022 at 11:18 AM lo <jam...@fr...> wrote:
>
>> Hi,
>>
>>
>> I have a question about the toolbox polytope;
>>
>> With
>>
>> import numpy as np
>> import polytope as pc
>>
>> A = np.array([[-1.0, 0.0],
>>                [0.0, -1.0],
>>                [1.0, 1.0]])
>>
>> b = np.array([0,0,1.0])
>>
>> p = pc.Polytope(A, b)
>> print(p.volume)
>>
>> I got 0.536, then 0.466, then 0.46, ... though I expect something very
>> close to 0.5;
>>
>> How can I reduce the variance, i.e. have more accurate results ?
>>
>> thanks for the help,
>>
>>
>> regards,
>>
>> Laurent
>>
>>
>>
>> _______________________________________________
>> tulip-control-users mailing list
>> tul...@li...
>> https://lists.sourceforge.net/lists/listinfo/tulip-control-users
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...

Re: [tulip-control-users] polytope: inaccurate results

[lo <jam...@fr...>]

Hi,


Thanks for your prompt answer;

I cannot install the latest version because I am stuck with python 3.6; 
but sampling in 3D is likely to be inefficient for high precision;

I am wondering if Lasserre’s recursive algorithm (see 
https://hal.inria.fr/hal-03029034/file/vol_article.pdf) is not much 
faster in low dimensions. Is there plan to switch to faster algorithms ?


regards,

Laurent


On 3/5/22 18:24, Necmiye Ozay wrote:
> Hi Laurent,
>
> Volume uses a sampling based approximation of the true volume. If you 
> increase the second argument, nsamples, here (note the default is 500 
> for 2d polytopes):
>
> https://github.com/tulip-control/polytope/blob/beadd1263adda6093c8ced3db1afd1a6ceeb069c/polytope/polytope.py#L1517
>
> the variance will reduce.
>
> Best,
>
> Necmiye
>
> On Sat, Mar 5, 2022 at 11:18 AM lo <jam...@fr...> wrote:
>
>     Hi,
>
>
>     I have a question about the toolbox polytope;
>
>     With
>
>     import numpy as np
>     import polytope as pc
>
>     A = np.array([[-1.0, 0.0],
>                    [0.0, -1.0],
>                    [1.0, 1.0]])
>
>     b = np.array([0,0,1.0])
>
>     p = pc.Polytope(A, b)
>     print(p.volume)
>
>     I got 0.536, then 0.466, then 0.46, ... though I expect something
>     very
>     close to 0.5;
>
>     How can I reduce the variance, i.e. have more accurate results ?
>
>     thanks for the help,
>
>
>     regards,
>
>     Laurent
>
>
>
>     _______________________________________________
>     tulip-control-users mailing list
>     tul...@li...
>     https://lists.sourceforge.net/lists/listinfo/tulip-control-users
>
-------------- next part --------------
An HTML attachment was scrubbed...

Re: [tulip-control-users] polytope: inaccurate results

[Necmiye O. <nec...@gm...>]

Hi Laurent,

Volume uses a sampling based approximation of the true volume. If you
increase the second argument, nsamples, here (note the default is 500 for
2d polytopes):

https://github.com/tulip-control/polytope/blob/beadd1263adda6093c8ced3db1afd1a6ceeb069c/polytope/polytope.py#L1517

the variance will reduce.

Best,

Necmiye

On Sat, Mar 5, 2022 at 11:18 AM lo <jam...@fr...> wrote:

> Hi,
>
>
> I have a question about the toolbox polytope;
>
> With
>
> import numpy as np
> import polytope as pc
>
> A = np.array([[-1.0, 0.0],
>                [0.0, -1.0],
>                [1.0, 1.0]])
>
> b = np.array([0,0,1.0])
>
> p = pc.Polytope(A, b)
> print(p.volume)
>
> I got 0.536, then 0.466, then 0.46, ... though I expect something very
> close to 0.5;
>
> How can I reduce the variance, i.e. have more accurate results ?
>
> thanks for the help,
>
>
> regards,
>
> Laurent
>
>
>
> _______________________________________________
> tulip-control-users mailing list
> tul...@li...
> https://lists.sourceforge.net/lists/listinfo/tulip-control-users
>
-------------- next part --------------
An HTML attachment was scrubbed...

[tulip-control-users] polytope: inaccurate results

[lo <jam...@fr...>]

Hi,


I have a question about the toolbox polytope;

With

import numpy as np
import polytope as pc

A = np.array([[-1.0, 0.0],
               [0.0, -1.0],
               [1.0, 1.0]])

b = np.array([0,0,1.0])

p = pc.Polytope(A, b)
print(p.volume)

I got 0.536, then 0.466, then 0.46, ... though I expect something very 
close to 0.5;

How can I reduce the variance, i.e. have more accurate results ?

thanks for the help,


regards,

Laurent

Re: [tulip-control-users] Dynamic Obstacles

[Ioannis F. <jfi...@gm...>]

Hi Rishabh,


TLA+
====

TLA+ is a language for writing mathematics, including specifications.
TLA+ is described in the book (PDF available there):
    http://lamport.azurewebsites.net/tla/book.html?back-link=learning.html#book

More about it, including tools, can be found at:
    http://lamport.azurewebsites.net/tla/tla.html
Raw TLA+ includes more temporal formulas than TLA+. The raw logic and how it
differs is described in the paper:
    http://lamport.azurewebsites.net/pubs/pubs.html#lamport-actions
Below I use raw TLA+.


Temporal formula form
=====================

At the temporal logic level of `tulip` there is no predefined variable that
counts time. Such a variable could be defined in your specification, but the
first complication that would arise would be due to the finiteness of the set
of values that that variable can take.

Instead of defining such a variable, the prime operator can be used to describe
how the system can change. For example, in raw TLA+:

```
(* Initial condition *)
Init == obs_loc = 1

(* How the obstacle can change locations. *)
Transitions ==
    /\ (obs_loc = 1) => \/ obs_loc' = 2
                        \/ obs_loc' = 4
    /\ (obs_loc = 2) => (obs_loc' = 3)
    /\ (obs_loc = 3) => (obs_loc' = 4)
    /\ (obs_loc = 4) => (obs_loc' = 4)

(* Which regions to avoid, depending on the current
location of the obstacle.
*)
WhatToAvoid ==
    /\ (obs_loc = 1) => ~ region_1
    /\ (obs_loc = 2) => ~ region_2
    /\ (obs_loc = 3) => ~ region_3
    /\ (obs_loc = 4) => ~ region_4

Prop ==
    /\ Init
    /\ [] /\ Transitions
          /\ WhatToAvoid
```

where `obs_loc` is a variable that describes the location of the obstacle
(as an index), and `region_1`, .., `region_4` are variables that name polytopes
in the workspace (`region_1` for example means `x \in Region1`, where `x`
would be the continuous state of the system).

More about using the prime operator to describe obstacle movement can be
found in the references that I linked to in my previous email.


polytope representation
=======================

The function `polytope.polytope.box2poly` is a convenience interface.
Currently, the class `polytope.polytope.Polytope` represents covex polytopes,
and the class `polytope.polytope.Region` polytopes (including nonconvex ones).
    https://en.wikipedia.org/wiki/Polytope
The half-space representation is used for convex polytopes. More about this
representation can be read at:
    https://en.wikipedia.org/wiki/Convex_polytope#Definitions
The minimal vertex representation can be computed from the half-space
representation using the function `polytope.polytope.extreme`:
    https://github.com/tulip-control/polytope/blob/f981f434a270ee005076b9c534383aeaba314f40/polytope/polytope.py#L1480
A half-space representation can be computed from a vertex representation using
the function `polytope.polytope.qhull`:
    https://github.com/tulip-control/polytope/blob/f981f434a270ee005076b9c534383aeaba314f40/polytope/polytope.py#L1567
An example that demonstrates these two functions is:
    https://github.com/tulip-control/polytope/blob/f981f434a270ee005076b9c534383aeaba314f40/examples/randplot.py

The geometry of the half-space representation is that it describes the
intersection of a collection of half-spaces, by describing the hyperplane that
bounds each half-space, which is done via a distance and a vector normal to the
hyperplane. Deciding whether a point is in the half-space is (roughly) done by
taking the inner product between the point's location vector and the
half-space's normal vector, and comparing this with the distance.
(A normalization step is needed to make the "distances" appear in the numbers.)

By your wording ("a series of vertices in a 2d plane"), you probably do not
mean the polytope defined as the convex hull of those vertices, but the set
of points "enclosed" by a simple closed polygonal chain:
    https://en.wikipedia.org/wiki/Polygonal_chain
in other words, a simple polygon:
    https://en.wikipedia.org/wiki/Simple_polygon
A simple polygon can be nonconvex, so the class `polytope.polytope.Region`
needs to be used to represent it. One way to do this is to first triangulate
the polygon, forming a mesh of simplices
    https://en.wikipedia.org/wiki/Triangle_mesh
then to convert the mesh to a `list` of convex polytopes using the function
`polytope.polytope.simplices2polytopes`:
    https://github.com/tulip-control/polytope/blob/f981f434a270ee005076b9c534383aeaba314f40/polytope/polytope.py#L2256
which can be used to instantiate a `polytope.polytope.Region`.
More about simplices can be found at:
    https://en.wikipedia.org/wiki/Simplex
Python packages like `shapely` or `pymesh` can probably be used for computing
the triangulation:
    https://github.com/Toblerity/Shapely
    https://github.com/PyMesh/PyMesh

Another resource is the documentation of the package `polytope`:
    https://github.com/tulip-control/polytope/blob/master/doc/tutorial.md

Best regards,
Ioannis

On 4/8/21 10:42 PM, Rishabh Thakkar wrote:
> Hi Ioannis,
>
>
>
> Thanks for the suggestions. I still had a few lingering questions.
>
> So my first thought was I could indeed define an "obstacle" to avoid for each individual timestep, but I was not able to see or understand how I would generate an LTL formula for avoiding the unsafe region at each time step. In other words, does there exist an internal state variable such as "t" representing time or a specific time step that I can access while generating the LTL formula as something like "[] (t=1 -> ~obstacle_t1 && t=2 -> ~obstacle_t2 && ... && t=n -> ~obstacle_tn)"? I realize worst case I can have something in the dynamics that increments by 1 at each step, but I was wondering if there was something already built in?
>
> Furthermore, I am also confused about defining a polytope that is not in the shape of a box. All of the examples use this box2poly function, but I don't see one defined with a series of vertices. I see that the constructor for a polytope asks for a matrix A and vector b denoted as hyperplane normals and offsets, but I don't exactly understand that terminology. Is there any reference that explains how I can take a series of vertices in a 2d plane represent them as a polytope? 
>
> Thank you,
> Rishabh
>
> On Thu, Apr 8, 2021 at 10:28 AM Ioannis Filippidis <jfi...@gm... <mailto:jfi...@gm...>> wrote:
>
>     Hi Rishabh,
>
>     It would possible to describe moving obstacles in discrete time
>     by using an LTL formula that mentions the names of polytopic regions
>     in the workspace. For example, if the formula requires that the system
>     not be in region_1 at one point in time, and not in a nearby region_2
>     at a consecutive point in time, etc., this would correspond to an
>     obstacle that moved from occupying region_1 to occupying region_2, etc.
>
>     Such a formula would probably better be formed programmatically by
>     operating on strings in Python (and defining the corresponding
>     polytopic regions). Writing the formula by hand may not be practical,
>     due to its size and complexity.
>
>     This approach also allows using discrete-valued environment variables
>     that determine how the obstacles move, thus enabling also the modeling of
>     an unknown behavior for how the obstacles will move, subject to
>     assumptions. More information about this approach can be found in
>     TuLiP's references, in particular:
>         https://github.com/tulip-control/tulip-control/blob/bb004422b575dccea8d19c33acfeb04b37c62a5a/doc/bib.txt#L57-L68
>     The resulting interaction between system and environment can be
>     regarded as a game.
>
>     About discretizing continuous movement in this way: by either
>     enlarging the obstacle regions, or using appropriate continuous-state
>     uncertainties in the system dynamics, it could be possible to
>     account for the intermediate positions that the obstacles occupy in
>     continuous time. This may be a conservative approximation of the
>     continuous-time planning problem.
>
>     I am not sure whether by "dynamic" obstacles you mean obstacles that
>     have continuous dynamics (besides moving).
>
>     Best regards,
>     Ioannis
>
>     On 4/8/21 2:31 AM, Rishabh Thakkar wrote:
>     > Hi there,
>     >
>     > I was browsing through the TuLiP examples, but it wasn't clear to me how or
>     > whether there was support for designing an environment with dynamic
>     > obstacles for a continuous environment. If that is not, is it possible to
>     > input a list of polytopes representing safe or unsafe regions for each
>     > discrete time step? Ultimately, I am trying to model a moving obstacle in
>     > the continuous world. I'm hoping to start with a deterministic path of the
>     > obstacle, but eventually transition it to something that behaves as an
>     > adversary to the primary system being controlled effectively creating a
>     > game. To what extent could TuLiP support modeling this type of system.
>     >
>     > Thanks,
>     > Rishabh
>     > -------------- next part --------------
>     > An HTML attachment was scrubbed...
>     >
>     > _______________________________________________
>     > tulip-control-users mailing list
>     > tul...@li... <mailto:tul...@li...>
>     > https://lists.sourceforge.net/lists/listinfo/tulip-control-users
>     >
>

Re: [tulip-control-users] Dynamic Obstacles

[Rishabh T. <ris...@ut...>]

Hi Ioannis,

Thanks for the suggestions. I still had a few lingering questions.

So my first thought was I could indeed define an "obstacle" to avoid for
each individual timestep, but I was not able to see or understand how I
would generate an LTL formula for avoiding the unsafe region at each time
step. In other words, does there exist an internal state variable such as
"t" representing time or a specific time step that I can access while
generating the LTL formula as something like "[] (t=1 -> ~obstacle_t1 &&
t=2 -> ~obstacle_t2 && ... && t=n -> ~obstacle_tn)"? I realize worst case I
can have something in the dynamics that increments by 1 at each step, but I
was wondering if there was something already built in?

Furthermore, I am also confused about defining a polytope that is not in
the shape of a box. All of the examples use this box2poly function, but I
don't see one defined with a series of vertices. I see that the constructor
for a polytope asks for a matrix A and vector b denoted as hyperplane
normals and offsets, but I don't exactly understand that terminology. Is
there any reference that explains how I can take a series of vertices in a
2d plane represent them as a polytope?

Thank you,
Rishabh

On Thu, Apr 8, 2021 at 10:28 AM Ioannis Filippidis <jfi...@gm...>
wrote:

> Hi Rishabh,
>
> It would possible to describe moving obstacles in discrete time
> by using an LTL formula that mentions the names of polytopic regions
> in the workspace. For example, if the formula requires that the system
> not be in region_1 at one point in time, and not in a nearby region_2
> at a consecutive point in time, etc., this would correspond to an
> obstacle that moved from occupying region_1 to occupying region_2, etc.
>
> Such a formula would probably better be formed programmatically by
> operating on strings in Python (and defining the corresponding
> polytopic regions). Writing the formula by hand may not be practical,
> due to its size and complexity.
>
> This approach also allows using discrete-valued environment variables
> that determine how the obstacles move, thus enabling also the modeling of
> an unknown behavior for how the obstacles will move, subject to
> assumptions. More information about this approach can be found in
> TuLiP's references, in particular:
>
> https://github.com/tulip-control/tulip-control/blob/bb004422b575dccea8d19c33acfeb04b37c62a5a/doc/bib.txt#L57-L68
> The resulting interaction between system and environment can be
> regarded as a game.
>
> About discretizing continuous movement in this way: by either
> enlarging the obstacle regions, or using appropriate continuous-state
> uncertainties in the system dynamics, it could be possible to
> account for the intermediate positions that the obstacles occupy in
> continuous time. This may be a conservative approximation of the
> continuous-time planning problem.
>
> I am not sure whether by "dynamic" obstacles you mean obstacles that
> have continuous dynamics (besides moving).
>
> Best regards,
> Ioannis
>
> On 4/8/21 2:31 AM, Rishabh Thakkar wrote:
> > Hi there,
> >
> > I was browsing through the TuLiP examples, but it wasn't clear to me how
> or
> > whether there was support for designing an environment with dynamic
> > obstacles for a continuous environment. If that is not, is it possible to
> > input a list of polytopes representing safe or unsafe regions for each
> > discrete time step? Ultimately, I am trying to model a moving obstacle in
> > the continuous world. I'm hoping to start with a deterministic path of
> the
> > obstacle, but eventually transition it to something that behaves as an
> > adversary to the primary system being controlled effectively creating a
> > game. To what extent could TuLiP support modeling this type of system.
> >
> > Thanks,
> > Rishabh
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> >
> > _______________________________________________
> > tulip-control-users mailing list
> > tul...@li...
> > https://lists.sourceforge.net/lists/listinfo/tulip-control-users
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...

Re: [tulip-control-users] Dynamic Obstacles

[Ioannis F. <jfi...@gm...>]

Hi Rishabh,

It would possible to describe moving obstacles in discrete time
by using an LTL formula that mentions the names of polytopic regions
in the workspace. For example, if the formula requires that the system
not be in region_1 at one point in time, and not in a nearby region_2
at a consecutive point in time, etc., this would correspond to an
obstacle that moved from occupying region_1 to occupying region_2, etc.

Such a formula would probably better be formed programmatically by
operating on strings in Python (and defining the corresponding
polytopic regions). Writing the formula by hand may not be practical,
due to its size and complexity.

This approach also allows using discrete-valued environment variables
that determine how the obstacles move, thus enabling also the modeling of
an unknown behavior for how the obstacles will move, subject to
assumptions. More information about this approach can be found in
TuLiP's references, in particular:
    https://github.com/tulip-control/tulip-control/blob/bb004422b575dccea8d19c33acfeb04b37c62a5a/doc/bib.txt#L57-L68
The resulting interaction between system and environment can be
regarded as a game.

About discretizing continuous movement in this way: by either
enlarging the obstacle regions, or using appropriate continuous-state
uncertainties in the system dynamics, it could be possible to
account for the intermediate positions that the obstacles occupy in
continuous time. This may be a conservative approximation of the
continuous-time planning problem.

I am not sure whether by "dynamic" obstacles you mean obstacles that
have continuous dynamics (besides moving).

Best regards,
Ioannis

On 4/8/21 2:31 AM, Rishabh Thakkar wrote:
> Hi there,
>
> I was browsing through the TuLiP examples, but it wasn't clear to me how or
> whether there was support for designing an environment with dynamic
> obstacles for a continuous environment. If that is not, is it possible to
> input a list of polytopes representing safe or unsafe regions for each
> discrete time step? Ultimately, I am trying to model a moving obstacle in
> the continuous world. I'm hoping to start with a deterministic path of the
> obstacle, but eventually transition it to something that behaves as an
> adversary to the primary system being controlled effectively creating a
> game. To what extent could TuLiP support modeling this type of system.
>
> Thanks,
> Rishabh
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> _______________________________________________
> tulip-control-users mailing list
> tul...@li...
> https://lists.sourceforge.net/lists/listinfo/tulip-control-users
>

[tulip-control-users] Dynamic Obstacles

[Rishabh T. <ris...@ut...>]

Hi there,

I was browsing through the TuLiP examples, but it wasn't clear to me how or
whether there was support for designing an environment with dynamic
obstacles for a continuous environment. If that is not, is it possible to
input a list of polytopes representing safe or unsafe regions for each
discrete time step? Ultimately, I am trying to model a moving obstacle in
the continuous world. I'm hoping to start with a deterministic path of the
obstacle, but eventually transition it to something that behaves as an
adversary to the primary system being controlled effectively creating a
game. To what extent could TuLiP support modeling this type of system.

Thanks,
Rishabh
-------------- next part --------------
An HTML attachment was scrubbed...

Re: [tulip-control-users] [TuLiP discuss] A problem about The Temporal Logic Planning (TuLiP) toolbox

[Scott C. L. <sco...@gm...>]

(moving this discussion to the users mailing list)

Unless I missed something, this is not "a problem" in the sense that
strategies are correct. However, they contain edges that will not be
traversed during feasible plays.

Did you find that the strategy is not winning with respect to the game?

~Scott


El sáb., 23 de mar. de 2019 a la(s) 12:37, Tierui HE
(th...@co...) escribió:
>
> Dear TuLiP project members,
>
> I am HE, Tierui, a PhD student in the Hong Kong University of Science and Technology. I have just tried The Temporal Logic Planning (TuLiP) toolbox and encountered a problem. For the file "controlled_switching.py" in the "examples" folder on GitHub, if I changed initial condition of the environment to "env_init = {'!park'}", I have tried to change "specs.qinit" to "'\E \E' ", "'\E \A' " or "'\A \E' ", but in some routes of the results, the initial value of 'park' is still True as underlined with red lines in the attached figure. How can I set the initial value of 'park' to False? Thank you very much.
>
> Best regards,
>
> Tierui
>
> _______________________________________________
> tulip-control-discuss mailing list
> tul...@li...
> https://lists.sourceforge.net/lists/listinfo/tulip-control-discuss

Re: [tulip-control-users] [TuLiP discuss] Problem running an old Tulip script

[Oliver M. <mar...@we...>]

Dear Scott,

Thanks for your help. At a first glance the results in the Jupyter 
notebook align with our expectations. We will continue working with it 
next week. After your assistance, it would no doubt be smoother. In the 
unlikely event that we encounter some issues, we'd like to contact you 
again.

Best
Oliver


Am 31.10.2018 um 20:57 schrieb Scott C. Livingston:
> Can you view the results in the Jupyter notebook at
> https://colab.research.google.com/drive/1KKxSfB3-Dz1V6U__Sx3-PADub2msYfHN
> and tell me if they align with your expectations, based on your
> previous (now broken) implementation?
>
> I made several small edits to give Python 3 support to your code.
>
> If the output does not appear as expected, I can find the most recent
> Tulip version that works with your code unmodified. Then, we can work
> on reconciling.
>
> ~Scott
>
>
> El sáb., 6 de oct. de 2018 a la(s) 11:57, Daniel Neider
> (ne...@mp...) escribió:
>> Dear Scott,
>>
>> Thanks for your quick reply. I'm adding my student Oliver to this
>> conversation as well as he is the one trying to make Tulip work with our
>> old script.
>>
>> Unfortunately, I cannot answer your first two questions because I was
>> not directly involved in conducting the experiments for our earlier
>> paper. I remember that one of Ufuk's students at UPenn was in charge of
>> that. Moreover, I recall that we published our paper at TACAS 2016.
>> Thus, we must have done the experiments around September or October
>> 2015, if that is of any help.
>>
>> We are using Tulip 1.3.0. The output is as follows:
>>
>>   >>> import tulip;
>>   >>> print(tulip.__version__)
>> 1.3.0
>>   >>>
>>
>> Thanks,
>> Daniel
>>
>> On 05/10/2018 15:13, Scott C. Livingston wrote:
>>> (moving this discussion over to tulip-control-users)
>>>
>>> El jue., 4 de oct. de 2018 a la(s) 23:55, Scott C. Livingston escribió:
>>>> To be clear, can you reproduce the results using the version of Tulip
>>>> with which the original work was performed? If so, can you tell me
>>>> which version number it was?
>>>>
>>>> Independently of your answer to the above, which version of Tulip are
>>>> you trying to use now? E.g., you can get this from
>>>>
>>>>       import tulip
>>>>       print(tulip.__version__)
>>>>
>>>> or in a single command:
>>>>
>>>>       python -c 'import tulip; print(tulip.__version__)'
>>>>
>>>> ~Scott
>>>>
>>>> El mar., 2 de oct. de 2018 a la(s) 10:34, Daniel Neider
>>>> (ne...@mp...) escribió:
>>>>> Dear Tulip team!
>>>>>
>>>>> Ufuk Topcu referred me to this email address regarding an issue with
>>>>> Tulip. I would be happy any assistance you can provide.
>>>>>
>>>>> Roughly two years ago, a former student of mine has successfully used
>>>>> Tulip for one of his projects. Unfortunately, the Python script he
>>>>> created (please see the script attached) does no longer work with the
>>>>> recent version of Tulip. Thus, we are unable to reproduce the results
>>>>> from this earlier project.
>>>>>
>>>>> The exact error message is the following (using gr1c 0.11.0):
>>>>>
>>>>> python GridWorldSequence_1D.py
>>>>> set(['(a0 && b0) || (a1 && b1) || (a2 && b2) || (a3 && b3) || (a4 && b4)
>>>>> || (a5 && b5)'])
>>>>> Traceback (most recent call last):
>>>>>      File "GridWorldSequence_1D.py", line 76, in <module>
>>>>>        ctrl = synth.synthesize('gr1c',specs, sys=sys,env = env1)
>>>>>      File
>>>>> "/home/oliver/.local/lib/python2.7/site-packages/tulip/synth.py", line
>>>>> 1126, in synthesize
>>>>>        strategy = gr1c.synthesize(specs)
>>>>>      File
>>>>> "/home/oliver/.local/lib/python2.7/site-packages/tulip/interfaces/gr1c.py",
>>>>> line 447, in synthesize
>>>>>        init_option = select_options(spec)
>>>>>      File
>>>>> "/home/oliver/.local/lib/python2.7/site-packages/tulip/interfaces/gr1c.py",
>>>>> line 495, in select_options
>>>>>        assert not spec.moore
>>>>>
>>>>> Would you be able to assist us with this problem?
>>>>>
>>>>> Thank you very much,
>>>>> Daniel
>>>>>
>>>>> --
>>>>> Daniel Neider
>>>>> Max Planck Institute for Software Systems
>>>>> Paul-Ehrlich-Str. 26, Room 316
>>>>> 67663 Kaiserslautern, Germany
>>>>>
>>>>> https://www.mpi-sws.org/~neider
>>>>> _______________________________________________
>>>>> tulip-control-discuss mailing list
>>>>> tul...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/tulip-control-discuss

Re: [tulip-control-users] [TuLiP discuss] Problem running an old Tulip script

[Scott C. L. <sco...@gm...>]

Can you view the results in the Jupyter notebook at
https://colab.research.google.com/drive/1KKxSfB3-Dz1V6U__Sx3-PADub2msYfHN
and tell me if they align with your expectations, based on your
previous (now broken) implementation?

I made several small edits to give Python 3 support to your code.

If the output does not appear as expected, I can find the most recent
Tulip version that works with your code unmodified. Then, we can work
on reconciling.

~Scott


El sáb., 6 de oct. de 2018 a la(s) 11:57, Daniel Neider
(ne...@mp...) escribió:
>
> Dear Scott,
>
> Thanks for your quick reply. I'm adding my student Oliver to this
> conversation as well as he is the one trying to make Tulip work with our
> old script.
>
> Unfortunately, I cannot answer your first two questions because I was
> not directly involved in conducting the experiments for our earlier
> paper. I remember that one of Ufuk's students at UPenn was in charge of
> that. Moreover, I recall that we published our paper at TACAS 2016.
> Thus, we must have done the experiments around September or October
> 2015, if that is of any help.
>
> We are using Tulip 1.3.0. The output is as follows:
>
>  >>> import tulip;
>  >>> print(tulip.__version__)
> 1.3.0
>  >>>
>
> Thanks,
> Daniel
>
> On 05/10/2018 15:13, Scott C. Livingston wrote:
> > (moving this discussion over to tulip-control-users)
> >
> > El jue., 4 de oct. de 2018 a la(s) 23:55, Scott C. Livingston escribió:
> >>
> >> To be clear, can you reproduce the results using the version of Tulip
> >> with which the original work was performed? If so, can you tell me
> >> which version number it was?
> >>
> >> Independently of your answer to the above, which version of Tulip are
> >> you trying to use now? E.g., you can get this from
> >>
> >>      import tulip
> >>      print(tulip.__version__)
> >>
> >> or in a single command:
> >>
> >>      python -c 'import tulip; print(tulip.__version__)'
> >>
> >> ~Scott
> >>
> >> El mar., 2 de oct. de 2018 a la(s) 10:34, Daniel Neider
> >> (ne...@mp...) escribió:
> >>>
> >>> Dear Tulip team!
> >>>
> >>> Ufuk Topcu referred me to this email address regarding an issue with
> >>> Tulip. I would be happy any assistance you can provide.
> >>>
> >>> Roughly two years ago, a former student of mine has successfully used
> >>> Tulip for one of his projects. Unfortunately, the Python script he
> >>> created (please see the script attached) does no longer work with the
> >>> recent version of Tulip. Thus, we are unable to reproduce the results
> >>> from this earlier project.
> >>>
> >>> The exact error message is the following (using gr1c 0.11.0):
> >>>
> >>> python GridWorldSequence_1D.py
> >>> set(['(a0 && b0) || (a1 && b1) || (a2 && b2) || (a3 && b3) || (a4 && b4)
> >>> || (a5 && b5)'])
> >>> Traceback (most recent call last):
> >>>     File "GridWorldSequence_1D.py", line 76, in <module>
> >>>       ctrl = synth.synthesize('gr1c',specs, sys=sys,env = env1)
> >>>     File
> >>> "/home/oliver/.local/lib/python2.7/site-packages/tulip/synth.py", line
> >>> 1126, in synthesize
> >>>       strategy = gr1c.synthesize(specs)
> >>>     File
> >>> "/home/oliver/.local/lib/python2.7/site-packages/tulip/interfaces/gr1c.py",
> >>> line 447, in synthesize
> >>>       init_option = select_options(spec)
> >>>     File
> >>> "/home/oliver/.local/lib/python2.7/site-packages/tulip/interfaces/gr1c.py",
> >>> line 495, in select_options
> >>>       assert not spec.moore
> >>>
> >>> Would you be able to assist us with this problem?
> >>>
> >>> Thank you very much,
> >>> Daniel
> >>>
> >>> --
> >>> Daniel Neider
> >>> Max Planck Institute for Software Systems
> >>> Paul-Ehrlich-Str. 26, Room 316
> >>> 67663 Kaiserslautern, Germany
> >>>
> >>> https://www.mpi-sws.org/~neider
> >>> _______________________________________________
> >>> tulip-control-discuss mailing list
> >>> tul...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/tulip-control-discuss

Re: [tulip-control-users] [TuLiP discuss] Problem running an old Tulip script

[Daniel N. <ne...@mp...>]

Dear Scott,

Thanks for your quick reply. I'm adding my student Oliver to this 
conversation as well as he is the one trying to make Tulip work with our 
old script.

Unfortunately, I cannot answer your first two questions because I was 
not directly involved in conducting the experiments for our earlier 
paper. I remember that one of Ufuk's students at UPenn was in charge of 
that. Moreover, I recall that we published our paper at TACAS 2016. 
Thus, we must have done the experiments around September or October 
2015, if that is of any help.

We are using Tulip 1.3.0. The output is as follows:

 >>> import tulip;
 >>> print(tulip.__version__)
1.3.0
 >>>

Thanks,
Daniel

On 05/10/2018 15:13, Scott C. Livingston wrote:
> (moving this discussion over to tulip-control-users)
> 
> El jue., 4 de oct. de 2018 a la(s) 23:55, Scott C. Livingston escribió:
>>
>> To be clear, can you reproduce the results using the version of Tulip
>> with which the original work was performed? If so, can you tell me
>> which version number it was?
>>
>> Independently of your answer to the above, which version of Tulip are
>> you trying to use now? E.g., you can get this from
>>
>>      import tulip
>>      print(tulip.__version__)
>>
>> or in a single command:
>>
>>      python -c 'import tulip; print(tulip.__version__)'
>>
>> ~Scott
>>
>> El mar., 2 de oct. de 2018 a la(s) 10:34, Daniel Neider
>> (ne...@mp...) escribió:
>>>
>>> Dear Tulip team!
>>>
>>> Ufuk Topcu referred me to this email address regarding an issue with
>>> Tulip. I would be happy any assistance you can provide.
>>>
>>> Roughly two years ago, a former student of mine has successfully used
>>> Tulip for one of his projects. Unfortunately, the Python script he
>>> created (please see the script attached) does no longer work with the
>>> recent version of Tulip. Thus, we are unable to reproduce the results
>>> from this earlier project.
>>>
>>> The exact error message is the following (using gr1c 0.11.0):
>>>
>>> python GridWorldSequence_1D.py
>>> set(['(a0 && b0) || (a1 && b1) || (a2 && b2) || (a3 && b3) || (a4 && b4)
>>> || (a5 && b5)'])
>>> Traceback (most recent call last):
>>>     File "GridWorldSequence_1D.py", line 76, in <module>
>>>       ctrl = synth.synthesize('gr1c',specs, sys=sys,env = env1)
>>>     File
>>> "/home/oliver/.local/lib/python2.7/site-packages/tulip/synth.py", line
>>> 1126, in synthesize
>>>       strategy = gr1c.synthesize(specs)
>>>     File
>>> "/home/oliver/.local/lib/python2.7/site-packages/tulip/interfaces/gr1c.py",
>>> line 447, in synthesize
>>>       init_option = select_options(spec)
>>>     File
>>> "/home/oliver/.local/lib/python2.7/site-packages/tulip/interfaces/gr1c.py",
>>> line 495, in select_options
>>>       assert not spec.moore
>>>
>>> Would you be able to assist us with this problem?
>>>
>>> Thank you very much,
>>> Daniel
>>>
>>> --
>>> Daniel Neider
>>> Max Planck Institute for Software Systems
>>> Paul-Ehrlich-Str. 26, Room 316
>>> 67663 Kaiserslautern, Germany
>>>
>>> https://www.mpi-sws.org/~neider
>>> _______________________________________________
>>> tulip-control-discuss mailing list
>>> tul...@li...
>>> https://lists.sourceforge.net/lists/listinfo/tulip-control-discuss

Re: [tulip-control-users] [TuLiP discuss] Problem running an old Tulip script

[Scott C. L. <sco...@gm...>]

(moving this discussion over to tulip-control-users)

El jue., 4 de oct. de 2018 a la(s) 23:55, Scott C. Livingston escribió:
>
> To be clear, can you reproduce the results using the version of Tulip
> with which the original work was performed? If so, can you tell me
> which version number it was?
>
> Independently of your answer to the above, which version of Tulip are
> you trying to use now? E.g., you can get this from
>
>     import tulip
>     print(tulip.__version__)
>
> or in a single command:
>
>     python -c 'import tulip; print(tulip.__version__)'
>
> ~Scott
>
> El mar., 2 de oct. de 2018 a la(s) 10:34, Daniel Neider
> (ne...@mp...) escribió:
> >
> > Dear Tulip team!
> >
> > Ufuk Topcu referred me to this email address regarding an issue with
> > Tulip. I would be happy any assistance you can provide.
> >
> > Roughly two years ago, a former student of mine has successfully used
> > Tulip for one of his projects. Unfortunately, the Python script he
> > created (please see the script attached) does no longer work with the
> > recent version of Tulip. Thus, we are unable to reproduce the results
> > from this earlier project.
> >
> > The exact error message is the following (using gr1c 0.11.0):
> >
> > python GridWorldSequence_1D.py
> > set(['(a0 && b0) || (a1 && b1) || (a2 && b2) || (a3 && b3) || (a4 && b4)
> > || (a5 && b5)'])
> > Traceback (most recent call last):
> >    File "GridWorldSequence_1D.py", line 76, in <module>
> >      ctrl = synth.synthesize('gr1c',specs, sys=sys,env = env1)
> >    File
> > "/home/oliver/.local/lib/python2.7/site-packages/tulip/synth.py", line
> > 1126, in synthesize
> >      strategy = gr1c.synthesize(specs)
> >    File
> > "/home/oliver/.local/lib/python2.7/site-packages/tulip/interfaces/gr1c.py",
> > line 447, in synthesize
> >      init_option = select_options(spec)
> >    File
> > "/home/oliver/.local/lib/python2.7/site-packages/tulip/interfaces/gr1c.py",
> > line 495, in select_options
> >      assert not spec.moore
> >
> > Would you be able to assist us with this problem?
> >
> > Thank you very much,
> > Daniel
> >
> > --
> > Daniel Neider
> > Max Planck Institute for Software Systems
> > Paul-Ehrlich-Str. 26, Room 316
> > 67663 Kaiserslautern, Germany
> >
> > https://www.mpi-sws.org/~neider
> > _______________________________________________
> > tulip-control-discuss mailing list
> > tul...@li...
> > https://lists.sourceforge.net/lists/listinfo/tulip-control-discuss

[tulip-control-users] Qinit in GRSpec question

[Joshua S. <jsh...@te...>]

Are there any further examples or sources for using the quantification
option associated with GRSpec besides the descriptions provided in the
documentation examples (which all appear to just use \E \A)?

Specifically I'm trying to better understand the warning messages,
"WARNING: `qinit = "\A \A"` but not `EnvInit => SysInit`" and "WARNING:
`qinit = '\A \A'` but not `EnvInit => (\E y': SysNext)`"

Joshua
-------------- next part --------------
An HTML attachment was scrubbed...

Re: [tulip-control-users] Issues with Omega synthesizing progress statements using 'Next' operator

[Scott C. L. <sco...@gm...>]

Are you representing the specification formula as an instance of GRSpec?

If so, then I think the error arises from not using GRSpec as
intended. GRspec represents a GR(1) formula where "system progress
statements" are subformulae of the form

    []<> f

where f does not contain any temporal operators. Thus, while []<> X
goal if and only if []<> goal, the formula

    []<> X goal

does not follow the GR(1) template. As such,

    import tulip.synth
    from tulip.spec.form import GRSpec
    tulip.synth.synthesize(GRSpec(sys_vars={'goal'}, sys_prog={'X goal'}))

leads to the error that you describe, but I do not consider it a bug.
Instead, your experience might motivate two feature requests:

1. make GRSpec more defensive, so arguments of the wrong form lead to
ValueError exceptions;
2. create a new class GRSpecFree that takes arbitrary strings that are
equivalent to some formula that satisfies the GR(1) template assumed
by GRSpec.

Cheers from DC,
Scott


El mié., 8 de ago. de 2018 a la(s) 22:33, Joshua Shaffer
(jsh...@te...) escribió:
>
> Hello,
>
> Not sure if this is a common problem as I haven't seen any mention of such,
> but suppose I have a specification with an AP *goal* and system progress
> statement of []<>*goal*. This is realizable. Intuitively, []<> X (*goal*)
> should also be realizable, but omega will consistently run into a "renaming
> target variable" issue using the 'dd' python module in its fixpoint.py
> script. Omega handles 'Next' operators in the safety specifications just
> fine, so I'm having difficulty understanding if this is an incapability on
> omega's side, an obscure issue with Tulip's use of omega, or an error in my
> understanding.
>
> Joshua Shaffer
> -------------- next part --------------
> An HTML attachment was scrubbed...
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> tulip-control-users mailing list
> tul...@li...
> https://lists.sourceforge.net/lists/listinfo/tulip-control-users

[tulip-control-users] Issues with Omega synthesizing progress statements using 'Next' operator

[Joshua S. <jsh...@te...>]

Hello,

Not sure if this is a common problem as I haven't seen any mention of such,
but suppose I have a specification with an AP *goal* and system progress
statement of []<>*goal*. This is realizable. Intuitively, []<> X (*goal*)
should also be realizable, but omega will consistently run into a "renaming
target variable" issue using the 'dd' python module in its fixpoint.py
script. Omega handles 'Next' operators in the safety specifications just
fine, so I'm having difficulty understanding if this is an incapability on
omega's side, an obscure issue with Tulip's use of omega, or an error in my
understanding.

Joshua Shaffer
-------------- next part --------------
An HTML attachment was scrubbed...

Re: [tulip-control-users] Errors in running TuLip

[Necmiye Ö. <nec...@gm...>]

MOSEK is not necessarily faster but it is numerically more stable. In
problems where the solvers complain about numerics, it is preferable (I use
it often).

Necmiye

On Thu, Jan 25, 2018 at 6:00 PM, Ioannis Filippidis <jfi...@gm...>
wrote:

> 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:tulip@tulip-control.
> org>; 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>
> >
> >
> >
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...

Re: [tulip-control-users] Errors in running TuLip

[Ioannis F. <jfi...@gm...>]

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>
>
>
>
>
>

Re: [tulip-control-users] Errors in running TuLip

[Mathur, U. <uma...@il...>]

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.py 2018-01-24 23:06:08.110735358 -0800
+++ continuous_reach_avoid.py 2018-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




-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: continuous_reach_avoid_4d.py
Type: text/x-python-script
Size: 3286 bytes
Desc: continuous_reach_avoid_4d.py
-------------- next part --------------
A non-text attachment was scrubbed...
Name: continuous_reach_avoid.py
Type: text/x-python-script
Size: 3622 bytes
Desc: continuous_reach_avoid.py
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pictorial_representation.png
Type: image/png
Size: 60446 bytes
Desc: pictorial_representation.png

Re: [tulip-control-users] Errors in running TuLip

[Ioannis F. <jfi...@gm...>]

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...>
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.py 2018-01-24 23:06:08.110735358 -0800
> +++ continuous_reach_avoid.py 2018-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...>
> 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...>
>> 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...]
>>> *Sent:* Wednesday, January 24, 2018 11:34 PM
>>> *To:* Mathur, Umang
>>> *Cc:* 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...>
>>> 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
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...

Re: [tulip-control-users] Errors in running TuLip

[Ioannis F. <jfi...@gm...>]

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.py 2018-01-24 23:06:08.110735358 -0800
+++ continuous_reach_avoid.py 2018-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...>
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...>
> 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...]
>> *Sent:* Wednesday, January 24, 2018 11:34 PM
>> *To:* Mathur, Umang
>> *Cc:* 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...>
>> 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
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: foo.pdf
Type: application/pdf
Size: 19237 bytes
Desc: not available

Re: [tulip-control-users] Errors in running TuLip

[Necmiye Ö. <nec...@gm...>]

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...> 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...]
> Sent: Wednesday, January 24, 2018 11:34 PM
> To: Mathur, Umang
> Cc: 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...> 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

-------------- next part --------------
An HTML attachment was scrubbed...

Re: [tulip-control-users] TuLiP receding horizon

[Ioannis F. <jfi...@gm...>]

On 11/20/17 8:38 AM, Joshua Shaffer wrote:
> I've read previous papers that state Tulip has the capability for performing its form of receding horizon control, but I can't seem to locate any reference to such in the readme files or online help.
>

Hi Joshua,

Indeed, there was an implementation of receding horizon control in earlier versions of
`tulip` [1]. Parts of `tulip` have been reimplemented since then (and API changed).
The newer version of receding horizon control is on branch `invariants` [2].
Possible alternatives you could consider are:

1. Install `tulip == 0.4a` and its dependencies, and run the old version.
   In principle this should be possible, but changes in operating systems may affect old
   versions of dependencies.

2. Use the current development version of `tulip`, which you can obtain
   from the GitHub repository. Receding horizon control has been reimplemented, and the
   result is on branch `invariants` [2]. It has not been merged into branch `master`.
   The most relevant commit is [3].

   The branch `invariants` is expected to work when the appropriate dependencies are present.
   So one option is to use the branch as is.

   A further option is updating that branch with respect to current `master`.
   I would expect this option to not be difficult, and require mainly resolving
   programming issues related to API changes.

If you do successfully merge `master` into `invariants`, it would be of interest
to open a pull request on GitHub, so that we can merge the changes back to `master`.

I have cc'ed the users' mailing list, where you can ask questions and
subscribe to receive discussion on questions by other users.

Please let us know in case you have further questions, via the mailing list,
or via the issue tracker on GitHub.

[1] https://github.com/tulip-control/tulip-control/blob/tulip-0.4a/examples/recedinghorizon/autonomous_car_road.py
[2] https://github.com/tulip-control/tulip-control/tree/invariants
[3] https://github.com/tulip-control/tulip-control/commit/fe12974a071bd20a3fec8b97731e53338f4982de

Best regards,
Ioannis Filippidis

Re: [tulip-control-users] [TuLiP discuss] Requesting Info: Using TuLiP as a Benchmark for nuSMV

[Scott C. L. <sco...@gm...>]

I am moving this thread into the tulip-control-users mailing list, to
which you can subscribe at
https://sourceforge.net/projects/tulip-control/lists/tulip-control-users

Unless I am mistaken about which paper that is, the implementation is
available in an old version of TuLiP. Some of that code did not survive
major verion changes of TuLiP, so running it will be easiest if you use
version 0.4a [1].

However, the old installation process of TuLiP is notoriously difficult,
so you might consider first studying the source code. I recommend
reviewing it at commit 9424db162b77fb8019c08fb8bfe875d4ed57516c of the
repository [2], in particular try to begin with benchmark_tools.py and
nusmvint.py [3], [4].

If you have questions after trying to read that code, ask here.

If you are interested in bringing that code into the current version of
TuLiP, then please send a pull request. I think that doing so is
worthwhile, but no one has had time to do so lately.


[1] https://github.com/tulip-control/tulip-control/archive/tulip-0.4a.zip
[2]
https://github.com/tulip-control/tulip-control/tree/9424db162b77fb8019c08fb8bfe875d4ed57516c
[3]
https://github.com/tulip-control/tulip-control/blob/9424db162b77fb8019c08fb8bfe875d4ed57516c/benchmark/benchmark_tools.py
[4]
https://github.com/tulip-control/tulip-control/blob/9424db162b77fb8019c08fb8bfe875d4ed57516c/tulip/nusmvint.py


On 11/16/2017 10:23 PM, Saveri Pal wrote:
> Hi,
> 
> I came across the paper 'Evaluation and Benchmarking for Robot Motion
> Planning Problems Using TuLiP' - N. Spooner, Richard Murray. In this paper
> they evaluate the performances of NuSMV and SPIN for 2D motion planning.
> They have used TuLiP to generate a gridworlds of various size and
> complexity, and checked this model with nuSMV and SPIN.
> 
> I am trying to solve a similar situation by generating a gridworlds of
> various complexity and using NuSMV to model check it.
> 
> I do not understand how they import the grid generated in TuLiP to NuSMV. I
> am new to TuLiP and I am sure I am missing out on something that connects
> the two.
> 
> Will you be able to shed some light to this? Any information, reading
> material, web link will be helpful. Thanks.
> 
> 
> Regards,
> Saveri Pal
> Aerospace Engineering
> Iowa State University
> (+1-515-451-9036)
> 
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> 
> 
> 
> _______________________________________________
> tulip-control-discuss mailing list
> tul...@li...
> https://lists.sourceforge.net/lists/listinfo/tulip-control-discuss
> 

-- 
+1 865 964 5384
AECA 499C 387E 6DC8 8A2C  D7CB 6449 4654 03B4 0F63

Re: [tulip-control-users] [TuLiP discuss] Difficulties

[Ioannis F. <jfi...@gm...>]

Hi Tarek,

I am sorry for the delay. I have not yet processed everything below in detail,
but will do so. In the meantime, I am responding to part of the notes below:


I don't think that the environment variable `slugsCompile` is used.
You will need to pass this argument:

https://github.com/tulip-control/tulip-control/blob/master/tulip/interfaces/slugs.py#L149

 > ls -l slugs, gives:

This is a directory. You need to give the path to the directory that
contains the compiled executable (that file is probably inside `src/`).


 > - I used sudo to install tulip, slugs and about everything

Better to avoid `sudo`. It can cause all sorts of errors when not working
as root, because the files got written with permissions that prevent
changes as a normal user. Installing to a virtualenv will work better.


 > Btw, you seem to have forgotten to put the links of the references.

I apologize--probably something wrong within the Gmail interface.
Adding the references:

[1] https://github.com/tulip-control/tulip-control/blob/master/tulip/interfaces/slugs.py#L201
[2] https://github.com/tulip-control/tulip-control/blob/master/tulip/interfaces/slugs.py#L49
[3] https://github.com/tulip-control/tulip-control/blob/master/tulip/interfaces/slugs.py#L184
[4] https://github.com/johnyf/openpromela/blob/master/openpromela/slugs.py
[5] https://github.com/tulip-control/tulip-control/blob/master/tulip/interfaces/omega.py

[6] https://github.com/johnyf/omega/blob/d63b1b3ad9d110748292400cae3d2d04788d8be8/omega/games/gr1.py#L411
[7] https://github.com/johnyf/omega/blob/d63b1b3ad9d110748292400cae3d2d04788d8be8/omega/games/gr1.py#L528
[8] https://github.com/johnyf/omega/blob/d63b1b3ad9d110748292400cae3d2d04788d8be8/omega/games/enumeration.py#L132

Regarding the path ([3]) the `slugs` executable is found, since [9] is not raised.

[9] https://github.com/tulip-control/tulip-control/blob/master/tulip/interfaces/slugs.py#L168

You write `.bashrs`, though `.bashrc` is the standard name.
Also, whether this file is appropriate depends on your OS, which you
can check by searching what the default config file is for it.

About succeeding with using `gr1c` with the `synthesis_many` function,
I think that after the PR you opened is addressed, then this function will be
updated to the latest API (it seems to have fallen out of date, thanks for
catching that).

Additional notes: I am updating handling of initial conditions in `omega` to simplify
and unify it, while remaining essentially equivalent. It will also be closer to
how `gr1c` handles initial conditions. Also, `omega` can work with CUDD after
`dd.cudd` is compiled:

https://github.com/johnyf/dd/blob/master/dd/cudd.pyx

ioannis



On 10/12/17 2:23 PM, Tarek Kabbani wrote:
> Hi Ioannis,
>
> Attached is my code with another file to try using more than 2 dimension dynamics. I have sent this to Scott as well, and I will be glad if you could help by looking at, in your free time.
>
> For the paths (both the compiler file above and slugs), I have already changed them to where slugs is installed in the interface.
>
> Printing options, I get:
>
> ['/home/tarekk/slugs', '/tmp/tmpLODEYY', '--explicitStrategy', '--jsonOutput']
>
> I am using the following commands:
>
> sudo chmod -R 777 '/home/tarekk/tulip-control-1.4.0_master'
> sudo chmod -R 777 '/home/tarekk/slugs'
> sudo chmod -R 777 '/usr/lib/python2.7'
> sudo chown -R tarekk '/home/tk/tulip-control-1.4.0_master'
> sudo chown -R tarekk '/home/tk/slugs'
> sudo chown -R tarekk '/usr/lib/python2.7'
>
> additional info that might help:
> - I used sudo to install tulip, slugs and about everything
> - I added the path of slugs directory by writing the following into .bashrs:
>
> export slugs=/home/tarekk/slugs
> export PATH=$PATH:$slugs
> export slugsCompile=/home/tarekk/slugs/tools/StructuredSlugsParser
> export PATH=$PATH:$slugsCompile
>
> stat slugs, gives:
>
> File: 'slugs'
> Size: 4096          Blocks: 8          IO Block: 4096 directory
> Device: 801h/2049d    Inode: 20528       Links: 9
> Access: (0777/drwxrwxrwx)  Uid: (    0/    root)   Gid: ( 0/    root)
> Access: 2017-10-12 13:50:37.193459704 -0700
> Modify: 2017-10-12 09:08:39.762752640 -0700
> Change: 2017-10-12 13:50:37.193459704 -0700
> Birth: -
>
> ls -l slugs, gives:
>
> total 32
> drwxrwxrwx 2 tarekk root 4096 Oct 12 09:08 doc
> drwxrwxrwx 8 tarekk root 4096 Oct 12 09:08 examples
> drwxrwxrwx 3 tarekk root 4096 Oct 12 09:08 lib
> -rwxrwxrwx 1 tarekk root 1612 Oct 12 09:08 LICENSE.txt
> -rwxrwxrwx 1 tarekk root 3798 Oct 12 09:08 README.md
> drwxrwxrwx 3 tarekk root 4096 Oct 12 09:08 robustifier
> drwxrwxrwx 3 tarekk root 4096 Oct 12 09:14 src
> drwxrwxrwx 4 tarekk root 4096 Oct 12 09:08 tools
>
> I am using slugs for the unique reason of not being able to get result  with 'gr1c', as synthesis_many work with only one of the two.
>
> Btw, you seem to have forgotten to put the links of the references.
>
> Thank you,
>
> Best,
> Tarek
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *From: *"jfilippidis" <jfi...@gm...>
> *To: *"Tarek Kabbani" <tar...@gr...>
> *Cc: *"Scott C. Livingston" <sco...@gm...>, "tulip-control-users" <tul...@li...>
> *Sent: *Thursday, October 12, 2017 7:54:46 PM
> *Subject: *Re: [TuLiP discuss] Difficulties
>
> Hi Tarek,
>
> Regarding the error
> ===============
>
> As Scott noted in a previous email, this error is most probably due to file permissions.
> The line that raises this error is [1] and how the paths are set is earlier in that module.
>
> There is a second path at the top [2] that needs to be correct too, but since execution
> has reached below that point, that path probably is correct.
> The path that causes trouble is [3]. The fastest way to confirm that it is the permissions
> for the `slugs` file that raise the error is to print the options passed to `subprocess`.
>
> Have you confirmed that you set the permissions correctly with `chmod`?
> You can use `ls -l` for that purpose.
>
> Sidenote: changing the permissions for `python` or files of the tulip package would
> not affect this call, because `subprocess`
>
> Sidenote: Another interface to `slugs` is at [4] (please note that the `dev` branch there
> works with Python 3).
>
>
> About synthesizers
> ===============
>
> The interface to `slugs` has not changed for some time now, and the functionality
> available in that interface is included in the other synthesizers.
>
> If you would like to work directly with symbolic strategies in Python, or modify the
> synthesis algorithm (e.g., to change how initial conditions are handled),
> then the interface to `omega` [5] is one possibility, or where the initial conditions
> are reasoned about in that tool [6, 7, 8]. I am likely to make a change there in the near
> future of how one case of initial conditions is handled, and a second pending change is [9].
>
>
> Approach to resolving issues
> ======================
>
> I think it will help to continue by focusing sequentially on each of the several issues that have arisen,
> by sending error traces as the one below, or minimal examples that demonstrate the difficulty.
> If you have changes to point out, as you mentioned, or potential errors, then discussing
> those will help us resolve them earlier.
>
> Best,
> ioannis
>
>
> On Thu, Oct 12, 2017 at 9:27 AM, Tarek Kabbani <tar...@gr... <mailto:tar...@gr...>> wrote:
>
>     Hi,
>
>     Here is the slugs error I am having:
>
>       File "build/bdist.linux-x86_64/egg/tulip/synth.py", line 999, in synthesize_many
>       File "build/bdist.linux-x86_64/egg/tulip/interfaces/slugs.py", line 96, in synthesize
>       File "build/bdist.linux-x86_64/egg/tulip/interfaces/slugs.py", line 206, in _call_slugs
>       File "/usr/lib/python2.7/subprocess.py", line 711, in __init__
>         errread, errwrite)
>       File "/usr/lib/python2.7/subprocess.py", line 1343, in _execute_child
>         raise child_exception
>       OSError: [Errno 13] Permission denied
>
>     Even after changing ownership and permission (for python, slugs and tulip).
>
>     Best,
>     Tarek
>
>     ----- Original Message -----
>     From: "Scott C. Livingston" <sco...@gm... <mailto:sco...@gm...>>
>     To: "Tarek Kabbani" <tar...@gr... <mailto:tar...@gr...>>
>     Cc: tul...@li... <mailto:tul...@li...>
>     Sent: Tuesday, October 10, 2017 8:30:58 PM
>     Subject: Re: Fwd: [TuLiP discuss] Difficulties
>
>     On 10/10/2017 09:46 AM, Scott C. Livingston wrote:
>     > Dear Tulip team,
>     > L ately, I am having some difficulties regarding some functions:
>     > 1- How to make [
>     > https://mail.univaq.it/zimbra/def%20synthesize_many(specs,%20ts=None,%20ignore_init=None <https://mail.univaq.it/zimbra/def%20synthesize_many%28specs,%20ts=None,%20ignore_init=None>,
>     > | synthesize_many ] work? I have tried it with two transition systems
>
>     Can you share the code using https://gist.github.com/ or some pastebin?
>
>     > (env and sys) which are discretized from continuous systems. Although I
>     > was able to synthesis a controller for them with the spec I wrote using
>     > the normal synthesize, I was not able to, using synthesize_many, and I
>     > am getting unrealizable with 'gr1c' (sometimes with code 3). This even
>     > though I have solve some potential issues that I believe they might need
>     > to be fixed in Tulip, as the matching of the qinit (and also the other
>     > options) of the written specs with the qinit of the spec of the ts
>     > (which are default to \A \A, moore=true, plus_one=true) , and the
>     > insertion of ignore_init and bool_actions which is strange (as if
>     > statevar found it gives true where it should give the value set in those
>     > two sets).
>
>     it will be easier to consider your comments when the code is visible.
>
>     > 2- I am not able to use slugs also, Is there a way to connect it to
>     > tulip and python, I tried everything like adding environment variable to
>     > PATH and changing it in the interface, and changing permissions of all
>     > (python, tulip and slugs) but I am ending up with this error: [Errno 13]
>     > Permission denied. this for using subprocess. At the end, I did a stupid
>     > move of python and the virtual machine crashed :(.
>
>     can you provide the terminal output?
>
>     one idea is that the slugs program file is not marked as executable. to
>     check this, try something like
>
>         cd /your/path/to/slugs-installation
>         stat slugs
>
>     if there are not `x` flags visible, then try
>
>         chmod +x slugs
>
>     > 3- Is there an example for having a system with 3-dimention? I am stuck
>     > with how to synthesize even a simple example for it.
>
>     answering this might be easier when your code is available. (read my
>     request in this email above.)
>
>     there might be an example added recently that I missed, but I do not
>     remember there being a 3D example. you can make a 2D example 3D by
>     adding extra rows and columns as expected, e.g., try to modify
>     examples/continuous.py by increasing dimensions of A matrix, U, etc. and
>     providing another interval to `box2poly`.
>
>     ------------------------------------------------------------------------------
>     Check out the vibrant tech community on one of the world's most
>     engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>     _______________________________________________
>     tulip-control-discuss mailing list
>     tul...@li... <mailto:tul...@li...>
>     https://lists.sourceforge.net/lists/listinfo/tulip-control-discuss
>
>