Visualiser les détails du résultat
| Identifiant | Projet | Catégorie | Visibilité | Date de soumission | Dernière mise à jour |
|---|---|---|---|---|---|
| 0001064 | SIC | Fortran Régulation | public | 2014-10-01 15:16 | 2014-10-02 18:02 |
| Rapporteur | dorch | Assigné à | dorch | ||
| Priorité | normale | Impact | critique | Reproductibilité | toujours |
| Statut | fermé | Résolution | corrigé | ||
| Version du produit | 5.34b | ||||
| Version ciblée | Priorité 1 | Résolu dans la version | 5.34d | ||
| Résumé | 0001064: Plantage sur prise inactive utilisée dans un module de régulation | ||||
| Description | POM a écrit : Bug du TPRISE lié à une variable utilisée par un module de régulation, mais qui est "inactive". Elle est dispo à l'interface des modules de régulation, mais il y a un moche plantage. Parmis diverses solutions possibles celle que je privilégie est de mettre un message propre dans Sirene et Fluvia, et si éventuellement possible dans Edisic avant l'appel à ces programmes. Mais pas d'interdire la saisie de ces choses dans le module de reg,car on peut les activer-desactiver dans les variantes alors qu'un module est commun au scenario et ses diverses variantes, voir à divers scénarios | ||||
| Étapes pour reproduire | Pour reproduire ce bug, mettre deux prises dans un noeud. Utiliser un module de régulation qui pointe sur la prise n°2 et mettre celle-ci en mode "Inactive". | ||||
| Balises | Aucune balise n'est associée. | ||||
| Temps projeté (jours) | |||||
|
|
Le problème est un tout petit peu plus compliqué qu'il n'y paraît. Car il y a en fait deux problèmes à régler : - Les indices des prises dans le XML et dans le Fortran ne sont pas les mêmes quand il y a des prises inactives (En effet dans le Fortran numérote systématiquement à partir de 1 et ignore les prises inactives). Le risque est de ne pas s'adresser à la bonne prise ou de planter l'appli si une prise inactive est présente. - Quand on essaie d'utiliser une prise inactive dans un module de régulation, il faut arrêter la simulation proprement. Il y a donc 3 choses à faire : - Dans C_REGULATION::LitXmlVarUYZ, il faut convertir le numéro de prise lu pour le régulateur avec la variable tPrise(:)%nNum pour déterminer quel indice de tableau utiliser dans le tableau tPrise. - Toujours dans C_REGULATION::LitXmlVarUYZ, si la correspondance n'est pas trouvée c'est que la prise demandée doit être inactive, il faut donc générer un message d'erreur adéquat et faire renvoyer .FALSE. par la fonction. - Vérifier pour Fluvia et Sirene qu'un renvoie de .FALSE. par la fonction C_REGULATION::LitXmlVarUYZ remonte correctement jusqu'au programme principal et que le programme s'arrête proprement. |
|
|
Dans REGUL.N04L |
| Date de modification | Nom d’utilisateur | Champ | Changement |
|---|---|---|---|
| 2014-10-01 15:16 | dorch | Nouveau bogue | |
| 2014-10-01 15:16 | dorch | Statut | nouveau => affecté |
| 2014-10-01 15:16 | dorch | Assigné à | => dorch |
| 2014-10-01 15:50 | dorch | Note ajoutée: 0001046 | |
| 2014-10-02 16:13 | dorch | Note ajoutée: 0001049 | |
| 2014-10-02 16:13 | dorch | Statut | affecté => fermé |
| 2014-10-02 16:13 | dorch | Résolution | ouvert => corrigé |
| 2014-10-02 16:13 | dorch | Résolu dans la version | => 5.34c |
| 2014-10-02 18:02 | dorch | Résolu dans la version | 5.34c => 5.34d |
