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

Right use of TaskGroups #737

Open
rhfogh opened this issue Jan 25, 2023 · 0 comments
Open

Right use of TaskGroups #737

rhfogh opened this issue Jan 25, 2023 · 0 comments

Comments

@rhfogh
Copy link
Collaborator

rhfogh commented Jan 25, 2023

Talking with Massif-1 raised the issue of how we are supposed to put things in TaskGroups ('DataCollectionGroups').
Apparently a lot of unnecessary TaskGroups are created and end up in ISPyB.

Taskgroups would seem to be used basically for organising display, both the UI queue display (in the Qt version) and for e.g. EXI.

Massif-1 seems to prefer a single task group per mounted sample, grouping mesh scan, centring, characterisation, acquisition and potentially multiple sweeps and multiple crystals in a single group.

Looking at usage, the Qt interface seems to create a TaskGroup for every Sample.

The web interface on the other hand seems to create a new TaskGroup for every major task (characterisation, data collection, workflow, XRF, ...) or other queue item.

In addition, the Gphl Workflow adds a TaskGroup for both (multisweep) DataCollection and (multisweep) Characterisation, AbstractXrayCentring adds a TaskGroup (I probably coded that one as well) and Charaterisation.handleDiffractionPlan adds a TaskGroup.

So, the question is: Should we not harmonize the use of TaskGroups between Web and Qt interfaces? How should the TaskGroup structure of the queue be? Should the additional TaskGroups used by the GPhL workflow (to group characterisation and acquisition sweeps generated by the workflow) be removed?

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

No branches or pull requests

1 participant