public class PropagatorsParallelizer extends Object
Multi-satellites propagation is based on multi-threading. Therefore, care must be taken so that all propagators can be run in a multi-thread context. This implies that all propagators are built independently and that they rely on force models that are also built independently. An obvious mistake would be to reuse a maneuver force model, as these models need to cache the firing/not-firing status. Objects used by force models like atmosphere models for drag force or others may also cache intermediate variables, so separate instances for each propagator must be set up.
This class will create new threads for running the propagators.
It adds a new global step handler to manage
the steps all at once, in addition to the existing individual step
handlers that are preserved.
All propagators remain independent of each other (they don't even know
they are managed by the parallelizer) and advance their simulation
time following their own algorithm. The parallelizer will block them
at the end of each step and allow them to continue in order to maintain
synchronization. The global handler will
experience perfectly synchronized steps, but some propagators may already
be slightly ahead of time as depicted in the following rendering; were
simulation times flows from left to right:
propagator 1 : -------------[++++current step++++]>
|
propagator 2 : ----[++++current step++++]--------->
| |
... | |
propagator n : ---------[++++current step++++]---->
| |
V V
global handler : -------------[global step]--------->
The previous sketch shows that propagator 1 has already computed states up to the end of the propagation, but propagators 2 up to n are still late. The global step seen by the handler will be the common part between all propagators steps. Once this global step has been handled, the parallelizer will let the more late propagator (here propagator 2) to go one step further and a new global step will be computed and handled, until all propagators reach the end.
This class does not provide multi-satellite events. As events may truncate steps and even reset state, all events (including multi-satellite events) are handled at a very low level within each propagators and cannot be managed from outside by the parallelizer. For accurate handling of multi-satellite events, the event detector should be registered within the propagator of one satellite and have access to an independent propagator (typically an analytical propagator or an ephemeris) of the other satellite. As the embedded propagator will be called by the detector which itself is called by the first propagator, it should really be a dedicated propagator and should not also appear as one of the parallelized propagators, otherwise conflicts will appear here.
| Constructor and Description |
|---|
PropagatorsParallelizer(List<Propagator> propagators,
MultiSatStepHandler globalHandler)
Simple constructor.
|
| Modifier and Type | Method and Description |
|---|---|
List<Propagator> |
getPropagators()
Get an unmodifiable list of the underlying mono-satellite propagators.
|
List<SpacecraftState> |
propagate(AbsoluteDate start,
AbsoluteDate target)
Propagate from a start date towards a target date.
|
public PropagatorsParallelizer(List<Propagator> propagators, MultiSatStepHandler globalHandler)
propagators - list of propagators to useglobalHandler - global handler for managing all spacecrafts
simultaneouslypublic List<Propagator> getPropagators()
public List<SpacecraftState> propagate(AbsoluteDate start, AbsoluteDate target)
start - start date from which orbit state should be propagatedtarget - target date to which orbit state should be propagatedCopyright © 2002-2022 CS GROUP. All rights reserved.