opus - optical design software

max reason

page contents

trivia - history and trivia
preface - copyright and license
overview - what is this software
audiences - who is this documentation for
downloads - how and where to download the software
installation - how to install the software on your computer
introduction - an introduction of opus windows, operation, features
documentation - general purpose documentation for optical designers

trivia
opus is short for "optics for us"
first developed in 1970s by Max Reason
copyright 1970s through 2001 by Max Reason
enhanced and often mutated from 1970s to 2001 by Max Reason
XBasic and C++ implementations released as open-source freeware under GNU public license in 2001

preface
This application, including source-code, software, documentation, glass database, optical designs and other files are copyright 1970s to 2001 (and beyond) by Max Reason, their original author.  Max Reason released this application as open-source software under the GPL (GNU public license), which grants substantial and important but limited rights to operate, modify and redistribute this application.  A copy of the GPL itself is part of this application, and must be included with every subsequent version, release and implementation.  See file gpl.txt for a copy of the GPL.

The GPL assures this version/release/implementation of this application, and every application based on any part of this application, are also licensed under the GPL.   The GPL license requires the source-code for this and every future version/release/implementation be provided with the opus application, including the source-code for every modification and addition in every distributed version/release/implementation.   This encourages unlimited ongoing enhancement, development and maintenance.

For more information about GPL, visit http://www.fsf.org/copyleft/gpl.html.

overview
opus is a software application for designing and evaluating optical systems. The first release of this opus software application was created by greatly cleaning and simplifying the application the author had enhanced and extended over decades on an as-needed basis.  This was done purposely to create a reasonably clean, simple, straightforward code base suitable for enhancement and extension by other programmers.  Some capabilities were removed in this process - to be re-implemented more cleanly and efficiently.

opus computes AKA "traces" the path of light "rays" from an "entrance-aperture" or "object-plane", through a series of "optical surfaces" (lens-surfaces, mirror-surfaces, vignette-stops) to a focal surface, where opus computes image error "aberrations" at several "field-angles" and colors AKA "wavelengths".

opus executes command lines entered by keyboard or read from a "macro" file.  These commands tell opus to change optical-system properties, compute the optical-system ray-trace, evaluate images & aberrations, and present general/design/aberration/image information as text (formatted columns of numbers and text) or as graphics (colorful spots, curves, lines and images drawn in on-screen windows).

audiences
This documentation is intended for optical designers, to help them run this application.   Documentation for programmers enhancing this software application is elsewhere - including source-code comments.

This document describes working software applications, but not every feature described in this document is currently implemented.  The original open-source release was simplified and cleaned-up-for-first-release.  The initial XBasic implementation has a user-interface and extensive graphics, while the C++ implementation has little more than core routines and code to print results for comparison to equivalent XBasic output.

The original release is intended as an appropriate for further open-source development by interested individuals in software and optics communities.  This document describe features that exist in one or both current implementations, plus features that are not yet implemented.   Both existing and proposed features are subject to critique, review and modification.  This document identifies all unimplemented features as being unimplemented - hopefully.

downloads
Attempt to download the latest opus release.   If this doesn't work, download from the opus_develop forum at http://groups.yahoo.com/group/opus_develop.   You'll need to join the opus_develop forum anyway to learn to install and operate the code, and learn the purpose of various files if you care.

installation
You must download and install Windows XBasic or Linux XBasic and make that work before you attempt to install and run the opus optical design & analysis software.  The following is a bare-bones description of how to install and run the opus software after you have Windows XBasic or Linux XBasic working and can at least load and run one of the demo programs included with XBasic - like ademo.x for example.

Download the opus.zip file into your XBasic working directory.  You must unzip the opus.zip file into the root directory of the same drive you installed XBasic.  This root directory will be C:\ or D:\ probably.  Then unzip the opus.zip file into this root directory with "recreate directory structure" option selected.  This option is the default on most unzip programs with GUIs designed to run on Windows.   After you complete the installation process, be sure the following directories & files are on your C:\ or D:\ drive:

If installation does not create these directories and files, repeat the installation until you get it right.   Once you have the installation correct, you should be able to load opus.x into the XBasic IDE, and run it.  Unfortunately, the instructions below are far from complete, and some commands have bugs.  Everyone is encouranged to find and fix bugs - this is now an open-source community development software project.  XBasic can create a standalone executable of opus, if you just want to run opus as an independent program.

introduction
This introduction is written so you can perform some operation of opus as described below, and see results.  This information should be correct for early XBasic implementations of opus ~ versions 0.0001 - 0.0007.  Actions you can take are shown in this color, and commands you can enter are this font and color.

This documentation is incomplete - I'm working on it.  Select command in the command window menu bar to see the currently valid list of commands.

start opus - click the opus icon on your desktop, or run the opus source-code in the XBasic IDE.
  >>>  opus loads a sample optical system design
  >>>  opus computes its characteristics and performance
  >>>  opus displays graphic results - design-layout, spot-diagrams, aberration-curves, etc.

Then opus enters a "command loop", and thereafter is "command driven":
  #1:  await the next command
  #2:  execute the command
  #3:  go to step #1

opus waits for you to enter commands into the command window in the upper-left corner of your screen.   Commands are not acted-upon until you press the enter-key.  So hey, let's enter a command...

>>>   command window  <<<
The command window is shown immediately following this paragraph.  Many buttons in the command window are currently disabled.  But the most important feature works - the command entry text field at its bottom.  This is where you enter commands to operate the opus application.  Other features still enabled include the  show buttons, and the file-load, file-quit, command selections in the menu-bar.  The command selection displays a quick-reference guide of currently recognized commands.

at the bottom of the command window, enter l schmax9e
  >>> the l character is the "load design" command
  >>> and schmax9e is the name of an optical design
  >>> opus loads file schmax9e.ops from your /opus directory
  >>> opus computes the characteristics and performance of schmax9e
  >>> opus updates its graphics windows to display its conclusions
         data window - displays optical design specifications
         spots window - displays spot diagrams at center, mid-way, edge-of-field
         design window - displays layout of optical elements and paths of edge rays
         aberration window - displays aberrations in terms of their effect on image

>>>   data window  <<<
From left to right, the columns in the data window are:

This schmax9e design is good to consider, because it contains a significant variety of surface types.  Zero or more letters specify the surface type for each surface.  The surface types recognized now are:

The letter i in the type column at surfaces 1, 8, 10 means light goes in a lens at these surfaces.
The letter o in the type column at surfaces 2, 9, 11 means light comes out a lens at these surfaces.
The letter r at surfaces 3 and 6 means rays reflect from these mirror surfaces.
The letter s at surface 2 means the surface has a Schmidt plate contour.

The Schmidt-plate contour was invented by Bernard Schmidt for his Schmidt camera, the most famous example being the 48" aperture f/2.5 Schmidt camera on Mount Palomar in California.  The Schmidt plate contour is also the shape on the front corrector lens of popular catadioptric telescopes made and sold by Celestron and Meade Instruments.  The Schmidt contour is near-flat and not conic.

No surface type letter is given for surfaces 0, 4, 5, 7, 12 in this design.  These are not optical surfaces.   Surface 0 is always an entrance aperture - where light rays enter the optical system.  And the last surface is always the focal surface - where light rays from the optical system [ should ] converge to form an image.  Typically photographic film or an image sensor ( like a digital-camera CCD ) is placed at the focal surface.  For visual observing through an optical system like a telescope or microscope, the viewer moves a separate optical system (called an eyepiece) until the image is sharp and in-focus - when the eyepiece focal surface coincides with focal surface of the main optical system.

In this design, surfaces 4, 5, 7 are also not optical surface.  These are vignette-stops and baffle-tubes designed to stop unwanted light from striking the image at the focal surface.  Light rays that intersect surfaces closer-to or further-from the optical-axis than specified in the vi and vo columns are vignetted, and the software assumes they do not reach the focal surface.  If vi or vo = 0, they do not cause vignetting.

>>>  design window  <<<
Opus draws a scale drawing of the optical system in the design window, including the path edge-zone rays take through the optical system.  And guess what?  When you maximize or resize the design window, opus instantly redraws the optical system layout to fill the new window size.  Not too shabby for first release.  The entrance aperture is drawn white, lens surfaces are drawn cyan, mirror surfaces are drawn yellow, vignette/baffle surfaces are drawn red, and the focal surface is grey.  The portions of optical surfaces inside or outside non-zero vi or vo radii are drawn in different colors.  opus will draw physical holes and the backsides of mirrors someday.  Here's a design window resized real small for your convenience:

>>>  spots window  -  geometric spot diagrams   <<<

>>>  spots window - wavefront interference images   <<<

>>>  wavefront comments  <<<
All electro-magnetic radiation, including those wavelengths we call light, is fundamentally wave phenomenon.  At any point in space where light of a given wavelength AKA color is in random phase, the waves cancel, and no energy is available.   At points where light of a given wavelength arrive in-phase, the waves reinforce, and energy is available in proportion to the percentage and degree of in-phase waves.

Optical systems are designed to make light waves of each color in-phase at every point on the focal surface so they re-inforce and make energy available to interact with some kind of sensor (retina, film, CCD, etc).

>>>  the wavefront nature of ~ diffraction-limited images  <<<
In a geometric ray-trace, an optical system can produce a "perfect image" - a infinitely tiny spot-diagram.  A single parabolic mirror forms a "perfect image" at the center of its focal-surface - in every wavelength.  But we can observe and measure the image, and its size is considerably larger than zero, and not a tiny dot.  The image looks much like the lowest of the three images in the example wavefront window, at above right.  The image is a brightish central diffraction-disk surrounded by a series of much fainter diffraction-rings.

The size of the diffraction-disk and diffraction-rings are proportional to the wavelength that forms them.   This is clearly visible in the middle image above-right, at 0.8 degrees off-axis.   The blue diffraction-disk is visibly smaller than the green diffraction-disk, which is visibly smaller than the red-diffraction-disk.  And the diffraction-rings follow the same pattern - shorter-bluer diffraction disks and rings are smaller.

Where light of all wavelengths AKA colors mix, the image appears roughly neutral or grey/white in color.   This is evident in the central region of the lowest example image, the on-axis image (0 degrees off-axis).  Even on-axis, the innermost red diffraction ring is visibly larger than the green diffraction ring.

>>>   the effects of vignetting on ~ diffraction-limited images  <<<
In the middle and upper wavefront images, first diffraction rings are clearly not evenly bright all the way around the central images.  Both vignetting and aberrations can cause this effect.

>>>  lateral chromatic aberration  <<<
An image exhibits lateral chromatic aberration when images of different wavelength AKA color form at different places on the focal-surface - closer/further from the optical axis in symmetric optical systems.  The two off-axis images in the above-right example clearly exhibit residual lateral chromatic aberration.  The red,green,blue images are almost completely distinct in the middle image, while the red,blue images overlap and merge in the upper drawing, and the green image is quite distinct below them.

    ---  schmax9e spot diagram image  ---          -  schmax9e wavefront-interference image  -

>>>  aberration curves -vs- wavefront images  <<<

Optics designers can sometimes guess what mix of aberrations influence an image from spot-diagrams and wave-front diagrams, especially when one or two aberrations dominate.  The wavefront-diagram above clearly shows lateral chromatic aberration, and with experience, the spot-diagram shows evidence too. But guessing aberrations from spot or wave diagrams is often difficult or impossible.  So opus measures all aberrations and presents them in 12 graphs in an aberration curves window. The graph at right plots lateral chromatic aberration for the same system.  The following three paragraphs compare this lateral-chromatic aberration plot with the wavefront-interference image directly above it.

>>>  aberration curves -vs- wavefront images  -   lateral chromatic aberration  <<<
All lateral aberration lines converge at the bottom, at 0-degrees off-axis (on-axis).  This agrees with the bottom wavefront-interference image, which shows no evidence of lateral chromatic aberration.

Halfway up the graph corresponds to 0.8-degrees off-axis and the middle wavefront image.  The graph clearly shows the green line in the middle, the violet line furthest to the right, and the red line between.  Sure enough, the red image is between the green and violet images, just as expected.

The top of the graph corresponds to 1.6-degrees off-axis and the top wavefront image.  The graph shows the green line near the middle, and the violet and red lines meeting well to the right.  This corresponds perfectly with the wavefront images - the green image is well below the merged red,violet images.

>>>   aberration window  <<<
The aberrations window contains 12 aberration graphs like the just discussed lateral chromatic example.  The meaning of each aberration graph is stated in the lower-left corner of the window.  opus estimates how much each aberration increases the image size, and draws accordingly.  All graphs are drawn at the same scale, per the horizontal line and micron values along the top of each graph.

>>>  left-most column - spherical and longitudinal chromatic  <<<
The three graphs in the left-most column display both spherical and longitudinal chromatic aberrations in several colors and three skew-angles.  Any non-vertical line indicates spherical aberration at that color.  Any horizontal separation of the lines indicates longitudinal chromatic aberration between those colors.  When different color lines bend differently, spherical aberration varies with color, and that is sometimes called sphereo-chromatic aberration.

>>>   middle-left column - coma  <<<
The three graphs in the middle-left column display coma.  The bottom graph show how coma varies from the center to the edge of the field.  The middle and upper graphs show how coma varies with zone at mid-angle and max-angle off-axis.  For a system dominated by coma, load "newtonian".

>>>  middle-right column - astigmatism  <<<
The three graphs in the middle-right column display astigmatism.  The bottom graph show how astigmatism varies from the center to the edge of the field.  The middle and upper graphs show how astigmatism varies with zone at mid-angle and max-angle off-axis.   For a system dominated by astigmatism, load "ritchey".

>>>  right-most column - image-size : field-curvature : lateral-chromatic   <<<
The three graphs in the rightmost column display three different aberrations.  The bottom graph shows how all aberrations combined affect the image from the center to the edge of the field.  The middle graph shows field curvature from the center to the edge of the field.  The top graph shows lateral chromatic from the center to the edge of the field.  This graph was discussed in a previous section.

The middle graph in the far-right column also shows which graphics colors correspond to each wavelength.

>>>   options window  <<<
The options window is a graphical display of currently selected values.  Many values can be toggled on/off or changed by entering clicking buttons or entering values in the appropriate fields of the options window.  Not every aspect of the options window shown below are enabled --- as of the date this is being written.  Currently the trace colors, wave colors, default color, and ray-input-pattern sections are functional, though these settings are not yet saved/loaded to/from disk when opus saves/loads optical designs.

The trace colors are the colors computed and displayed in the aberration window and spot diagram images.  The wave colors are the colors computed and displayed in the wavefront-interference images.

All wavelengths are in angstrom units.  The default of 4047A - 7065A approximately corresponds with human visual sensitivity and many photographic emulsions.  Many monochrome emulsions are sensitive at shorter wavelengths, and the atmosphere transmits reasonably well at 3126A or 3341A --- depending on altitude and relative-humidity.

Up to 9 trace colors can be selected simultaneously.  Up to 3 wave colors can be selected simultaneously.   Every selected wave color must be a selected trace color, because only the trace colors are computed.

numeric printouts
Only the XBasic implementation of opus draws pretty graphics windows as described and illustrated above.  The current C++ implementation only displays columns of numbers, albeit nicely labeled and formatted.  Fortunately, the numeric printouts from both implementations print exactly the same information in exactly the same format --- which comes in mighty handy when debugging code in one implementation or the other.

>>>  optical-system specifications  <<<
The optical system specs printout contains the same information as the data-window described far above.  The top half of the following windows are optical-system specs printouts from C++ and XBasic opus:

A number in the # column is a surface-number.  opus considers surface # 0 to be an entrance-aperture, and the last surface-number is always the focal-surface.  All surfaces between the entrace-aperture and the focal-surface are treated as optical-surfaces by opus, even those that have no effect on light-rays.

A number in the radius column is a surface radius-of-curvature.  A surface with a negative radius is concave toward the left - toward the object the optical system is imaging.  The radius of a flat surface is mathematically infinite, and not expressible with any real number or numeric format.  So opus adopts a simplifying convention; radius-of-curvature = 0 means flat surface.

A number in the position column is a surface position.  In other words, the position of all surfaces are specified in a coordinate systems that can reasonably thought of as either "optical-system coordinates" or "optical-axis coordinates".   surface # 0 or surface # 1 are usually placed at position = 0 for simplicity, but opus does not require this.  The space between any two surfaces is the difference in their positions.

A number in the conic column is a surface conic-shape.  conic = 1 - e*e, where e = eccentricity.   opus prefers conic to eccentricity because conic can express oblate-spheroids, while eccentricity cannot.  The following table describes common conic surfaces in terms of conic-shape and eccentricity.

A number in the vi column is a surface vignette-inside radius.  A light-ray that hits a surface closer to the optical-axis than vi is vignetted = stopped at that surface. vi = 0 never vignettes.

A number in the vo column is a surface vignette-outside radius.  A light-ray that hits a surface further from the optical-axis than vo is vignetted = stopped at that surface. vo = 0 never vignettes.

A number in the pi column is a surface physical-inside radius - the distance from the optical-axis to the inside-edge of the central hole in a surface. pi = 0 means the surface has no hole. pi is primarily for drawing the optical-surfaces and has no effect on vignetting.

A number in the po column is a surface physical-outside radius - the distance from the optical-axis to the outside-edge of the surface. po must not be zero, since that surface would have no size. po is primarily for drawing the optical-surfaces and has no effect on vignetting.

One or more letters in the type column specify surface-type, as follows:

A name in the glass column is the name of the optical glass at the surface.  The glass has no optical effect unless the surface-type contains an i or o, which specifies refraction entering or leaving a lens surface.

>>>   aberration tables  <<<
The lower half of the following window (repeated from above) contains a printout of an aberration table:

The first line of each aberration table begins with a blank line and a series of ######## characters; for easy reading and possible machine processing.  The values in that line are:

Each aberration table contains information about the image formed at one skewangle, with one color light.  The top line in the above example above says "in the center of the field at 4047A, this optical system has about 0.19 waves of image error from all causes (aberrations and non-optimal focus)".  Aberration tables say nothing about image quality, aberrations or non-optimal focus at other skewangle, color combinations.  But each aberration table does show the extent and effect of aberrations for each zone.

The columns of this table are:

   >>>  zone
opus traces rays in 9 zones through optical systems starting at surface 0 - the required entrance aperture.  opus currently supports five ray input patterns, with 36, 72, 144, 216, 432 rays at the entrance aperture.  The images below show illustrate the ray input patterns in a system with a central obstruction:

36 ray input pattern : 4 rays in each of 9 zones

72 ray input pattern : 8 rays in each of 9 zones

144 ray input pattern : 16 rays in each of 9 zones

216 ray input pattern : 8,12,16,20,24,28,32,40 rays in zones 1 to 9

432 ray input pattern : 16,24,32,40,48,56,64,72,80 rays in zones 1 to 9

   >>>  ray input patterns
The zones in the 36, 72 and 144 ray input patterns are spaced so every zone covers the same area of the entrance aperture.  The zones and rays-per-zone in the 216 and 432 ray input patterns are configured so every ray covers an approximately equal area of the entrance aperture.

A minimum of 4 rays per zone are required to compute aberrations by intersection with the focal surface.   Therefore the 36 ray input pattern is sufficient to design optical systems manually or automated routines.  The spot diagrams produced by the 36 ray input pattern sometimes misrepresent image shape and slightly understate OPD errors, but the overall image size of spot images is similar to the more extensive patterns.  Wavefront interference images produced by the 36 and 72 ray input patterns are extremely unreliable.  The 216 and 432 ray input patterns produce accurate and attractive wavefront-interference images.

In general, ray input patterns with fewer rays run faster but produce less accurate, less attractive results, while ray input patterns with more rays run slower but produce more accurate, realistic, attractive results.

For design by keyboard entry, all ray input patterns are generally acceptable, since they all require under one second to recompute and display aberrations, spot images and optical system layout for ~10 surfaces.  Unfortunately, wavefront-interference images take much longer to draw, even in the best circumstances.  Nonetheless, wavefront-interference images should always be drawn with 216 or 432 ray input patterns to avoid very inaccurate and ugly results.  opus can draw wavefront-interference images 4 and 9 times faster, albeit at lower resolution.  Even so, these lower resolution images are far more accurate and attractive than wavefront-interference images drawn with 36 and 72 ray input patterns at normal speed & resolution.

The 36, 72 and 144 ray input patterns are sufficiently accurate for virtually all automatic optimization.

The following 5 spot images and corresponding 5 wavefront-interference images illustrate these issues.   These 10 images are shown full-size and side-by-side on another web-page - click any image to visit.

-----    spot-diagram images   -----
36 rays                       72 rays                       144 rays                     216 rays                     432 rays


36 rays                       72 rays                       144 rays                     216 rays                     432 rays
-----   wavefront-interference images   -----

   >>>  d-tan
The so-called tangential rays are the top and bottom rays in each zone.  The position along the optical-axis where the top and bottom rays of a zone cross/focus/converge is called the tangential-focus of that zone.  The tangential-focus position is given for the inner zone, while the tangential-focus position of other zones is given relative to the inner-zone, hence the d-tan column heading.

   >>>  d-sag
The so-called sagittal rays are the top and bottom rays in each zone.  The position along the optical-axis where the top and bottom rays of a zone cross/focus/converge is called the sagittal-focus of that zone.  The sagittal-focus position for all zones is given relative to the tangential-focus position for the inner zone, hence the d-sag column heading.

   >>>  delta-y
In the zone pattern above, the optical-axis runs through the center of the zone pattern, and:
  *  the x-axis runs left-right with its origin = 0,0000 at the optical axis
  *  the y-axis runs up-down, with its origin = 0.0000 at the optical axis
  *  the z-axis runs toward-away along the optical axis

The terms on-axis and skewangle = 0 refer to the image formed by an optical-system of a point directly along the optical axis.  All conventional optical-systems (with centered, rotationally symmetric surfaces), focus the image of that point also on the optical-axis, which is commonly called the center of the field.

opus traces optical-systems at 9 skewangles, from on-axis or skewangle = 0 to a maximum skewangle that corresponds to the intended edge of the field.  The image at each skewangle is formed at some height above the optical-axis - in the y direction.  The average height the rays from each zone intersect the focalsurface is given relative to the y-height for the inner zone, hence the delta-y column heading.

In the example printout above, all delta-y numbers are zero because skewangle = 0, so the image is formed symmetrically on and around the optical-axis.  At all off-axis skewangles, the top delta-y is the average height above the axis the rays in the inner-zone hit the focalsurface, and the delta-y numbers below are the average image height for the rays in the other zones relative to the inner-zone.

   >>>  spherical
An optical-system exhibits spherical aberration when the tangential focus in all zones is not at the same position along the optical axis.  opus takes the tangential focus of the outer zone as reference, then computes the size of the image blur caused by spherical aberration at each of the other zones and prints those values under the spherical column heading.  Spherical aberration exists on-axis and off-axis.

   >>>  coma
opus measures and computes the size of the image blur caused by coma at each zone and prints those values under the coma column heading.   xxxxx  write description soon   xxxxx

   >>>  astigmatism
opus measures and computes the size of the image blur caused by astigmatism at each zone and prints those values under the astigmatism column heading.   xxxxx  write description later  xxxxx

command examples
First you should know the easy way to enter values for any surface property without any command.  Obviously this feature only exists in the XBasic implementation, since the C++ code doesn't recognize commands in any form yet.

See the cyan-color label in the data-window?  That's right, the window that displays optical system specs.  If not, click your mouse on any of the surface properties to select it, and make it turn cyan - it better!  Make sure you see the text-insert cursor (a vertical line) in the text-line field in the command window.  Okay, now press the up-arrow, down-arrow, left-arrow, right-arrow cursor keys on your keyboard, and watch the selected surface-property move correspondingly - that's right, the cyan blob moves around.   Stop the cyan blob on something simple, one of the conic values for example.  Then enter a number and press the enter-key.  Yes!  The number you entered appears in the currently selected label - and you've changed that surface property.  Now change it back before you forget.  Yes, this beats entering commands, but you can only set surface properties this way, so you need to learn a few commands from the following table to be able to run this application.

The following command examples are preliminary and subject to massive change without any guilt whatever.   Commands to set surface properties are not show below, but are described in a later section.

documentation
Each command is one line of text.  But one of the commands is "execute this macro", where a "macro" is a named text-file containing any number of commands on separate lines.  The "macro language" is identical to the normal command language - no separate macro language exists.

UNIMPLEMENTED:  macro support is not fully implemented in the XBasic implementation.
UNIMPLEMENTED:  macro support is not implemented in the C++ implementation.

The common way to enter commands is - type on a keyboard.  No command is "entered", "received" or "acted-upon" until the text is "entered".  A command is "entered" when the "enter-key" is pressed on the keyboard, or when each newline character is found in a macro.   So keyboard command lines can be edited by pressing the usual editing keys like "backspace", "delete", "left-arrow", and "right-arrow" before they are finally "entered" by pressing the enter key.

The following are representative command lines.  The comments to the right of these commands describe the commands for this documentation - they are not part of the commands and should not be typed or entered.

r1 -20.250      ' set radius of curvature of surface #1 to -20.250 ( = assumed )
r1 = -20.250    ' set radius of curvature of surface #1 to -20.250
r2 + 0.100      ' add 0.100 to radius of curvature of surface #2
r3 - 0.250      ' subtrace 0.250 from radius of curvature of surface #3
b5 +12.500      ' bend radius of curvature of surface #5 to +12.500 ( = assumed )
b5 = +12.500    ' bend radius of curvature of surface #5 to +12.500
b7 + 0.100      ' bend radius of curvature of surface #7 to current value + 0.100
b7 - 0.250      ' bend radius of curvature of surface #7 to current value - 0.250
vo3 = 4.75      ' set vo (vignette-outside radius) of surface #3 to 4.75
m = 4           ' set maximum field-angle to 4 degrees off-axis
a = 2           ' set current field-angle to 2 degrees off-axis
t               ' trace optical system and display results (aberrations/spots/etc)

All commands conform to one of two or three syntax:

r1 -20.250      ' property_surface operand-or-value
r1  = -20.250   ' property_surface operator operand-or-value
tw              ' command
zi 1.50         ' command operand
zo 4.00         ' command operand
zz 1.50 4.00    ' command operand operand

The parts of a command are separated by one or more space characters - consecutive space characters have the same effect as one space character.  Multiple spaces can make macro files easier to read, for example:

r1      -20.250
r2   =    0.100
r3   +    0.100
r4   -    0.250
b5   =  +12.500
b7   +    0.100
vo3  =    4.750
m    =    4
a    =    2
t

The command-set supports variables and arrays.  The names of all variables and arrays must begin with an underline character, as in _var and _var[n].  Every array index "i" must be 0 <= i <= 65535.

_a = r1         ' assign radius-of-curvature of surface #1 to variable _a
_bb + 0.250     ' add 0.250 to variable _bb
_ccc + r2       ' add radius-of-curvature of surface #2 to variable _ccc
_r[3] = r3      ' assign radius-of-curvature of surface #3 to array-element _r[3]
_p[4] + 0.010   ' add 0.010 to current value of array-element _p[4]

UNIMPLEMENTED: variables and arrays are not implemented.

The proposed command set does NOT support compound operations in a single command.

r1 = r2         ' valid command - not compound
r5 = r6 + 0.10  ' invalid command - compound

But compound operations can be formulated as two or more commands, so the invalid command:

r5 = r6 + 0.10  ' invalid - compound command

can be written as two steps:

r5 = r6         ' valid - not compound
r5 + 0.10       ' valid - not compound

or with a variable

_v = r6         ' valid - not compound
_v + 0.10       ' ditto
r5 = _v         ' ditto

copyright 1988-2001 - all rights reserved - patents pending