ariadne-cps / ariadne

C++ framework for rigorous computation on cyber-physical systems
http://www.ariadne-cps.org
GNU General Public License v3.0
28 stars 9 forks source link

Plotting when there are auxiliary variables #6

Closed lgeretti closed 7 years ago

lgeretti commented 7 years ago

Originally reported by Luca Geretti (Bitbucket: lgeretti, GitHub: lgeretti)


When using algebraic expressions for dynamics in a given location, plotting with Axes that include such variables fails due to the variables not being found in the corresponding Space.

See the watertank-compositional example.


lgeretti commented 7 years ago

Original comment by Pieter Collins (Bitbucket: pietercollins, GitHub: pietercollins)


Supported auxiliary variables for (hybrid) enclosures.

lgeretti commented 7 years ago

Original comment by Luca Geretti (Bitbucket: lgeretti, GitHub: lgeretti)


First, I think it could be useful to be able to discretize with respect to time, so I would provide the capability.

Second, I agree on the second option. I do not see use cases where mixed operations with subspaces are needed, that cannot be dealt with by rather working on a projection.

As for the HybridFlowTube, I guess every objectification is welcome.

lgeretti commented 7 years ago

Original comment by Pieter Collins (Bitbucket: pietercollins, GitHub: pietercollins)


I have working code for this, but would like some advice as to the semantics of HybridEnclosure operations of discretising and drawing.

For drawing, I think it's clear that we can just have access to all these variables. For discretising (and other set-based operations) I see a number of options:

  1. We could treat the enclosure as lying in one of (state), (state,auxiliary) or (state,time,auxiliary) space. If we want to discretise on a subset of variables, we need to explicity project().
  2. We could say the enclosure is "compatible" with any subset of its variables. This means we could (say) adjoin to a paving with just state variables, or with both state and auxiliary variables.

At the moment, I'm leaning towards saying the space is (state,time,auxiliary) and we must explicitly project() to subspaces. This gives maximal drawing flexibility, and keeps consistency between drawing and discretising.

Note that at some point (soon), I would like to move to using HybridFlowTube, which provides a set (usually empty or singleton) of reachable points given the initial state and the time.

lgeretti commented 7 years ago

Original comment by Pieter Collins (Bitbucket: pietercollins, GitHub: pietercollins)


Currently, only state variables are carried over in the Enclosure, but I think it's worth putting auxiliary variables in as well. This may require changes to the integration routines, so be nontrivial to do.