Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 14:14
    schillic opened #177
  • 14:14

    schillic on abstractinterval

    generalize to AbstractInterval (compare)

  • 13:26

    mforets on gh-pages

    build based on 17b25d7 (compare)

  • 12:46

    mforets on lgg09_symbol

    (compare)

  • 12:46

    mforets on master

    add test Update LGG09.jl Merge pull request #555 from Ju… (compare)

  • 12:46
    mforets closed #555
  • 11:20

    mforets on gh-pages

    build based on 93fab9b (compare)

  • 11:09

    mforets on gh-pages

    build based on 3947b22 (compare)

  • 10:37
    mforets synchronize #555
  • 10:37

    mforets on lgg09_symbol

    Update LGG09.jl (compare)

  • 10:24

    mforets on homogeneize

    (compare)

  • 10:24

    mforets on master

    update homog methods updates homog Merge pull request #556 from Ju… (compare)

  • 10:24
    mforets closed #556
  • 05:22
    schillic review_requested #2879
  • 04:33
    schillic synchronize #2879
  • 04:33

    schillic on exponential_map

    concrete exponential map add concretize for ExponentialM… (compare)

  • 03:46

    mforets on gh-pages

    build based on ba9fb8a (compare)

  • 03:42

    mforets on gh-pages

    build based on 5c7deae (compare)

  • 03:02
    mforets opened #556
  • 03:01
    mforets opened #555
Christian Schilling
@schillic
the time you show here is just the doctests. the building happens in the first command and does not print the time (you should have gotten the result of time for everything at the very end)
also, you are only showing the time for the plot tests and doctests. there are a lot more of them
what is true is that most of the time is spent in precompilation. running the tests a second time is fast
Marcelo Forets
@mforets
:thumbsup:
Christian Schilling
@schillic
building the docs takes 5:30 and running the tests takes 11:00 on a github server
Christian Schilling
@schillic
Christian Schilling
@schillic
the time for using LazySets increased by 2 seconds compared to v1.6.1 :(
Marcelo Forets
@mforets
ohh
2 seconds is a lot. you tried v1.7 the other day. it also has that additional latency? (i guess so? )
there is supposed to be a workshop / talk about how to use tools to reduce latency
Christian Schilling
@schillic
in v1.7.0-beta3.0 it's 1 second faster compared to v1.6.2 :)
Marcelo Forets
@mforets
the workshop It's all Set: A hands-on introduction to JuliaReach
has been announced
and also the minisymposium Set Propagation Methods in Julia: Techniques and Applications
https://pretalx.com/juliacon2021/talk/DRMPLU/
Christian Schilling
@schillic
@mforets: about the recent segmentation fault when building the docs: it's not just us: JuliaPolyhedra/Polyhedra.jl#265
Marcelo Forets
@mforets
i feel like adding the content of the notebooks to the packages docs
i also like the guided introduction to NNA
can we also trim the youtube video? i mean, the last 15 mins with the NNA presentation
so we can link that directly from the NNA docs
Christian Schilling
@schillic
:+1:
Marcelo Forets
@mforets
FYI there is a #set-propagation discord channel for JuliaCon
Marcelo Forets
@mforets
during the w.e. i plan to continue working on the RA docs revamp
i think we should update the names of the section in a better way
it might be like this:
  • Linear methods (which explains reach-sets, flowpipes, etc in the context of ivps with set initial conditions of the form x' = Ax )
  • Handling inputs sets (not sure about the section name. this is about linear systems with non-deterministic inputs).
  • Taylor models methods
  • Hybrid systems
  • Clocked systems
  • Exploiting structure (which goes at depth into different use cases of LGG09, BFFPSV18)
    • ... the list continue
the motivation to separate "Linear methods" wrt systems with inputs is to introduce the set propagation concepts incrementally
Christian Schilling
@schillic
"nondeterministic linear systems"?
or "with uncertainties"
Marcelo Forets
@mforets
perfect
Marcelo Forets
@mforets
a blog post on julia ecosystem statistics: https://julialang.org/blog/2021/08/general-survey/
Marcelo Forets
@mforets
Ellipsotopes!
Marcelo Forets
@mforets
Luca has added an explanation about solving interval linear systems with LazySets, https://juliaintervals.github.io/IntervalLinearAlgebra.jl/dev/explanations/solution_set/#Oettli-Pr%C3%A4ger-theorem
Marcelo Forets
@mforets
FYI the new version of the RFEM article is available on arxiv, https://arxiv.org/pdf/2105.05841.pdf
pastankaitis
@pastankaitis
Hi all, I totally new to JuliaReach and trying to use it for computing reach sets of hybrid systems (specifically simple water tank model). But encountered few issues is there some could help with those or where would be the best place to ask for advice? Thank you
Marcelo Forets
@mforets
Welcome, here is a good place to ask. Do you have a example code, or the model described in other format?
pastankaitis
@pastankaitis
Hi @mforets. I just uploaded the current version of the water tank model to https://github.com/pastankaitis/WaterTank.git. I mostly used your spacecraft model (but looked at others too) as guiding example for the development. I'm getting this error "LoadError: BoundsError: attempt to access 1-element Vector{TaylorN{Float64}} at index [2]" but not sure what could the problem :) Thanks for any help!
Marcelo Forets
@mforets
Thanks for sending your model. In the dynamic equation for the stable mode I think there's a typo:
@taylorize function stable!(du, u, p, t)
    # differential equations for the stable water tank mode
    du[1] = 0
    du[2] = 0
    du[1] = 0 # < du[3] = 0 ?
    return du
end
Apart from that, due to a current limitation in the way @taylorize works, please substitute all right-hand sides which are numeric constants with zero(u[1]) or one(u[1]). For example,
For example, the equation for the filling mode should read:
@taylorize function stable!(du, u, p, t)
    #differential equations for the stable water tank mode
    du[1] = zero(u[1])
    du[2] = zero(u[1])
    du[3] = zero(u[1])
    return du
end

and for the filling mode,

@taylorize function filling!(du, u, p, t)
    d_in, d_out, h = u
    #differential equations for the filling water tank mode
    du[1] = one(u[1])
    du[2] = zero(u[1])
    du[3] = d_in
    return du
end

etc

Marcelo Forets
@mforets
I also noted something strange in the definition of the hybrid automaton, namely that two transitions have the same source/destination modes, and also the same label. I copy them here:
    # transition "stable" -> "normal"
    add_transition!(automaton, 1, 2, 1)
    #guard_1 = HalfSpace(h >= 0, var)
    t1 = @map(h -> h, dim: 3)

    # transition "normal" -> "filling"
    add_transition!(automaton, 2, 3, 2)
    guard_2 = HalfSpace(h <= V_saf_min, var)
    t2 = @map(h -> h, dim: 3, h ∈ guard_2)

    # transition "normal" -> "emptying"
    add_transition!(automaton, 2, 3, 2)
    guard_3 = HalfSpace(h >= V_saf_max, var)
    t3 = @map(h -> h, dim: 3, h ∈ guard_3)
In the add_transition! annotations, the integer arguments correspond to the source (resp target nodes), while the final argument is just a label (tag) for the transition.
So 2, 3, 2 should be repeated. It is possible to have more than one transition between the same pair of source/node modes, but from your comment in the code, and given that
modes=[stable_mode, normal_mode, filling_mode, emptying_mode]
Then I expect to see something more like:
    # transition "stable" -> "normal"
    add_transition!(automaton, 1, 2, 1)
    #guard_1 = HalfSpace(h >= 0, var)
    t1 = @map(h -> h, dim: 3)

    # transition "normal" -> "filling"
    add_transition!(automaton, 2, 3, 2)
    guard_2 = HalfSpace(h <= V_saf_min, var)
    t2 = @map(h -> h, dim: 3, h ∈ guard_2)

    # transition "normal" -> "emptying"
    add_transition!(automaton, 2, 4, 3)
    guard_3 = HalfSpace(h >= V_saf_max, var)
    t3 = @map(h -> h, dim: 3, h ∈ guard_3)

Does that make sense?

Another thing that I noticed is that the automaton begins at the "stable" mode, and the dynamics is zero, so I'm not sure that it will eventually take a transition. I may be wrong, but perhaps it's good if you revise the model with my previous comments, then we continue discussing how to obtain the reachability solution.

Marcelo Forets
@mforets
Looking further, I saw that the @map macro with a constrained set is ignored, in fact there is an unresolved issue about that (https://github.com/JuliaReach/MathematicalSystems.jl/issues/198#issuecomment-909562237)
With those changes, the transitions part looks like this (note that I also added a "universal" constraint to the first transition; since it is required at the moment).
    # transition "stable" -> "normal"
    add_transition!(automaton, 1, 2, 1)
    guard_1 = Universe(3)
    t1 = ConstrainedIdentityMap(3, guard_1)

    # transition "normal" -> "filling"
    add_transition!(automaton, 2, 3, 2)
    guard_2 = HalfSpace(h <= V_saf_min, var)
    t2 = ConstrainedIdentityMap(3, guard_2)

    # transition "normal" -> "emptying"
    add_transition!(automaton, 2, 4, 3)
    guard_3 = HalfSpace(h >= V_saf_max, var)
    t3 = ConstrainedIdentityMap(3, guard_3)
Marcelo Forets
@mforets
Another comment: if you plan to be working with linear hybrid automata, then I strongly suggest that you learn and use the linear solvers.