Electric Field Class

Registered by Tom Dimiduk

The new way of working with things has us passing E-fields around a lot more. Currently we do that with a 3-tuple of 2d-ndarrays. There are some slightly subtle details on how we work with them (ie interference, phase referencing, do we neglect z fields, etc). It might be worth making a class that handles E-fields and gets all of this right in one place.

Things this class should do
* Store the 3 electric fields
* allow addition and interference with other e-fields, handling polarisation effects

Things this class could do
* track the phase reference origin (ie particle center for most of our computed fields), and handle phase shifts when interacting with other E-fields.
* Allow runtime setting of things like whether to ignore Z fields

tdimiduk can write the class if we think it is a good idea, but will want careful checking from others to make sure it gets all the details right, since we have had subtle problems with this in the past.

This is also a good time to have discussions about things like when it is correct to ignore the z component of the E field. Does anyone know off the top of their head what conditions ensure the z component is small? Is that something that will always stay met when we move to more complicated geometries?

[JF responds: we neglect the z component of the E field, not because it's small (although that is the case when you're close to the optic axis, since the E and H fields are transverse), but because the detector is oriented perpendicular to the optical axis. It therefore is sensitive to energy transport (via the Poynting vector) in the z direction, and the z component of E x H only depends on the x and y components.]

[VNM: in principle having a class for the E-field makes sense: it would save a little bit of code duplication, and it might be useful for more arbitrary detector geometries (e.g. when the detector is not perpendicular to the optical axis). Since we have no standard for how the low-level scattering modules return the field information, we would need to have a python wrapper around each C or fortran routine that turns the arrays they return into E-field objects. Each Scatteringtheory module already contains some kind of wrapper, so it seems that we could easily implement the conversion to E-field object inside these functions.

Blueprint information

Status:
Complete
Approver:
Vinothan N. Manoharan
Priority:
Medium
Drafter:
None
Direction:
Approved
Assignee:
Tom Dimiduk
Definition:
Approved
Series goal:
Accepted for dev
Implementation:
Implemented
Milestone target:
None
Started by
Tom Dimiduk
Completed by
Tom Dimiduk

Related branches

Sprints

Whiteboard

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.