You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Anticipating the parallelisation of the framework, a concurrent execution of the components was used to allow for task decomposition (i.e. running the components in parallel) in addition to domain decomposition (i.e. running spatial subsets of the domain in parallel).
Some definitions:
concurrent = computations (i.e. call to components) are order-independent, the result is the same regardless of the order
sequential = computations need to be executed in a specific order to produce the correct result
Assuming components run on the same time resolution for simplicity, with a concurrent approach, during each time iteration, each component is aware of the state of the other components at the beginning of the iteration. With a sequential approach, the second component called is aware of the state of the first component at the end of the given iteration.
E.g., in our framework, with a concurrent approach, if rainfall yields throughfall in the surface layer component during the first time iteration, the sub-surface component will be given this throughfall and yield some runoff from it only during the second time iteration, and the open water component will be given this runoff and route it through the river channel only during the third time iteration. This means that if e.g. all components are run at a daily time step, there will be some "artificial" (numerical) additional delay of 2 days between the rainfall event and the flow peak compared with a sequential approach.
This effect can be minimised by using a shorter time step (e.g. hourly), which would reduce the artificial delay to 2 hours. But if changing the time step is not desirable, or if 2 hours is still too much, a sequential approach may be required instead.
The text was updated successfully, but these errors were encountered:
After a technical meeting with the Hydro-JULES team, it was mentioned that to do task parallelism, the component timestep and the time scale of the physics it considers needs to be appropriately decoupled (see Balaji et al. (2016), Lawrence et al. (2018)). So task parallelism can be done for slow physics, but not for fast physics.
So the decision to run components concurrently is fine so long as the temporal resolutions are appropriate with respect to the physics they model, which probably means that we need both concurrent and sequential coupling to be available?
Anticipating the parallelisation of the framework, a concurrent execution of the components was used to allow for task decomposition (i.e. running the components in parallel) in addition to domain decomposition (i.e. running spatial subsets of the domain in parallel).
Some definitions:
Assuming components run on the same time resolution for simplicity, with a concurrent approach, during each time iteration, each component is aware of the state of the other components at the beginning of the iteration. With a sequential approach, the second component called is aware of the state of the first component at the end of the given iteration.
E.g., in our framework, with a concurrent approach, if rainfall yields throughfall in the surface layer component during the first time iteration, the sub-surface component will be given this throughfall and yield some runoff from it only during the second time iteration, and the open water component will be given this runoff and route it through the river channel only during the third time iteration. This means that if e.g. all components are run at a daily time step, there will be some "artificial" (numerical) additional delay of 2 days between the rainfall event and the flow peak compared with a sequential approach.
This effect can be minimised by using a shorter time step (e.g. hourly), which would reduce the artificial delay to 2 hours. But if changing the time step is not desirable, or if 2 hours is still too much, a sequential approach may be required instead.
The text was updated successfully, but these errors were encountered: