Task #3877
open
Matrices de passage par défaut pour les ASM : à valider
0%
Description
Oui c'est exactement ça, dans le dernier où avant dernier commit tu trouveras les matrices par défaut générées avec les valeurs de Thomas.
Envoyé depuis mon smartphone Xperia de Sony
---- Bruno KATRA a écrit ----
Salut Alexis et Thomas.
J'ai pensé à un truc : qu'en est-il des KCOEFF par défaut au démarrage
de LFR?
De mémoire, avec l'ancienne implé : tous les coeff étaient à 1.0 au
démarrage.
Mais maintenant que les KCOEFF ne sont plus des KCOEFF mais les
paramètres permettant de calculer les matrices de passage pour les ASM,
je suppose qu'il existe des matrices par défaut au démarrage de LFR et
que donc les KCOEFF par défaut ne sont pas des 1.0 mais bien des valeurs
différentes?
Merci
-------------------------------------------------------------
Mapping Discospace :
Analog Discovery 1 : E1/E2
Analog Discovery 2 : B1/B2
Analog Discovery 3 : B3
-------------------------------------------------------------
Files
Related issues
Updated by bruno katra over 2 years ago
- Assignee changed from bruno katra to thomas chust
Afin de faire une première validation des matrices KCOEFF par défaut, ici un jeu de données pour Thomas :
https://ao.lpp.polytechnique.fr/index.php/apps/files/?dir=/LFR/3.3.0.7/PREL-07&fileid=2501641
Il contient les données dans des répertoires avec des noms explicites : il s'agit de données LFR avec une fréquence propre (pour F0, F1 et F2) avec les matrices KCOEFF unitaires puis matrices KCOEFF par défaut pour comparaison.
Ceci afin de faire une première validation rapide.
Des tests plus précis et exhaustifs (avec déphasage, plusieurs fréquences ....) seront constitués ensuite et ajoutés à la SVS.
Il y a une nouvelle DECOM à utiliser pour le FSW 3.3 à partir de maintenant.
Elle est ici :
https://hephaistos.lpp.polytechnique.fr/redmine/attachments/5284
Updated by bruno katra over 2 years ago
bruno katra wrote in #note-1:
Afin de faire une première validation des matrices KCOEFF par défaut, ici un jeu de données pour Thomas :
https://ao.lpp.polytechnique.fr/index.php/apps/files/?dir=/LFR/3.3.0.7/PREL-07&fileid=2501641
Il contient les données dans des répertoires avec des noms explicites : il s'agit de données LFR avec une fréquence propre (pour F0, F1 et F2) avec les matrices KCOEFF unitaires puis matrices KCOEFF par défaut pour comparaison.
Ceci afin de faire une première validation rapide.
Des tests plus précis et exhaustifs (avec déphasage, plusieurs fréquences ....) seront constitués ensuite et ajoutés à la SVS.
Il y a une nouvelle DECOM à utiliser pour le FSW 3.3 à partir de maintenant.
Elle est ici :
https://hephaistos.lpp.polytechnique.fr/redmine/attachments/5284
ATTENTION : les signaux sont triggés 4s après le passage de LFR en mode NORMAL donc il ne faut pas prendre la 1ere ASM du jeu de données !
Aussi , les signaux sont envoyés sur E1, E2, B1, B2 et B3.
Updated by thomas chust over 2 years ago
- Assignee changed from thomas chust to bruno katra
Bruno, j'ai quelques éléments supplémentaires:
- à F0 le cas le plus chahuté, les termes non-diagonaux (cross-correlation), à la différence des termes diagonaux, sont variables au cours du temps, et en plus ne sont pas proches de nombres réels purs (i.e., ne correspondent pas à des phases relatives entre les signaux de 0°). C'est cela qui expliquerait les écarts observé au cours du temps, c-à-d entre les différentes matrices, car la calibration implique les termes non-diagonaux.
- à F1 où tout semble parfait sur les termes diagoanaux, les termes non-diagonaux (cross-correlation) valent exactement 0 (cas des KCOEFF unitaires), c'est à dire que tes 5 signaux seraient tous parfaitement incohérent entre eux. Cela sens un bug du coté d'Alexis. Donc ce semblant de perfection serait dû à l'absence de prise en compte des termes non-diagonaux ...
- à F2 c'est un peu comme à F0 mais en mon fort: les résultats sont moins chahutés et les termes non-diagonaux sont plus proches de nombres réels purs.
De ton coté, Bruno, est ce que tu peux rejouer la même chose et:
- t'assurer que les phases entre les 5 signaux soit 0° ou à défaut quelque chose de constant
- de faire exactement la même chose pour tous tes runs (rebooter chaque fois au préalable ...) ?
Et toi Alexis, est ce que tu peux jeter un oeil à comment tu traites les termes non diagonaux dans le cas des KCOEFF unitaires, et en particulier pour F=1?
Voili voilà
Thomas
Updated by bruno katra over 2 years ago
thomas chust wrote in #note-3:
De ton coté, Bruno, est ce que tu peux rejouer la même chose et:
- t'assurer que les phases entre les 5 signaux soit 0° ou à défaut quelque chose de constant
Je ne peux pas vraiment m'en assurer mais, Alexis confirmera, par essence même du setup et de comment est fait le Discospace : je configure les 3 cartes nécessaires pour injecter sur E1, E2, B1, B2 et B3 avec la même conf et un trigger externe qu'Alexis a conçu comme une "rampe commune" donc 1 seul signal de trig active toutes les cartes en même temps.
Après on a seulement le fait que les 3 cartes peuvent avoir des horloges qui sont infimement différentes.
Je rajoute dans le sujet de cet issue le mapping.
- de faire exactement la même chose pour tous tes runs (rebooter chaque fois au préalable ...) ?
Je suis en train de refaire les runs pour être sûr.
Et toi Alexis, est ce que tu peux jeter un oeil à comment tu traites les termes non diagonaux dans le cas des KCOEFF unitaires, et en particulier pour F=1?
Voili voilà
Thomas
Updated by bruno katra over 2 years ago
- Description updated (diff)
- Status changed from New to In Progress
Updated by bruno katra over 2 years ago
- Assignee changed from bruno katra to thomas chust
J'ai refait les runs mais en redémarrant LFR entre chaque pour avoir une comparaison idéale :
https://ao.lpp.polytechnique.fr/index.php/apps/files/?dir=/LFR/3.3.0.7/PREL-08&fileid=2504978
Updated by thomas chust over 2 years ago
- File VERIF_LFR_FSW_R3_3_Bruno_20220311.html VERIF_LFR_FSW_R3_3_Bruno_20220311.html added
- Assignee changed from thomas chust to Alexis Jeandet
En attaché mon notebook qui analyse ce nouveau jeu de données. La tendance observée reste la même:
- à F1 les termes non diagonaux valent 0 exactement dans le cas des KCOEFF unitaires; en fait une partie des termes non diagonaux valent aussi 0 dans le cas des KCOEFF par défaut. Donc il y a un bug quelque part, a priori au niveau du produit des matrices (Alexis a priori c'est de ton coté)
- à F0 les résults sont mitigés selon les composantes des ASM (des dérives de phase importante entre les signaux injectés sont observées comme avant et cela pourrait expliquer que les deux runs ne soient pas facilement comparables [KCOEFF unitaires versus KCOEFF défaut])
- à F2 finalement c'est pas mal du tout ! (malgré des dérives de phase entre les signaux injectés; certes dérives qui sont moins importantes étant donné les échelles de temps F2 plus larges que celles pour F0)
Avant d'aller plus loin, il serait bien de corriger le problème bien visible à F1; a priori cela devrait avoir des implication ailleurs ...
Updated by bruno katra over 2 years ago
- Related to Bug #3936: Comparaison/validation FSW 3.2.0.24 vs 3.3.0.7 avec matrices unitaires. added