Skip to content

Discussion of current status and understanding 08 07 2017

Jump to bottom
Vivekanandan (Vivek) Balasubramanian edited this page Nov 27, 2018 · 2 revisions

Discussion of current status and understanding - 08/07/2017

The following table is a consolidation of a high level understanding of AdaptiveMD, Copernicus and EnTK. Thus: (1) There may be development versions which may conflict with data here and (2) some of the functionalities might be attainable with more than trivial effort.

Topic AdaptiveMD Copernicus EnTK
Arch Master-worker Master-worker Worker-worker
Exec model Control flow Dataflow Control flow
Kernels Gromacs only Gromacs but can be extended Kernel independent
Interactive Yes Yes No
Remote submission No No (workers have to be started via batch scripts) Yes
Resource Mapping No Yes - based only on existence of kernel executables Not yet
Performance data (throughput) NA 7 jobs/s O(100) tasks/s (limitation from RP)
Workflow Adaptivity* Task count, Task order Task count Task count, Task order, Task attribute

* It is important to note that there is no strong notion of workflow in AdaptiveMD. Tasks of the application are submitted to their respective master processes.

AdaptiveMD: The current examples in AdaptiveMD suggest that it is possible to change the task count and task order during execution.

Copernicus: The task order is predefined for an application by describing the workflow via copernicus specific library and xml files. Current understanding suggests that task count can possible be varied during runtime. Changing the task type during runtime might not be possible.

EnTK: The task count can be changed during runtime as the exact number is polled multiple types (when required) during execution. The tasks are not created unless they need to be executed (lazy creation) and thus can be modified at various points of execution, hence task attribute adaptivity. Since the tasks are lazily created and their order is not predefined, the order can be changed during runtime.

  • Challenges in workflow adaptivity: Functionally, in order to support workflow adaptivity, the main requirement is the lazy creation of tasks of the workflow. Once available, the overhead in lazy creation and modification of the workflow is of importance. This can be become a significant quantity depending on the application, e.g. applications consisting of large number of short tasks, requiring hight throughput. Although the functionality and performance aspects are easier to address, the difficult issue is the API exposed to the user that is minimally sufficient but expressive to capture the adaptivity in the workflow. This requires feedback from users to be incorporated in iterations of the API. EnTK supports lazy creation of tasks and as a first iteration supports task count and task attribute adaptivity implicitly. Task order adaptivity is supported by exposing methods to move pointers to the current execution around the workflow.

  • Previous reading of the NIH proposal suggested that these 3 modes of adaptivity: task count, task order and task attribute are sufficient to express multiple MD algorithms. Revision is pending.

  • MSM efforts summary: https://github.com/vivek-bala/adaptive-msm-openmm/wiki/MSM-report---08-04-17

Clone this wiki locally