Using Atmospheric Thermal Blooming Models

RESTRICTED AVAILABILITY NOTICE:

The thermal-blooming components of LightLike are only available with specific permission from the government sponsor.  Contact TimeLike Systems for details.

In addition to atmospheric turbulence, there is another physical phenomenon that can add further distortion to the phase front of a propagating optical beam.  This new distortion is due to heating of the medium caused by absorption of part of the beam energy.  The numbers are such that, generally, this phenomenon is only noticeable in atmospheric propagation with truly high-energy lasers.  The heating of the medium is spatially non-uniform, due to finite-beam geometry as well as turbulence scintillation.  Consequently, there are non-uniform density changes in the medium, which produces a non-uniform refractive index field, which in turn produces new phase distortions upon propagation.  From its manifestation in a simple geometry, the beam distortions due to the heating are known as "thermal blooming".

To numerically simulate the effect of thermal blooming on wave-optics propagation, we use a procedure that meshes with the split-step method described earlier for modeling the effect of turbulence.  The propagation path is again divided into subintervals, and the integrated phase retardation map for that subinterval is computed.  From this, a blooming phase screen is constructed, and then used in the framework of the split-step propagation concept.  Typically, there will be turbulence phase screens in addition to blooming phase screens, although one can of course set the turbulence strength to zero to study the blooming effect in isolation.

Since atmospheric absorption is the source of thermal blooming, evidently the key new physical information that must be supplied is a profile of atmospheric absorption coefficients along the propagation path, together with allied information.  Since the absolute power or energy striking each screen determines the heating in the associated subinterval, a profile of atmospheric scattering coefficients is required in addition to the absorption coefficients.  Only the absorbed energy translates into heating, but scattering reduces the net beam power and hence reduces the absolute amount of energy absorbed for a given absorption coefficient.  The scattered energy simply disappears from the problem in the LightLike model.

The LightLike setup procedures for a system with thermal blooming parallel the setup procedures for a system with turbulence only.  The key differences are that we:

(1) Use the components TBAtmoPath or TurbBloomAtmosphere instead of AtmoPath or GeneralAtmosphere.

(2) Use the function MtbAtmSpec in addition to AcsAtmSpec.  (AcsAtmSpec is still used to specify the turbulence screens and specs).

Acknowledgement

The computer code for creating the thermal blooming phase screens in LightLike was copied directly from the MOLLY code created by authors at the MIT Lincoln Laboratory.  The key portions of the MOLLY code were integrated into the LightLike propagation framework.

LightLike library modules used to specify thermal blooming

The LightLike subsystems used to model thermal blooming in conjunction with turbulence are TBAtmoPath or TurbBloomAtmosphere.  These two modules play the same role as AtmoPath or GeneralAtmosphere, respectively, play for turbulence alone.  Note that TBAtmoPath and TurbBloomAtmosphere contain both thermal blooming and turbulence specifications, so they can be used instead of, not in addition to, AtmoPath or GeneralAtmosphere.

TBAtmoPath and TurbBloomAtmosphere are related to each other in the same way that AtmoPath and GeneralAtmosphere are related.  TBAtmoPath is a composite system that consists of TurbBloomAtmosphere plus two PropagationControllers.  For new LightLike users, we suggest the use of TBAtmoPath, which simplifies matters by automatically setting certain options.  The circumstances under which one wants to separately invoke PropagationControllers are discussed in another Guide section.

In the present tutorial section, we explain the turbulence inputs in the context of the TBAtmoPath module.  The specifications are essentially the same in TurbBloomAtmosphere, when the user graduates to that level.  The diagram at right shows the interface of TBAtmoPath.  The module has a LightLike input and a LightLike output for each propagation direction.  Additionally, there are many parameters, but only the one bracketed by the red bar is specifically relevant to thermal blooming.  The remaining parameters are the same ones that appeared in the AtmoPath interface, and specify the turbulence-related parameters.  The new parameter is named mtbSpec, and its setting expression is used to enter all the data needed for thermal blooming specifications.  In the sample at right, this information is entered in a setting expression that uses a special function from the LightLike library:

  MtbAtmSpec(...)

The name of the function should be entered just as shown, and the ellipsis replaced by a sequence of input arguments.

As noted above, the single library module TBAtmoPath is used to specify both the turbulence and the thermal blooming data.  The parameters other than mtbSpec have the same meaning for turbulence as explained in the section describing the AtmoPath module.

Use of MtbAtmSpec to specify blooming parameters and path geometry

To enter thermal blooming specifications into a LightLike simulation, one uses the MtbAtmSpec function in a setting expression in TBAtmoPath.  The mechanism is illustrated in the second parameter line in the preceding picture.  In the same vein as AcsAtmSpec, MtbAtmSpec has several different allowed sets of arguments.  The following table of cases illustrates several options.  After digesting the cases documented below, the more experienced user can inspect the argument lists in the source code file to see if other options may be useful.  The available options may be increased from time to time, between official releases of LightLike.  

General rules

There are some general rules that apply to all argument list options (or at least to all cases where the item appears):

(1) In the table below, the data types of the arguments are prefixed to the arguments.  The purpose of doing this in the table is just to clarify whether the arguments are scalars or vectors:  when the user actually enters the setting expression in LightLike, the data type designators should be omitted.

(2) The position (z) coordinates of screens, are defined with respect to LightLike's z-coordinate conventions.  The key facts are that z=0 is the platform end and z=L(propagation range) is the target end of the propagation module into which MtbAtmSpec is inserted.

(3) Particularly in the case of vector arguments, the user will find it most convenient to enter symbolic names for the arguments, elevate the arguments up the system hierarchy, and assign values to the vectors at that top level (i.e., in the Run Set Editor).

Actually, this holds for most scalar arguments as well:  the atmospheric specifications in general are quantities that we often wish to vary when exploring performance, so it is best to elevate those quantities to the Run Set level before assigning numerical values.

(4) As elsewhere in LightLike, physical units are MKS, unless explicitly specified otherwise.  In particular, absorption and scattering coefficients should have units of m-1.  However, temperature should be in °C (note: notKelvin).

Table of basic cases

Definition of parameters in table of cases

nxy – the number of points across the thermal blooming screen (currently this is assumed to be a square lattice of points).

dxy – the spacing between adjacent points in the thermal blooming screen (measured in meters).

xmin – x-coordinate of the lower left hand corner of the thermal screen (this is currently setup to match the lower left hand corner of the propagation mesh).

ymin –  y-coordinate of the lower left hand corner of the thermal screen (this is currently setup to match the lower left hand corner of the propagation mesh).

dtime – time delta between successive updates of the thermal screens (should be set to the record time of the output at the target end of the propagation, measured in seconds).

absorption – the absorption portion of the extinction (measured in meters-1).

scattering – the scattering portion of the extinction (measured in meters-1).

temperature – representative of the ambient temperature in the temperature model implemented (in degreescentigrade).

lambda – the wavelength (in meters) of the HEL (high-energy laser beam), which creates the thermal screens.  Currently the model supports only one HEL beam.  .

positions – specifies the distance of the thermal screens from the HEL beam’s aperture (in meters).  CAUTION: there is presently a special constraint on the screen positions:  see the two worked examples in a linked document.

xWind – specifies the velocity of the true wind in the x-direction at each of the thermal screens (measured in meters/second).

yWind – specifies the velocity of the true wind in the y-direction at each of the thermal screens (measured in meters/second.)

xvs – the slew speed in the x-direction (conforms to LightLike notation rate-of-change-in-x-slope).

yvs – the slew speed in the y-direction (conforms to LightLike notation rate-of-change-in-y-slope).

xvt – the translation speed in the x-direction of the platform relative to the atmosphere (measured in meters/second).

yvt – the translation speed in the y-direction of the platform relative to the atmosphere (measured in meters/second.)

numberSavedStates – specifies the number of past thermal screens that are required.  While for most applications, a value of one for this parameter suffices, it may occur in simulations involving very long propagation paths that past thermal states are needed to accurately model the return from a target.  An example of its use is provided in the sample problems.

Sample Problems

Due to the complexity of the parameter setup for thermal blooming, it may be helpful for the user to have some examples and sample results for reference. Two worked examples are given in an auxiliary document.

Use of TurbTool or PropConfig to generate blooming parameters and path geometry

As illustrated in the above table of basic cases, we must always use either the MtbAtmSpec or the PropConfigTBAtmSpec functions to input thermal blooming information into LightLike.  Depending on the data possessed by the user, it may be simple to create the required input numbers for MtbAtmSpec.  However, just as in the case of the AcsAtmSpec input data, the user may find it helpful to obtain absorption and scattering coefficient data by doing preliminary work with the PropConfig  helper program.