| | 12 | |
| | 13 | |
| | 14 | Main actions / points discussed are |
| | 15 | - The need to test/update routing_PP (pre-processor) in order to work with icosaedric grid (especially for the number of neighbours) |
| | 16 | - Potentially test the "efficiency" of routing_PP with a very large number of processor to gain speed (currently several hours in one node for a regional configuration) |
| | 17 | - NEED to test the routing scheme in ORCHIDEE with respect to the intrinsic and numerical properties of the scheme in order to better understand why the results seems to critically depend on the time step in routing and possibly on the number of HTU (hydrological Transfert Units) per grid box (a parameter that can be chosen), etc... For that |
| | 18 | - Need to check/update the "force_routing" program in order to do simple test with a uniq input (drainage and runoff) pre-calculated by ORC. |
| | 19 | - Need to do some elementary tests on the different configuration for the time step, the choise of the initial high resolution description of the basins, etc |
| | 20 | - Yan suggest |
| | 21 | - EM suggest to |
| | 22 | - Agnes wans to contr |
| | 23 | |
| | 24 | - Next big step will be to parallelise "routing.f90" |
| | 25 | - Yan will be able to help with XIOS to compute the Halo for each domains, given that the conectivities are pre-calculated by "routing_PP" |
| | 26 | - |
| | 27 | |
| | 28 | == Meeting 08 October 2020 == |
