Optical systems

A collection of optical elements is referred to as a system in the context of this package. Optical systems are used together with beams for the solve_system! function. In general, optical systems must fulfill the BeamletOptics.AbstractSystem interface in order to be compatible with the standard solvers in this package:

BeamletOptics.AbstractSystem — Type

AbstractSystem

A generic representation of a system of optical elements.

Implementation reqs.

Subtypes of AbstractSystem must implement the following:

Fields:

objects: a vector or tuple of AbstractObjects that make up the system
n: (optional) RefractiveIndex of the surrounding medium, default value is 1.0

Functions:

refractive_index: returns the RefractiveIndex n of the system medium, see above

source

As is, the package provides two basic system types: System and StaticSystem. Refer to the Beam expander tutorial for an example on how to define a simple optical system.

Tracing logic

In order to solve optical systems, this package uses a hybrid sequential and non-sequential mode. Which mode is being used is determined automatically by the solve_system! function. This will be explained in more detail below.

BeamletOptics.solve_system! — Function

solve_system!(system::System, beam::AbstractBeam; r_max=100, retrace=true)

Manage the tracing of an AbstractBeam through an optical system. The function retraces the beam if possible and then proceeds to trace each leaf of the beam tree through the system. The condition to stop ray tracing is that the last beam intersection is nothing or the beam interaction is nothing. Then, the system is considered to be solved. A maximum number of rays per beam (r_max) can be specified in order to avoid infinite calculations under resonant conditions, i.e. two facing mirrors.

Arguments

system::System: The optical system in which the beam will be traced.
beam::AbstractBeam: The beam object to be traced through the system.
r_max::Int=100 (optional): Maximum number of tracing iterations for each leaf. Default is 100.
retrace::Bool=true (optional): Flag to indicate if the system should be retraced. Default is true.

source

Tracing systems

In the initial state, is is assumed that the problem consists of objects <: BeamletOptics.AbstractObjects (in a system) and a beam <: BeamletOptics.AbstractBeam with a defined starting position and direction. No additional information is provided, and the specific path of the beam is not known beforehand. Consequently, brute force tracing of the optical system is required, involving testing against each individual element to determine the trajectory of the beam.

This non-sequential mode is comparatively safe in determining the "true" beam path, but will scale suboptimally in time-complexity with the amount of optical elements. After solving the system, the beam path is known and can be potentially reused in the future.

Object order

Unlike with classic, surface-based ray tracers, the order in which objects are listed in the System object vector/tuple is not considered for the purpose of tracing or retracing.

Retracing systems

Once a system has been traced for the first time, the system and beam can be solved again. However, this time the solver will try to reuse as much information from the previous run as possible by testing if the previous beam trajectory is still valid in a sequential tracing mode. Retracing systems assumes that the kinematic changes (e.g. optomechanical aligment) between the current tracing procedure and the previous one are small. If an intersection along the beam trajectory becomes invalid, the solver will perform a non-sequential trace for all invalidated parts of the beam.

Retracing blocked beam paths

The implemented standard retracing procedure can handle beam path invalidations under certain conditions. However, one case that will lead to a silent error is if an element in the system is moved such that it blocks the beam path between two other elements. The retracer will not be able to detect this, since the testing of the previous intersection will return a valid intersection.

If this kind of situation must be modeled, e.g. in the case of an optical chopper wheel, retracing should be disabled.