Open dandelany opened 1 month ago
A couple additional notes and questions to consider:
Seconding this use case. A headless Aerie would make it a much more viable drop-in replacement in legacy ops planning toolchains. I’m particularly thinking of SMAP, but there are likely several other missions that could use such a feature.
Exposing some standard driver interface that lets a user run procedural scheduling, perform a simulation, grab the decomposed activities’ computed attributes, export resource timelines, etc. would be very useful.
Some of this wrapper code has definitely been implemented on a per-adaptation level, but having it as part of the core would be stellar.
Met with Aerie developers today to start sketching out implementation details for this... Some conclusions from this:
node
as an additional system dependencystdout
? Streaming output vs. write once at the end?stdout
unless benefits of doing otherwise are large, for sake of modularitystdout
during simulation, & scheduling which will be interleaving different kinds of resultsstdout
in a performant way.I just want to throw one more thing out there that I think is reasonable to include in our trade space. While we could implement a standalone command line stateless Aerie, it may be sufficient enough to provide a template that users could use to build their own command line utility. This template would include a basic main() function, helper functions to orchestrate simulation and scheduling (and potentially constraint checking in the future), and helper functions for reading/writing data. This would require users to use an IDE to build their own stateless Aerie, but give them more control to design their stateless Aerie to meet their specific needs.
For example, in the SMAP use case, plan and simulation data output is actually not what's important to them. Instead it's sequences embedded in contributed attributes within activities. In this example, SMAP could design their stateless Aerie to simply write out the sequences, which would require some mission-specific code, instead of having to write a separate script to do that work. Admittedly another way to do this would be to write a scheduling procedure that writes out the sequences and run that procedure last, which could be done with a generic stateless Aerie utility that provided an orchestration script. This, in fact, is the way that APGen worked via command line.
Another question I have is whether a user could bundle model and procedure jars together so as not to have to input a bunch of procedure jars separately into a command line utility. It's not uncommon to have 10s (maybe even 100s) of scheduling procedures and dealing with all of those separately would be painful.
Headless Aerie is now demoable for simulation, complete with JSON Sim Results. Open tasks:
Discussed briefly with @JoelCourtney what ought to be expected from scheduling. We agreed that an updated plan.json makes sense as the default output, with an additional flag to optionally write the final sim results to a file. Scheduling goal satisfaction did not come up.
Suggestion from demos: Consider adding a validate
subcommand that runs validation on each activity in the plan.json
Description
Per discussions with @ewferg, some users would like an officially-supported way to use Aerie's simulation and scheduling engines as a simpler "stateless" and "headless" program.
stdin
and writes results tostdout
when complete.Requirements
We don't yet have all of the requirements or implementation fully planned out yet, but I wanted to open this to track our progress. I will meet with @ewferg soon to discuss - please comment here or in Slack if you're interested in participating. As a starting point, here's a rough draft of some requirements:
Notes & Questions
aerie-cli
functionality, and should we consider taking ownership ofaerie-cli
and implementing this feature there, or is this a part of Aerie core, or a new tool altogether that interfaces with Aerie core?