[Epic] GraphNode C++

[trisyoungs]

Focus

This Epic details the fundamental paths, problems, and work required, and likely refactoring jobs in order to take the Dissolve CLI / backend away from the linear simulation workflow we have currently and into one based on a Node-based graph.

Specific Points to Consider

• Nodes are general-purpose objects which will encompass the current GeneratorNode and Module classes, as well as any new helper-style nodes (e.g. one which decomposes an input Vector3 into it's x, y, and z components, or provide a single value of some kind.
• Species will not be Nodes since they are loaded or created from some source, but there will necessarily be a set of creator nodes for them.
• Configurations will not be Nodes since they are created data - there will likely be a CreateEmptyConfigurationNode which provides the source of the data, but this empty structure will be passed on to other principally Generator-style nodes to perform the creation. This does raise an interesting little question on where the visualisation of Configurations would now occur - perhaps as a ConfigurationVisualiserNode.
• The current Keyword system needs to be morphed into something more akin to a Parameter system - a Parameter still has a specific value type and widget representation in the GUI, but also has attached with it an associated input link (which sets the value away from the default) and output link(s) (which carry the value to another Parameter input). Graph edges corresponding to connections can be represented as a list of pairs of pairs: "SourceNode/OutputParameter" and "DestinationNode/InputParameter". These are trivially stored as text in the input file, but when loaded the source/destination Nodes can of course be determined and stored as pointers for efficiency at runtime.
• Any Node will provide a display name, icon, and list of Parameters. How other data (e.g. graphs) are to be presented is still under discussion.
• Because we are reducing all of Dissolve's useful working functions to a set of Nodes we must fundamentally rewrite how the simulation is performed, i.e. how we traverse the graph which now represents the simulation / task.
• Since dependencies between Parameters are now explicitly defined by Nodes and edge connections there is no need to maintain a static list of keywords in order to update keyword values because of an object deletion, for instance.
• What about forcefield terms? We could, for instance, have a Node which basically encompasses the AddForcefieldWizard, but what about MasterTerms and editing individual AtomTypes? This could remain as-is in the current UI, as it isn't clear how this would be best incorporated into a graph/node workflow.
• What about PairPotentialOverrides? These are again done at the topmost "forcefield level", so may not require integration into the graph/node workflow.
• What about SpeciesSites? These are data items defined locally on Species - how do we allow them to be easily used as inputs to Parameters since the Species themselves necessarily occur at a place in the graph which is likely to be far from the analysis section requiring the sites.
• It feels as if CoreData will be reduced to being a container for forcefield-related terms - AtomTypes, MasterTerms, and PairPotentialOverrides, and as such should probably be renamed.
• EdgeDefinition class to be introduced to allow storage of connections - this will be two-way data with knowledge of both source and destination points.
• Keywords to be refactored into Parameters with implicit provision of typed input and output slots. An EdgeConnection should be shared between two connected nodes, rather than duplicating the definition.

Task Triage