Prébarrage : puissance dissipée négative

Reproduction :

• ouvrir la calculette Prébarrage avec les valeurs par défaut
• mettre le débit à 12
• calculer

assigned to @david.dorchies

By Grand Francois on 2022-05-06T11:24:22 (imported from GitLab)

changed milestone to %Version 4.17.0

added bug label

removed milestone %Version 4.17.0

Bug non reproductible sur ma machine avec Firefox / Windows.

By Dorchies David on 2022-10-12T13:57:02 (imported from GitLab)

closed

reopened

Problème reproduit avec les paramètres suivants :

• nb de décimales affichées : 3
• précision de calcul 1e-7
• nombre d'itérations solveur : 5

résultat : Q = -171000.

Mettre le nombre d'itérations à 100 donne Q=399.8.

By Grand Francois on 2022-10-12T17:00:31 (imported from GitLab)

Tout s'explique !

Bon le soucis c'est qu'il manque un message d'erreur ou un warning indiquant que le calcul n'a pas convergé.

By Dorchies David on 2022-10-12T17:00:31 (imported from GitLab)

La non convergence est censée être traitée avec un warning (cf. jalhyd#275 (closed)).

• Vérifier que l'avertissement est généré côté jalhyd
• Si l'avertissement est généré, corriger nghyd pour que l'avertissement s'affiche.
• Si pas d'avertissement, corriger jalhyd (et migrer ce ticket dans jalhyd).

By Dorchies David on 2022-10-12T17:05:30 (imported from GitLab)

added To Do label

assigned to @francois.grand and unassigned @david.dorchies

By Grand Francois on 2022-10-28T11:14:02 (imported from GitLab)

@francois.grand

il ne semble pas que ça soit un pb de non convergence dans jalhyd. je suis en train d'essayer de comprendre pq les résultats varient en fonction du nombre d'itérations...

Le nombre d'itération et la précision du calcul interviennent à deux niveaux dans le module Pré-barrage :

1. Au niveau du calcul des côtes amont (Z1) des PbCloisons
2. Au niveau du calcul d'équilibrage des débits du PreBarrage

A chaque itération de calcul de convergence de la phase 2, on relance un calcul de convergence de la phase 1.

Cependant, après quelques tests, j'ai l'impression que j'ai figé dans le code le nombre d'itérations de calcul de la phase 2. Ce qui peut te faire penser que le problème ne vient pas du nombre d'itérations.

Sur l'exemple de session fourni dans jalhyd#275 (closed), mettre la précision de calcul à 1E-7. On voit apparaître un avertissement de non convergence qui concerne la convergence de la phase 2 uniquement. Si on réduit le nombre d'itérations à 10, le calcul renvoie des hauteurs d'eau négative dans les bassins et il n'y a aucun message d'avertissement ou d'erreur.

Du fait du ticket jalhyd#275 (closed) je suppose que j'ai du mettre un try/catch qui étouffe les erreurs sur la phase 1 de calcul et qui ne remonte donc pas les erreurs de convergence au niveau des PbCloisons. Du coup, si on diminue le nombre d'itérations:

• les calculs de Z1 de PbCloisons vont être faux
• le calcul de la phase 2 sur PreBarrage peut bien converger si il a son propre nombre d'itérations figé
• Aucun avertissement de non convergence n'est remonté
• Le résultat est pourri du fait de calcul de cote dans les PbBassins loin de la réalité (Cote Z de PbBassin = moyenne des cotes amont Z1 des PbCloisons aval)

Je pense que la non convergence de calcul sur une PbCloison est rédhibitoire et devrait déclencher une erreur comme dans le cas d'un calcul de cote amont sur une Cloison ou un ParalelStructure. Cependant, il faut que les erreurs générées par la phase 1 pendant les itérations de calcul de la phase 2 soient étouffées mais qu'à la fin du calcul de la phase 2, les erreurs générées par la phase 1 soient remontées. Si il y a un try catch, il faudrait qu'à la dernière itération de calcul (mais je crois qu'il y a peut-être un calcul de phase 2 qui est relancé à la toute fin), le catch fasse remonter les erreurs plutôt que de les stopper.

By Dorchies David on 2022-10-28T16:17:41 (imported from GitLab)

Ce qui peut te faire penser que le problème ne vient pas du nombre d'itérations.

J'ai dit exactement le contraire :-) (le fait de mettre le nb d'itérations à 5 provoque une erreur, cf. mon commentaire). J'ai dit que la valeur négative de la puissance ne semblait pas reliée à une non convergence.

Du fait du ticket jalhyd#275 (closed) je suppose que j'ai du mettre un try/catch qui étouffe les erreurs sur la phase 1

Les seuls try/catch qui auraient un rapport avec du calcul sont dans Dichotomie.Dichotomie() et Dichotomie.getStartInterval() et on ne passe dans aucun des catch avec Q=12 et niter=5 (en fait on ne passe dans aucun catch dans tout jalhyd avec ces conditions).

By Grand Francois on 2022-10-28T16:49:28 (imported from GitLab)

closed

moved to jalhyd#330 (closed)

By Grand Francois on 2022-11-02T15:29:11 (imported from GitLab)

reopened

created merge request !189 (merged) to address this issue

By Grand Francois on 2022-12-02T08:51:41 (imported from GitLab)

mentioned in merge request !189 (merged)

By Grand Francois on 2022-12-02T08:51:42 (imported from GitLab)

marked this issue as related to jalhyd#330 (closed)

By Grand Francois on 2022-12-02T10:34:57 (imported from GitLab)

mentioned in commit 070271d5

By Grand Francois on 2022-12-06T15:22:59 (imported from GitLab)

mentioned in commit 96b87a9e

By Grand Francois on 2022-12-06T15:22:59 (imported from GitLab)

mentioned in commit 209be381

By Grand Francois on 2022-12-06T15:22:59 (imported from GitLab)

closed

mentioned in commit 535e848d

By Dorchies David on 2022-12-07T17:33:27 (imported from GitLab)