Shaped Work - Deliverable 1

[AlexanderDefuria]

Shape Up Pitch – Deliverable 1

Circuit Step Solver - Central Data Structure

Problem

Currently the data container for the circuit schematic contains lists of Reference Counted components that make up the design and functionality of schematic and its meta characteristics. This has posed a problem for expanding the functionality of the solver as the reference counted components provide no interior mutability which does not allow the solver to update the model (data container) with new information, instead it is simply displayed to the user. This has been fine for now as the data has been relatively simple in the initial phases of testing but will pose issues for UI and compound data manipulation in the future as schematics and operations alike develop greater complexity.

The solver generates a fair amount of information that directly overlaps with what is stored in the model and its components. Although originally intended to simply display information back to the user, with the significant data carry over between steps there is a notable developmental overhead to provide this carry over within the solver. The data that is created is formatted by the solver and returned to the user on the front end. This issue becomes even more pronounced when working with multiple different solvers. There is currently no good solution to taking the output of a mesh analysis or Thevenin equivalency and using a subsequent method of analysis on the resulting schematic. There are work arounds, but those workarounds are incredibly poor leading to significant and rapid accumulation of technical debt in a core piece of functionality.

Appetite

The core functionality of the solver and the container is there. The results are being output to the user, so we don’t necessarily want to change anything forward facing yet. The flow of interactions between the container and the solver are the bottle neck and make good candidates for change. Underlying this interaction is the core structure of the container; all interaction with it is done using predefined methods that are spread out over the Controller, Container, and Solver. Outside of these three locations there should be not interaction with the container. The solution should be one that only changes the nature of the interaction between the Container and Solver. This means as we increase interaction the amount of data we store in the solver and container should either lessen or remain constant, there should be no addition to information or alteration of the Solver’s processes.

Solution

Building on what is already here seems to be a reasonable place to start. The standard approach to complex mutability patterns in single threaded rust is typically to use the pattern of reference counted mutability cells of the pattern Rc<RefCell<T>>. This pattern provides a reference to a memory location that is mutable and implements dynamic borrow checking rules (meaning we can still have safety while enabling useful runtime errors). By reworking this interior mutability pattern we have to adjust how a massive number of references and occurrences work within all parts of the program. This probably isn’t suitable for all parts of the program but the solver should be able to mutate the original container and return it to the user.

Rabbit Holes

The optimal solution in terms of performance may be to remove Reference Counting entirely and only deal with sharing lifetimes. This can be totally fine and ideal in a limited scope or portion of the program, but it would take a significant amount of time and effort to refactor into something optimized for performance. There are significant potential gains in performance and reliability through static analysis, but the overhead can quickly explode in complexity. Best to avoid.

Further Notes on Rc

There are significant interdependencies between the Container and the Elements and Tools as Tools which are a part of the container require references to Elements in order to function effectively. This violates the static analysis borrow checking rules as is because the Container and the Tools are both effectively seen as owners of the data contained within the Rc<T> structs. There is a way to work around this by passing references and managing lifetimes effectively but at the moment the mood is move fast and break things. This design pattern was part of the breaking, but it is also becoming readily apparent that it will actually be helpful moving forward with the Solvers so it is best to lave in place at this over arching scale. For those of you not familiar with Rust it is worth reading up on how it does static lifetime analysis at compile time, quite interesting and incredibly useful!

No-go’s

Adding any new data structures is a no go. There is no need for any extra information simply the sharing of the existing data slightly differently. Redesigning the solver as a part of this redesign is tempting and potentially beneficial but it should very much wait until the new mutability patterns have been implemented so that we can know our full range of options for interacting with the model. The redesign of the solver isn’t necessary currently, there is nothing about it that blocks implementation of the remaining solvers. It’s also risky to change the design of the Solver as there will be subtle differences between the matrix analysis and nodal analysis Solver’s.