Overview of the meep_adjoint class hierarchy¶
As noted in the :doc:tutorial,
The OptimizationProblem class exported by meep_adjoint
is the top-level entity in a hierarchy of classes that collectively
implement most of the mechanics of the adjoint solver.
Before delving into the detailed API reference,
on the following pages, we pause here to introduce the various classes
in the hierarchy and sketch how they work together to implement
the adjoint solver.
The class hierarchy in a nutshell¶
In rough order from highest-level to lowest-level, the classes in the hierarchy are:
OptimizationProblem
ObjectiveFunction:
DFTCell:
Design rationale
The definitions and interactions of the classes are guided
by a Unix-like logical aesthetic in which we aim for each
class to do one thing and do it well; thus, each class
has one overarching answer to the question
what does this entity know how to do?, and (where appropriate)
we take the class method implementing this basic operation
as the __call__ magic method of the class,
yielding a syntax that emphasizes the logical structure
(see examples below).
In what follows we introduce the members of the class hierarchy by describing the core competency of each, together with its instantiating data (the info required to identify a unique instance, passed as input parameters to the constructor) and any state data it may accumulate over its lifetime.
/*
*/