New class structure for scattering theories
(What we used to call "models" we are now calling "theories".) Make scattering theories into classes that store parameters related to the numerical implementation of the theory and that define certain functions:
calc_field(): calculates scattered fields. A scattering theory must define this function; without it, it won't be possible to calculate the hologram. Having a calc_field() for each model also makes it possible to calculate a hologram using more than one model. For example, if you want to simulate scattering from a sphere cluster and a separate coated sphere, you can calculate the scattered field from the sphere cluster using T-Matrix routines, then calculate the fields from the coated sphere using a coated Mie theory, then superpose them.
OPTIONAL calc_intensity(): calculates scattered intensity. Having this function allows the theory to be used to calculate form or structure factors
OPTIONAL calc_holo(): calculates hologram given an optical train. The simplest way to do this is through a python function that calls self.calc_field() and uses the fields to generate the hologram. But you can override this for efficiency (by, for example, C or fortran functions that calculate the hologram directly without requiring a call to calc_fields).
We will also have module-level calc_field, calc_holo, and calc_intensity functions. These might have the following form:
holopy.
Calculates scattering from scatterer using theory. theory is an instance of any valid scattering theory class. If theory is None, calc_field should inspect the structure of the scatterer and figure out what theory (or combination of theories) to use. Should implement superposition of fields if multiple types of scatterers are defined.
holopy.
Calls holopy.
holopy.
Calls holopy.
This class structure maintains the flexibility of the module structure while still allowing methods to be overriden for efficiency. It also has several advantages:
1) it makes it easy to create a new scattering theory ; simply define calc_field() for your theory and the module-level functions will automatically provide a calc_holo() and calc_intensity(), albeit not very efficient ones
2) it makes the scattering code modular. We could imagine creating a separate "scattering models" package that not only calculates holograms, but also calculates form or structure factors through calc_intensity().
3) we could conceivably implement a module-level calc_holo that uses the optical train to propagate the fields from calc_field(). This makes it easy to correct for aberrations and distortions in the optical train in a way that works for all models.
4) defining calc_field() makes it easy to do superposition on generic objects, such as mixtures of scatterers. The module-level calc_holo should handle superposition automatically.
Blueprint information
- Status:
- Complete
- Approver:
- Vinothan N. Manoharan
- Priority:
- High
- Drafter:
- Vinothan N. Manoharan
- Direction:
- Approved
- Assignee:
- Vinothan N. Manoharan
- Definition:
- Approved
- Series goal:
- Accepted for dev
- Implementation:
-
Implemented
- Milestone target:
-
2.0
- Started by
- Vinothan N. Manoharan
- Completed by
- Tom Dimiduk
Related branches
Related bugs
Sprints
Whiteboard
I think I am now convinced this is a good idea. It does in fact make sense to treat scattering theories as objects because they may need data, iteration limits or the like for tmatrix and other series expansion methods, or discritization gridding type information for arbitrary space models.
I think we are renaming scattering models to scattering theories to be a little more descriptive.
Work Items
Dependency tree

* Blueprints in grey have been implemented.