# Module de décomposition spatiale du débit - Création et implémentation dans le modèle hydrologique J2000P

O Grandjouan, F Branger

► To cite this version:

O Grandjouan, F Branger. Module de décomposition spatiale du débit - Création et implémentation dans le modèle hydrologique J2000P. Projet CHYPSTER - Livrable WP4-1 (version finale), INRAE. 2022, pp.25. hal-05190409

HAL Id: hal-05190409

https://hal.science/hal-05190409v1

Submitted on 28 Jul 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
Projet ANR-21-CE34-0013

CHYPSTER

Programme CES 34 Contaminants, Ecosystèmes et santé AAPG 2021

# Module de décomposition spatiale du débit - Création et implémentation dans le modèle hydrologique J2000P

## Livrable WP4-1 (version finale)

Auteurs : O. Grandjouan¹, F. Branger¹

<table><tr><td>RiverLy</td><td><sup>1</sup> INRAE, unité de recherche RiverLy, Villeurbanne</td></tr><tr><td>ECOLOGIE MICROBIENNE LYON</td><td><sup>2</sup> LEM</td></tr><tr><td>IGE</td><td><sup>3</sup> IGE</td></tr><tr><td>Pacte<br>Laboratoire de sciences sociales</td><td><sup>4</sup> PACTE</td></tr></table>
## Remerciements

Ce rapport a été réalisé dans le cadre du projet de recherche CHYPSTER « Approche intégrée biogéochimique, géographique et hydrologique pour déterminer les sources de contaminants sur des bassins versants d'usage mixte », financé par l'ANR (projet ANR-21-CE34-0013).

Nous remercions Sven Kralisch de l'université FSU Jena pour son appui technique autour de la plate-forme de modélisation JAMS, l'ensemble des membres du groupe J2000 d'INRAE Riverly pour leurs remarques et conseils tout au long du développement, ainsi que Marina Coquery (INRAE/RiverLy) pour la coordination du projet.

## Pour citer ce rapport

Grandjouan, O. Branger, F. (2022). Module de décomposition spatiale du débit - Création et implémentation dans le modèle hydrologique J2000P. Rapport final. ANR CHYPSTER. 25 p.
Résumé

Dans l'objectif de pouvoir utiliser le modèle hydrologique distribué J2000P pour décomposer les écoulements en rivière et notamment tracer les contributions de différentes sources (définies comme des sous-bassins versants élémentaires caractérisés par une empreinte biogéochimique caractéristique, liée notamment aux usages du sol, à la géologie ou à la pédologie), un module de décomposition spatiale a été développé. Ce document présente le principe, l'implémentation et les résultats des tests de validation technique de ce module sur le cas d'application du bassin versant du Ratier.

Mots clefs :

J2000P, module de routage, développement de composante, validation, bassin versant du Ratier.
Table des matières

<table><tr><td>1.Introduction</td><td>5</td></tr><tr><td>2.Méthodologie générale</td><td>6</td></tr><tr><td>3.Étape 1 : Création du modèle autonome d'écoulement dans le réseau hydrographique</td><td>7</td></tr><tr><td>4.Étape 2 : Création et implémentation d'un module de décomposition spatiale du débit dans le modèle autonome</td><td>15</td></tr><tr><td>5.Étape 3 : Validation des résultats du modèle autonome avec le module de décomposition spatiale du débit ReachTracking</td><td>20</td></tr><tr><td>6.Étape 4 : Implémentation du module de décomposition spatiale du débit dans le modèle hydrologique J2000P</td><td>22</td></tr><tr><td>7.Mise à disposition du code</td><td>25</td></tr><tr><td>8.Conclusion et perspectives</td><td>25</td></tr></table>
# 1. Introduction

Le milieu péri-urbain présente des éléments anthropiques qui viennent modifier les chemins de l'eau au sein d'un bassin versant : surface imperméable, réseau d'assainissement, déversoirs d'orage... Leur présence rend difficile la modélisation hydrologique dans de tels bassins. L'autre particularité des bassins versants péri-urbains réside dans la diversité des occupations et des usages des sols (forestier, agricole, urbain...). Cette hétérogénéité du paysage s'accompagne d'un apport d'éléments chimiques et biochimiques important et varié. Différentes sources peuvent apporter une contribution hydrologique au débit total. Ces sources peuvent être caractérisées par des compartiments hydrologiques (souterrain, subsurface, surface) ou des sous-bassins aux occupations ou usages de sols particuliers (forêt, urbain, agricole...). Elles peuvent apporter une contribution diffuse (pâturage, culture...) ou ponctuelle (surverses de réseau d'assainissement) et présentent des empreintes chimiques et biochimiques particulières. Cette diversité des apports biogéochimiques couplée à la modification des chemins de l'eau peut mener à d'importantes perturbations de la qualité des eaux de rivières dans ces bassins et les rendre néfaste pour les écosystèmes aquatiques ou pour l'Homme.

Les modèles hydrologiques distribués sont des outils prometteurs pour estimer la contribution des sources de contamination sur un bassin versant péri-urbain. Ces modèles considèrent des bassins divisés en mailles hydrologiquement homogènes appelées Unités de Réponse Hydrologiques (HRUs). Ces HRUs produisent des écoulements qui sont transférés, via les autres HRUs et les brins de rivière, jusqu'à l'exutoire du bassin. Le modèle hydrologique J2000P (Labbas et al., 2015)<fnref n="1" /> permet actuellement une décomposition du débit total en calculant la contribution des différentes composantes du débit : composante de surface rapide RD1, composante de subsurface RD2, composantes souterraines RG1 et RG2). Mais le modèle J2000P ne permet pas encore la séparation spatiale du débit total en contributions des différents sous-bassins, qui permettrait d'estimer les contributions spécifiques de certaines sources.

Parallèlement les modèles de mélange biogéochimiques sont des méthodes qui permettent de déconvoluer spatialement la masse d'eau à l'exutoire par les contributions des sources par des empreintes chimiques et biochimiques particulières.

Afin de mettre en regard les résultats de cette décomposition du débit par les modèles de mélange biogéochimiques avec les simulations du modèle hydrologique J2000P, il est nécessaire de connaître les contributions des sources considérées calculées par le modèle. L'intégration d'un module de décomposition spatiale du débit peut répondre à cette demande, en permettant de tracer l'origine des masses d'eaux routées de brin en brin jusqu'à l'exutoire. L'objectif d'un tel module est de connaître la contribution d'un ou de plusieurs brins spécifiques au débit total en chaque point du réseau et à chaque pas de temps. Par extension, la contribution

<footnote n="1">¹ Labbas M., Branger F., Braud I. (2015), Développement et évaluation d'un modèle hydrologique distribué pour des bassins périurbains - Application au bassin de l'Yzeron (150 km²). *La Houille Blanche*, 5, 84-91.</footnote>
du brin pourra être interprétée comme la contribution du sous-bassin versant drainé par le brin donné et correspondant à une source particulière. Cette méthode permettra de relier les simulations avec les résultats obtenus à partir des modèles de mélange biogéochimiques.

## 2. Méthodologie générale

La mise en place du module de décomposition spatiale du débit s'effectue en étapes progressives avec la création et le test du module dans des situations simples jusqu'à des conditions complexes, avant l'application dans le modèle hydrologique J2000P. Les étapes principales de la création et de l'implémentation du module sont les suivantes :

* Étape 1 : Création d'un modèle autonome d'écoulement dans le réseau hydrographique

Afin de tester le module dans des conditions simplifiées, un modèle (dénommé ci-après « modèle autonome ») est créé à l'image du modèle J2000P sur le Ratier (Bonneau et al., 2022)<fnref n="2" /> mais composé uniquement du réseau hydrographique fonctionnant de manière autonome. Des débits d'entrée sont attribués à chacun des brins les plus en amont sur le bassin. L'utilisation d'un tel modèle permet de vérifier le traçage des volumes par le module, en comparant les volumes en entrée (connus car attribués manuellement) avec les volumes obtenus en sortie.

* Étape 2 : Implémentation d'un module de décomposition spatiale du débit dans le modèle autonome

Le module de décomposition spatiale du débit est créé et implémenté dans le modèle autonome pour permettre de garder en mémoire l'origine de l'eau et donc de connaitre la contribution d'un ou de plusieurs brins précis en chaque point du réseau et à chaque pas de temps.

* Étape 3 : Validation des résultats du module de décomposition spatiale du débit dans plusieurs conditions

Pour valider les résultats du module, un protocole est appliqué dans différentes conditions, de la situation la plus simple à la situation la plus complexe. La validation de ces résultats permet de confirmer la possibilité d'implémenter le module dans le modèle hydrologique J2000P.

* Étape 4 : Implémentation du module de décomposition spatiale du débit dans le modèle hydrologique J2000P.

Le module est intégré au modèle hydrologique distribué J2000P appliqué au bassin versant du Ratier. L'utilisation de ce module dans le modèle J2000P permet d'estimer la contribution du sous-bassin drainé par le brin tracé au débit total, notamment par le rôle des HRU lors du transfert des volumes d'eau.

<footnote n="2">² Bonneau J., Branger F., Castebrunet H. Lipeme-Kouyi G., 2022. The impact of stormwater management strategies on the flow regime of a peri-urban catchment facing urbanisation and climate change: a distributed modelling study in Lyon, France. *Urban Water Journal (soumis).*</footnote>
### 3. Étape 1 : Création du modèle autonome d'écoulement dans le réseau hydrographique

L'objectif de cette étape est de créer un modèle autonome du réseau de brins de rivière de J2000P sur le bassin versant du Ratier. La figure 1 représente ce réseau composé de 16 brins de rivière. Ce modèle autonome est nommé « J2KP_Ratier_reseau_autonome ». Cette partie décrit le fonctionnement de ce modèle (processus physiques et équations) ainsi que son implémentation informatique (nom des composantes et localisation dans l'arborescence du code source de J2000).

<figure><img src="image_2.png" /><figcaption>Figure 1 - Réseau hydrographique considéré pour la création du modèle autonome (bassin versant du Ratier)</figcaption></figure>

Pour la création du modèle autonome, les contextes suivants sont nécessaires :

* Le contexte principal *J2KP_Ratier_reseau_autonome*

C'est le contexte principal du modèle qui contient tous les autres contextes et les modules utilisés par la suite. C'est un contexte du type JAMScontext où l'utilisateur définit le pas de temps et la durée souhaité pour la simulation. Les contextes qui sont gérés par le contexte principal sont *ParameterInput* et *TimeLoop*.

* Le contexte *ParameterInput*

C'est un contexte de type *JAMScontext* qui contient le module *StandardEntityReader* permettant de lire le fichier d'entrée définissant les brins du réseau et les unités de réponses hydrologiques (HRU), et d'intégrer les données au modèle dans des variables dédiées. A partir du fichier *reach.par*, ce module crée une collection d'entité correspondant aux brins de rivière et défini des connexions entre ces entités à partir de la topologie décrite par le fichier.
* Le contexte temporel *TimeLoop*

C'est un contexte itératif du type *JAMSTemporalContext* qui est exécuté pour chaque pas de temps de la simulation. Il gère l'exécution itérative du contexte *TSInput*, qui effectue une lecture des données de débit attribuées en entrée aux brins amont, et du contexte spatial *ReachLoop*. Il contrôle également l'écriture des résultats de simulation à chaque pas de temps grâce au module *CatchmentResetter* qui remet les valeurs de sortie à zéro au début de chaque pas de temps.

* Le contexte spatial *ReachLoop*

Le contexte itératif *ReachLoop*, du type *JAMSSpatialContext*, est une boucle spatiale qui gère
le fonctionnement et les interactions entre les brins de rivière représentant le réseau
hydrographique, en commençant par les brins les plus en amont jusqu'à l'exutoire en aval. Le
réseau est constitué d'un ensemble de brins caractérisés par des paramètres géométriques et une
topologie. Les connexions entre les entités sont déterminées par le modèle au cours de l'étape
d'initialisation. Dans la boucle spatiale *ReachLoop*, le routage dans la rivière est effectué par le
module de routage *J2KProcessReachRouting*, qui correspond au module le plus important de
ce modèle.

La figure 2 représente l'architecture du modèle autonome et les modules utilisés dans chaque
contexte.

<figure><img src="image_3.png" /><figcaption>Figure 2 – Architecture du modèle autonome (à gauche), modules utilisés (à droite)</figcaption></figure>
Dans le module de routage J2KProcessReachRouting, l'eau est routée de brin en brin selon la topologie définie pour le réseau hydrographique. Le modèle permet de garder en mémoire les types d'écoulements produits (RD1, RD2, RG1, RG2) lors du routage de brin en brin. Au sein de chacune de ces composantes, le mélange des eaux est considéré comme un mélange parfait et indissociable. Le routage de l'écoulement est effectué selon une approche par onde cinématique simplifié. Au début de chaque pas de temps, l'eau contenue dans un brin act(t), est actualisée en ajoutant le volume reçu des brins amont. La somme obtenue correspond au volume total actoTot(t) présent dans le brin au pas de temps t :

$$actTot(t) = act(t) + (t)$$

Le volume sortant d'un brin au temps t est déterminé en fonction de la vitesse d'écoulement $v_i(t)$ qui est elle-même calculée selon l'équation de Manning-Strickler en considérant une géométrie des brins simplifiée (sections rectangulaires). Ce calcul s'effectue par itération jusqu'à ce que la différence entre les vitesses calculées aux itérations i et i-1 soit inférieure à 0.01 m.s⁻¹. Plus précisément, le calcul de la vitesse de l'eau sortant d'un brin à l'itération i s'effectue selon la formule suivante :

$$v_i(t) = \lambda \times \sqrt{\alpha} \times \left( \frac{actTot(t)/v_{i-1}(t)}{L + 2 \times (actTot(t)/v_{i-1}(t) \times L)} \right)^{\frac{2}{3}}$$

avec $\lambda$ la rugosité du brin en m¹/³·Δt¹, $\alpha$ la pente du brin et $L$ la largeur du brin en m.

Le volume sortant du brin au temps t, out(t) est ensuite calculé selon le volume présent dans le brin au pas de temps t, actTot(t) la vitesse calculée v et la longueur l du brin considéré :

$$out(t) = actTot(t) \times e^{\frac{-1}{v/l}}$$

Les différentes contributions routées au brins suivant sont ensuite calculées à partir des proportions des contributions par rapport au volume total et à partir de l'écoulement :

$$\begin{align*} outRD1(t) &= \frac{RD1(t)}{actTot(t)} * out(t) \\ outRD2(t) &= \frac{RD2(t)}{actTot(t)} * out(t) * outRG1(t) = \frac{RG1(t)}{actTot(t)} * out(t) \\ outRG2(t) &= \frac{RG2(t)}{actTot(t)} * out(t) \end{align*}$$

Le volume du brin au temps t est enfin actualisé afin de soustraire le volume sortant du volume total :

$$act(t) = actTot(t) - out(t)$$

La figure 3 illustre le principe du routage du volume de brin en brin dans un exemple de système simple à 3 brins. Le modèle autonome reprend ce principe dans son fonctionnement. Il est à noter que l'ensemble des brins est considéré à sec lors du démarrage de la simulation.
<figure><img src="image_4.png" /><figcaption>Figure 3 – Principe simplifié du routage de brin en brin du volume d'eau par le modèle hydrologique J2000P, repris dans le modèle autonome</figcaption></figure>

## Instance J2KProcessReachRouting

Le principe de routage du volume d'eau de brin en brin est exécuté grâce au module J2KProcessReachRouting instancié dans le modèle. Ce module appartient au package J2K_base.org.unijena.j2k/routing et l'instance s'exécute dans le contexte ReachLoop. A partir des volumes en entrée, l'instance calcule le transfert des écoulements entre les brins. Le tableau 1 récapitule les entrées et sorties de l'instance.

<table><caption>Tableau 1 - Récapitulatif des entrées et sorties de l'instance J2KProcessReachRouting</caption><thead><tr><th>Variables</th><th>R/W</th><th>Type</th><th>Description</th><th>Unit</th></tr></thead><tbody><tr><td>entities</td><td>R</td><td>EntityCollection</td><td>Collection de reaches</td><td></td></tr><tr><td>width</td><td>R</td><td>Double</td><td>Largeur du brin</td><td>m</td></tr><tr><td>length</td><td>R</td><td>Double</td><td>longueur du brin</td><td>m</td></tr><tr><td>slope</td><td>R</td><td>Double</td><td>Pente du brin</td><td>%</td></tr><tr><td>roughness</td><td>R</td><td>Double</td><td>Rugosité du brin</td><td>m<sup>1/3</sup>·Δt<sup>-1</sup></td></tr><tr><td>inRD1, inRD2, inRG1, inRG2</td><td>R/W</td><td>Double</td><td>Flux sortant amont</td><td>L</td></tr><tr><td>channelStorage</td><td>W</td><td>Double</td><td>Eau stockée dans le brin</td><td>L</td></tr><tr><td>actRD1, actRD2, actRG1, actRG2</td><td>W</td><td>Double</td><td>Eau dans le brin</td><td>L</td></tr><tr><td>outRD1, outRD2, outRG1, outRG2</td><td>W</td><td>Double</td><td>Flux sortant du brin</td><td>L</td></tr><tr><td>catchmentRD1, catchmentRD2, catchmentRG1, catchmentRG2</td><td>W</td><td>Double</td><td>Flux à l'exutoire</td><td>L</td></tr><tr><td>simRunoff</td><td>W</td><td>Double</td><td>Ecoulement total à l'exutoire</td><td>L</td></tr></tbody></table>
Les autres modules instanciés dans le modèle autonome sont les suivants :

* Instance *StandardEntityReader*

Le module correspondant se trouve dans le package `J2K_base.org.unijena.j2k.io` et intervient dans le contexte `ParameterInput`. L'instance lit les fichiers d'entrée `reach.par` et `hru.par` et crée les collections d'entité `reaches` et `hru` dans le contexte principal `J2000`. Dans le module autonome, seul les brins de rivières sont considérés et aucune HRU n'est lu par l'instance. Les entités sont reliées aux paramètres définis dans les fichiers d'entrée des brins : identifiant unique (`reachIDAttribute`), paramètres géométriques de l'ensemble des brins de rivière (pente, longueur, largeur, rugosité), paramètre de topologie (`reachTreachAttribute`).

Les connexions entre les entités sont établies de la manière suivante. Si un brin transfère ses écoulements à un autre brin, son paramètre `reachTreachAttribute` prend la valeur de l'identifiant du brin récepteur. Pour le brin exutoire, ce paramètre vaut 0. Les entrées et sorties de cette instance sont récapitulées dans le **tableau 2**.

<table><caption>Tableau 2 - Récapitulatif des entrées et sorties de l'instance StandardEntityReader</caption><thead><tr><td>Variables</td><td>R/W</td><td>Type</td><td>Description</td><td>Unit</td></tr></thead><tbody><tr><td>reachFileName</td><td>R</td><td>String</td><td>Fichier d'entrée des brins</td><td></td></tr><tr><td>reaches</td><td>W</td><td>EntityCollection</td><td>Collection de brins</td><td></td></tr><tr><td>reachIDAttribute</td><td>R</td><td>String</td><td>Identifiant du brin</td><td></td></tr><tr><td>reachTreachAttribute</td><td>R</td><td>String</td><td>Identifiant du brin récepteur</td><td></td></tr></tbody></table>

* Instance *CatchmentResetter*

Permet de remettre les variables catchmentRD1, catchmentRD2, catchmentRG1, catchmentRG2, catchmentSimrunoff et channelStorage à zéro à chaque pas de temps pour obtenir ces valeurs en sortie du modèle pour chaque pas de temps. Le **tableau 3** récapitule les entrées et sortie de cette instance.

<table><caption>Tableau 3 - Récapitulatif des entrées et sorties de l'instance CatchmentResetter</caption><thead><tr><td>Variables</td><td>R/W</td><td>Type</td><td>Description</td><td>Unit</td></tr></thead><tbody><tr><td>attributes</td><td>W</td><td>Double</td><td>Attributs de sortie à modifier (ex : catchmentRD1, catchmentRD2...)</td><td>L</td></tr><tr><td>value</td><td>R</td><td>Double</td><td>Valeur à attribuer (ex : 0)</td><td>L</td></tr></tbody></table>

* Instances `RD1_DataReader`, `RD2_DataReader`, `RG1_DataReader` et `RG2_DataReader` à partir du module `Double Setter`

Ces instances proviennent du module *Double Setter* appartenant au package `jams-components.jams/components.io`. Elles s'exécutent dans le contexte `TSInput` du contexte `TimeLoop` et permettent de lire les fichiers de débit en entrée à attribuer à chaque brin en amont (`input_discharge_RD1.dat`, `input_discharge_RD2.dat...`). Les instances vérifient que les données de ces fichiers recouvrent la période de la simulation choisie par l'utilisateur et que leur pas de temps correspond à celui fixé pour la simulation. Elles sélectionnent également les données sur cette période, lisent les métadonnées du fichier et récupèrent les noms des brins correspondant à chaque série de débit. Le **tableau 4** récapitule les entrées et sorties de ces instances.
<table><caption>Tableau 4 – Récapitulatif des entrées et sorties des instances RD1_DataReader, RD2_DataReader, RG1DataReader et RG2DataReader</caption><thead><tr><th>Variables</th><th>R/W</th><th>Type</th><th>Description</th><th>Unit</th></tr></thead><tbody><tr><td>Id</td><td>R</td><td>String</td><td>Fichier d'entrée des débits</td><td></td></tr><tr><td>timeInterval</td><td>R</td><td>TimeInterval</td><td>Intervalle de temps entre deux lectures</td><td>H</td></tr><tr><td>dataArray</td><td>W</td><td>DoubleArray</td><td>Volume en entrée des brins amont (RD1_array, RD2_array, RG1_array, RG2_array)</td><td>L</td></tr><tr><td>names</td><td>W</td><td>DoubleArray</td><td>Noms des brins</td><td></td></tr></tbody></table>

* Instances `DischargeRegionalizer RD1`, `DischargeRegionalizer RD2`, `DischargeRegionalizer RG1` et `DischargeRegionalizer RG2` à partir du module `Regionalisation Dam`

Ces instances proviennent du module `RegionalisationDam` appartenant au package (répertoire de code-source) `J2K_Irstea.management`. Ils s'exécutent dans le contexte `RegionalizationDischarge` du contexte `ReachLoop`. Ces instances sont utilisées pour extraire les informations du tableau des débits en entrée pour chacun des brins considérés dans le contexte `ReachLoop`. Les débits d'entrée sont stockés dans des variables intermédiaires `dataValue` instanciées `inflowRD1` à `inflowRG2`. Le **tableau 5** récapitule les données d'entrée et de sortie de l'instance `DischargeRegionalizer`.

<table><caption>Tableau 5 - Récapitulatif des entrées et sorties des instances DischargeRegionalizerRD1, DischargeRegionalizerRD2, DischargeRegionalizerRG1 et DischargeRegionalizerRG2</caption><thead><tr><th>Variables</th><th>R/W</th><th>Type</th><th>Description</th><th>Unit</th></tr></thead><tbody><tr><td>dataArray</td><td>R</td><td>DoubleArray</td><td>Volume en entrée des brins amont</td><td>L</td></tr><tr><td>names</td><td>R</td><td>DoubleArray</td><td>Noms des brins</td><td></td></tr><tr><td>entities</td><td>R</td><td>EntityCollection</td><td>Collection des brins</td><td></td></tr><tr><td>ID</td><td>R</td><td>Double</td><td>ID du brin</td><td></td></tr><tr><td>dataValue</td><td>W</td><td>Double</td><td>Volume en entrée pour le brin considéré (inflowRD1, inflowRD2, inflowRG1, inflowRG2)</td><td>L</td></tr></tbody></table>

* Instances `J2KOutsideInflow RD1`, `J2KOutsideInflow RD2`, `J2KOutsideInflow RG1`, `J2KOutsideInflow RG2` à partir du module `J2KOutsideInflow`:

Ces instances proviennent du module `J2KOutsideInflow` appartenant au package (répertoire de code-source) `J2K_base.org.unijena.j2k/routing`. Elles s'exécutent dans le contexte `RegionalizationDischarge` du contexte `ReachLoop` et permettent d'additionner les variables instanciées `inflowRD1` à `inflowRG2` aux variables `inRD1` à `inRG2` pour le reach et le pas de temps considéré. Si ces instances ne sont pas appliquées et qu'on attribue directement le débit depuis le module de régionalisation, il y a juste une mise à jour des débits et pas d'addition. Le **tableau 6** récapitule les entrées et sorties de ces instances.
<table><caption>Tableau 6 - Récapitulatif des entrées et sorties des instances J2KOutsideInflow_RD1, J2KOutsideInflow_RD2, J2KOutsideInflow_RG1, J2KOutsideInflow_RG2</caption><thead><tr><td>Variables</td><td>R/W</td><td>Type</td><td>Description</td><td>Unit</td></tr></thead><tbody><tr><td>entities</td><td>R</td><td>EntityCollection</td><td>Collection des brins</td><td></td></tr><tr><td>reachID</td><td>R</td><td>Double</td><td>ID du brin</td><td></td></tr><tr><td>inflow</td><td>R</td><td>Double</td><td>Volume en entrée pour le brin considéré (inflowRD1, inflowRD2, inflowRG1, inflowRG2)</td><td>L</td></tr><tr><td>inaddIn</td><td>R/W</td><td>Double</td><td>Volume auquel ajouter le débit en entrée (inRD1, inRD2, inRG1, inRG2)</td><td>L</td></tr></tbody></table>

Afin de vérifier que le modèle autonome fonctionne normalement, un test a été effectué en appliquant un débit d'entrée variable pour chacun des 8 brins amont. Ces débits d'entrée variables proviennent de séries de débits simulées par le modèle J2000P appliqué au bassin versant du Ratier. Les volumes sortant de chacun des brins amont ont été extraits pour être utilisés en tant que débit d'entrée. Les volumes cumulés sont comparés avec les volumes en sortie cumulés à la fin de la simulation afin de vérifier que le volume d'entrée est routé correctement jusqu'à l'exutoire. La figure 4 montre le résultat de cette vérification. Le léger décalage observé entre les volumes en entrée et les volumes en sortie s'explique par l'initialisation du bassin à sec. Les volumes remplissent d'abord les brins avant d'être transférés aux brins suivants. Le décalage est donc proportionnel à la taille du bassin et au temps mis par les volumes pour être transféré du brin initial jusqu'à l'exutoire.
<figure><img src="image_5.png" /><figcaption>Figure 4 - Résultats de la simulation effectuée avec le modèle autonome avec (a) les volumes en entrée et en sortie et (b) les volumes en entrée cumulés comparés avec les volumes en sortie cumulés à l'exutoire du bassin versant (catchmentSimRunoff) et avec le volume restant dans l'ensemble des brins (channelStorage)</figcaption></figure>

D'après les résultats observés en fin de simulation et illustrés dans le tableau 7, le volume cumulé en entrée correspond bien à la somme du volume cumulé en sortie et du volume restant dans les brins. Il n'y a donc pas de perte de volume et le modèle autonome fonctionne donc correctement.

<table><caption>Tableau 7 - Résultats de la simulation avec le modèle autonome</caption><thead><tr><td>Volumes cumulés en m³ en fin de simulation</td><td>Volume total</td></tr></thead><tbody><tr><td>Volume en entrée cumulé</td><td>135196</td></tr><tr><td>Volume en sortie cumulé +<br>Volume restant dans les brins</td><td>135196</td></tr></tbody></table>
## 4. Étape 2 : Création et implémentation d'un module de décomposition spatiale du débit dans le modèle autonome

Une fois le modèle autonome en place, l'objectif est de pouvoir connaître la contribution d'un brin particulier au débit total en tout point en aval de celui-ci et à chaque pas de temps de la simulation. Ce traçage de volume permettra de conserver l'information du chemin, de l'origine et de la quantité d'eau provenant du brin dont on veut connaître la contribution.

Le principe de ce traçage de volume est de calculer la proportion du volume provenant du brin tracé, parmi le volume sortant. Ce calcul sera effectué dans chaque brin aval du brin tracé afin de connaître sa contribution en tout point aval du réseau.

Si le brin *r* est considéré comme le brin dont on veut connaître la contribution en tout point en aval, le volume *out(t)* sortant de ce brin correspond au volume à tracer dans les brins en aval et sera nommé par la suite *trackedVolume* pour plus de lisibilité. Ce volume est transféré au brin *i* connecté en aval lors du routage des volumes. Le volume *trackedVolume* entrant dans le brin *i* est ajouté au volume *trackedVolume* correspondant au volume provenant du brin *r* déjà présent dans le brin *i* (issu des routages aux pas de temps précédents le cas échéant).

Le nouveau volume provenant du brin *r* présent dans le brin *i*, *trackedVolume*tot correspond donc à :

$$trackedVolume_{tot}(t) = trackedVolume_{act}(t) + trackedVolume_{in}(t)$$

Le volume sortant du brin *i* au pas de temps *t*, *out(t)*, est calculé selon la méthode de routage décrite précédemment. Parmi ce volume *out(t)*, l'objectif est de connaître la proportion provenant du brin *r*. En connaissant le volume total présent dans le brin *i*, *actTot(t)*, la part du brin *r* parmi ce volume, *trackedVolume*tot(*t*) et le volume sortant du brin *i*, *out(t)*, et en considérant que les proportions provenant du brin *r* sont les mêmes dans le volume total *actTot(t)* que dans le volume sortant *out(t)* (on considère un mélange parfait), il est alors possible de déduire la part du brin *r* sortant du brin *i* par un simple calcul de proportionnalité :

$$trackedVolume_{out}(t) = \frac{trackedVolume_{act}(t) * out(t)}{actTot(t)}$$

Le volume provenant du brin *r* non routé au brin suivant et présent dans le brin *i* après le routage est mis à jour selon :

$$trackedVolume_{act}(t) = trackedVolume_{tot}(t) - trackedVolume_{out}(t)$$
La figure 5 illustre le principe de traçage des volumes.

<figure><img src="image_6.png" /><figcaption>Figure 5 - Principe du traçage des volumes pendant le routage de brin en brin</figcaption></figure>

L'application de ce principe passe par la création et l'implémentation de plusieurs modules qui seront couplés au module *J2KProcessReachRouting*. Afin qu'il soit possible de tracer plusieurs brins à la fois, les données et les résultats sont traités sous forme de tableaux (array en langage JAVA). L'architecture du modèle autonome avec traçage des volumes est présentée en figure 6.
<figure><img src="image_7.png" /><figcaption>Figure 6 - Architecture du modèle autonome auquel ont été ajoutés les instances des modules permettant le traçage des volumes (encadrés en rouge)</figcaption></figure>

* Instance J2KProcessReachRouting_totalActVolumeSave :

Cette instance correspond à une version modifiée du module J2KProcessReachRouting. Ce dernier calcule déjà le volume total présent dans un brin après l'apport de l'amont et avant le routage en sortie, actTot(t) mais ne le garde pas en mémoire en dehors du module. Comme ce volume est nécessaire au calcul des contributions des brins tracés, le module a été modifié pour pouvoir extraire ce volume et le lire dans la suite du contexte ReachLoop. Quatre variables ont donc été ajoutées pour stocker cette information pour les différentes composantes du débit :

➤ actTotRD1 ;

➤ actTotRD2 ;

➤ actTotRG1 ;

➤ actTotRG2,

Ces variables sont ensuite lues et utilisées dans l'instance ReachTracking. Le tableau 8 représente les entrées et sorties de cette instance.
<table><caption>Tableau 8 - Entrée et sorties de l'instance J2KProcessReachRouting_totalActVolumeSave. En jaune les variables ajoutées par rapport au module originel J2KProcessReachRouting</caption><thead><tr><th>Description</th><th>R/W</th><th>Type</th><th>Description</th><th>Value</th></tr></thead><tbody><tr><td>entities</td><td>R</td><td>EntityCollection</td><td>Collection des brins</td><td></td></tr><tr><td>Caractéristiques du brin</td><td>R</td><td>Double</td><td>Longueur, largeur...</td><td></td></tr><tr><td>inRD1, inRD2, inRG1, inRG2</td><td>R/W</td><td>Double</td><td>Flux sortant amont</td><td>L</td></tr><tr><td>channelStorage</td><td>W</td><td>Double</td><td>Eau stockée dans le brin</td><td>L</td></tr><tr><td>actRD1, actRD2, actRG1, actRG2</td><td>W</td><td>Double</td><td>Eau dans le brin</td><td>L</td></tr><tr><td>outRD1, outRD2, outRG1, outRG2</td><td>W</td><td>Double</td><td>Flux sortant du brin</td><td>L</td></tr><tr><td>catchmentRD1, catchmentRD2, catchmentRG1, catchmentRG2</td><td>W</td><td>Double</td><td>Flux à l'exutoire</td><td>L</td></tr><tr><td>simRunoff</td><td>W</td><td>Double</td><td>Débit total à l'exutoire</td><td>L</td></tr><tr><td>actTotalRD1, actTotalRD2, actTotalRG1, actTotalRG2</td><td>Double</td><td>R/W</td><td>Volume total stocké temporairement dans le brin</td><td>L</td></tr></tbody></table>

## Module ArrayCreator

Afin de pouvoir calculer la contribution de plusieurs brins simultanément et de manière indépendante, l'ensemble des volumes traités doit être géré sous forme de tableaux (ou array en langage JAVA) pour lesquels les colonnes correspondent aux brins tracés.

L'instance *ArrayCreator* permet de créer et gérer des tableaux dans lesquels sont stockés des informations. Pour chacun des brins, les volumes stockés (*trackedVolume<sub>act</sub>*) et sortant (*trackedVolume<sub>out</sub>* ) sont sauvegardés pour tous les brins tracés. Les différents tableaux créés sont les suivants :

* trackedVolumeRD1Array ;

* trackedVolumeRD2Array ;

* trackedVolumeRG1Array ;

* trackedVolumeRG2Array ;

* trackedVolumeRD1Array_act ;

* trackedVolumeRD2Array_act ;

* trackedVolumeRG1Array_act ;

* trackedVolumeRG2Array_act ;

Les calculs s'effectuent seulement pour les brins tracés et seules les colonnes correspondantes seront remplies, ce qui permet de réduire le temps de simulation en évitant de surcharger les calculs. Le tableau 9 résume les entrées et sortie de cette instance.
<table><caption>Tableau 9 - Entrées et sorties de l'instance ArrayCreator. En jaune les nouvelles variables créées par cette instance.</caption><thead><tr><th>Variables</th><th>R/W</th><th>Type</th><th>Description</th><th>Unit</th></tr></thead><tbody><tr><td>entities</td><td>R</td><td>Entity<br>Collection</td><td>Collection des brins</td><td></td></tr><tr><td>names</td><td>R</td><td>DoubleArray</td><td>Noms des brins</td><td></td></tr><tr><td>trackedVolumeRD1Array,<br>trackedVolumeRD2Array,<br>trackedVolumeRG1Array,<br>trackedVolumeRG2Array</td><td>R/W</td><td>DoubleArray</td><td>Tableau des volumes tracés sortant<br>pour tous les brins</td><td>L</td></tr><tr><td>trackedVolumeRD1_actArray,<br>trackedVolumeRD2_actArray,<br>trackedVolumeRG1_actArray,<br>trackedVolumeRG2_actArray</td><td>R/W</td><td>DoubleArray</td><td>Tableau des volumes tracés stockés<br>dans tous les brins</td><td>L</td></tr></tbody></table>

## ■ ReachTracking

Cette instance provient du nouveau module *ReachTracking* permettant de calculer la contribution du ou des brins tracés au débit total dans les brins en aval selon la procédure décrite précédemment. Une colonne nommée *track* a été ajoutée au fichier *d'entrée reach.par* lu dans le contexte afin d'indiquer si le brin devra être tracé (1) ou non (0). Cette colonne est lue dans l'instance *StandardEntityReaders* comme les autres paramètres de chaque brin. Le **tableau 10** résume les entrées et sorties de l'instance *ReachTracking*.

<table><caption>Tableau 10 - Entrées et sorties de l'instance du module de décomposition spatiale du débit *ReachTracking*. En vert les nouvelles variables créées dans par l'instance *J2KProcessReachRouting_totalActVolumeSave*, en bleu les nouvelles variables créées par l'instance *ArrayCreator* et en jaune le nouveau paramètre de traçage lu à partir du fichier *reach.par*.</caption><thead><tr><th>Description</th><th>R/W</th><th>Type</th><th>Description</th><th>Unit</th></tr></thead><tbody><tr><td>entities</td><td>R</td><td>Entity<br>Collection</td><td>Collection des brins</td><td></td></tr><tr><td>outRD1, ouRD2, outRG1,<br>outRG2</td><td>W</td><td>Double</td><td>Flux sortant du brin</td><td>L</td></tr><tr><td>simRunoff</td><td>R</td><td>Double</td><td>Débit total à l'exutoire</td><td>L</td></tr><tr><td>actTotalRD1, actTotalRD2,<br>actTotalRG1, actTotalRG2</td><td>R/W</td><td>Double</td><td>Flux total stocké temporairement dans<br>le brin</td><td>L</td></tr><tr><td>trackedVolumeRD1Array,<br>trackedVolumeRD2Array,<br>trackedVolumeRG1Array,<br>trackedVolumeRG2Array</td><td>R/W</td><td>DoubleArray</td><td>Tableau des volumes tracés sortant<br>pour tous les brins</td><td>L</td></tr><tr><td>trackedVolumeRD1_actArray,<br>trackedVolumeRD2_actArray,<br>trackedVolumeRG1_actArray,<br>trackedVolumeRG2_actArray</td><td>R/W</td><td>DoubleArray</td><td>Tableau des volumes tracés stockés<br>dans tous les brins</td><td>L</td></tr><tr><td>track</td><td>R</td><td>Double</td><td>Indique si le brin est tracé ou non</td><td></td></tr></tbody></table>
## 5. Étape 3 : Validation des résultats du modèle autonome avec le module de décomposition spatiale du débit *ReachTracking*

Les résultats du module sont testés dans plusieurs conditions. Ces résultats sont validés si la valeur des volumes en entrée cumulés à la fin de la simulation correspond à la somme des volumes tracés en sortie cumulés et des volumes tracés restant dans les brins en aval du brin tracé, mais aussi si la dynamique des écoulements en sortie suit correctement celle des écoulements attribués en entrée. Cette méthode permet de repérer une perte de volume pendant les calculs. Les conditions suivantes sont testées :

1) Un brin alimenté à un débit constant et une seule composante RD1;

2) 3 brins alimentés à un débit constant et une seule composante RD1;

3) 3 brins alimentés à un débit constant pour toutes les composantes (RD1, RD2, RG1, RG2);

4) Un brin alimenté à un débit variable et une seule composante RD2;

5) 8 brins alimentés à un débit variable et une seule composante RD2;

6) 8 brins alimentés à un débit variable pour toutes les composantes (RD1, RD2, RG1, RG2).

Les **tableau 11** montre les bilans de volumes obtenus à partir des résultats selon les différentes conditions testées. La **figure 7** montre les résultats de la simulation pour le test n°6.

<table><caption>Tableau 11 - Bilan des volumes en entrée, du volume tracé en sortie et du volume tracé restant dans les brins pour les tests 1 à 6.</caption><thead><tr><th>Tests</th><th>Volumes en m³ pour le brin tracé 2600</th><th>RD1</th><th>RD2</th><th>RG1</th><th>RG2</th><th>Volume total</th></tr></thead><tbody><tr><td rowspan="3">N°1</td><td>Volume en entrée cumulé</td><td>50</td><td></td><td></td><td></td><td>50</td></tr><tr><td>Volume tracé en sortie cumulé</td><td>45</td><td></td><td></td><td></td><td>51</td></tr><tr><td>Volume tracé stocké dans les brins</td><td>6</td><td></td><td></td><td></td><td></td></tr><tr><td rowspan="3">N°2</td><td>Volume en entrée cumulé</td><td>50</td><td></td><td></td><td></td><td>50</td></tr><tr><td>Volume tracé en sortie cumulé</td><td>5</td><td></td><td></td><td></td><td>51</td></tr><tr><td>Volume tracé stocké dans les brins</td><td>46</td><td></td><td></td><td></td><td></td></tr><tr><td rowspan="3">N°3</td><td>Volume en entrée cumulé</td><td>21</td><td>42</td><td>210</td><td>11</td><td>283</td></tr><tr><td>Volume tracé en sortie cumulé</td><td>20</td><td>40</td><td>201</td><td>10</td><td>283</td></tr><tr><td>Volume tracé stocké dans les brins</td><td>1</td><td>2</td><td>9</td><td>1</td><td></td></tr><tr><td rowspan="3">N°4</td><td>Volume en entrée cumulé</td><td></td><td>12126</td><td></td><td></td><td>12126</td></tr><tr><td>Volume tracé en sortie cumulé</td><td></td><td>12105</td><td></td><td></td><td>12126</td></tr><tr><td>Volume tracé stocké dans les brins</td><td></td><td>21</td><td></td><td></td><td></td></tr><tr><td rowspan="3">N°5</td><td>Volume en entrée cumulé</td><td></td><td>12126</td><td></td><td></td><td>12126</td></tr><tr><td>Volume tracé en sortie cumulé</td><td></td><td>12109</td><td></td><td></td><td>12126</td></tr><tr><td>Volume tracé stocké dans les brins</td><td></td><td>17</td><td></td><td></td><td></td></tr><tr><td rowspan="3">N°6</td><td>Volume en entrée cumulé</td><td>357</td><td>12126</td><td>32128</td><td>1349</td><td>45960</td></tr><tr><td>Volume tracé en sortie cumulé</td><td>357</td><td>12126</td><td>31726</td><td>1348</td><td>45961</td></tr><tr><td>Volume tracé stocké dans les brins</td><td>0</td><td>0</td><td>403</td><td>1</td><td></td></tr></tbody></table>
<figure><img src="image_8.png" /><figcaption>Figure 7 - Résultats de la simulation effectuée pour la vérification 6 avec (a) les volumes en entrée et en sortie et (b) les volumes en entrée cumulés comparés avec les volumes tracés en sortie cumulés à l'exutoire du bassin versant (trackedVolume) et avec le volume tracé restant dans l'ensemble des brins (trackedVolume_act)</figcaption></figure>

Le décalage entre les volumes en entrée et les volumes en sortie est toujours visible sur la **figure 7.a**, témoin du temps de transfert des volumes entre l'amont et l'exutoire. La dynamique des débits d'entrée est toutefois respectée. La **figure 7.b** montre que la somme cumulée des composantes tracées en sortie et du volume tracé stocké dans les brins correspond aux volumes en entrée cumulés.

Pour tous les tests effectués, les bilans des volumes en entrée et des volumes en sortie sont corrects. Le module de décomposition spatiale du débit est donc validé.
## 6. Étape 4 : Implémentation du module de décomposition spatiale du débit dans le modèle hydrologique J2000P

Une fois le module de décomposition spatiale du débit validé, les modules permettant le suivi des volumes sont instanciés au sein du modèle hydrologique distribué J2000P :

* J2KProcessReachRouting_totalActVolumeSave en remplacement de J2KProcessReachRouting

* ArrayCreator

* ReachTracking

Des instances supplémentaires ont également été ajoutées afin d'agréger les résultats obtenus selon les deux points choisis dans le modèle : Mercier et Ratier. Les instances MercierRD1_Track, MercierRD2_Track, MercierRG1_Track, MercierRG2_Track, RatierRD1_Track, RatierRD2_Track, RatierRG1_Track, RatierRG2_Track, MercierTot_Track, RatierTot_Track issues du module WeightedSumAggregator_array ont été ajoutées. Ces instances permettent le passage du contexte ReachLoop au contexte TimeLoop et d'extraire les volumes obtenus pour l'ensemble de la simulation. Les résultats de la décomposition spatiale du débit peuvent donc être obtenus pour les stations du Mercier et du Ratier, mais pas pour n'importe quel point du réseau. La figure 8 montre l'architecture du modèle avec les nouveaux modules nécessaires au traçage des volumes.

Le module de décomposition spatiale du débit est intégré et testé au sein du modèle hydrologique. Contrairement au module autonome, les volumes en entrée proviennent du transfert des précipitations vers les rivières via les différents chemins de l'eau représentés par le modèle (interception par la végétation, infiltration, ruissellement...). Ce sont les HRU qui produisent des écoulements qui sont routés de HRU en HRU jusqu'aux brins de rivière. Pour vérifier le traçage correct du volume provenant d'un brin tracé, les volumes obtenus en sortie sont comparés avec les volumes sortant du brin tracé en amont. Une dynamique similaire permet de vérifier le routage correct des volumes provenant des brins tracés jusqu'à l'exutoire. De plus, les volumes en sortie cumulés sont comparés à la somme des volumes en sortie du brin tracé et des volumes tracés restant dans les brins en aval du brin tracé. Si les volumes correspondent, le traçage des volumes a correctement été effectué et le module est considéré comme validé.
<figure><img src="image_9.png" /><figcaption>Figure 8 - Architecture du modèle J2000P avec l'implémentation des instances du module de décomposition spatiale du débit et des modules nécessaires au suivi des volumes</figcaption></figure>

Deux brins ont été tracés simultanément (2600 et 3600). Les résultats peuvent être obtenus pour la station du Mercier et celle du Ratier. Seuls les résultats obtenus sur le Ratier sont montrés. La figure 9 montre les résultats de la vérification dans J2000P et le tableau 12 le bilan des volumes pour les brins tracés 2600 et 3600.

<table><caption>Tableau 12 - Bilan des volumes en entrée, du volume tracé en sortie et du volume tracé restant dans les brins pour la vérification dans J2000P et le brin tracé 2600</caption><thead><tr><th>Brin tracé</th><th>Volumes cumulés en m³ en fin de simulation</th><th>Volume total</th></tr></thead><tbody><tr><td rowspan="3">2600</td><td>Volume en entrée cumulé</td><td>43086</td></tr><tr><td>Volume tracé en sortie cumulé</td><td rowspan="2">43086</td></tr><tr><td>Volume tracé stocké dans les brins</td></tr><tr><td rowspan="2">3600</td><td>Volume en entrée cumulé</td><td>8490</td></tr><tr><td>Volume tracé en sortie cumulé +<br>Volume tracé stocké dans les brins</td><td>8490</td></tr></tbody></table>
<figure><img src="image_10.png" /></figure>

<figure><img src="image_11.png" /></figure>

Figure 9 - Résultats de la simulation effectuée pour la vérification dans J2000P et le brin tracé 3600 avec (a) les volumes en entrée et en sortie et (b) les volumes en entrée cumulés comparés avec les volumes tracés en sortie cumulés à l'exutoire du bassin versant (trackedVolume) et avec le volume tracé restant dans l'ensemble des brins (trackedVolume_act)

Le bilan des entrées et sortie est correct pour les deux brins tracés. L'utilisation du modèle de mélange est donc validée dans le modèle J2000P.
## 7. Mise à disposition du code

Le code-source du module de décomposition spatiale est à disposition, en open-source, sur la Forge svn de l'université Friedrich Schiller à Jena, en Allemagne, co-développeur de la plate-forme JAMS et du modèle J2000 :

http://svn.geogr.uni-jena.de/svn/jamsmodels (accès en lecture avec le login/pdp guest/guest)

Le modèle J2000P Ratier est également disponible sur :

http://svn.geogr.uni-jena.de/svn/modeldata/J2KP_Ratier (version d'origine), et

http://svn.geogr.uni-jena.de/svn/modeldata/J2KP_Ratier_h_test_tracking (version avec composante de tracking).

## 8. Conclusion et perspectives

Intégré au modèle J2000P, le module de décomposition spatiale du débit permettra de tracer les contributions au débit total des différentes sources de contamination identifiées sur les bassins d'application du projet CHYPSTER, à chaque pas de temps et en tout point du réseau hydrographique (dont naturellement les exutoires). Il permettra ainsi de comparer la modélisation aux décompositions issues des modèles de mélange biogéochimiques.

Ce module de décomposition spatiale du débit est pour l'instant intégré au modèle J2000P du bassin versant du Ratier. Il sera également intégré au bassin versant de la Claduègne dans la suite du projet. Au-delà du projet CHYPSTER, il sera utile en modélisation hydrologique distribuée pour identifier les contributions au débit à l'exutoire de différents sous-bassins (par exemple identification des contributions glaciaires sur le bassin du Rhône). Pour la suite des développements, on peut imaginer aller vers la simulation de temps de résidence.