Certains paramètres ou résultats liables ne sont pas accessibles depuis certains modules.
Par exemple, la cote de fond aval d'une passe macrorugo n'est pas accessible depuis la plupart des paramètres liés à une élévation. Mais elle est accessible depuis les modules mathématiques qui n'effectuent pas de tri par famille.
Autre exemple, le Strickler équivalent calculé dans la passe macrorugo est liable depuis le régime uniforme mais pas depuis la courbe de remous.
La profondeur d'une passe macrorugo n'est pas liable avec le tirant d'eau du régime uniforme.
Voici ci-dessous le résultat de mes tests effectués à partir de la création d'un module macro-rugo avec les valeurs par défaut et le calcul effectué (Le Strickler équivalent et la cote de fond aval sont des résultats complémentaires inconnus si le résultat n'existe pas):
Cas 1: "la cote de fond aval d'une passe macrorugo n'est pas accessible depuis la plupart des paramètres liés à une élévation"
Module
paramètre
Lien disponible
Bief
cotes de fond (amont et aval)
oui
pente
cotes amont/aval
oui
Loi d'ouvrage
cote de radier d'un ouvrage
oui
Cas 2: "Strickler équivalent calculé dans la passe macrorugo est liable depuis le régime uniforme mais pas depuis la courbe de remous"
Module
paramètre
Lien disponible
Section paramétrée
Strickler
oui
Régime uniforme
Strickler
oui
Courbe de remous
Strickler
non
Bief
Strickler
oui
Cas 3: "La profondeur d'une passe macrorugo n'est pas liable avec le tirant d'eau du régime uniforme."
Module
paramètre
Lien disponible
Section paramétrée
tirant d'eau
non
Régime uniforme
tirant d'eau
non
By Dorchies David on 2022-06-02T19:09:17 (imported from GitLab)
Calcul d'un bief où la pente du fond (If) est une variable cachée et calculée à partir des cotes de fond amont et aval. Un module Régime uniforme est créé et on vérifie que la pente du fond du premier module n'est pas accessible en lien. Voilà qui explique qu'un "paramètre interne d'une section ne devrait pas être liable".
La question est: est-ce que c'est grave de voir apparaître dans les liens une variable qui n'a pas été saisie et est issue du calcul ? A priori, ce n'est pas grave tant que cette variable est consistante.
si ça peut aider, les autres paramètres dont on vire la famille :
bief/If
remous/If
section circulaire/LargeurBerge
section trapèze/LargeurBerge
Le problème concernant ces variables c'est que ce sont des paramètres d'entrée du calcul mais qui sont pré-calculés à partir d'autres paramètres (cotes de fond amont/aval pour If et des paramètres de géométrie des sections pour LargeurBerge). S'ils apparaissent dans les liens, il y a un risque que la valeur affichée ne corresponde à rien si le calcul dans le module source n'a pas été lancé.
Le logiciel couvre actuellement les cas suivants pour les liens:
Paramètres d'entrée
Paramètre en calcul (unique)
Résultats complémentaires
Il n'existe pas de concept qui permette de gérer correctement un paramètre d'entrée caché qui est pré-calculé pour le calcul du module. C'est pour cela qu'on avait décidé de ne pas permettre de lien vers ces paramètres qui, en fonction de la nature du module ou de la section, sont des vrais paramètres d'entrée ou des paramètres pré-calculés à partir d'autres.
By Dorchies David on 2022-06-16T13:16:48 (imported from GitLab)
Réglé en supprimant undefineFamily() et en gérant la non visibilité de Y dans Bief/CourbeRemous.
Cela a comme conséquences :
de ne plus pouvoir créer de lien vers un paramètre caché (intermédiaire).
de provoquer une erreur au chargement de fichiers session contenant ce type de lien. Dans ce cas, l'application passe le paramètre en mode fixé/valeur undefined
cf. jalhyd#289 (closed)/adf6009, #551 (closed)
By Grand Francois on 2022-06-29T17:19:07 (imported from GitLab)