Dans "Informations sur la Continuité Ecologique - ICE; Evaluer le franchissement des obstacles par les poissons; Principes et méthodes" (ICE, page 171, 173 du PDF), il est écrit :
"D’autres critères dimensionnels que ceux analysés dans le cadre du protocole ICE peuvent également
être importants suivant les types de dispositifs (dimensions des déflecteurs, largeur des bassins, dimensions des orifices, taille des ralentisseurs et longueur de volées...). Ils ne seront pas analysés dans le cadre de ce pré-diagnostic et devront être vérifiés lors de l’expertise finale, en se référant notamment aux guides techniques de dimensionnement"
Est-ce que Cassiopée v3 intègre ces critères ? Sinon, quels sont les "guides techniques de dimensionnement" dans lesquels on peut les trouver ?
By Mathias Chouet on 2020-03-30T11:18:49 (imported from GitLab)
OK il y a en effet un tableau par passe, mais quand tu dis "Les critères spécifiques au type de dispositif sont déjà intégrés dans les limites qu'on a imposé sur nos outils" je pensais que tu parlais de ceux-ci justement. À bien les regarder je n'ai pas l'impression que beaucoup de ces critères soient déjà intégrés, je vérifierai au cas par cas.
By Mathias Chouet on 2020-03-30T12:04:30 (imported from GitLab)
J'ai l'impression que ça ressemble dans l'esprit à ce que l'on veut faire.
Je crois que ça récupérait les résultats d'un calcul sur un ouvrage de franchissement et que ça regardait la puissance dissipée, la vitesse et le Froude.
Mais c'est différent de ce que propose l'ICE dans l'esprit (Ludo fait des critères OK entre 0. à 1.2 x une valeur cible alors que l'ICE donne des valeurs limites.
Du coup, il faut qu'on valide avec l'OFB ce qu'on est censé faire.
By Dorchies David on 2020-03-30T11:16:44 (imported from GitLab)
le Nub "espèce" aurait éventuellement des champs différents selon le type de passe à vérifier (ex: longueur pour les passes à ralentisseurs, mais pas pour les passes à bassins)
le Nub espèce doit pouvoir charger des modèles, et enregistrer les réglages courants sous forme de modèle
n'est-ce pas un coup à se retrouver avec 250 modèles nommés n'importe comment par les différents utilisateurs ?
faut-il alors avoir une banque de modèles figés dans l'appli, et enregistrer les modèles persos sur l'ordinateur de l'utilisateur ? (vérifier avec electron/cordova que le "local storage" ne pète pas quand on met à jour)
By Mathias Chouet on 2020-03-30T11:40:03 (imported from GitLab)
D'accord. Mais actuellement dans le fichier de session les Nubs enfants (ex: les modèles Espèce enfants d'un Vérificateur) sont irrémédiablement associés à leur parent; pour réutiliser un modèle Espèce dans plusieurs vérificateurs il faudra faire une gymnastique de clonage, qui ne permettra tout de même pas de mélanger dans le même Vérificateur deux modèles Espèce issus de deux sessions. N'est-ce pas limitant ?
By Mathias Chouet on 2020-03-30T11:47:13 (imported from GitLab)
Oui OK je comprends, s'il y a beaucoup de modèles d'espèces ça risque de faire un peu fouillis non ? Mais en effet je vois mal de meilleur et d'aussi robuste moyen.
C'est clair chef !! :)
By Mathias Chouet on 2020-03-30T11:56:15 (imported from GitLab)
Dans Cassiopée 3, il n'y a de vérification que pour les PAR et il y a 4 espèces :
Je doute qu'on en fasse beaucoup plus. Si on s'en tient au IEC, il y en aura 10 au maximum. Si l'utilisateur a besoin d'un truc spécifique, ce sera une espèce qu'il créera et ajoutera lui-même et je doute que dans ce cas, il cumule d'autres espèces dans sa vérification.
Je suppose qu'au max. pour un calcul donné, on vérifie pour 3 ou 4 espèces quoiqu'il arrive.
By Dorchies David on 2020-03-30T12:02:18 (imported from GitLab)
Je ne sais pas si on doit prévoir 3 réponses aux critères comme l'avait fait Ludovic : vert, jaune, rouge. Ou si l'on doit faire du binaire. Des pistes dans l'ICE ?
By Dorchies David on 2020-03-30T12:04:41 (imported from GitLab)
Dans ICE, on trouve des valeurs "min" ou "max", jamais simultanément, et on trouve exceptionnellement le duo "Chute maximale / chute préconisée". Je n'ai pas trouvé de mention d'une marge d'erreur, ni de zone rouge avant disqualification de la passe, mais je vais relire.
By Mathias Chouet on 2020-03-30T14:14:14 (imported from GitLab)
Le résultat de la vérification est un synthèse des conditions des espèces choisies en prenant à chaque fois le critère de l'espèce la plus restrictive.
Il nous faut une structure répétée pour les espèces.
By Dorchies David on 2020-03-30T11:21:46 (imported from GitLab)
Les instances d'especes présentes dans le tableau especes[] sont soit des instances créées lorsqu'on sélectionne une espèce prédéfinie, soit un pointeur vers un Nub Espece présent dans la session.
Dans l'interface graphique cela pourrait revenir à choisir ses espèces dans une liste comprenant les espèces prédéfinies et les nub Espèce trouvés dans la session. (Et on peut ajouter un bouton pour créer son espèce personnalisée qui ajouterait un nub Espece dans la session et créerait le pointeur dans le tableau especes[]
By Dorchies David on 2020-03-31T10:53:49 (imported from GitLab)
Bon y a tout de même un souci pour le Vérificateur, c'est que les valeurs de seuil pour un critère donné sont dépendants de l'espèce bien sûr, mais aussi du type de passe, voire d'une de ses caractéristiques…
Exemple pour le saumon atlantique : la chute maximale dans une PAB à jet de surface est 0.35m, de 0.75m dans une PAB à jet plongeant, et de 0.3m dans une MacroRugo à rangées périodiques (bien qu'on ne gère pas ce type d'ouvrage me semble-t-il)
MacroRugo à rangées périodiques sont effectivement apparentées aux PAB (ICE p.155).
Du coup c'est pas grave en soi, mais pour l'interface graphique ça empêche de charger à l'écran les valeurs des critères lorsqu'on sélectionne une espèce, puisque le module Espece ne connaît pas à l'avance la passe qu'il va devoir vérifier… c'est ballot…
À la place on peut charger les valeurs des critères au moment de calculer la vérification, puisqu'on a la passe à ce moment-là, et conserver les valeurs dans les champs pour le coup suivant, mais c'est un peu nul non ?
Ou alors lorsqu'un espèce prédéfinie est choisie on masque tous les champs ? J'espérais pouvoir faire un choix par sélecteur (comme l'ancienne version de Lechapt-Calmon) qui précharge des critères, pour aider ensuite à créer une espèce personnalisée à partir d'une existante, mais du coup ça semble compromis.
Faisons simple :
dans le vérificateur, on ne sélectionne que l'espèce et on n'affiche pas les critères.
Créons des jeux de données d'espèces prédéfinies lors du calcul avec une fonction especeFactory qui prend en entrée l'espèce et le type de passe et qui peuple une instance d'Espece avec les valeurs correspondantes.
Pour l'instant, une espèce personnalisée est créée vide par défaut. On pourra toujours ajouter un "Wizard" sous la forme d'une dialog box qui demande une espèce et un type de passe et qui nous pré-remplira notre espèce prédéfinie.
By Dorchies David on 2020-04-01T09:34:57 (imported from GitLab)
Bon, on a les données pour les PAB avec différents jets, les PAM et les PAR.
Je ne vois pas comment on peut utiliser la chute préconisée: ça n'est pas une limite. Pour le reste des critères ça me parait OK.
Comment différencie-t-on les deux types de PAB ? En fonction du résultat du type de jet des ouvrages des cloisons de la PAB (c'est un peu chaud si on rencontre plusieurs types de jet dans la passe).
By Dorchies David on 2020-03-31T19:03:54 (imported from GitLab)