Ajouter le calcul des courbes de remous

Ajouter la classe CourbesRemous pour la calculette de calcul des courbes de remous

S'inspirer du code source de la calculette actuelle :

• La partie résolution numérique du calcul d'une courbe de remous se trouve dans : https://zone.spip.org/trac/spip-zone/browser/plugins/hydraulic/trunk/hyd_inc/courbe_remous.php
• La partie orchestrant le calcul des deux courbes et leur raccordement avec le calcul du ressaut se trouve dans la méthode calculer de : https://zone.spip.org/trac/spip-zone/browser/plugins/hydraulic/trunk/hyd_inc/form_courbe_remous.class.php

Pour les données d'entrée, on retrouve les paramètres spécifiques aux différents types de section, les paramètres liés au canal (Rugosité, pente) comme dans les calculs hydrauliques d'une section paramétrée et le régime uniforme et le paramètre de précision du calcul. A cela s'ajoute la longueur du canal, le pas d'espace et le choix de la méthode de résolution numérique.

Pour la structuration des données en sortie, la différence par rapport aux calculettes précédentes est que cette calculette renvoie deux séries de résultats : un pour la courbe fluviale et un autre pour la courbe torrentielle et que les deux peuvent exister pour une abscisse donnée. La calculette en ligne propose optionnellement de calculer un des paramètre hydraulique présent dans la calculette section-param pour les deux courbes de remous. On a donc en sortie deux séries de tirant d'eau et optionnellement deux séries d'un paramètre hydraulique calculé (Froude, Vitesse, Impulsion...). Ces différentes sorties servirons dans ngHyd à afficher un tableau avec 3 ou 5 colonnes correspondant aux abscisses et aux 2 ou 4 variables à afficher, un graphique représentant les deux courbes de remous et un graphique optionnel représentant le paramètre hydraulique calculé en fluvial et torrentiel.

Dans les sorties, il faut aussi gérer un journal de calcul qui va afficher des informations, des warnings et des erreurs fatales qui peuvent intervenir en cours de calcul. Je vois qu'il y existe déjà une classe log inutilisée chargée de ce travail. Je pense qu'elle devrait se trouver à un niveau supérieur et n'être pas seulement dévolue aux sections. Il faut aussi penser à l'internationalisation et je pense donc qu'elle ne devrait servir qu'à archiver dans un tableau les codes de message et des valeurs associées sachant que ces codes et valeurs seront traduits intelligiblement et dans la langue demandée dans nghyd.