Generalized Dynamic Resources

[JoelCourtney]

Currently Merlin's only type of resource that has dynamics (as in it represents a value that changes over time even when you're not touching it) is linear equations. There have been requests and complaints over the years about not being able to represent other types of functions like higher degree polynomials, sinusoids, exponential decay, etc., but I guess there's never been an extremely compelling use case to support them first-class. Users have always been able to work around this limitation by emitting linear approximations with a high enough sample rate for it to be "good enough".

But I think that by not working in that direction, we didn't notice some extremely useful advantages that we could get by supporting arbitrary dynamics. Specifically I'm talking about piecewise functions. Resources are already piecewise functions, but each of those pieces is emitted by a separate write operation, with its own delay in the activity or daemon effect model. If a single write operation could emit many pieces into the future it could unlock some new patterns that would be very powerful.

Hypotheticals

Emitting any behavior would allow modelers to more easily express the future evolution of a resource as it would be if nothing else changed. Say you want to write a preheat curve to a temperature resource. If all goes well this could be a pretty complicated function (on M20 this would be an exponential growth up to a high set point, followed by oscillation between between low and high set points for the rest of the preheat margin and subsequent activity). It would be nice to emit that whole thing in one event at the start of the preheat. But the cool part is if something goes wrong.

If the preheat is aborted (say something else triggers safe mode), we want to replace the future behavior with an exponential decay back to ambient temperature. In Merlin's current design, this means sending some sort of message to whatever routine is emitting the heat curve to tell it to stop, or having the routine constantly check for conditions that would make it abort. But if the entire preheat curve was emitted an hour ago and there's no ongoing routine, you can just overwrite the rest of it with the exponential decay.

Concurrent logic in a single activity

Say you want to model two concurrent behaviors in one activity (like heating and telecom, or driving and power). They both have effects over time, potentially with dynamic delays in between operations. Currently you have two options:

• Spawn child activities, which might not be ideal. For whatever reason, the modeler has decided that these two behaviors belong together, and splitting it into two would conflate the ideas of an activity being a "logical group of actions by the spacecraft" and a "sequence of resource operations in Merlin".
• Interleave the behaviors in one effect model, which could potentially be a huge pain. Now its very difficult to use delay to jump to the next time something happens, because you have to juggle the dynamic delays of both behaviors and interleave them in monotonically increasing time. Just because these two behaviors belong in one activity doesn't mean they should be mixed together in the same control flow.

If you could emit arbitrary functions in to the future, this would let the modeler express one behavior alone, then cognitively rewind time to express the other, without actually having to roll back simulation somehow.

How hard would this be?

Frankly I have no idea. I don't know how hard it would be because I haven't worked much with Merlin internals. Feel free to tell me this is a pipe dream or fundamentally incompatible with the resource framework.

Outside of Merlin, I do know that we could make things easier by flattening out the pieces in each profile, regardless of whether those pieces occurred at a write operation or in between.

[bradNASA]

The streamline contrib library that David Legg developed has an Unstructured resource which is meant to be a catchall for functions over time for which we don't have a customized resource type. BTW, there is a Polynomial resource which supports piecewise polynomials. The Unstructured resource could be built around a sin(t), for example. If you create this resource, nothing is ever computed for it during simulation unless a task asks for the value or if a registered resource is defined in terms of it. So, if you want to display it in the UI, you can convert it to a piecewise linear function. Here's some example code that shows how to do that. SRL's mission model uses code similar to this for resources modeling sunlight on Mars based on geometry, etc., that you would often just get from SPICE. Wrapping SPICE calls in an Unstructured resource could be useful, too.

[JoelCourtney]

Huh, well I guess I was completely misinformed lol. I didn't think this was practically possible. Thanks!

[bradNASA]

It's certainly possible to have some complex events emitted that can change a resource in creative ways. The Europa Clipper model often emits lambda functions to operate on a resource state just to avoid having to enumerate specific effect types. I suppose an Unstructured resource could be defined to accept a lambda function in an emitted event that replaces the time-based function inside the Unstructured.

[bradNASA]

Regarding concurrent logic in an activity, I think this awkwardness is due to the modeling being procedural. Spawning has the same meaning in simulation as it does in executing pocedural code (Java); spawning a thread is a common way to get concurrency. A declarative language captures concurrency more simply. An example would be good here, but . . .

[bradNASA]

You ask how hard all this would be. I'm not sure if David's implementation addresses all of the things you mention, but what David did was really hard, at least for David. . . . I mean, even for David. ;-)

[jmdelfa]

@JoelCourtney, @bradNASA . Here is an example of polynomial implemented by @ewferg that we use to model power production:

MutableResource<Unstructured<Double>> unstructuredPower = MutableResource.resource(Unstructured.timeBased(t -> { long deltaMillis = Duration.addToInstant(planStart, t).toEpochMilli() - config.decayStart().toEpochMilli(); double newPower = config.numRTGs() * config.bolPowerPerRTG() * Math.exp(-config.decayRate()/xxx * deltaMillis / YearToMillis); // decay rate is number of years return newPower; }))

this.powerProduction = PolynomialResources.asPolynomial$( UnstructuredResources.approximateAsLinear(unstructuredPower, 1e-4)); Naming.name(powerProduction, "rtg.powerProduction");

The main problem is the performance. In Endurance, I simulate a mission (>200k activities) in 30 seconds. When I add the power model with RTG and Battery, the simulation takes ~300 seconds, which is a huge impact.

[DavidLegg]

To Brad's point - Unstructured resources could represent these kind of piecewise functions, but they completely erase the structure of the dynamics to do it. I think the point of this proposal is that having that piecewise structure, potentially as a wrapping layer over our regular dynamics objects, is very useful. I think that could be true - I'm swayed by use cases like "temporarily increase this resource" or "compute the maximum of two resources" being handled not by a task that changes some cell somewhere, but by a dynamics type that can express the entire piecewise-polynomial (in these examples) answer in one shot.

I think that the piecewise-dynamics part of this idea shouldn't be too hard to implement, actually. I think you could write an interface called Piecewise<D>, which implements Dynamics by taking a Dynamics D. I think Piecewise forms a monad, and I'd expect that monad to distribute over our current monad stack, such that you could write Resource<Piecewise<D>> for any dynamics type D and get all the monad methods we know and love for that type. From there, we have a couple options. We could add methods to the registrar to accept piecewise discrete and linear dynamics, and it would run a notifying task to tell Aerie to re-sample each piece. Or, we could fold that logic into the existing registrar methods, and fold Piecewise into the existing resource monad stack. That would make our "full" dynamics type ErrorCatching<Expiring<Piecewise<D>>>.

One final note on implementation - for performance, you probably want the pieces in this piecewise object in something like a lazy list. Something that only computes a piece when it's asked for, unlike a List, but also stores that piece so it can be retrieved many times, unlike a Stream. I'm thinking of things like the approximation for the RTG - getting a piece of that dynamics is fairly expensive, because the approximation code runs optimizers and stuff. Also, there's no reason to limit how many pieces that dynamics could have - as the simulation goes on, it should just keep stacking more pieces onto that approximation, effectively expanding an ever-increasing slice of a theoretically infinite list of pieces. Another idea I'm stealing from Haskell 😄