I just started using Orekit. It’s a great tool and thanks for developing it!
Recently I met a problem with the InterSatDirectViewDetector (I think?), and I hope you could help me out.
So I was trying to simulate some ISL measurements which would be used later for orbit determination. I wanted to build an EventBasedScheduler which would be used in the generator. And I selected InterSatDirectViewDetector as the event detector. After setting up, I tried to debug the script. Strangely, the program seemed stuck and didn’t stop. But when I checked the CPU consumption, the program almost didn’t use any CPU powers… Like it’s paused and waiting for something…
I also tried to use ContinuousScheduler instead, and it works fine. So I guess the problem is from the detector. I checked the documation, I found it states that
I’m not sure if this is the problem.I tried to build the two satellites provider (numerical propagator) as independtly as possible (I created new instance and variable for every parameter that they may share), but still no luck.
Could you help me finding out where I did it wrong? I hope I told it clearly, if you need any further information, please tell me. Thanks a lot in advance!
I suggest you look at the IntersatellitesRangeBuilderTest in the junit tests of the library. Here is an excerpt:
Generator generator = new Generator();
ObservableSatellite receiver = generator.addPropagator(buildPropagator());
final Orbit o1 = context.initialOrbit;
// for the second satellite, we simply reverse velocity
final Orbit o2 = new KeplerianOrbit(new PVCoordinates(o1.getPVCoordinates().getPosition(),
o1.getPVCoordinates().getVelocity().negate()),
o1.getFrame(), o1.getDate(), o1.getMu());
ObservableSatellite remote = generator.addPropagator(new KeplerianPropagator(o2));
final double step = 60.0;
// beware that in order to avoid deadlocks, the slave PV coordinates provider
// in InterSatDirectViewDetector must be *different* from the second propagator
// added to generator above! The reason is the event detector will be bound
// to the first propagator, so it cannot also refer to the second one at the same time
// this is the reason why we create a *new* KeplerianPropagator below
generator.addScheduler(new EventBasedScheduler<>(getBuilder(new Well19937a(seed), receiver, remote),
new FixedStepSelector(step, TimeScalesFactory.getUTC()),
generator.getPropagator(receiver),
new InterSatDirectViewDetector(context.earth, new KeplerianPropagator(o2)),
SignSemantic.FEASIBLE_MEASUREMENT_WHEN_POSITIVE));
final double period = o1.getKeplerianPeriod();
AbsoluteDate t0 = o1.getDate().shiftedBy(startPeriod * period);
AbsoluteDate t1 = o1.getDate().shiftedBy(endPeriod * period);
SortedSet<ObservedMeasurement<?>> measurements = generator.generate(t0, t1);
The important part is that we build two different propagators for orbit o2. In this case, they are both Keplerian propagators for testing purposes, but of course for accurate measurements generation you need to build proper numerical propagators with full force models.
What you experience is probably a deadlock as explain in the comment.
You can also consider using ephemeris mode to avoid repeating the integration twice. Something like:
NumericalPropagator n = ...;
n.setEphemerisMode();
n.propagate(a, b)
Propagator e1 = n.getGeneratedEphemeris();
Propagator e2 = e1.getGeneratedEphemeris;
Now e1 and e2 should use the same in memory ephemeris, but be otherwise be independent. Perhaps faster but uses more memory. Note that I didn’t test the code above.