[Documentation Code Camp] - Added introductory section for queue documentation - Part 1

[marcus-oscarsson]

This is still very much in progress, Ill try to add a bit more introduction and some figures that might make things easier to understand. Then Ill go on with some more details that will point out where things are implemented and how new tasks are created.

[marcus-oscarsson]

If you think about something that you'd like to know Id try to add it, I'm not promising that it will be any clearer but it least it will be documented ;)

[rhfogh]

I do have one. As I understood the old system, there was a single source of truth, specifically the tree of QueueModelObjects. But (again as I understood it) MxcubeWeb introduced a new data structure that served as a competing source of truth that could be queried or modified independently. I'd like to understand what both those structures are and how they interact.

[marcus-oscarsson]

Ill try to clarify that, the queue is the same in both Qt and Web, still the same old tree of QueueModelObjects but ill try to clarify that. The creation of the nodes differ slightly a bit but it should otherwise be the same.

[marcus-oscarsson]

I'm sorry @axelboc but I'm not done yet its still very much work in progress this but ill make a diagram as well

[rhfogh]

AH, one question here:

In the diagram it is shown with Samples always at the top ()makes sense) and with only one level of DataCollectionGroup. Is that a rule, just common practice, or a coincidence? When running multisweep workflow experiments, it arguably makes more sense to have multiple levels or groupings, a group for the entire workflow, containing another group for teh characterisation, and yet another group for the actual acquisition sweeps. And indeed this is how I have coded the GPhL workflow. I think we need to decide whether we accept multiple levels of groupings or not, and make it explicit in the documentation, otherwise people will start making incorrect assumptions and different bits of code can clash.

[marcus-oscarsson]

@rhfogh, I'm still working on this section and ill try to make some notes on whats common practice between what is possible. There is no decision on how deep one can nest data collection groups or samples for that matter. Its left open by purpose. The conventional one crystal type per pin with sample changer collection is whats shown in the figure, Ill make a note on that.

One can imagine that for instance a plate sample changer where one have two levels of samples plate and crystal, I'm not saying that thats how it should be done but its a possibility. For workflows nested groups could make sense and even for multi sweep collections.

[rhfogh]

OK, If you will put in something explicit about allowing nested groups, I'll remove my 'Request Changes' immediately and leave the rest to you. I made the point because (until I modified it) there was code assuming that the Sample was always two levels up from the DataCollection.

I still need to check with Olof exactly what the rules and assumptions about grouping are for MASSIF-1 operation.

[marcus-oscarsson]

I'm not sure how to approach this because I make some changes and push mostly to see how it renders, but then I get comments on certain things that are still in progress. As its draft Ill try to answer your general questions regarding the queue like the one @rhfogh asked, and the rest is still very much subject to change.

[rhfogh]

You could mark it as WIP, if you prefer that we wait with the comments.

[axelboc]

We just got mixed up on what "Draft" means. Marcus opened this to show progress and to preview his work, not to request a review. As discussed during the meeting this morning, "Draft" means that it's not yet ready for review (unless the opener specifically asks for feedback). The removal of "Draft" status by the opener means that reviews are welcome.

[marcus-oscarsson]

I happy for the broader questions like the one @rhfogh asked or general questions about the queue that you'd like to know about, it helps me to narrow down on some details. Just to avoid that we waste our time on things that will most likely change. I also mark it as WIP ;)

[marcus-oscarsson]

I believe this is starting to get usable, its not complete yet I will add a few sections in a near future. I plan on adding more on how the execution works and then Ill add something about the new queue design and the drawbacks of the current design. However, thats for Part 2 :)

[beteva]

Nice with diagrams.