Optical systems

A collection of optical elements forms an optical system. Optical systems are used together with beams for the solve_system! function. Depending on the system type, different solver implementations can be activated. Currently the following types are available:

└── BeamletOptics.AbstractSystem
    ├── StaticSystem
    └── System

At least 2 types have been found.

Refer to the Tutorials section for examples on how to define optical systems.

BeamletOptics.System Type

System <: AbstractSystem

A container storing the optical elements of, i.e. a camera lens or lab setup.

Fields

• objects: vector containing the different objects that are part of the system (subtypes of AbstractObject)

source

BeamletOptics.StaticSystem Type

StaticSystem <: AbstractSystem

A static container storing the optical elements of, i.e. a camera lens or lab setup. Compared to System this way defining the system is less flexible, i.e. no elements can be added or removed after construction but it allows for more performant ray-tracing.

Warning

This type uses long tuples for storing the elements. This container should not be used for very large optical systems as it puts a lot of stress onto the compiler.

Fields

• objects: vector containing the different objects that are part of the system (subtypes of AbstractObject)

source

Solving systems

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 is explained in more detail in the section: Tracing logic.

BeamletOptics.solve_system! Function

solve_system!(system::System, beam::AbstractBeam; r_max=get_default_r_max(), retrace=true, depth_max=get_default_depth_max(), check_invariant=true, threshold=get_invariant_threshold())

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. Likewise, depth_max limits how many branching levels are explored when new sub-beams are generated (for example, by beamsplitters) so that the tree cannot grow without bound. Sub-beams beyond the depth limit are dropped from the tree.

Arguments

• system::System: The optical system in which the beam will be traced.

• beam::AbstractBeam: The beam object to be traced through the system.

Keyword Arguments

• r_max = get_default_r_max(): Maximum number of tracing iterations for each leaf.

• retrace = true: Flag to indicate if the system should be retraced. Default is true.

• depth_max = get_default_depth_max(): Maximum number of branching levels explored from the root beam

• check_invariant = true: enables or disables optical invariant checks where applicable

• threshold = get_invariant_threshold(): threshold for paraxial invariant checks

source

solve_system!(system::AbstractSystem, bg::AbstractBeamGroup; progress=true, kwargs...)

Trace every beam of the beam group bg through the system, multithreaded over the member beams. All other kwargs are passed on to solve_system! for each beam.

Keyword Arguments

• progress = true: show a progress bar once tracing has run for get_progress_threshold() seconds (default 5 s). It is only drawn if stderr is a terminal, so documentation builds, CI logs and piped output stay clean.

source