feat: LoopGraph

[trisyoungs]

This PR implements a LoopGraph node - a simple Graph-type node which iterates over its children a number of times. It changes the InputsNode to mirror its proxy output parameters to identically-named input parameters, allowing edges to be created to transfer data back to the beginning of the loop.

The actual data flow in this PR is worth explicitly stating. In the unit test, when the node y_ is pulled to start the processing the LoopGraph is activated and processes it's input edges (only one, from the node i_). It then proceeds to iterate its subgraph for the required number of cycles. Loopback edges are not pulled on the first iteration, only on every subsequent iteration in order to provide any new input data. This means that, unless the node i_ is modified, calling the graph again (as is performed in the unit test) will result in it being Unchanged.

The loopback of data is achieved in practice by essentially disconnecting the InputsNode from natural node behaviour, principally overriding it's run() function to not automatically pull input edges (which would cause an infinite loop) and let LoopGraph handle this when necessary. Furthermore, propagation of "update required" flags is deliberately stopped at edges connecting to an input on an InputsNode as again this would cause an infinite loop.

Complicated, but hopefully a solid solution. Thoughts please!

[RobBuchananCompPhys]

Good progress! I think it would be worth investing some time while we're developing more tests to try and make test graph initialisation more efficient i.e. via some sort of TestGraph class hierarchy as commented above.

[RobBuchananCompPhys]

Is this something we need to do often when setting up test graph? It may be good to have a base class for these tests which takes ownership of root_ and zeroes the coordinates behind the scenes, so we don't have to think about it.

namespace UnitTest
{
class LoopGraphTest :  public GraphTest // derives from public ::testing::Test
{
    public:
    LoopGraphTest() : GraphTest(), dissolve_(coreData_) {} // GraphTest could have default xtor args like centered = true //which give us a centered (x0, y0) graph

    // Create a graph for testing
    void createGraph()

[rprospero]

My suspicion would be that, in the longer term, most of these test graphs would be loaded from a TOML file instead of crafting the graphs by hand.

[rprospero]

This looks like a solid design to me and answers most of the questions that I had in the stand-up. I'm particularly please that we know that the loop won't have to be re-run if the user changes and downstream analysis nodes.

[rprospero]

Watching this grow, I'm wondering if we might be better off with a third party logging library. We've already written half of one and we might get some free functionality from one that is pre-built

[rprospero]

When we had discussed your proposal during the stand-up, I had misunderstood and thought that you were putting this logic into the input nodes. Having this in the node answers 95% of my concerns.

[rprospero]

My suspicion would be that, in the longer term, most of these test graphs would be loaded from a TOML file instead of crafting the graphs by hand.

[RobBuchananCompPhys]

Seems like there was more to come here!

[RobBuchananCompPhys]

My feeling is that there are some similarities we have converged on, but also differences in the complexity and robustness of the looping strategies. Personally, my preference would be to implement something simpler, which the other PR demonstrates (in about half the lines of code)! This economy, I find, is easier to reason about. However, there are short comings there which I think you have covered here particularly with regards to robustness of version indexing, and as you mentioned in the stand up, ensuring that the loop graph isn't re-traversed when an external node is changed, which I hadn't taken into account. So, ideally I'd like to go with the simpler option and see how it holds up for now, but if you and Adam think this is the one that's fine also.