| | 6 | [[Image(wiki:OasisDriver:Witout_OASIS.png, 350px)]] |
| | 7 | |
| | 8 | This assumes that the domain decomposition of the atmospheric model or the driver are the same. It also means that the processors which have no land point to deal with are waiting for their pairs to finish. |
| | 9 | |
| | 10 | In order to avoid these issues and generalise the coupling of ORCHIDEE with other atmospheric components the OASIS-MCT coupler can be used. In this case the atmosphere can work on any number of processors and ORCHIDEE on a distinct set of processors. This is exemplified in the driver2oasis presented below. Here the atmosphere is a single processor code which just reads some forcing file and provides that data to OASIS. But it is a model for any atmospheric model which would provide the same fields from its n processors to OASIS. |
| | 11 | |
| | 12 | [[Image(wiki:OasisDriver:With_OASIS.png, 350px)]] |
| | 13 | |
| | 14 | In the OASIS approach to coupling a number of advantages are gained : |
| | 15 | |
| | 16 | * The atmosphere can run on a different set of processors than the land surface and have its own domain decomposition. |
| | 17 | |
| | 18 | * ORCHIDEE will only execute on the processors attributed to it and only treat land surface points. |
| | 19 | |
| | 20 | * After the atmosphere has sent its data to OASIS it can continue to work on processes which do not require the input of the land surface. |
| | 21 | |
| | 22 | * In the same way, once the land surface has returned the variables needed by the atmosphere (i.e. after solving the surface energy balance) it can continue to work and prepare the next time step. |
