Tidy3D 3.0 🚀

[daquinteroflex]

I have opened this discussion as I'm now organising the implementation plan for the 3.0 restructure, based on that we seem to be more keen to explore this approach.

Overview

We can break down this restructure into two aspects:

1. Multiphysics simulations
2. Sort out the code structure issues on 2.0

The benefit is that these tasks can be broken down into subsections and are decoupled from each other, which inherently means they're progressively implementable.

The ethos of this approach is:

• Have all "nice user interface features" decoupled from the actual "solvers".
• We don't have to replace the existing simulations, but we are providing a space to move all the "highly coupled" user functionality into a dedicated "multiphysics user-specific" class.
• We want to have clear interfaces which improve maintainability of coupling relationships, we want to enable extensibility of the physical coupling we want to represent in a microservice-esque development scheme.

High Level View

Lower Level View

Implementation Considerations

Assumptions

These assumptions are based on the feedback sessions with the solver team, product directions, conversations I have had, Tyler’s core concept:

We want to manage the multi-solver coupling in the frontend.
Each solver in the backend can be treated as a self-contained solver.

• If strong coupling is designed between solvers in the backend, this is treated as another self-contained solver as defined by a CouplingSpec .
• Hence, the scalability of maintenance of each solver is linear and self-contained. Coupling definitions and supported relationships are frontend-defined.
• We want to maintain as most compatibility with 2.0 as possible.
• We want to maintain class methods linked and easy to access by the user.
• We do not want to move solver methods outside of classes, and make classes more typing based, and methods to operate on this types essentially, and hence method compatibility scalability inherently depends on inheritance/repeatability rather than functional typing extensions.
• IMPORTANT: Coupled simulations require coupled property monitors for the entire simulation region.

Architectural Theory

• We want to do the opposite of inheritance, we want to “compose” our simulations out of smaller building blocks. The goal is that this allows us to manage coupling in a more defined way.

General Important Changes

• A “multi-physics simulation” composes a the physics we want to represent from “single solver simulations”.
  • Possibly, to some level, some aspect of parallel batch multi-physics simulations can be enabled depending on the type of coupling from previous solver results.
• A “multi-solver simulation scheduler” manages the creation of simulation tasks. This is constructed out of a CouplingSpec
• A “grid/multi-solver interpolation utility” handles all the translation methods between the solvers. The idea is to move the structure of the PerturbationMediums into a dedicated supported section.