Optimal Strand
The Chain Optimal Strand properties allows you to determine the best strands for a computed Chain based on a specified metric. When a Chain is computed, all possible strands from the start object to end object through the specified connections are determined and times of valid access intervals are stored for each strand. The resultant intervals for each strand simply records when the start object can see the end object through the objects in that strand.
For a given time, many strands may be possible for the start object to see the end object. But which of those strands is the “best” strand? The Optimal Path options allow you to apply a metric to each connection pair in a strand and then compare or combine the pair-wise values to come up with an overall metric value for the entire strand to compare strands to one another. You can specify metrics such as distance, processing delay, or even use an AWB Calculation Scalar as the computed metric.
The following options can be used to define the chain optimal strand data configuration:
| Option | Description |
|---|---|
| Compute | Compute optimal strands. The Chain must be computed for optimal strands to be stored. |
| Metric | The computational metric to be evaluated for each valid strand at the sample times to determine the “best” strands. |
| Strand Comparison | Comparison operator (min or max) used to compare the computed metric for two strands to determine the “best” strands. |
| Sampling Timestep | Time step to sample the best strands referenced from the animation start time. |
For a Chain with many strands, it would be too slow to evaluate which strand is best at any time requested, especially during animation. For this reason, the Optimal Strands are computed at sampled times determined by a specified time step.
For a given time, what is “best” for a given metric? Low values may be best for some metrics, such as distance, while large values may be best for others, such as signal strength. You can specify whether to use the minimum or maximum value of a strand metric when determining the best strand. In addition, you can specify the number of best strands to keep in memory. Keeping all data for all strands in memory could be both time and memory intensive so limiting the number stored to a small value will improve performance when computing and when animating.
Metrics in STK
STK has the ability to generate many, many metrics. For the Optimal Strand metric, you can use distance between objects in a strand, the processing delay of a strand or an access Analysis Workbench Calculation Scalar. Distance and processing delay metrics are summed across the connection pairs for a strand to compute an overall strand value. Calculation Scalars are a bit more complicated.
Calculation Scalar metrics can be used in two forms:
- an AWB file (*.awb) which is an exported access object Calculation Scalar
- a named built-in access object Calculation Scalar
When the optimal strand computations are executed, each pair of objects in the strand is used to create a temporary access object behind the scenes and a Calculation Scalar of the specified type is created for that access. The Calculation Scalar is then evaluated to come up with a value of the metric for that pair of objects. The metric value is computed for each pair of objects defining the strand, then the values are combined to come up with a value for the entire strand. But how are the pair-wise values combined across the strand? That's where the Link Metric Comparison is used. The minimum, maximum, or summed values of the metrics for each objects pair in the strand is used to determine the single metric for the strand.
| Metric Options | Description |
|---|---|
| Distance | The summed distance between object pairs in a strand. Light time delay is not taken into account. |
| Processing Delay | The summed time values of the processing delays specified by each object in the strand plus the light time delay between object pairs in the strand. The light time delay between object pairs is computed simply based on the objects positions divided by the speed of light. The first object’s processing delay is not included. |
| Scalar Calculation | An AWB Calculation Scalar along with a Link Metric Comparison operator (min, max, sum) can be used as the metric to evaluate the value of a strand. The Calc Scalar must be valid for an Access object as the metric is evaluated on each sequential pair of objects in the strand. The link metric comparison operator is then used to compare each object pair’s computed metric to come out with an overall value for the strand. The Calculation Scalar can be specified using a file from an exported Access object Calculation Scalar or as the name of a built-in Access Calculation Scalar. |
If the Calculation Scalar is not valid for any used connections in your Chain, the optimal strands are not be computed and an error message is displayed in the Message Viewer.
| Scalar Calculations Options | Description |
|---|---|
| File | Specify the Analysis Workbench file (.awb) file to be used as the metric when evaluating object pairs. |
| Name | Specify the Analysis Workbench built-in access Calculation Scalar to be used as the metric when evaluating object pairs. |
| Link Metric Calculation | Method used to evaluate object pair metric values when computing an overall strand metric from its constituent strand object pairs. The min, max, or sum of object pair metric values may be specified as the overall strand value. |
Create an Analysis Workbench File (*.awb)
To create an Analysis Workbench file (*.awb) that can be used as a metric for the optimal strand calculation, you can create an access between two objects that represent similar objects to the objects in your Chain connections. Then in the Analysis Workbench tool, create a Calculation Scalar for the metric you want to compute with and export it. The access object can be deleted; it is not needed for the actual Chain computations. When the optimal path calculation is run, a temporary Calculation Scalar is created by importing this file for each of the object pairs in the strand and deleted when the computation is done.
To discover the built-in Calculation Scalar names, it’s easiest to create a temporary access between two objects that represent similar objects to the objects in your Chain connections.
- In the AWB tool, select the Calculation tab.
- Select the access object you just created. You will see the available built in components.
- Look at the tooltip for a Calculation Scalar component and use the name next to the label “Scalar Calculation Name” as the metric name.
- Delete the temporary access object.
When the optimal path calculation is run, a temporary Calculation Scalar is created with this built-in type for each of the object pairs in the strand and deleted when the computation is done.
Example of a best path strand
As a hypothetical example, suppose you have a Chain with two valid strands where you want to evaluate the best path based on some metric:
- Place1 ->Satellite1 -> Place2
- Place1 ->Satellite2 -> Place2
Let’s use a calculation scalar to simulate the shortest path (even though we have a hard-coded metric of distance) so you use the built-in metric name: From-To-AER(Body).Cartesian.Magnitude.
If you hypothetically (completely notional) say the pair distances for a given time are evaluated as follows:
| Connection | Pair |
|---|---|
| Place1 -> Satellite1 | 10 km |
| Satellite1 -> Place2 | 70 km |
| Place1 -> Satellite2 | 20 km |
| Satellite2 -> Place2 | 40 km |
Given the object pair metric values for the connection pairs above, an overall metric value can be assigned to each strand depending on the link comparison operator. The table below shows the possible strand values for the different link operator option:
| Strand | Minimum link distance | Maximum link distance | Sum of link |
|---|---|---|---|
| Place1 -> Satellite1 -> Place2 | 10 km | 70 km | 80 km |
| Place1 -> Satellite2 -> Place2 | 20 km | 40 km | 60 km |
After the strand values are computed based on the connection pair metric values and the link metric comparison setting, the individual strands are compared to find the “best strand.” The following tables shows what would be computed as the “best” strand based on the link comparison and the strand comparison options:
| Strand comparison | (Link comparison operator = min) | (Link comparison operator = max) | (Link comparison operator = sum) |
|---|---|---|---|
| Min | Place1 -> Satellite1 -> Place 2 | Place1 -> Satellite2 -> Place2 | Place1 -> Satellite2 -> Place2 |
| Max | Place1 -> Satellite2 -> Place2 | Place1 -> Satellite1 -> Place 2 | Place1 -> Satellite1 -> Place2 |
Best Strands Time Samples
The best strands are stored at sampled times based on the input sample time step. For very large Chains, it would not be possible to store all data for all strands or be able to compute the best strands on the fly while animating.
| Option | Description |
|---|---|
| Sampling Timestep | Time step to sample the best strands referenced from the animation start time. |
| Include Strand Access Edge Times | Specify whether to include all start and stop access times from all valid strands in addition to the sampled timesteps. |
| # Strands to Store | Specify the maximum number of strands to store as “best.” Stored strands are ordered based on strand metric value and strand comparison type. |
To aid in making sure the visualized best strands are accurate for the current animation time, sample times are referenced to the start animation time. Including strand access end times will add the start and stop access times from all valid strands into the sampled times. This option can lead to the sampled data having many additional sample times computed and stored, especially for Chains with many valid strands. While the option can cause a large amount of memory to be used and lead to a much slower calculation of optimal strand data, it does ensure that reported intervals when there is at least one optimal strand will be exact.
The timeline view below shows the effect of including and not including strand edge times. Chain1 has two valid strands with optimal strands computed at one (1) minute intervals. If samples are taken without edge times, for the animation time in the timeline view image (where the vertical line is, 18:59:45), there will be no valid optimal strands displayed since the last computed sample time is used to choose which optimal strand to display. At the animation time of 18:59:45, the optimal strand sample time of 18:59:00 is used, which has no valid strands.
If the edge times are included, a valid strand (18:59:30) will be displayed. Problems can still occur even with edge times included as shown when the animation time is at the end of Strand2. If the animation time is between the last time of the interval time (19:04:30) and the next sample time (19:05:00), an optimal strand may attempt to be displayed, but there really isn’t a valid strand. STK detects this problem and doesn't display any best strands in this case, but there are times when the wrong best path may be displayed. For this reason, it is important to keep the animation time in sync with the sample times.
