Visualiser les détails du résultat
Identifiant | Projet | Catégorie | Visibilité | Date de soumission | Dernière mise à jour |
---|---|---|---|---|---|
0001315 | SIC | Exe Sirene | public | 2017-01-17 15:48 | 2019-03-28 20:23 |
Rapporteur | dorch | Assigné à | dorch | ||
Priorité | urgente | Impact | bloquant | Reproductibilité | toujours |
Statut | fermé | Résolution | corrigé | ||
Version du produit | 5.37b | ||||
Version ciblée | 5.37c | Résolu dans la version | 5.37c | ||
Résumé | 0001315: Résultats débit aux prises incorrect si débit piloté par un module en boucle ouverte | ||||
Description | Si on utilise un BOLST (exemple Lez) pour définir le débit sur des prises, dans les résultats apparaissent des débits au prises qui correspondent à celui saisi dans l'interface et pas celui fournit par BOLST. | ||||
Balises | Aucune balise n'est associée. | ||||
Temps projeté (jours) | |||||
|
Le problème se pose sur le Lez, mais je n'arrive pas pour l'instant à le reproduire sur des cas simples. Sur le Lez, le problème semble venir du fait que le débit du bief défluent au as de temps précédent est faux : il est égale à celui du pas de temps en court d'où l'erreur de calcul sur le bilan des masses. |
|
Le problème est corrigé en rendant actif tous les régulateurs BO au premier pas de temps de SIRENE (c'était appliqué uniquement pour FLUVIA jusqu'à présent). Par contre, la validation ne passe pas sur l'ex8 où il y a une commande BOLST avec U relatif sur un débit de prise. La valeur initiale n'est pas prise en compte dans le calcul de la commande relative. |
|
J'ai résolu le problème en doublant l'appel à RegManager avant le premier pas de temps de calcul de Sirene. Je m'explique : Dans Sirene - Au pas de temps initial : - 1er appel à RegManager(.FALSE.) où ne tourne que le module LOI afin de récupérer les valeurs correctes du pas de temps initial défini dans les interfaces - 2ème appel à RegManager où on définit les valeurs de référence et où on fait tourner uniquement les régulateurs BO Dans Fluvia : - 1er appel à RegManager(.FALSE.) où ne tourne que le module LOI afin de récupérer les valeurs correctes du pas de temps initial défini dans les interfaces - 2ème appel à RegManager où on définit les valeurs de référence et où on fait tourner uniquement les régulateurs BO - Les appels suivants se font pour tous les régulateurs. Cette façon de faire permet de faire tourner correctement les cas : - Même régulateur BO utilisé en permanent et transitoire que ce soit en relatif ou en absolu - Régulateur BO uniquement en transitoire en relatif ou en absolu Par contre, le bilan de débit au noeud au pas de temps initial ne sera pas respecté si on utilise des régulateurs BO qui feront que les CI aux prises ne seront pas identiques pour le pas de temps initial du permanent et du transitoire. Pour conclure, il semble nécessaire que les conditions limites aux prises (a priori cote ET débit) soient stockées en temps que conditions initiales pour être sur que le transitoire démarre avec les bonnes CI aux prises. Dans ce cas, il faudra modifier RegManager pour ne pas lancer les régulateurs BO (y compris LOI) au pas de temps initial dans SIRENE. REGUL.N06I FLUVIA2.N13I SIRENEx.N22B |
|
La modification ne passe pas les jeu test sur les exemples avec des modules BO avec U en relatif : les valeurs sont doublées entre autre sur USER et SimLink-Bomat. |
|
Corrigé dans REGUL.N06K Le problème venait du type de variable appliquée quand plusieurs commandes s'appliquent à la même localisation. |
Date de modification | Nom d’utilisateur | Champ | Changement |
---|---|---|---|
2017-01-17 15:48 | dorch | Nouveau bogue | |
2017-01-17 15:48 | dorch | Statut | nouveau => affecté |
2017-01-17 15:48 | dorch | Assigné à | => dorch |
2017-01-17 15:51 | dorch | Note ajoutée: 0001407 | |
2017-01-17 18:05 | dorch | Catégorie | Fortran Qualité/Sédiments => Exe Sirene |
2017-01-17 18:05 | dorch | Résumé | Oscillation de la concentration au noeud sur variation de débit => Résultats débit aux prises incorrect si débit piloté par un module en boucle ouverte |
2017-01-17 18:05 | dorch | Description mise à jour | Voir les révisions |
2017-01-17 23:33 | dorch | Note ajoutée: 0001408 | |
2017-01-18 18:19 | dorch | Note ajoutée: 0001409 | |
2017-01-18 18:19 | dorch | Statut | affecté => fermé |
2017-01-18 18:19 | dorch | Résolution | ouvert => corrigé |
2017-01-18 18:19 | dorch | Résolu dans la version | => 5.37c |
2017-01-30 17:19 | dorch | Note ajoutée: 0001418 | |
2017-01-30 17:19 | dorch | Statut | fermé => retour d'informations |
2017-01-30 17:19 | dorch | Résolution | corrigé => réouvert |
2017-01-30 17:23 | dorch | Note ajoutée: 0001419 | |
2017-01-30 17:23 | dorch | Statut | retour d'informations => affecté |
2017-01-30 17:23 | dorch | Statut | affecté => fermé |
2017-01-30 17:23 | dorch | Résolution | réouvert => corrigé |
2019-03-28 20:23 | dorch | Relation ajoutée | relatif à 0001414 |