Fix missing ci missing api doc

[maximejay]

Fix #45 and #46

[maximejay]

Pourra-t-on introduire ces changements dans une version 0.5.1 ?

[inoelloc]

• Checker la compile de la doc avant de commit dessus. Je sais que c'est pénible et que ca prend du temps mais je me retrouve à devoir le faire. Sinon, je vais devoir etre plus restrictif sur les tests de doc et pas checker uniquement que ca compile mais aussi les warnings ou les documents qui sont pas inclus dans le toctree.
• Pour ci, il faut qu'on trouve une meilleure solution globale. ci n'est pas un parametre en soit, si on suppose que les parametres sont optimisables. J'aimerais attendre la version 1.0.0 pour trouver une structure correcte à ci.
• Point à verifier, le but de ci est d'avoir une cohérence des flux entre des simulations au pas de temps journalier et horaire (ou autre). Je ne sais pas si dans un cas de validation, il ne vaut mieux pas laisser ci etre recalculée sur la période donnée que de prendre la valeur de la période de calage ?

[maximejay]

• C'est compliquer de faire toute ces manip.... peut-être tu devrais nous faire une petite formation doc ? Par exemple la doc je ne sais pas comment ca fonctionne et j'oublie forcément des choses.( Je l'avais pourtant tout bien préparer et vérifieé dans un commit précédent (que j'avais oublié de pousser avant le merge...), du coup là, j'ai oublié...) Déso ..

• Pour Ci, je ne suis pas d'accord avec toi. Ci est un paramètre du modèle. Qu'on le calle ou qu'on le fixe, c'est un paramètre. De plus sa valeur est fonction de la période temporelle sur laquelle on travaille. Elle est censée devenir stable si on travail sur des périodes temporelles suffisement longues. Comme on ne va pas analyser une fenêtre temporelle longue à chaque fois que l'on veut faire un run, ce paramètre doit être calé ou calculer sur une période temporelle on l'on dispose d'observations. Cela doit être fait sur la période utilisée pour le calage des autres paramètres. Il faut donc pouvoir récupérer cette valeur, c'est pour cela que je l'ai mis dans la liste des paramètres. Je considère donc que c'est un bug et que mes simu sont faussés car je n'utilise pas le bon Ci par rapport aux paramètres calés par Truyen. Je pense donc que c'est très bien comme tu l'a fait, ne change pas, corrigeons juste les bug dans un premier temps. Par défaut, on empèche juste le calage de Ci (cela à du sens car il est auto-calculé). Mais c'est bien de laisser la souplesse de pouvoir le caller si besoin (pour faire des expériences jumelles par exemple, pour analyser des changement de Ci dans des perspectives de changement climatique etc...). Il faut garder un code le plus souple possible, c'est au modélisateur de l'utiliser avec soin :)

• Pour ta question sur les flux, j'intuiterais que la valeur de Ci va dépendre aussi de la valeur des autres paramètres qui ont été calé... (notemment la production qui est un opérateur non-conservatif) Mais on peut poser la question à Pierre, peut-être il aura une idée plus précise la dessus.

• Les expériences de calage / validation ne sont pas la seule façon de travailler (même si on en fait une spécialité dans notre unité :) ) Ce modèle hydrologique peut être utilisé de manière opérationnelle ou même de manière événementielle. C'est pour cela qu'il faut être bien rigoureux sur la manipulation des paramètres et des états.

[inoelloc]

Bon pour moi