Software nulls are generated by raytracing a double-pass, as-built lens model that includes the measured CGH substrate flatness, transmitted wavefront distortion (TWD) and thickness. Flatness is modeled as identical Zernike surface deformations on the CGH front and back surfaces. TWD is modeled as an additional Zernike surface deformation on the back surface. These Zernike surface deformations are represented as Code V .INT files. Departure from the design thickness will contribute spherical aberration in the case of a spherical wavefront.
The software null is defined at the Exit Pupil of the raytrace model. This is a next-to-last surface, made to be concentric with the point source or perpendicular to the collimated source. The axial position of the Exit Pupil (which determines its radius of curvature) is chosen to be a best image of the test optic. This is appropriate if the interferometer is focused onto the test optic. In practice, if the software null correction is small then the position of the Exit Pupil is not critical. Ideally, the Exit Pupil would be the interferometer camera, but we lack sufficient information to raytrace the interferometer. If we are given your Fizeau sphere prescription, we can readily incorporate this into the raytrace model (making the Exit Pupil a plano surface). We do assume that the interferometer optics image the Exit Pupil onto its camera without distortion.
The software null is represented by a square grid of OPD values in the form of a Code V .INT file of wavefront type. The number of grid points is typically 500×500, but any density is possible. The software null is generated by tracing rays to each grid point and noting the optical path difference from the source. By using a grid representation (rather than Zernikes) we are able to define the software null over only those grid points that represent rays passing through the CGH null aperture. The test optic aperture is ignored.
The raytrace model typically includes two or more fiducials. These are identifiable features on the CGH null. The locations of these fiducials are recorded in the leading comment lines of the CodeV .INT file. These fidicials are to be used to achieve proper scaling and registration of the software null to your interferogram.
A null test configuration typically includes several compensators. Typically, if we view things from a CGH-centric viewpoint, the location of the interferometer focus provides 3 compensators and the location of the rotationally symmetric test asphere provides 5 compensators. We generally instruct the user to first align the CGH to the interferometer, using an Alignment CGH and/or retro-alignment features integral to the CGH null. Subsequently, the test asphere is aligned to best null the interferogram.
Prior to generating a software null, we simulate this alignment process with our as-built raytrace models. This assures that the software null correction is as small as possible and that it corresponds to the interferogram that you will achieve using best practice.
The software null is also a good measure of the error you will incur by not applying a software null. This error is often small enough that users will elect not to apply the software null correction.
Software nulls need not be in support of CGH nulls. Diffraction International can generate software nulls for any null test configuration that we can model. An example would be a mild asphere tested against a spherical wavefront.
