A ForceModel defines a particular force acting on a body based on a model of the physics in the body's environment. When combined together with a PropagationNewtonianPoint, the force models define a body's equations of motion according to Newton's second law. The Newtonian position uses the force models along with a specified mass to determine the acceleration used to integrate the position and velocity.
The functionality described in this topic requires a license for the Orbit Propagation Library.
Spherical harmonic gravity models the gravitational effects produced by the mass distribution of a large body. The gravity is handled by three types: SphericalHarmonicGravityModel, SphericalHarmonicGravityField, and SphericalHarmonicGravity.
The gravity model represents the full set of coefficients and can be read in from a ".grv" file. This is then used to construct the immutable gravity field by downselecting to the desired fidelity in the degree and order of the represented field, as well as configuring other options, such as the inclusion of tidal data. This gravity field is then used to define the gravity force at a given position.
In addition, there is the simple TwoBodyGravity force, which treats the central gravitational body as a point mass, and the ThirdBodyGravity perturbation force which models the addition of the point-mass gravity from bodies other than the primary gravitational body.
The AtmosphericDragForce is constructed using one of several ScalarAtmosphericDensity models, as well as Scalars representing the object's CoefficientOfDrag (get / set) and ReferenceArea (get / set). Since the position and velocity are required to compute density and in order to avoid possible inconsistency, the drag force acquires the position and velocity from the scalar density model in order to compute the force.
It's important to note that there are many different models for the Earth's atmosphere and some are more accurate than others. Ultimately the variability and uncertainty in modeling the atmosphere makes atmospheric drag the least physically accurate force model in the provided set. However, for low-altitude satellites having an approximation for the atmospheric drag is crucial for determining an estimation for its trajectory.
SimpleSolarRadiationForce models the effect of pressure exerted by radiation from the Sun. The force is modeled as being projected along the vector from the Sun to the object. The entire ReferenceArea (get / set) is taken to be orthogonal to the incident radiation.
SimpleSolarRadiationForce is constructed using a ScalarOccultation model, as well as Scalars representing the object's coefficient of reflectivity, normalized area, and the Sun's luminosity. Similar to atmospheric drag force, the position is used by the occultation factor and also provides the position for the force.
Three basic occultation factor models are available: ScalarOccultationDualCone, ScalarOccultationCylindrical, and ScalarOccultationNoShadow. These models take an observing Point, and CentralBody instances representing the illuminating body and occluding bodies. The VectorType (get / set) property can be used to specify whether the calculation uses the true position for all bodies involved, or the apparent position that adjusts for light time delay and aberration. Also note that while an occultation factor model is needed to compute the SimpleSolarRadiationForce, it can also be used independently as a metric to determine the percentage of illumination at a particular (potentially time-varying) location in space.
A fourth occultation factor is also available: ScalarOccultationRegulatedDualCone. This model must be used when correcting the solar radiation force with SolarRadiationBoundaryMitigation during propagation. If the corrector is not being used, then the normal dual-cone shadow model should be used instead.
While the dual-cone model will most frequently be used in conjunction with the solar radiation force, it can also be used in more general cases, such as the occlusion of a target body by its moon(s), or as a simple means of determining whether a vehicle is in direct, partial, or no sunlight.
Custom forces can be created by extending the ForceModel class and defining a ForceEvaluator which computes the force. See the Evaluators And Evaluator Groups topic for more information. Some forces are specific, indicating that they already account for mass in their calculation. For instance, most gravity models usually express the specific force (acceleration) on a body, since the mass simply cancels. For the sake of coordinate transformations, specific forces are still treated as forces even though the PropagationNewtonianPoint does not divide them by mass in order to compute the acceleration.
There are some custom forces that will require some care when using them to propagate a trajectory, for example, thrust. It's simple for a user to create a thrust model by specifying a force and determining a mass flow rate (or vice versa) and then specifying a position element and a mass element to integrate in the state. However, care needs to be taken that the mass doesn't become negative after the fuel is exhausted. Generally, forces that only apply for short periods of time need to be handled slightly differently from forces that occur as a result of the environment. Such forces should only be applied in a NumericalPropagator over the span when the force is active and it will need to target the time at which the engine stops, after which a new propagator should be used. Otherwise, it's possible to adjust results with a PropagationStateCorrector, but in some cases this method can cause inaccuracies and other problems during propagation.
STK Components is validated using an automated test suite that uses the most recent version of STK. There are a few things that users should know when attempting to compare values from the numerical propagator in STK Components against HPOP in STK:
Generally, it is best to start by integrating a trajectory with TwoBodyGravity as the only force model, to verify that the initial state, frame, and time standards are all identical before proceeding to more complex force models. In STK, you can do this by creating an STK HPOP satellite and turning off all of the force models except for gravity and then decreasing the degree and order to zero with tides turned off.
Both STK 11 and STK Components use InternationalCelestialReferenceFrame (get / set) (ICRF) by default to define the Earth's InertialFrame (get / set). If you are comparing against earlier versions of STK, you may need to reassign the Earth's InertialFrame (get / set) to be the J2000Frame (get / set). It is also important to note that propagation should generally occur in an inertial frame (either ICRF or J2000), unless the user intends to model coriolis and centrifugal effects separately.
By default, STK uses Earth Orientation Parameters (EOP) to define polar corrections to the orientation of the Earth's FixedFrame (get / set). To match exactly, STK Components must use the same EOP data as STK. See the External Data topic for more information on obtaining and configuring EOP data.
By default, STK 11 uses JPL DE430 ephemerides for the positions of the Sun, Moon, and other celestial bodies. To match with STK, you should use JplDE430 to update the central bodies in the calculation context, as well as set the MoonCentralBody.FixedFrame (get / set) to be the topographic fixed frame, available from the getMoonTopographicFixedFrame method. Without setting the lunar fixed frame, third body occlusion calculations may be slightly inaccurate when radiation is obscured by the Moon. See the External Data topic for more information on obtaining JPL Ephemerides and configuring them in STK Components.
In STK 11, the default constant value for solar luminosity is 3.839e+26 watts. Old versions of STK used a different default value. SimpleSolarRadiationForce in STK Components uses the same value as STK 11 as its default.
In STK 11, the default radius of the solar body is 6.95508e+8 meters. Old versions of STK used a different default value. SunCentralBody in STK Components uses the same value as STK 11 as its default.
Small differences in how the Earth's geoid Shape (get / set) is represented and used to transform between geodetic and cartesian positions may cause slight discrepancies in ephemeris between STK Components and STK. The iteration involved in computing geodetic positions causes numerical noise which will create small discrepancies between two different algorithms and will grow over several integration steps.
Care should be taken when noting settings on types requiring vectors to the Sun or other celestial bodies. Force models will often provide options indicating whether to use apparent or true vectors. STK 11 and STK Components share the same defaults and in most cases use apparent vectors accounting for light time delay and aberration where radiation is involved.
STK uses a ratio of area/mass to denote constants for drag and solar radiation. Due to the modular nature of STK Components, the constants are specified directly, leaving the choice of whether to use a scalar ratio up to the user. So, for the STK defaults (a ratio of 0.02 m2/kg for a 1000 kg spacecraft), the corresponding reference area would be 20 m2. You could also create a Scalar representing the STK ratio value and multiply by the Scalar representing mass.
Note that when comparing values between any two sources, care needs to be taken that interpolation schemes are not inserting additional numerical error above and beyond that associated with propagation. To match precisely, it's important that the values be compared at the same time, in the same time standard, and that time needs to be EXACTLY at an ephemeris point.
Using a RungeKuttaFehlberg78Integrator using a fixed 60 second step size, with SphericalHarmonicGravity, ThirdBodyGravity to model solar and lunar perturbations, ScalarDensityJacchiaRoberts, SimpleSolarRadiationForce using ScalarOccultationDualCone, and a lot of careful management of numerical noise in initial state and time, the correspondence to STK 11 over one day is well below a millimeter of error and in some cases is on the order of a micrometer, depending on the test orbit used.
Lastly, if you do decide to attempt your own validation of STK Components and run into discrepancies, please contact AGI support. Chances are there are settings that are causing the discrepancy. However, in many cases it is important to remember that small "discrepancies" between STK Components and STK may simply be the accumulation of numerical noise and still be well below the accuracy of the force models themselves, most especially ones involving models of the Earth's atmosphere.