228 lines
9.1 KiB
XML
228 lines
9.1 KiB
XML
La phrase "it is less computationally intensive... the compiler". est mal dite;
|
|
tu peux dire que c'est la methode classique, par exemple, implementee pour
|
|
simulink et aussi Zelus.
|
|
|
|
Rmq:
|
|
|
|
- Les methodes numeriques (centralisees) les premieres ont ete faites
|
|
pour resoudre un probleme initial. dx/dt = f (x(t)) t et x(0) = x0 ou x est un
|
|
vecteur.
|
|
|
|
- La "simulation distribuee" (cad faisant intervenir plusieurs solveurs)
|
|
existe aussi mais pose d'autres problemes: efficacite, convergence. Elle est
|
|
plus difficile a implementer.
|
|
|
|
- Sundials CVODE a une methode centralisee mais avec une implementation de
|
|
manipulation des vecteurs qui peut etre parallele, cad que tous les calculs de
|
|
vecteur/matrice peuvent se faire en parallele. On ne l'utilise pas dans Zelus.
|
|
|
|
p2.
|
|
"we cannot necessarily use "pre"...": a mon avis, le lecteur ne peut pas
|
|
comprendre ce que tu ecris ici. A mon avis, tu peux dire ce qui marche (si je ne
|
|
me trompe pas, pouvoir internaliser le solveur au modele et donc le composer
|
|
avec un observateur qui contient son propre solveur) et ce qui est a faire (si
|
|
je comprends, pouvoir ecrire directement assert dans le code et la compilation
|
|
pour pouvoir co-simuler le modele et ses differents observateurs/assertions.
|
|
Pour le "pre", c'est un point que tu peux mentionner plus loin dans le rapport
|
|
lorsque le lecteur a plus de contexte et de matiere sur ce que tu as fait.
|
|
|
|
Il n'y a pas de numero en bas des pages dans ton texte. Il en faut. Impossible
|
|
de savoir ou on est sinon.
|
|
|
|
section 2. Tu parles de streams (Nat -> V) alors que tu donnes une semantique
|
|
avec des etats. C'est bizarre. Tu ecris pre(s) alors que l'on ne sait pas ce que
|
|
c'est. le
|
|
|
|
```ocaml
|
|
let rec (o, s) = M.f_step(i, M.s0 -> pre(s))
|
|
```
|
|
|
|
n'est pas du caml valide.
|
|
|
|
Que veux-tu dire ? Quel est le type de Simulate(M) ? Je pensais (cf. page
|
|
d'apres) que tu voudrais ecrire:
|
|
|
|
```ocaml
|
|
simulate(M): list(I) -> list(O)
|
|
```
|
|
|
|
Le listing 1 ne correspond pas a la page precedente (ou l'inverse). Pourquoi ?
|
|
|
|
Page d'apres (5 ?).
|
|
|
|
Je ne suis pas fan de l'exemple sincos_discrete() tel que tu l'as ecrit car il
|
|
diverge. Il laisse soupconner que l'on ne peut pas ecrire de schemas numeriques
|
|
avec des streams. C'est faux, en general.
|
|
|
|
En somme, le code listing 2 est un mauvais programme. Il y a une raison
|
|
mathematique liee a l'analyse des poles; je te montrerai a mon retour. Si tu
|
|
veux garder cet exemple de sin/cos, il faut mettre deux integrateurs differents,
|
|
un forward et un backward.
|
|
|
|
Ou alors, il faut faire un discours (plus long) pour expliquer pourquoi c'est
|
|
mieux d'ecrire la forme a temps continu, que justement, elle permet de ne pas se
|
|
casser la tete pour savoir ou et quand mettre un pre. Mais c'est un peu
|
|
orthogonal a ce que tu veux raconter.
|
|
|
|
Discrete models -> Discrete-time models.
|
|
Continuous models -> Continuous-time models.
|
|
|
|
Tu pourras ensuite dire que tu confonds les deux.
|
|
|
|
2.2 la raison de la divergence n'est pas la. Si tu prends un schema backward +
|
|
forward, ca ne diverge pas. Par contre, si tu prends Van der Pol en discret, pas
|
|
fixe, avec un pas trop petit ou trop petit, tu tombes sur nan. Regarde. J'avais
|
|
fait l'exemple (regarde sur le depot; ou refais le).
|
|
|
|
Rmq: sin/cos n'est pas un super exemple pour justifier l'interet de Zelus (ou du
|
|
temps continu en general) car ce systeme est lineaire. Un schema numerique pas
|
|
fixe (donc programmable directement en synchrone) marche bien. C'est plutot
|
|
quand la dynamique est compliquee, non lineaire, qu'il te faut un schema
|
|
numerique plus elabore et que l'expression directe d'un modele a temps continu
|
|
se justifie. La modelisation d'evenement en etat (zero-crossing) le justifie
|
|
aussi. Le cas classique, c'est le modele bang-bang. Tu veux detecter les
|
|
instants ou la temperature passe un seuil. Avec un modele de temps pas fixe, tu
|
|
ne peux pas.
|
|
|
|
avant de donner CNode(...), dit ce qu'est le probleme.
|
|
Qu'est ce qu'un modele M ?
|
|
|
|
```ocaml
|
|
model (i) = o where
|
|
der s = f_der i s
|
|
der o = f_out i s
|
|
```
|
|
|
|
2.3. Tu n'as pas dit/defini ce qu'etait un "initial value problem". Le faire
|
|
(sinon, on ne comprends pas).
|
|
|
|
"the integr node from Listing 2 is another example of a numerical solver
|
|
(albeit not a very good one)"
|
|
|
|
A mon avis, inutile. Que veux-tu dire que tu n'as pas deja dit (on peut calculer
|
|
une approximation de `(der(x)/dt)(t)` a des instants `n * h` (`n in Nat`) par
|
|
`(x - pre(x))/h`?
|
|
|
|
|
|
"Of particular interest is the fact that numerical ODE solvers compute
|
|
approximations sequentially. "
|
|
|
|
Ca depend. Les solveurs a memoire (dits "multi-pas"). Les solveurs sans memoire
|
|
tels que RK, non. A mon avis, tu peux commencer par exempliquer ce que calcule
|
|
un solveur: etant donne le IVP, l'objectif est de calculer une solution
|
|
[0, tmax] -> V. En pratique, il ne calcule pas toute la solution. Il calcule une
|
|
suite de solution pour [0, h0][h0, h1][h1, h2], etc. Relis l'article de
|
|
Chapoutot et al., de memoire, c'est tres bien explique. Sinon, il y a les livres
|
|
jaunes dans l'etagere de mon bureau.
|
|
|
|
"This sequential process gives way to a synchronous interpretation of an ODE
|
|
solver as a discrete node."
|
|
|
|
Qu'est-ce qu'un "discrete node" ?
|
|
|
|
IVP(Y, Y'). Aurait du arriver bien plus tot.
|
|
|
|
dy /dt (t) = f t (y(t))
|
|
y(0) = y0
|
|
|
|
donner l'horizon de temps (par defaut, +infty ?).
|
|
|
|
Je prendrais une autre lettre que "s". (on note s pour "state" en general). "o",
|
|
pour "output" ?
|
|
|
|
La notation pointee est un peu troublante (en math, on la confond avec la
|
|
multiplication. Utiliser une police ad-hoc pour h et u de sorte que s_0.u ne
|
|
soit pas ambigu.
|
|
|
|
mets des numeros de ligne dans ton texte stp. Il y a un style latex pour ca. Ou
|
|
au moins des no. de page.
|
|
|
|
"The ODE solver does not itself introduce discontinuities; the only
|
|
discontinuities in the system are those introduced by the input signal."
|
|
|
|
Avant de dire cela, tu ne parles par d'entrees. Pour le moment, ton systeme
|
|
n'est pas "hybride". C'est une ODE. Tu ne donnes pas d'hypotheses sur f. En
|
|
faut-il ? Lesquelles ?
|
|
|
|
"The simulation of a continuous-time system with an ODE solver is now itself a
|
|
synchronous node:"
|
|
|
|
c'est un point de vue. Puisque la simulation d'un modele a temps continu calcule
|
|
une suite de solutions approchees, ne pourrait-on pas la voir elle meme comme
|
|
une machine synchrone qui...
|
|
|
|
page suivante.
|
|
|
|
Plutot que Signal(V), j'utiliserais un autre nom. Tu as deja un langage qui
|
|
manipule des signaux, non ?
|
|
|
|
Superdense(V) ? En reference aux travaux de Pnueli et al. Puis Edward Lee et al.
|
|
Puis Caspi et al.
|
|
|
|
Superdence(V) = R+ -> Nat -> V avec, a cote, une fonction qui pour chaque t in
|
|
R+, donne le nombre de sauts (relire les articles; j'ai oublie le nom de cette
|
|
fonction). step(t) in Nat.
|
|
|
|
est-ce tres different de
|
|
|
|
Nat -> R+ -> V avec a cote, une fonction qui indique le temps qui s'ecoule pour
|
|
chaque n in Nat ?
|
|
|
|
Dans un des articles de Edward Lee, il explique le type des signaux pour le
|
|
temps continu. Regarde son livre (vert) sur mon etagere.
|
|
|
|
Le texte de cette page (8 ?) est un peu confus.
|
|
|
|
est-ce que les bouts de fonctions sont collees les uns aux autres ?
|
|
|
|
none a le sens de "not yet" ? Comment recolles-tu les morceaux ?
|
|
|
|
(h0, u0) (h1, u1) ... (hn, un)
|
|
|
|
est-ce equivalent a :
|
|
|
|
(h0, u0) none (h1, u1) none none (hn, un) ?
|
|
|
|
A ce stade, tu n'as pas dit ce qu'etait $italic("CNode")(I, O, S_M, S'_M)$. A
|
|
quoi ca ressemble ?
|
|
|
|
Les elements du listing 4 doivent etre donnes dans le texte en maths. Le code
|
|
caml doit etre mis aussi dans le listing 4. Je comprends bien mieux le code que
|
|
les explications ! Sois plus precis dans le texte, ca aidera a comprendre.
|
|
|
|
utiliser hmax plutot que h pour ivp. Eviter les surcharges de noms autant que
|
|
possible.
|
|
|
|
Plutot que "discrete node", utiliser "synchronous machine" ? Le terme "machine"
|
|
est un terme technique des annees 60/70. Cf. articles historiques sur les
|
|
automates et les "sequential machines". Tu peux dire, qui se caraterise par un
|
|
etat initial, une fonction step lisant une entree et produisant une sortie,
|
|
(plus une fonction reset) si tu veux.
|
|
|
|
"Since time is logical in discrete nodes". Un peu trop pedant (et obscur) a mon
|
|
avis. On manipule des suites de valeurs; il n'y a donc pas de temps reel ou
|
|
physique. Le temps est juste la succession des valeurs.
|
|
|
|
Le paragraphe "The question of discrete events..." est un peu confus. Donne un
|
|
exemple. E.g., un timer: un controleur ouvre un robinet pendant 4s; une lumiere
|
|
doit clignoter en alternant allume/eteint 1s/2s. ce sont des cas ou il y a des
|
|
evenements en temps, cad en reference a la variable t (der t = 1 init 0).
|
|
D'autres evenements ne sont pas des evenements en temps. E.g., une roue qui
|
|
tourne (e.g. volant moteur). Compter le nombre de tours de roue par seconde avec
|
|
un capteur. Le schema general est dit de "Zero-crossing". Etc. La balle qui
|
|
rebondit, etc. Tu en trouveras d'autres !
|
|
|
|
|
|
La suite est pas mal. Il faut expliquer (et possiblement donner le code, au
|
|
moins en annexe) pour 2.5, 2.6, 2.7.
|
|
|
|
Ca prend forme. Tu peux donner l'intuition de la compilation. Dans le source, on
|
|
melange les der, present, up, etc. et le compilo., apres une analyse statique
|
|
(qui va verifier des proprietes et donc rejeter certains programmes), va
|
|
produire les differentes fonctions necessaires a la simulation qui alterne des
|
|
phases d'integration (le temps ronronne) et des pas discrets (reactions
|
|
instantanees).
|
|
|
|
Super. Continue ! --Marc
|
|
|
|
|