2.3 Rethink structure of code for ease of use

[Jashcraf]

Recently was introduced to the @classmethod way of constructing the raybundle. Think it might be nice to do so I have alternate ways of constructing the raybundle based on whether polarization ray tracing or gaussian beamlets is being done. The ideal product is suitable for both - but I don't want to force the user to construct the differential ray bundles if they don't have to.

Easy changes (could do right now)

• [x] change Raybundle to Rayfront because portmanteaus are the highest form of expression

Medium changes (take a week to make sure I do it right)

• [ ] Add alternative @classmethod constructors for the Rayfront class to make differential ray tracing cleaner

Hard changes (take >1 week to fully implement well)

• [x] Re-organize poke to make more intuitive for development

[Jashcraf]

On Restructuring Poke

The development philosophy I find intuitive is to have one python file for each type of utility. These are simply lists of functions that can be called to perform a task. Then there's a file where we construct the Rayfront class

List of Files

• math: functions that hold constants / convenient mathematical operations
• utils: creature comfort functions (zero padding, cropping/roi, etc.)
• poke_core: function that constructs the Raybundle and uses all of the other methods
• raytrace: functions pertaining to raytracing in ZOS/CODE V or directly manipulating ray data
• prt: functions that perform polarization ray tracing math
• gbd: functions that perform gaussian beamlet decomposition
• polarization: functions that hold polarization-dependent calculations (mueller, jones)
• polarimetry: Stokes, Mueller, PDI polarimetric data reduction
• thinfilms: fresnel coefficients and thin film physics
• readwrite: reading and writing data to and from poke
• accel_math: inspired by POPPY's accel_math, holds math accelerators like cupy, jax
• plotting: standardized plotting functions
• interfaces: code for interfacing with POPPY, HCIPy, prysm.

At the moment this is a big change from where we are now, but I didn't expect Gaussian Beamlets to be so compatible with Poke so originally it was just for polarization ray tracing.

[Jashcraf]

More thoughts for a polarization script. Including some method of handling mueller matrices and polarimetry would be nice, but making the code readable is key. Maybe we split polarization to hold the matrices and polarimetry to hold the data reduction.

[Jashcraf]

Is poke just going to be an amalgamation of all the code I wrote in grad school rather than having a cohesive theme? Yes, probably it will.

[Jashcraf]

poke_core

Rayfront class

• construct as coherent wavefront (GBD)
• construct as polarized wavefront (PRT)

Methods

• propagate through system
• compute differential ray data
• compute polarization ray tracing matrix per surface
• compute decomposed PRT matrix per surface (Oout, J, Oin) for targeted optimization of fresnel coefficients
• make Rayfronts writeable? It would be a way to pass optical systems around, I just don't really know how to do it

[Jashcraf]

Idea for passing surface data as dictionaries

This seems sufficient to turn into a branch, gonna try that now

[trentjbrendel]

Is poke just going to be an amalgamation of all the code I wrote in grad school rather than having a cohesive theme? Yes, probably it will.

This is the way.

[Jashcraf]

Poke has been restructured in the restructure branch. Currently the following modules exist:

• poke_math: functions that hold constants / convenient mathematical operations
• poke_core: function that constructs the Raybundle and uses all of the other methods
• raytrace: functions pertaining to raytracing in ZOS/CODE V or directly manipulating ray data
• polarization: functions that hold polarization-dependent calculations (prt, fresnel)
• thinfilms: fresnel coefficients and thin film physics
• writing: reading and writing data to and from poke
• plotting: standardized plotting functions

To do

• [x] gbd: now that GBD is figured out we do gaussian beamlets
• [x] interfaces: code for interfacing with POPPY, HCIPy, prysm.
• [ ] accel_math: inspired by POPPY's accel_math, holds math accelerators like cupy, jax
• [ ] polarimetry: Stokes, Mueller, PDI polarimetric data reduction
• [ ] utils: creature comfort functions (zero padding, cropping/roi, etc.)

[Jashcraf]

I think accel_math got folded into poke_math, and polarimetry doesn't really fit here. I don't particularly care for utils scripts, because they just feel like a pile of uncategorized things. For now, I'm closing this up