Graph-based task flows

[Gdawson771]

When making a graphical user interface for the Proter API, I chose to represent flows as a graph, where nodes represent single instances of tasks and edges are the dependencies linking those graphs. The issue is, you can create a graph which cannot be represented by the Proter API's logic of IPAR and ITHEN, see the attached graph. That graph should be represented as Task 1 and Task 2 run in parallel and when both are finished Task 3 runs and when only Task 2 is finished then Task 4 can run, I cannot convert this logic in to IPAR and ITHEN. I am not sure what the best way to fix this in the Proter API would be.

One suggestion is representing the graph as a directed adjacency matrix of not only individual tasks, but also combinations of tasks. From the table attached, we can see that only the entry "Task 1 and Task 2" can reach Task 3 and either the entry "Task 2" or "Task 1 and Task 2" can reach Task four. This table does contain the logic that Task 3 can only occur after Task 1 and 2 is done, but Task 4 can occur after only Task 2 is done.

I can represent the task flow in any graph representation that is convenient for the front-end, the important feature is that every graph can be represent in the Proter API.

[PetrosPapapa]

Hi @Gdawson771 thank you for the feature request.

When you mention "any graph representation that is convenient for the front-end" could you perhaps explain this a bit more? What representation are you currently using, for instance? Is it a standard graph representation with nodes/edges or do you have any additional limitations?

The current Flow structure already works with callbacks, so it should be straightforward to have "merge" nodes (similarly to how And works). I am just not sure what would be a good representation. If on your frontend you just use a generic graph, then I could potentially replicate that in the backend.

[Gdawson771]

Hello @PetrosPapapa,

Sorry for the delayed response, I have now submitted my thesis and should be free over the coming weeks to work on this issue.
In the interface I implemented, our nodes objects consist of a name and x/y coordinates, we don't have Then' Nodes and And' nodes. The edges consist of a source node and target node. The only constraint I can think of is that the structure is parsed from a starting node.

Here is the site if you would like to have a look https://dazzling-sopapillas-ddab72.netlify.app/ (Please don't submit too many simulations until my thesis is marked as the limit is 100 form submissions, also feel free to give me as much feedback/feature requests as you please.)

The parser in the front-end will need changed. Currently, I parse through the nodes starting at the starting node and create the IFlow, but I haven't implemented any logic to merge nodes. I should be able to do this if it is helpful.

Let me know if this is not clear, or if you have any other questions. I am much more free now than I was a week ago.

Kind regards,
Gareth

[PetrosPapapa]

Hi @Gdawson771 congrats on your thesis submission! Good luck with your results.

Thank you for the clarifications. I am thinking of implementing this using a standard graph and a starting node. It will allow full freedom (at least in the first instance), including loops. The server will enforce that a time limit be provided for graph simulations to escape infinite loops.

A node will consist of a task and a unique name to be able to reference it in the graph.

Can't think of much else in terms of restrictions, but time will tell.

If you would like to help, some examples I could use to test with would be very useful.

[PetrosPapapa]

Todo list:

• Graph representation
• Callback semantics
• Graph testing
• JSON en/decoding
• Server testing
• Documentation

[PetrosPapapa]

Just a quick note to say that I'll assume or (if possible) enforce that the graph is acyclic. The only reasonable way to execute graphs with cycles is to reduce them to Petri-Nets and use markings to track states.

[Gdawson771]

Hello,

Yes I'll work on adding functionality to enforce that acyclic graphs are prevented.

Below are a number of task flows scenarios, and I am also attaching their object representation .
1)Tasks in sequence

Sequence.txt

2)Tasks in parallel
Parallel.txt

3) Tasks in parallel followed by tasks in sequence
ParallelThenSequence.txt

4. Tasks in sequence followed by tasks in parallel
   
   SequenceThenParallel.txt

5)Tasks in parallel followed by another set of tasks in parallel

ParallelThenParallel.txt

If this isn't quite what you were looking for let me know.