aiidalab / aiidalab-home

AiiDAlab Home App
MIT License
5 stars 9 forks source link

Implement AiiDA control page #156

Open yakutovicha opened 1 year ago

yakutovicha commented 1 year ago

fixes #155

cpignedoli commented 1 year ago

User-Friendly AiiDAlab App for Managing Main Workflows (MWs)

This AiiDAlab app aims to enhance the user experience when working with Main Workflows (MWs) in AiiDA. Currently, the default "verdi process list -a" command provides an overview of all workflows, but it lacks user-centric features and can be cumbersome to navigate, especially when dealing with numerous MWs.

MW is a workflow submitted by a user, usually with a description, that will typically have child workflows

Key Features:

1. Intuitive MW List: The app will present a user-friendly MW list, displaying the descriptions of each workflow along with their statuses. Users can quickly identify MWs, such as "PDOS DBBR on Au," "STM goblet," etc., based on the provided descriptions rather than the AiiDA workchain names.

2. Workflow Progress Visualization: Users can easily track the progress of a specific MW by clicking on it. The app will visually highlight completed steps and indicate which step is currently running, queued, or paused. This provides users with a clear understanding of where their MW stands in terms of execution.

3. Process Control: The app will empower users to interact with their MWs efficiently. Users can pause and resume processes as needed, allowing better control over long-running or resource-intensive calculations. Additionally, the app will provide a "kill" option to terminate unwanted or problematic MWs.

4. Efficient Workflow Retrieval: Searching for past MWs will be a breeze with the app's convenient filtering and sorting options. Users can effortlessly find a specific MW, like "DBBR Br removed on Au" from two months ago, and access its individual steps with ease. The app will allow searching based on date ranges and provide a smooth scrolling experience, avoiding disruptive automatic page refreshes.

5. Optimized Performance: Ensuring the app's responsiveness and speed is a priority. By optimizing database queries and utilizing efficient data retrieval techniques, we aim to create a seamless experience for users, even when dealing with a significant number of MWs.

The goal of this app is to make MW management in AiiDA more intuitive, efficient, and enjoyable for users who frequently submit and monitor complex workflows. Your feedback and contributions are highly appreciated as we strive to create a powerful tool that complements AiiDA's capabilities.

unkcpz commented 1 year ago

The control page dependent on the aiidalab-widgets-base, uses widgets from AWB. It is still an open question whether AWB should be the dependency of aiidalab-home. A problem I can foresee is since app share the environment with all kernel packages, install/update app will potentially break the control page.

We can also make AWB the core package as defined in aiidalab and prevent user to override with incompatible version. But this brings restriction to app developers.

The ultimate solution could be for every app has its own Python environment created when using aiidalab install by create an independent conda environment. I had played with this idea a bit but stuck at the jupyter kernel as well as the python interpereter's should be set into notebook metadata in advance which makes no sense for app developement. (I was thinking that the kernel can be set such as passing kernel name to URL, but didn't find anything solution like this.)

danielhollas commented 1 year ago

@yakutovicha thanks for this. :clamp: I like the overall approach and design. I would suggest two things so we can move with an initial version of the control page:

  1. Vendor in AWB dependencies. This will allow faster iteration on the design, and in the meantime we can figure out whether / how to add AWB to base image.
  2. It is clear that the Process page will require the most discussion. Therefore I would omit it in the first version, so that it can be discussed separately and we can have something basic in the meantime.

Couple minor things / ideas...

  1. Perhaps it would make sense to merge the Status and Daemon pages? I would imagine most of the time I'd like to see both at the same time to get the overall state of the system and be able to control it.
  2. Provide buttons to increase / decrease number of daemon workers
  3. Daemon page: Start / Stop buttons should be deactivated when the daemon is (not) running.
  4. Profile page: "Make default" button should not be active for default profile.
  5. Get rid of the alert prompt when exiting the page using the same trick as in other pages.
danielhollas commented 6 months ago

It would be great to re-enable the tests in CI before this PR is merged, per #161, and add basic tests for the new functionality.