New class structure for scattering theories

Registered by Vinothan N. Manoharan

(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.model.theory.calc_field(scatterer, theory=None):
    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.model.theory.calc_intensity(scatterer, theory=None):
    Calls holopy.model.theory.calc_field() and squares the fields to get the intensity

holopy.model.theory.calc_holo(scatterer, theory=None, alpha=1.0):
    Calls holopy.model.theory.calc_field() and calculates the hologram by interfering the scattered wave with the incident wave. Adds the scattered intensity calculated by holo.model.theory.calc_intensity()

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:
milestone icon 2.0
Started by
Vinothan N. Manoharan
Completed by
Tom Dimiduk

Related branches

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.

This blueprint contains Public information 
Everyone can see this information.