Feature #3905
closed
La TM_KCOEFF_DUMP n'a plus la structure dédcrite dans l'ICD
Added by bruno katra about 3 years ago. Updated almost 2 years ago.
0%
Description
L'ICD précise qu'un KCOEFF_DUMP contient :
n blocs de [KCOEFF_FREQ + 32xKCOEFF] où KCOEFF_FREQ est un UINT16 et KCOEFF des floats.
Or dans FSW > 3.3 : le paramètre KCOEFF_FREQ n'a plus de sens et son espace est utilisé pour stocker directement des floats.
Les conséquences :
- Il faut mettre à jour la decom LFR (Bruno) : en cours fait!
- Le bouton du LFR GSE pour dumper les KCOEFF n'est plus utilisable car elle décommute à la volée selon l'ICD et donc lit 1 float sur 32 comme un entier 16 bits
- Le champ BLOCK_NUMBER qui est 30 ou 6 (selon que c'est le 1er ou le 2eme paquet de KCOEFF_DUMP) n'est plus applicable, on pourrait le modifier pour qu'il donne le nombre de float à lire (changer les DEFINE dans le code du FSW) : Alexis > FAIT Il va falloir prévenir Plasson ou Leeroy pour modifier l'ICD avec les remarques ci-dessus car le segment sol du LESIA l'utilise pour nous générer les L1 : Bruno
Related issues
Updated by bruno katra about 3 years ago
- Related to Bug #3908: Taille des paquets KCOEFF_DUMP en FSW >=3.3 added
Updated by bruno katra about 3 years ago
- Description updated (diff)
- Assignee changed from bruno katra to Alexis Jeandet
- Priority changed from High to Urgent
ll faudrait changer les 2 DEFINE du code du FSW qui contiennent le champ BLOCK_NUMBER : Les DEFINE sont actuellement à 30 et 6, il faudrait les mettre à 676 et 338.
Cela devrait résoudre l'issue 3908.
Updated by bruno katra about 3 years ago
- Status changed from New to In Progress
Pb #3911 : le champs blk_number est un octet, on ne peut pas stocker 676 et 338.
Discuté avec Alexis : le BLOCK_NUMBER pourrait contenir le nombre de floats/26 (26= nombre de floats pour 1matrice B + 1 matrice E).
L'ICD serait modifié avec juste la modification du champs en jaune :
/SOURCE_DATA/Repeated N times, with N in [0..PA_LFR_KCOEFF_BLK_NR[
deviendrait
/SOURCE_DATA/Repeated N times, with N in [0..PA_LFR_KCOEFF_BLK_NR*26[
+
/SOURCE_DATA/[...]/LFR_KCOEFFICIENTS_PARAMETERS qui contient actuellement une structure 1UINT16 + 32 floats
deviendrait juste 1 float
A proposer à Plasson + Xavier
Updated by bruno katra about 3 years ago
- Related to Bug #3911: KCOEFF_DUMP : champ PA_LFR_KCOEFF_BLK_NR faux added
Updated by bruno katra about 3 years ago
- Assignee changed from Alexis Jeandet to bruno katra
Il faut maintenant prévenir le LESIA
Updated by bruno katra almost 3 years ago
- Related to Bug #3916: Les valeurs reportées dans le KCOEFF_DUMP ne sont pas comme attendues. added
Updated by bruno katra almost 3 years ago
Partant de la résolution de #3916, voici une nouvelles proposition "plus élégante" pour la mise à jour de l'ICD et la définition du champs PA_LFR_KCOEFF_BLK_NR :
le champs PA_LFR_KCOEFF_BLK_NR pourrait contenir le nombre de couple de matrices B/E pour un bin donné.
Il serait donc égal à 26 pour le 1er paquet et 13 pour le 2ème : ça tient dans un uint8.
Pour Alexis cela revient juste à changer les 2 DEFINE dans le code.
Côté ICD, il ne faudrait modifier que la partie :
/SOURCE_DATA/[...]/LFR_KCOEFFICIENTS_PARAMETERS qui contient actuellement une structure 1UINT16 + 32 floats
et qui deviendrait :
B11_real FLOAT
B11_ima FLOAT
B12_real FLOAT
B12_imag FLOAT
....
B33_ima FLOAT
E11_real FLOAT
E11_ima FLOAT
....
E22_ima FLOAT
Cette représentation est plus pertinente et plus structurée qu'une suite de floats.
Au niveau L1 cela permettra des CDF plus pertinent et auto consistants.
A proposer à Philippe Plasson et Leeroy.
Updated by bruno katra almost 3 years ago
- Related to Task #3918: Mise à jour des 2 DEFINE PA_LFR_KCOEFF_BLK_NR pour le KCOEFF_DUMP added
Updated by bruno katra over 2 years ago
Teleconf avec Leeroy, Diane et Xavier du LESIA le 29 mars 2022 :
On ne peut pas toucher au nombre de float de la structure de l'ICD car impact IDB. Idem, la suppression du UNSIGNED KCOEFF_FREQUENCY n'est pas souhaitable car impact IDB
Par contre, on peut mettre en SPARE certains champs, juste un impact sur les labels + range min/max
Proposition LPP pour la TM_KCOEFF_DUMP :
- on garde le KCOEFF_FREQUENCY et on y met le numéro de BIN
- On n'utilise que 26 floats sur les 32,les autres sont basculés en SPARE.
Il faut harmoniser les labels avec la TC_LOAD_KCOEFF. Voir #3944
Updated by bruno katra over 2 years ago
- Related to Task #3944: Modif de la TC_LOAD_KCOEFF : ICD + LFR FSW added
Updated by Alexis Jeandet over 2 years ago
https://github.com/LaboratoryOfPlasmaPhysics/LFR_Flight_Software/commit/9e4e76d3a5f5c54587fb2c23aff08f5caf3696d6
Normalement il y a des blocks composés de:
- 1 int16 pour l'index
- 26 floats avec les matrices
- 6 floats à 0 pour "bourrer"
Updated by bruno katra over 2 years ago
Alexis Jeandet wrote in #note-14:
J'ai push une version avec le bon layout:
https://github.com/LaboratoryOfPlasmaPhysics/LFR_Flight_Software/commit/9e4e76d3a5f5c54587fb2c23aff08f5caf3696d6
Normalement il y a des blocks composés de:
- 1 int16 pour l'index
- 26 floats avec les matrices
- 6 floats à 0 pour "bourrer"
Ok merci, t'es allé vite ! Je pensais soumettre les propositions de changement au LESIA d'abord et qu'ils valident de leur côté, vu qu'ils sont un peu titilleux...
Je mets de côté pour l'instant, si le LESIA valide je testerai directement comme ça.
Du coup, effet de bord mineur certes mais bien quand même : le bouton DUMP_KCOEFF du GSE va refonctionner correctement !
Updated by bruno katra almost 2 years ago
- Status changed from In Progress to Closed
Finalement après 10 mois de discussions, le LESIA rejette toutes les demandes de modifs (telecon 13/01/2023), voir mail ci-dessous :
Salut à tous, nous avons une petite teleconf rapide avec LeeRoy et Philippe cet aprem pour refaire le point suite à mon mail ci-dessous.
Concernant le changement des labels prévus niveau TM, Philippe estime après réflexion que cela est trop risqué en terme de régression IDB comparé au gain d'information, il est vrai léger, que ces changements apporteraient. Il préconise plutôt qu'on laisse comme c'est et que l'on fasse un tableau explicite de correspondances 'labels IDB' <-> 'nouveaux labels/fonctions' dans le SUM. Du coup on ne touche aucun label.
Pour la valeur min/max du champs TM KCOEFF_FREQ, le risque est moins élevé mais comme il y a un flou si cette valeur est utilisée en aval (ROC, ESA, ...), il y a toujours un risque de régression. Alexis et moi avons proposé comme solution alternative de recompiler le logiciel de vol LFR en cours de validation pour remettre des valeurs qui sont dans l'intervalle actuel donc sans modifs IDB. Philippe et LeeRoy nous ont laissé évalué si cela était acceptable (car cela entraine une nouvelle version du FSW) ou si ils tentaient la mise à jour IDB.
Après discussions avec Alexis : on opte pour la recompilation du FSW LFR avec des valeurs qui sont valides avec le min/max actuel de l'IDB. On prend la responsabilité de ne pas recommencer la campagne de tests intégralement car la modif est plus que minime : on remplace la variable KCOEFF_FREQ (UINT_16) actuelle qui oscille entre 0 et 127 par : constante '0' pour les matrices de passage F0, constante '1' pour les matrices de passage F1,constante '2' pour les matrices de passage F2. Je rejouerai quand même les tests spécifiques sur les KCOEFF puisque c'est la seule portion du code qui est touchée.
Diane et Xavier : pour ce qui est de la livraison prévue le 20/01, nous avons pris du retard suite aux diverses grippes hivernales et à un problème de régression pas sur LFR mais sur le banc de test! (les machines vieillissent ) Le problème semble résolu depuis cette semaine et on a repris le rythme de croisière. Pour faire simple, à l'heure qu'il est et au chausse pied il est peut-être possible de livrer le 20/01 mais on ne peut plus le garantir. Quelles sont les options sans trop de contraintes pour vous ? Il me semble que l'ESA avait parlé d'une indisponibilité de leur côté courant février donc en gros si on ne livre pas le 20/01 on partirait pour fin février/début mars? Si vous souhaitez qu'on en discute de vive voix lundi ou mardi, n'hésitez pas.
Désolé de ce mail un peu long, beaucoup d'évènements ces quelques derniers jours!
Bon week-end à tous.
Bruno