Add flexibility in CoexistenceGoal timing

[anselrd]

endsAt/startsAt/endsWithin/startsWithin are insufficient to link activities together for the Clipper use case. These clauses do not provide a way to connect activities with a guaranteed buffer period between them. For example, movement that precedes an activity may require settling time during which that activity should not start. Currently this is achieved by specifying endsAt, which is often too strict and can decrease performance by adding simulation cycles or preclude the success of the goal depending on the model. Ideally users would specify an arbitrary window with lower and upper bounds relative to the coexisting activity's start and end time.

A more effective system would allow a user to specify not only one of the window boundaries in [starts|ends]Within, but both. This could be achieved by adding endsBy and endsAfter along with startsBy and startsAfter, or by adding complexity to the existing *Within arguments.

[dyst5422]

This seems like a side effect of (perhaps intentional) insufficient depth of modeling.

When you talk about "settling time", I'm guessing it is a loose proxy for some other unmodeled resource - like thermal load, vibrational energy, or some such thing.

Just trying to understand whether extending the constraint grammar is really the correct solution in this case.

[anselrd]

I think that in most cases you're right, but I don't know that it means the constraint grammar isn't the right solution. For one, we already have a way of specifying relative timing for coexistence goals, but in my mind the current limitations are a bit arbitrary and artificial. Why does one of the boundaries have to be the start or end of the coexisting activity? Also, encoding this specific type of pattern in the mission model is a bit clunky since there is no first principles model that drives it -- we just have some waiting period after something else occurs. I've written that pattern in for other things, but it seems unwarranted here because its only purpose would be for scheduling and would often result in wasted computations

[sschaffe]

PS there is a general concept in simple temporal constraint networks literature (STNs/TCNs) of constraint bounds being an interval, so for example "A.end precedes B.start by [5min,20min]", which admits any separation between those bounds. And I even think the underlying scheduling engine already handles that flexibility in its TCN propagation.

[sschaffe]

to underscore a specific issue Ansel is struggling with, the underlying activity model not only takes an uncontrollable duration to complete the setup turn for his observation, but that duration ends on certain discretization cycles (due to the way gnc commands are collected, dispatched, and observed). So it might not be possible to find a start time for A such that it exactly ends at B's start, only within some discretization margin around that. But there's no way to express that margin either (EndsWithin is the wrong semantic, since it would allow intrusion into the settling time).

[sschaffe]

Dylan, to answer your question about the physics of the situation, yes it is an unmodeled resource: namely the slowly dampening vibrational energy of the spacecraft (especially the very long solar arrays). Some observations require much more stringent pointing than others and so more settling time, configured in their scheduling rule relationships. Modeling the mechanical vibration is out of scope for our model, though we could conceivably add some additional parent activity (SlewWithSettle?) with a "settleDuration" parameter that is just a dead waiting period tacked on to the nominal end of the main Slew activity.

[dyst5422]

@sschaffe It seems like a simplified model based on some operational guidelines could fit this problem well - encode a more direct proxy for the mechanical vibrations into the resources (vibration level) that could be scheduled against with a less than operator that is dependent on the activity type relationships.

Again, not saying that SHOULD be the solution, just that it COULD be a solution.

[sschaffe]

Working through your proposal, you would have an acceptableVibrationThreshold parameter to Slew activity, then put a waitUntil() condition within the Slew activity effect model to await that vibrationLevel resource reached the threshold? And the vibrationLevel resource would be eg a linearly (really exponentially...) decaying double?

[dyst5422]

Something like that, yeah.

The spirit of strategy is to use the parts of the Aerie system as they were/are modeled and designed.

[dyst5422]

I think there are plenty of valid business reasons to go a different route - restrictions on allocations of resources within the projects that adopt Aerie being a prime example.

In this case, it might be less cost to use a constraints mechanism than increase the depth of modeling and the associated dependencies there.

I think one of the nice things about the modeling approach is that you can surface issues of activity dependency/interference that you wouldn't necessarily think of.

[Twisol]

I tend to agree with Dylan's design sense here. It feels like these kinds of assumptions about the flight system behavior ought to be modeled; in fact, I would argue that such assumptions do constitute a model, and I would be concerned about having bits of model scattered throughout the system. Ideally, the mission model should provide whatever(*) observable hooks are necessary for downstream use-cases.

(*) For those things that are behaviorally described by the mission model, anyhow. One of the motivators for external datasets was to relieve the model of reporting resources that aren't actually owned by or determined by the model, e.g. information properly contained in SPICE kernels, DSN allocation files, and other such external models. I don't think that's relevant here, but I wanted to make that subtlety explicit.

[anselrd]

A couple thoughts regarding these philosophies:

1. No model can incorporate everything, or we'd live in a deterministic universe. One can always add more states to a model to trivialize all the downstream logic but that doesn't make it a good idea. In the extreme, you end up with one state that shows how many requirements are satisfied and it's the only one you care about. Merlin/Aerie is a tool that will be used for mission planning and operations but is not the end-all-be-all of the Clipper mission. I recognize that this leaves us with the question of what should we model if some things are to be omitted and assumptions must be made, which is the actual question at hand. As I said before, since the only reason we would include this in the model is to facilitate this particular scheduling logic, I'd rather omit it because...
2. Clipper has complex scheduling needs and a complex mission model and that complexity translates to decreased performance. Where possible and reasonable, it is advantageous to cut some corners. I would rather have fewer states and simpler scheduling logic in general, and especially for a detail as small as this. I know there are many others on the project who share my concerns about scheduling and until those concerns are assuaged I will err on the side of caution with regards to additions to the model and more complex scheduling if the results are the same.
3. It is impossible to completely divorce modeling and scheduling for all but the most trivial use cases, and for a mission like Clipper it is a foregone conclusion that the mission model and scheduling rule structure will not be perfect at launch.
4. While you may disagree with this use case, based on Steve's comments it sounds like aerie already has the capability to provide this flexibility under the hood. I still don't see why it's so much more philosophically sound to allow some flexibility with the timing but not allow complete control over start and end windows. To be honest, I assumed it was just a first cut to provide functionality as quickly as possible and would eventually be updated anyway.

TL;DR - I see your points, but I'd still rather do it the wrong way

[mattdailis]

Ansel you beat me to it :P

Great points all around - I will add my 2 cents that I don't think we were particularly deliberate about this limitation of the Coexistence goal in the scheduling eDSL. It was most likely my lack of understanding of how TimeExpressions are intended to work that lead to this limitation:

https://github.com/NASA-AMMOS/aerie/blob/26a7d5d5f426495bde8fe89a4b900fb1933d38d7/scheduler-driver/src/main/java/gov/nasa/jpl/aerie/scheduler/constraints/timeexpressions/TimeExpression.java

I would support this extension to the Coexistence goal - in this particular case, I don't think it would violate any design principles. Perhaps the way to go would be to expose a richer "TimeExpression" interface

[mattdailis]

Bonus points if, before we try implementing this, @adrienmaillard or @sschaffe can drop a Java example of using a time expression to define an interval that doesn't include the anchor point - looking at the class, I'm having trouble figuring out how that would be expressed

EDIT: Actually, I'm not sure we would need an "interval that doesn't include the anchor point", so maybe disregard this - I suppose we mostly want a "Before" time expression and an "After" time expression, that can compose with an "Offset" time expression

[Twisol]

While you may disagree with this use case

To avoid doubt, it's not that I disagree with the use-case. In fact, I think it's essential to drive forward based on use-cases. I think that there are tradeoffs with any design decision, here, and that we need to go into it eyes wide open, aware of the pros and cons of any option. To that end, I really appreciate your in-depth explanation of the business scenario you're working under -- it deeply informs any choice of solution.

I tend to prefer that things that the model need not know about not be in the model, so I think our philosophies are aligned here. However, I am also a big proponent of using existing capabilities as far as we can; then asking how much further we could push them within their remit; then asking what additional features might better serve purposes.

Assuming Steve is correct that the scheduling engine already supports this kind of reasoning internally, that alleviates a lot of my own concerns about layering on additional complexity.

[mattdailis]

I am also a big proponent of using existing capabilities as far as we can

Agreed here, and to give @anselrd and @sschaffe et al. credit - they are doing all they can to creatively push the scheduling eDSL all the way to its limits

[dyst5422]

Completely agree with all that's been said. My point in the original questioning was not to dissuade from the scheduling goal solution, but to ensure the full conversation occurred such that, as @Twisol pointed out, a sufficient understanding of the trade offs and solution space are understood before prescribing a solution.

I'm fully satisfied with the scheduling grammar solution as long as it's well thought out and not just the nearest hammer.

[anselrd]

I just wanted to provide a bit more context for this. I tried implementing my scheduling rule with settling time incorporated into the model. Let's define and example and use the canonical theme of bananas since this is the public github.

• Activity Peel_Banana that peels (let's say) the top half of the banana and causes the /banana_stability state to be put into the UNSTABLE state. For 5 minutes after the Peel_Banana activity is over, the state will stay UNSTABLE, and if no other Peel_Banana activities occur, then after the 5 minutes is up the state will return to STABLE
• We have another activity Eat_Banana that can only begin when the banana is STABLE. However, while eating the banana, the bottom half must be peeled which means that during the Eat_Banana activity the state returns to UNSTABLE, then consumption resumes after stability is again achieved within the Eat_Banana activity.

The scheduler will fail to place the Eat_Banana activity goal which includes an applyWhen(Discrete.Resource('/banana_stability').equal('STABLE')) clause, since the goal changes the '/banana_stability' windows on which it is predicated. The eDSL doesn't have a way to specify that this is specifically a precondition or a condition that must only be satisfied in order to place the activity and not one that must be true after the activity is simulated.

[jmdelfa]

Propose to close it in favour of #995

[adrienmaillard]

Closing. Solved by #1069.