Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Concurrent execution vs. sequential execution #41

Open
ThibHlln opened this issue May 4, 2021 · 1 comment
Open

Concurrent execution vs. sequential execution #41

ThibHlln opened this issue May 4, 2021 · 1 comment
Labels
question Further information is requested

Comments

@ThibHlln
Copy link
Member

ThibHlln commented May 4, 2021

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.

@ThibHlln ThibHlln added help wanted Extra attention is needed question Further information is requested and removed help wanted Extra attention is needed labels May 4, 2021
@ThibHlln ThibHlln changed the title Review devision on concurrent coupling Concurrent coupling vs. sequential coupling May 4, 2021
@ThibHlln ThibHlln changed the title Concurrent coupling vs. sequential coupling Concurrent execution vs. sequential execution May 28, 2021
@ThibHlln
Copy link
Member Author

ThibHlln commented May 28, 2021

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant