|
|
|
In ORCHIDEE the graph of the water routing through rivers was generated on the fly in the main code.
|
|
|
|
|
|
|
|
This solution was not ideal for various reasons :
|
|
|
|
* It was difficult to parallelize as in ORCHIDEE the domain decomposition does not foresee exchange of halos.
|
|
|
|
This solution is not ideal for various reasons :
|
|
|
|
* It is difficult to parallelize as in ORCHIDEE the domain decomposition does not foresee exchange of halos.
|
|
|
|
* The routing graph produced in ORCHIDEE could not easily be verified before a simulation is launched.
|
|
|
|
* We plan evolution of the routing scheme which will require a large number of extra information (floodplains, dams, adduction networks, ...) and it will be complicated to add this within the full model.
|
|
|
|
|
|
|
|
This pre-processor should be able to generate the full information needed by ORCHIDEE to route the water to the ocean or return it to evaporative processes. It required the grid of the model and the land/sea mask. All the rest should be ancillary information.
|
|
|
|
|
|
|
|
Furthermore the global hydrological data ([HydroSHED](https://hydrosheds.org/), [MERIT](http://hydro.iis.u-tokyo.ac.jp/~yamadai/MERIT_Hydro/)) sets are at such higher resolution now that they cannot be dealt with on one processor alone. It is necessary to parallelize the usage of these data and the construction of the routing graph for ORCHIDEE. This parallelization is more driven by the memory needs than the speed of simulation and thus could be different than in ORCHIDEE itself.
|
|
|
|
|
|
|
|
[Installation](installation)
|
|
|
|
|
|
|
|
[Code Documentation](Code Documentation)
|
| ... | ... | |
| ... | ... | |