TSC 07 2024

TSC/2024/07.md

@@ -0,0 +1,56 @@
+# Dissolve: Technical Steering Committee Meeting
+### Friday 2nd August 2024, 14:00 - 14:30
+### Jitsi
+
+### Attending
+
+- Tristan Youngs (TY)
+- Adam Washington (AW)
+
+### Apologies
+
+- Daniel Nixon (DN)
+
+### Agenda
+
+1. Project Direction, July 24
+2. Custom Model
+3. Vision for 2.0
+4. Team News
+5. AOB
+
+## 1. Project Direction, July 24
+
+- TY created Milestone 1.6 intended to capture the significant effort put in by the team. The intention is to get v1.6 released by week ending 9th August.
+- TY created a stack of PRs to remove the now-redundant `ProcedureNode`s focussing on analysis, and refactored the entire `Procedure` ecosystem into a `Generator` since this is now the only use of that framework.
+- TY made significant progress on a custom model interface, but reached a stopping point in the process (see Item 2 below).
+- AW continued work on the QML graphing implementation, focussing on bringing in a preliminary version in to Dissolve in order to demonstrate linkage and highlight the route forward.
+- RB continued work on parallelisation strategies for modules, and also created an entirely new `VoxelDensity` module for release 1.6.
+- DB worked largely on scientific endeavours, including creation of a new `TR` module slated for inclusion in release 1.6.
+
+## 2. Custom Model
+
+- TY reported that work towards a generic, custom model interface designed to ease the pain of integrating our data into Qt widgets had proceeded well, but had reached a natural impasse.
+- The principal issue is that `KeywordBase` takes a `const CoreData &` since an early assumption of the design was that a keyword would never need to mutate the core data forming the basis of the simulation, and would be restricted e.g. to parameters specific to module operation.
+- The current incarnation of the `DataTable::VectorModelable` class forming the basis of any tabulated, modelable data in the code must be be passed non-const to the Qt interface class (`DataModelTableInterface`) in order for the Qt widget to register lamba signal callback in the base model. This permits the C++ class itself to inform the model that the data has changed and so should the view, but while remaining completely separated from the Qt/GUI side of things.
+- Thus, to proceed we would need to give a non-const ref to `CoreData` to all keywords in order to get specific keyword types to work under this new system. However, in Version 2.0 as currently envisaged (see Item 3) the flow of data between objects in the code is markedly different, and so many keywords on non-POD types are likely to be made redundant.
+- As such, it is suggested that work on the custom model interface be conducted as part of the push towards v2.0.
+
+## 3. Vision for 2.0
+
+- TY created some exemplars of what Version 2.0 could / should / might look like (available on the Teams site).
+- Briefly, this involves a graph/node-based workflow, rather than the linear stepwise workflow in Dissolve 1.X, and is designed to offer the increased flexibility needed for more complex workflows and science to be performed moving forwards.
+- Since this new model involves explicit data connectivity between nodes, keywords referencing global "stores" of a particular type of data will become largely redundant (hence work on the custom model should be paused for now).
+- A significant point for discussion is the implementation of graph/node visualisation since this represents a significant part of the new UX. Several libraries already exist offering varying degrees of utility, and which should be investigated thoroughly.
+- TY proposed that JS could take this on during August.
+
+## 4. Team News
+
+- Disordered Material's new IP student Alex Boswell started in July 2024 and is learning the fundamentals of C++ development. He will join the Dissolve team when ready and take on small development tasks in order to familiarise himself with the code.
+
+## 5. AOB
+
+- TY apologises for the missed June TSC and the delay to the July TSC due to "ISIS operational difficulties"!
+- The team discussed the appropriateness of the TSC in its current form, noting that the majority of discussion was just highlighting work relevant to the project direction which had already been discussed at the preceding stand-ups.
+- The team agreed to try a more reactive form of technical steering whereby discussion around significant technical developments, issues, or related Epics could be captured as a log or decision-style document.
+- An idea which presented itself once the TSC had finished - perhaps GitHub's own Discussions feature could be the right platform?