Array Element List *.sarr) Format

Array Element List (*.sarr) Format

The array element list (.sarr) file format describes an array as a collection of antenna elements. To use the Custom Array By File... command for an HFSS SBR+ custom array, you must provide a .sarr file that describes the positions, orientations, and weights of array elements. In a .sarr file, each element is defined by its position, orientation, and possibly frequency- and state-dependent weights. The number of weights (Nw) per element is determined by the frequency-domain and num_states specifications in the header; it is the product of the number of frequency samples and the number of states: Nw = Nf Ns. The Ansys Electronics Desktop SBR+ Custom Array feature does not support .sarr files without weights. Therefore, the has_weights header key must be set to true and element weights must be provided.

Multi-state arrays can be configured to capture, for example, multiple electronic beam steering angles or different aperture amplitude tapers in a single .sarr fille. When multi-state results are desired involving an array antenna, using a multi-state array file is more convenient than setting up and running Ns SBR+ designs based on Ns single-state .sarr files.

The file format consists of a header section followed by a data section. The header section is based on keys. Header key lines define what to expect in the data section. The key lines can appear in any order, with the exception of the num_elements key line, which both specifies the number of array elements and marks the end of the header section. The next active (non-comment) line after the num_elements key line is always the first data line of the first array element.

The format supports the liberal use of commenting in both the header and data sections. Blank lines and lines beginning with a pound ('#') sign are ignored. Short comments can also be appended to any key or data line using a pound sign.

Header Keys

has_weights: This is a required key line that indicates whether the array file include element weights. This key must always be set to true, and .sarr files imported into an SBR+ custom array must always contain element weight data.

freq or freq_list: One of these two key lines (but not both) must appear in the header to define the frequency domain of the array. The specified frequency sampling, along with the num_states key, determines the number of complex amplitude weights that will be read for each array element. Use the freq key to configure a uniform frequency sweep. Use the freq_list key if the frequency sampling is nonuniform. In either case, the specified frequencies are always expected in units of GHz. The lower and upper extents of the array frequency domain must match or exceed the frequency extents of SBR+ solution setups where it is used as part of the HFSS design. During simulation analysis, an error message will be issued and the analysis aborted if this condition is not satisfied. Beyond that requirement, the sampling density of the array frequency domain only needs to be sufficient for accurate interpolation of the weights and does not need to match the frequency sampling of the solution setup. The example file below shows the precise syntax for encoding the frequency domain using these two keys

num_states: This is an optional key line that specifies the number of array element weight sets (i.e., array states, Ns). This, along with the number of frequency samples (Nf) determines the number of complex amplitude weights (Nw) expected per element: Nw = Nf Ns. When this key line is not included in the header, the number of states is assumed to be one (Ns = 1).

num_elements: This is a required header key that specifies the number of array element data blocks expected after the header. It must be the last key line in the header because it is also used to mark the end of the header section and the start of the element data blocks section of the file.

Following the header are data blocks, one block for each element of the array. Each block specifies the element's position, orientation (relative to the array antenna local coordinates), and frequency-dependent weights.

An simple .sarr file example is given below. It uses header comments to self-document the format.

#-------------------------------------------------------------------------------

# Template array element list file to define the file format

# Blank lines and lines beginning with '#' are ignored.

#-------------------------------------------------------------------------------

# Has weights {true} (required line)

# Weight data is required in the element data blocks.

#-------------------------------------------------------------------------------

has_weights true

#-------------------------------------------------------------------------------

# frequency domain (required line)

# freq <start_ghz> <stop_ghz> <nstep>

# where:

# nstep = num freq samples - 1

#-------------------------------------------------------------------------------

# -> Specifies, along with num_states, the number of complex amplitude weights

# that file reader expects for each element when has_weights = true:

# Nwgt = Nfreq * Nstate

# -> Determines the frequency samples available for array rendering

#-----------------------------------------------------------------------

freq 0.15 0.15 0

#-----------------------------------------------------------------------

# The frequency domain can alternatively be defined with a list.

# The list must be monotonically increasing but does not need to be uniformly

# spaced.

# freq_list <Nf>

# <freq_ghz[1]>

# <freq_ghz[2]> ( > freq_ghz[1] )

# :

# <freq_ghz[Nf]> ( > freq_ghz[Nf - 1] )

# where Nf is the number of frequencies

#-----------------------------------------------------------------------

# Uncomment these lines and comment the freq key line in order to switch

# how the element weights frequency domain is defined

#-----------------------------------------------------------------------

# freq_list 4

# 0.1

# 0.2

# 0.4

# 0.8

#-----------------------------------------------------------------------

# number of weight states (optional line, default = 1 state)

# Multi-state arrays can be configured in this file format.

# This provides a second dimension in addition to frequency along which

# element weights can be varied. Some examples of weight set variations:

# - beam steer angle

# - aperture amplitude taper for sidelobe control

# - switching sub-arrays on/off by selectively nulling weights

#-----------------------------------------------------------------------

num_states 1

#-----------------------------------------------------------------------

# number of elements (required line)

# This key line marks the end of the header and the start of the element

# list data blocks.

#-----------------------------------------------------------------------

num_elements 2

#-----------------------------------------------------------------------

# For each element of the array

#-----------------------------------------------------------------------

# Array element description (mandatory):

# <pos_x> <pos_y> <pos_z>

# <oriX_x> <oriX_y> <oriX_z>

# <oriY_x> <oriY_y> <oriY_z>

# <wgt_rl[1]> <wgt_im[1]> (Only if has_weights = true)

# <wgt_rl[2]> <wgt_im[2]>

# : : :

# <wgt_rl[NfNs]> <wgt_im[NfNs]>

# where:

# <pos_i> - element position in array coords [meters]

# <oriX_i> - local x-axis of element, unit vector

# <oriY_i> - local y-axis of element, unit vector

# <wgt_rl[k]> - real part of kth element weight

# <wgt_im[k]> - imaginary part of kth element weight

# k = ifreq + Nf*(istate - 1), weights are looped with frequency within state

#-------------------------------------------------------------------------------

0. -0.5 -0.5

1. 0. 0.

0. 1. 0.

1. 0.

0. 0.5 0.5

1. 0. 0.

0. 1. 0.

1. 0.