search

deepmodeling / dflow

Dflow is a Python framework for constructing scientific computing workflows (e.g. concurrent learning workflows) employing Argo Workflows as the workflow engine.
GNU Lesser General Public License v3.0
58 stars 24 forks source link

Frontend UI for dflow #223

Open zjgemi opened 1 year ago

zjgemi commented 1 year ago

Dflow is designed for scientific computing and has different focus in comparison to the general-purpose Argo. An independent frontend UI is necessary for dflow. The possible features include

  1. Display dflow's key in a sensible place.
  2. Fix or workaround the bug of Argo reusing parent node. (https://github.com/argoproj/argo-workflows/issues/7873)
  3. Keep the concept of ID and UID from users, only one ID is retained.
saltball commented 1 year ago

Are there any technical plans for UI, such as development based on Argo UI or just using Argo's API, even Kubernetes API to make a completely new one. Perhaps more detailed planning should be scheduled based on communities' feedback to determine what needs "scientific computing" can't be met by Argo UI?

It seems to me that scientific computing users may value using the UI to quickly and interactively assemble their predefined workflows more than using the UI to check the execution of workflows, which Argo UI does not seem to support at all at the moment. Even the UI may need to have access to some external workflows and OP sharing libraries to help build.

This may require a lot of redesign, is this a possible direction for the dflow UI? Or do this plan mainly want to extract some of the features that Argo UI already has and make a simplified version?

zjgemi commented 1 year ago

Are there any technical plans for UI, such as development based on Argo UI or just using Argo's API, even Kubernetes API to make a completely new one. Perhaps more detailed planning should be scheduled based on communities' feedback to determine what needs "scientific computing" can't be met by Argo UI?

It seems to me that scientific computing users may value using the UI to quickly and interactively assemble their predefined workflows more than using the UI to check the execution of workflows, which Argo UI does not seem to support at all at the moment. Even the UI may need to have access to some external workflows and OP sharing libraries to help build.

This may require a lot of redesign, is this a possible direction for the dflow UI? Or do this plan mainly want to extract some of the features that Argo UI already has and make a simplified version?

Good point. I think an UI for checking and operating existed workflows and an UI for defining new workflows should be separated. The UI discussed here is the former one which can be seen as an enhanced version of Argo UI. Besides the 3 points listed above, the dflow UI may also provide user-friendly interfaces for debuging OPs (https://github.com/deepmodeling/dflow/issues/225). For defining workflows via clicking and dragging, some elaborate OPs in some specific application domains are prerequisites, while few projects are ready for that at this time (https://github.com/deepmodeling/fpop is under development). Besides, at least an exclusive page should be designed for a specific application domain (e.g. first principle calculation, molecular dynamics, etc). Such an UI may be more suitable to be placed on the Bohrium platform.