2.1

The Physical Basis

WISER is a wave propagation software, which enables to accurately simulate the electromagnetic field along a train of mirrors, accounting for the surface error metrology. WISER’s goal is precision rather than performance. The propagation of light is modeled with fully coherent monochromatic light within Kirchoff’s scalar diffraction theory, and the explicit evaluation of Huygens-Fresnel integral is carried out by recursive summation of complex exponentials (associated to spherical waves). Contrarily to many commonly used approaches in computational optics, FFT algorithm is not used. The attention devoted to metrology and the explicit summation of spherical waves are the main differences of WISER with respect to other well established – and more capillary – wavefront propagation software, such as SRW [8]. The surface error is modeled following the traditional classification of figure error and roughness: The first one is fed as a residual height profile with respect to the ideal curvature and the second one is fed as the Power Spectral Density of the surface height profile. Waive the use of the FFT makes computations longer, but it avoids the a-priori approximations which are necessary to make FFT-based propagators work when tilted planes are involved.

The integration is performed along the tangential (i.e. longitudinal) direction only. Such a choice is a consequence of the fact that, at the X-ray wavelengths, the mirrors are typically operated at grazing incidence, and sagittal scattering is negligible [1]. Each Optical Element (OE) is represented over a lD-support, which is described in a Cartesian space by a couple of arrays (x_m, y_m). Ultimately, real-world optical elements are represented by their longitudinal section: ellipsoidal or Kirkpatrick-Baez mirror are represented by elliptic arc sections, paraboloid mirrors by parabolic arc sections, plane mirrors and detectors by line segment, and so on.

The theoretical basis of WISER can be found in [1], where we find the expression of the field propagated from the optical starting element γ₀ to the arrival element γ₁, which is written as:

where λ is the wavelength, k= 2π/λ, L is the total length of the arrival element γ₁, ϑ is the grazing angle comprised between the incident wave-vector and the tangent at the mid-point if γ₁, R_mk the distance between the points and E is the complex field. Both elements sampled with N points.

3.

ARCHITECTURE

WISER is written making extensive use of object oriented programming and design patterns with a manifold aims in mind: a) creating a flexible, modular code that can be progressively extended; b) giving the user a smooth, intuitive programming experience, also taking advantage of the auto-completion features of the modern IDE (Spyder, pyCharm); c) making the connection to OASYS simple and more natural.

The foundations of WISER are:

An inclusion relation holds between these entities: a BeamlineElements objects contain a collection of OpticalElementobjects, and every OpticalElement object contains a CoreOptics object. A sketch of WISER ecosystem is shown in Figure 1.

Figure 1.

Layout of the Optics object class. For each class, the representative members are shown only.

3.2

OpticalElement class

OpticalElement is as an empty container whose tasks are:

• 1. Storing the positioning command in the PositioningDirective object

• 2. Storing the information about siblings (parent, child/children), the computed data and the computation settings

• 3. Storing the complex CoreOptics subsystem and implementing a facade pattern, to provide just the functionalities that are really needed in the BeamlineElement ecosystem.

A diagram of the OpticalElement class is shown in Figure 2.

Figure 2

Diagram of the OpticalElement class.

3.3

Optics and CoreOptics

The Optics classes provide the true implementation of the real-world optical elements. In particular, the ultimate implementation is carried out by a subset of the Optics classes, which is informally called CoreOptics.

Eventually, the instances of a CoreOptics object are:

• 1. containing the specific code, which defines object behavior, namely how the coordinates within the canvas, the incident and the emerging vector are computed;

• 2. storing the specific parameters of the object to be created (e.g. the wavelength for a light source, or the incidence angle for a mirror, etc.);

• 3. storing the metrology information (figure error and roughness);

• 4. storing low-level computation settings;

• 5. providing, among the others, the following milestone attributes:

  • a. GetXY (to get the x,y coordinates of the CoreOptics object),

  • b. EvalField(x,y, …) to propagate the field from the present optical element to the coordinates (x,y),

  • c. RayInNominal, RayOutNominal, i.e. the vectors (represented in WISER class) associated to incident and emerging scattering wave vector,

A layout of the class hierarchy is shown in Figure 3. The classes Optics, OpticsNumerical, OpticsAnalytical and Mirror acts as abstract blueprint for the “concrete” objects SourceAnalytical, MirrorElliptic, MirrorSpherical, MirrorPlane, Slit, Detector, etc. For these reason, the formers are marked as “<<abstract>>”, understanding that they can not be initialized as standalone objects. The complexity of the CoreOptics classes depend on the optical element itself. For instance, the set of additional formulas required for handling the elliptic mirror are more involved than the ones required for plane mirrors. However, the autonomy of CoreOptics objects is rather limited, as the parent classes already implement the most challenging task: the positioning and rotation algorithms, and the propagation. For this reason, adding a new CoreOptics object is a straightforward operation end requires little or no maintenance to the main code.

Figure 3

Diagram of the Optics object class. For each class, only the representative members are show.

4.

EXAMPLE

A more thorough documentation of WISER, with examples, will be available online on the GIT repository [5]. Here we are just interested in presenting the general appearance of a client code that uses Lib Wiser. We will consider a simple example of a beamline composed by a FEL-like source, a plane mirror, a focusing ellipsoidal mirror and a detector. Parameters can be found in the code.

Units are expessed in S.I. and angles are in radians. After instantiating the CoreOptics objects s, pm, kb, Detector, the BeamlineElements object can be instantiated and populated as well:

The command Beamline.RefreshPositions() gives the instruction to traverse the chain of OpticaElement objects and physically assign the XYCentre attribute to each item. After the beamline is refreshed, it is possible to check the internal representation of WISER,by means of:

The command iterates across the optical elements of Beamline and for each optical element displays its name (marked by double “*”), the name of its parent (to the left), the name of its first child (to the right). “DeltaZ” is the distance from the previous optical element, and “Z” is the cumulative distance from the source.

Another option for checking the internal representation of WISER is the Beamline.Paint() command, which produces a simplified sketch of the optical elements in the WISER canvas. Such a tool is just intended for debug purpose, and shall not be used for producing publication level graphics.

Figure 4

Example of the output of the .PaintQ command.

Finally, the field can be computed onto all the optical elements by means of the ComputeField command.

For each optical element, the results are stored in

which has the following attributes:

The intensity at the detector can be displayed by means of:

Figure 5

Example of the intensity computed at the nominal focal plane, with ideal mirror curvature.

The following code shows how to add a figure error to the surface profile of the optical element:

Figure 6

Example of intensity computed at the nominal focal plane, with non-ideal mirror curvature.

In the example shown, the field is computed at the nominal position of the detector. There may be a wide number of reasons, however, for which the true focal plane is shifted from its nominal position. Possible causes can be: the Gaussian nature of the source, the figure error itself, or the combination of the two [9]. WISER has dedicated functions to find the best focal spot by minimizing the spot size while performing a through-focus scan, which is already integrated in OASYS, as it is shown in Figure 7. In addition, it can be adapted to more sophisticate investigations which involve parametric scans. This make it an ideal tool for optical system performance analysis [10].

Figure 7

Screenshot of the “detector” widget in OASYS, which enables to find the best focus by minimizing the HEW. In the example considered, the best-focus is 5.7mm upstream with respect to the nominal focus. Simulation is performed at λ= 4nm. For the other parameters see Figure 8.

Figure 8

Example of some parametric scan which can be performed with WISER. The parameter is the source wavelength. a) dependence of the spot size as function of the wavelength; b) dependence of the focal shift as function of the wavelength; c) sketch of the conceptual layout; d) figure error used. The computation is performed with a Gaussian source (waist size=150 μm, M² = 1) illuminating an elliptic mirror (f₁ = 88.5 m, f₂= 1.2 m, υ_i = 2°).

As an example, in Figure [],we display the parametric plot of the spot size (computed as the Half Energy Width) and of the focal shift as function of the wavelength for an ellipsoidal mirror illuminated by a Gaussian source.

Some of these functionalities are directly available into OASYS.