A suite of software tools and services created to support activity planning and sequencing needs of missions with modeling, simulation, scheduling, and validation capabilities.
Please read the CONTRIBUTING.md guidelines for branch naming and pull request conventions.
Note: this PR does not actually change any functionality, per se. It merely requires activities to explicitly opt-in to having their durations controlled by the scheduler.
Currently, the scheduler assumes that all activities have a duration parameter, which can be used to control their duration. This is not, in general, true.
One option to reconcile this is to have the scheduler inspect the parameters of an activity type, and check if there is a duration parameter with the correct type. However, this feels wrong to me, since it ascribes a meaning to a particular parameter name - something we've managed to avoid thus far. Parameter names should be completely up to the mission modelers.
The option I chose to pursue is to add an annotation, @ControllableDuration(parameterName = "myDurationParam") that allows an activity definition to opt-in to being controllable by the scheduler. I added a validateControllableDurationParameter method to the MissionModelParser that checks that the string provided:
The scheduler will be able to call TaskSpecType::getDurationType on a particular activity's TaskSpecType, and get back whether the activity has opted-in to having a controllable duration:
![[AERIE-1656] Activities opt-in to controllable duration](https://avatars.githubusercontent.com/u/1189602?v=4)
public sealed interface DurationType {
record Controllable(String parameterName) implements DurationType {}
record Uncontrollable() implements DurationType {}
}
The contract between the scheduler and the mission model is that after simulating any activity marked with @ControllableDuration, its actual duration is expected to be equal to the value of the declared duration parameter. The scheduler will rely on this fact to satisfy certain goals (such as lining up the end time of one activity with the start time of another activity).
I modified the scheduler to use getDurationType to look up what parameter to set for a desired duration. For activities with Uncontrollable duration, the scheduler prints a warning, but does not throw an exception. The main reason here is I do not want to impede uncontrollable activities in existing plans. Future work is to test that the scheduler works with an existing plan.
I ran the aerie lander tests, and they passed (though they don't seem to have very clear success criteria, so I want to spend some time in a future PR making the tests stricter).
I'll make a corresponding PR to aerielander momentarily.
This will, of course, need to be documented, but it's still in flux. We have a meeting with some stakeholders next week, where we'll get some feedback.
Uncontrollable. For example, if the scheduler knew that an activity's duration is "Context Independent", it would know that the activity's duration is invariant under translation in time, which could reduce the necessity to re-simulate.This PR adds a gradle action to copy files matching constraints-*.ts out of the constraints-dsl-compiler and into the scheduling-dsl-compiler.
It then replaces the scheduling language's state-based windows expressions with the constraints windows expressions.
Activity expressions are treated separately, because they are intended to have a slightly different semantics in the scheduler, since they are not well represented by an Expression<Windows>. We can revisit these in a future PR.
Some amount of rebasing/coordination will be required between this PR and the constraints type checking PR.
Existing scheduler tests were updated (since their assertions turned out to be incorrect). Then, the tests were updated again to match the new syntax. They now pass.
This section in the wiki will need to be updated: https://github.com/NASA-AMMOS/aerie/wiki/Scheduling-Guide#coexistence-goal-coming-soon
Mission modelers currently don't have access to a plan's start time.
With this PR a plan start time Instant parameter can optionally be declared in the top-level mission model ("Mission.java") constructor.
If a top-level mission model defines a constructor with Instant as the 2nd argument then the sim. start time will be passed to the mission model upon instantiation. If the Instant parameter (or Registrar parameter and optionally a "Configuration" parameter) is declared out-of-order then an actionable error message is now presented at compile-time. See the section below for examples.
More concretely, the following top-level mission model constructor parameters are allowed (lifted from MissionModelParser.java):
![[AERIE-1935] Expose plan start time to mission model](https://avatars.githubusercontent.com/u/2623817?v=4)
// - (Registrar, Instant, Configuration)
// - (Registrar, Configuration)
// - (Registrar, Instant)
// - (Registrar)
As seen above, both sim. start time and mission model configuration parameters are optional. However, if both are defined "Configuration" must be declared last. This ensures backwards compatibility with existing mission models while allowing future mission models to make use of this Instant.
See the future work section for a discussion on alternative approaches for this PR.
See foo-missionmodel's MissionConfigurationTest.
When the following Mission constructor parameters are declared in an allowable order no compile-time error is thrown:
public Mission(final Registrar registrar, final Instant planStart, final Configuration config) {
...
}
However, when Instant (or any of the above parameters) are declared out of expected order a custom error message will appear:
.../foomissionmodel/package-info.java:21: error: The top-level model's constructor is expected to accept [gov.nasa.jpl.aerie.merlin.framework.Registrar, java.time.Instant, gov.nasa.jpl.aerie.foomissionmodel.Configuration], found: [gov.nasa.jpl.aerie.merlin.framework.Registrar, gov.nasa.jpl.aerie.foomissionmodel.Configuration, java.time.Instant]
In this example, Mission's constructor was declared with a plan start Instant in the wrong expected order:
public Mission(final Registrar registrar, final Configuration config, final Instant planStart) {
...
}
deployment/Environment.md and deployment/README.md for information on UNTRUE_PLAN_START.Initially a @PlanStart annotation was considered but in prototyping this implementation it was found that this change would require plan information to be passed in at our GQL layer (to allow any configured context to have plan information).
This would break existing GQL queries and more tightly couple our plan and model "domains".
See Slack thread for more context and discussion on this.
This PR enables each loaded model to acquire their own isolated instance of SPICE. (I kind of can't believe I'm writing those words!) The key ingredients are:
The host program must not have JNISpice available, much less depend on JNISpice itself. It is absolutely crucial that the classes cspice.basic.CSPICE and gov.nasa.jpl.aerie.spice.SpiceLoader be loaded by the model JAR's ClassLoader, not the Aerie application classloader. As I found out the hard way, nested classloaders check their parents first before attempting any specialized behavior. So the parent classloader must not satisfy requests for JNISpice classes.
The native library must be loaded from completely independent copies (with completely different canonical file paths) every time. It isn't sufficient to simply hard-link a file with a different name to the same libJNISpice.so; the JVM and the OS both must be convinced that they are independent images, or else either the JVM will throw an error (it won't tolerate explicit duplicates, or even distinct files with the same path) or the OS will silently provide a handle to the same library you've previously opened.
("But wait, Jonathan -- how can two distinct files have the same path???" Well, made-up interrogator, if you load a library at a path, delete that file, and create a new one in its place, your JVM will have a reference to a file that is no longer accessible to the filesystem, but did have a particular path on load, and you will have a new file that the JVM has not (yet) loaded at the same path!)
I've gone through the Aerie codebase and removed all indirect dependencies on SPICE that are not model-side. The SPICE classes used to be accessed through merlin-sdk, which meant they were available everywhere. I moved them to the contrib module, and cleaned up any minor dependencies on contrib from the rest of the system.
The current NAIF distribution of JNISpice for MacOS throws us another curveball: it compiles the library with extra flags (see "Future work") that cause the first-loaded library to greedily satisfy all matching native method resolutions, even if the JVM is specifically asking for a symbol from a different loaded library. I was able to make a custom build of libJNISpice.jnilib and confirm that, all together, these factors allow each model to have their own isolate of SPICE.
I've replaced the libJNISpice.jnilib in our source tree with my custom-built one. Neither this nor the old one is particularly easy to reproduce, so I don't think I'm making the situation any worse with this change. Nonetheless, it's worth noting that I did build both an Intel and an M1 version of the library and fuse them together (with lipo), since the old one was similarly universal.
On Linux, this StackOverflow discussion indicates that we should get the desired behavior without any changes. We'll see.
I modified Banananation's Mission class to load SPICE and perform a furnsh bracketed by two ktotals printed to screen. I then made a little main() in simulation-driver, confirmed that it didn't already observe CSPICE using the system classloader, and loaded banananation.jar three times in succession.
Normally this would output 0 1 1 2 2 3, as each successive model instance observes the previous one's kernel loads.
Now, it outputs 0 1 0 1 0 1. Isolation! (Holy smokes!)
We need to document for users this new understanding about how native libraries interact with models. In particular, if models bundle their own native libraries and load them, they should automatically be scoped to that model. (As long as they don't include antagonizing flags like libJNISpice.jnilib did, at least!)
This is extremely delicate right now; if any application-side Aerie component ever needs SPICE and needs to work with arbitrary mission models, the application-level SPICE is likely to be shared with all the models it loads. We ought to document this somewhere, and very clearly and carefully, because it is not the kind of thing that is very loud when it breaks.
Maybe we should add a ClassLoader.loadClass("spice.basic.CSPICE") call in a reasonable location for the application-side components, and throw an error if it succeeds? At least then it will break loudly.
I have a prototype solution for this, but it is not the kind of thing that can easily be placed on top of JNISpice. It's something that would need to be integrated pretty well into JNISpice proper. So I'm not sure how likely that is to happen.
Petition NAIF to remove the flags -flat_namespace -undefined suppress from their build script for libJNISpice.jnilib. As it stands, the -flat_namespace flag causes all native methods to get resolved to the first loaded copy of the library, making it impossible to interact with multiply-loaded SPICE libraries.
Petition NAIF to distribute an M1 (arm64) version of JNISpice. If they distribute separate Intel and M1 versions with the above flags removed, we can easily fuse them together into a universal library using lipo.
Implement a child-first classloader (see also)to better insulate models from the application classpath. If both sources provide a class, we want the model to see the model's version, not the application's version. (This would likely allow the application to depend on CSPICE without causing global sharing to occur -- though some details around native library loading are still unclear.)
Make the scheduler less dependent on the particular representation of controllable duration parameters. The model could always override the value mapper used for Duration, so the scheduler's use of DurationValueMapper was already suspect; my changes here just make that dependency explicit.
We ought to instead add a method fromDuration to the SchedulerModel that allows the scheduler to turn a given Duration into a SerializedValue suitable for that parameter. I have a mock-up here.
Includes the autogenerated EDSL API documentation in our documentation site
Makes EDSL documentation part of the docsite generation and includes them in the docsite outputs. Includes some links to them in the existing docsite files.
Release procedure:
Ensure the current docs for EDSLs are in docs/edsl-api-docs/<constraints|schedling>-edsl-api/develop (can run ./gradlew publishDocs to generate it there) and copy it to a versioned directory (ie docs/edsl-api-docs/<constraints|schedling>-edsl-api/v0.13.2). Note that this versioned directory MUST have the same name as the release tag for it to properly be linked in the site docs.
This new versioned directory needs to be committed to git so we maintain the older versions of edsl docs.
Generated them locally and was able to link locally - will have to build + deploy to see if it works in CI
None
I've taken #17 and split it into three branches. I'll PR them sequentially, so we can focus on one at a time.
EDIT: If it would help declutter, I can make a separate PR for the refactoring commits. Let me know if anyone would prefer that.
The focus of this PR is reporting a value as part of simulation results upon completion of an activity instance.
The commits in this PR fall into one of the following phases
We continue to support void return types as before. These activities will have a SerializedValue.UNIT return value.
I've done some simple manual testing by giving BiteBanana a non-void return type and viewing it via hasura. Some more thorough verification is needed prior to merging.
This work is part of the Activity Computed Attributes working group: https://wiki.jpl.nasa.gov/display/MPSA/Working+Group%3A+Activity+Computed+Attributes
Step 2: (AERIE-1630) Make this value available to the caller Step 3. (AERIE-1631) Tag events with activity ids
Thanks to work on previous PRs (#209, #211, #189), simulation results are now entirely separated from the simulate Hasura action. Constraint violations are now queried with constraintViolations, resource samples with resourceSamples, and simulated activities directly from the database. UI has been updated to use new queries.
Manually tested UI to ensure functionality is maintained.
 Include EDSL API docs in docs](https://avatars.githubusercontent.com/u/13282627?v=4)
![[AERIE-1893 ] Remove deprecated sim results response code](https://avatars.githubusercontent.com/u/49844593?v=4)
query {
simulate(planId: 1) {
status
reason
results
}
}
used to get a response of
{
"data": {
"simulate": {
"status": "complete",
"results": {
"unfinishedActivities": {},
"start": "2022-023T12:12:12.000000",
"activities": {
...
"constraints": {
"model/no waste": [
...
"events": [
{
"graph": {
"suffix": {
...
now
query {
simulate(planId: 1) {
reason
status
}
}
receives
{
"data": {
"simulate": {
"status": "complete"
}
}
}
Need to rework existing documentation on simulate responses, and point towards new API calls.
Opens the door for simulation streaming to database, as clients are no longer dependent on monolithic simulate call
by commit:
![[AERIE-2145] Gaps in external profiles](https://avatars.githubusercontent.com/u/23269439?v=4)
nullableP parser currently cannot unparse nulls because it throws a NoSuchElementException when unwrapping. The workaround is to throw a ClassCastException which the chooseP parser will catch try the next option. @Twisol was this the intended pattern? I don't see another way to do it, but throwing for control flow on the happy path seems iffy.ProfileSets to be Optional. This allows external dataset profiles to have gaps, but also requires all segments of simulated profiles to be wrapped in Optional.of(). Also, the Post/GetProfileSegmentsActions were updated to write to the new is_gap column of the profile_segment table.I'm in progress writing an e2e test(s) for this.
I have added tutorial docs for uploading external datasets and using them in constraints. I will add a page for scheduling when we enable that.
This branch provides the implementation of the scheduler-server's PostgresResultsCellRepository. The commits on this branch define the Postgres actions that will be used by the repository, and in the final commit the actions are hooked up tot he repository. Do note that some commits have descriptions explaining the motivation for their changes that reviewers may find useful.
Each commit was tested by running ./gradlew classes to make sure all commits compile. ./gradlew test was also run at the end to ensure that no tests were broken. I also made sure the database initializes properly, since the scheduling_request table was modified.
As for testing the postgres actions themselves, I haven't run them since the scheduling agent is still in development.
No documentation updates needed. These features are in development, and not yet documented.
Once the scheduler agent is hooked up we should do some integration testing and make sure a scheduling request can be created and run through our system, even if we have to manually insert the data into the database since the UI isn't hooked up yet. As careful as we try to be, it's difficult to be sure our code that interacts with the database is accurate without actually testing. Since none of this is in use yet, though, it shouldn't be a big deal if there's any issues to fix.
Adds type-checking for the following values in the constraints DSL:
![[AERIE-1674] Persist Scheduling Results](https://avatars.githubusercontent.com/u/7594482?v=4)
ValueSchema.REAL.ForEachActivity - kind of
(instance: ActivityInstance<A extends ActivityTypeName>) => Constraint. Essentially, the alias is no longer a string but a variable. (Thanks @mattdailis for the idea!)ForEachActivity calls .toString() on the function handle and searches through to find the argument name. The "alias" string is set to the argument name and stored inside the ActivityInstance class.instance.parameters().myParameter. The During, StartOf, and EndOf functions are now instance.during(), instance.start() and instance.end().// Forbids the usage of an activity type.
export default (): Constraint => Constraint.ForEachActivity(
"activityType",
(instance) => instance.during().not()
);
Discrete.Resource(...) and instance.parameters().myDiscreteParameter. This is done by adding a __schemaInstance: Schema private field to the Discrete<Schema> class, and populating it with an unrelated dummy default value.Many tests have been added and updated in ConstraintsDSLCompilationServiceTests.
The in-code docs for the constraints API have been updated.
checkmark = committed
__schemaInstance field and how do we make it go away"once in main.tsWhen attempting to simulate a plan whose model loads SPICE, the following error occurs when SPICE is loaded:
java.lang.UnsatisfiedLinkError: /tmp/JNISpice-4439314142500713632.tmp: /tmp/JNISpice-4439314142500713632.tmp: cannot open shared object file: No such file or directory (Possible cause: can't load AMD 64 .so on a AARCH64 platform)
@Twisol and I have so far been discussing this in PR #322.
fix/spice_m1 branch| Status | Count | |---------------|-------| | π Total | 257 | | β Successful | 212 | | β³ Timeouts | 0 | | π Redirected | 0 | | π» Excluded | 0 | | β Unknown | 0 | | π« Errors | 45 |
@Export.WithDefaults](@Export.WithDefaults): Cached: Error (cached) (status code: ERR)@Export.Validation.Subject](@Export.Validation.Subject): Failed: Unreachable mail address: ``@Export.Validation.Subject: Invalid: Email doesn't exist or is syntactically incorrect (status code: ERR)@Export.Template](@Export.Template): Cached: Error (cached) (status code: ERR)@Export.Parameter](@Export.Parameter): Cached: Error (cached) (status code: ERR)@Export.Validation](@Export.Validation): Failed: Unreachable mail address: ``@Export.Validation: Invalid: Email doesn't exist or is syntactically incorrect (status code: ERR)@Export.Validation](@Export.Validation): Failed: Unreachable mail address: `@Export.Validation: Invalid: Email doesn't exist or is syntactically incorrect (status code: ERR)@Export.Parameter](@Export.Parameter): Failed: Unreachable mail address: `@Export.Parameter: Invalid: Email doesn't exist or is syntactically incorrect (status code: ERR)@Export.WithDefaults](@Export.WithDefaults): Failed: Unreachable mail address: ``@Export.WithDefaults: Invalid: Email doesn't exist or is syntactically incorrect (status code: ERR)@Export.Template](@Export.Template): Failed: Unreachable mail address: `@Export.Template: Invalid: Email doesn't exist or is syntactically incorrect (status code: ERR)@Export.WithDefaults](@Export.WithDefaults): Failed: Unreachable mail address: `@Export.WithDefaults: Invalid: Email doesn't exist or is syntactically incorrect (status code: ERR)@Export.Parameter](@Export.Parameter): Failed: Unreachable mail address: ``@Export.Parameter: Invalid: Email doesn't exist or is syntactically incorrect (status code: ERR)@Export.Template](@Export.Template): Failed: Unreachable mail address: ``@Export.Template: Invalid: Email doesn't exist or is syntactically incorrect (status code: ERR)See: https://maven.apache.org/repository/guide-central-repository-upload.html
This would help decrease the barrier to entry a bit since right now you need a GitHub account to use the Aerie Maven GitHub packages.
ciInitial creation of an Aerie open source governance model. This simply adds a GOVERNANCE.md document to describe our governance.
documentationThis is a follow-up to #449. That ticket is about modifying the database to store/validate Anchors. This ticket is about modifying Simulation to process Anchors so that it can start simulating them at the correct time.
featureAs far as I can tell there's no ability to search the aerie documentation website. There's a lot of information in there and as a newcomer it's hard to know where to find things.
https://nasa-ammos.github.io/aerie/stable/
documentation
v2.12.0 to v2.12.1. See the security advisory here.Please see our latest upgrade guide for complete instructions for upgrading from 1.0.0 to 1.0.1.
Full Changelog: https://github.com/NASA-AMMOS/aerie/compare/v1.0.0...v1.0.1
Source code(tar.gz)Please see our latest upgrade guide for complete instructions for upgrading from 0.13.2 to 1.0.0.
scheduler-server by @pcrosemurgy in https://github.com/NASA-AMMOS/aerie/pull/424api-examples by @Mythicaeda in https://github.com/NASA-AMMOS/aerie/pull/456setProperty() in configure block by @pcrosemurgy in https://github.com/NASA-AMMOS/aerie/pull/418Full Changelog: https://github.com/NASA-AMMOS/aerie/compare/v0.13.2...v1.0.0
Source code(tar.gz)@EffectModel function.failWith() reasons by @pcrosemurgy in https://github.com/NASA-AMMOS/aerie/pull/362refreshActivityValidations event trigger by @pcrosemurgy in https://github.com/NASA-AMMOS/aerie/pull/370InvalidArgumentsException -> InstantiationException by @pcrosemurgy in https://github.com/NASA-AMMOS/aerie/pull/371Full Changelog: https://github.com/NASA-AMMOS/aerie/compare/v0.13.1...v0.13.2
Source code(tar.gz)@Validation.Subject annotation is available to report the parameter(s) associated with a particular activity parameter validation response.@Validation.Subject where possible by @pcrosemurgy in https://github.com/NASA-AMMOS/aerie/pull/329ValidationResponse.errors to be null (when success false) by @pcrosemurgy in https://github.com/NASA-AMMOS/aerie/pull/319activity_directive_validations by @pcrosemurgy in https://github.com/NASA-AMMOS/aerie/pull/330
Activity parameter argument validations are available to query on the graphql API via the activity_directive_validations@Parameter support by @pcrosemurgy in https://github.com/NASA-AMMOS/aerie/pull/334Full Changelog: https://github.com/NASA-AMMOS/aerie/compare/v0.13.0...v0.13.1
Source code(tar.gz)Command expansion now passes the computed attributes of a simulated activity to the activity-command expansion process. See docs
Users can now compose a stand alone sequence and generate a seqjson document. See docs
Composite goal types were refactored with the user facing changes being the inPeriod operator of the CardinalityGoal removed from the eDSL, bug fix where the horizon was not set (forAllTimeIn) in the conjunctive goal, and the criterion for satisfaction of composite or/and goal refactored to be similar to the semantics of partialSatisfiability for non-composite goals.
Documentation updates in preparation for publishing of an autogenerated eDSL API documentation similar in style to javadocs.
Scheduler populates source activity metadata field.
Bug fixed where extra quotes would be parsed in a constraint definition.
Secrets have been removed from the repository and Aerie docker compose file now takes secrets as environment parameters.
This change will require any clients to update their graphql query from activity to activity_directive.
Make use of an unconfigured mission model, rather than a configured mission model, wherever possible. This should increase system responsiveness when loading activity plans. This change is the culmination of discussions about which actions need "fully instantiated" mission models, and which actions only need "loaded mission models". The terminology in the code uses the words "Configured Mission Model" to mean one whose constructor had been called, and "Unconfigured Mission Model" for mission models whose factories had been loaded, and directive types extracted, but no constructor had been called.
A bug limiting the number of activity definitions in the annotations processor has been fixed.
The plan start time is now available to the mission model during initialization.
This change will require any clients to update their graphql query from activity to activity_directive.
Full Changelog: https://github.com/NASA-AMMOS/aerie/compare/v0.12.3...v0.13.0
Source code(tar.gz)Activity to Command Expansion
[AERIE-1824] Rework TimeType API by @goetzrrGit in https://github.com/NASA-AMMOS/aerie/pull/241: Time types are now written as R00:15:00 rather than R(Temporal.Duration.from({ minutes: 15 }). The old method is deprecated and will be supported for a few more releases.
https://github.com/NASA-AMMOS/aerie/wiki/Setup-IDE-and-Writting--Expansion-Logic#time
[AERIE-1875] Return Dictionary fields when uploading by @goetzrrGit in https://github.com/NASA-AMMOS/aerie/pull/268: When uploading a command dictionary the API returns the unique id to the new set of commands and associated metadata. https://github.com/NASA-AMMOS/aerie/wiki/Upload-and-Generate-Command-Library-File#upload
Automated Scheduling
Constraints
Documentation
General
Planning (Activity)
[AERIE-1934] Add metadata to activity directives by @dyst5422 in https://github.com/NASA-AMMOS/aerie/pull/245
[AERIE-1943] Mission specific activity directive metadata by @dyst5422 in https://github.com/NASA-AMMOS/aerie/pull/253: These two changes make possible activity metadata via the API. The corresponding Aerie UI change will fully realize this capability for UI users.
feat: add Hasura relationship from plan to plan_dataset by @camargo in https://github.com/NASA-AMMOS/aerie/pull/266
[AERIE-1826] Accumulate activity/configuration instantiation errors by @pcrosemurgy in https://github.com/NASA-AMMOS/aerie/pull/258: When an activity contains erroneous arguments to parameters or insufficient arguments Aerie now returns all errors, as opposed to simply returning the first error encountered.
[AERIE-1497] Raise negative plan duration PG exception by @pcrosemurgy in https://github.com/NASA-AMMOS/aerie/pull/277: Aerie now disallows negative and zero duration plans, raising an error which is reported via the Aerie API.
Full Changelog: https://github.com/NASA-AMMOS/aerie/compare/v0.12.2...v0.12.3
Source code(tar.gz)General
Full Changelog: https://github.com/NASA-AMMOS/aerie/compare/v0.12.1...v0.12.2
Source code(tar.gz)Activity-Command Expansion
Automated Scheduling
General
simulate query response by @skovati in #237SerializedValue LGTM errors by @pcrosemurgy in #238Full Changelog: https://github.com/NASA-AMMOS/aerie/compare/v0.12.0...v0.12.1
Source code(tar.gz)Activity-Command Expansion
Automated Scheduling
Constraints
constraintViolation action by @skovati in https://github.com/NASA-AMMOS/aerie/pull/211General
Simulation
resourceSamples action by @pcrosemurgy in https://github.com/NASA-AMMOS/aerie/pull/189constraintViolations schema addition. An example query is shown in the wikiFull Changelog: https://github.com/NASA-AMMOS/aerie/compare/v0.11.3...v0.12.0
Source code(tar.gz)Activity-Command Expansion
Automated Scheduling
Constraints
General
Simulation
return for activities with return values by @Twisol in https://github.com/NASA-AMMOS/aerie/pull/169Full Changelog: https://github.com/NASA-AMMOS/aerie/compare/v0.11.2...v0.11.3
Source code(tar.gz)Automated Scheduling
Aerie UI
Activity Command Expansion
Full Changelog: https://github.com/NASA-AMMOS/aerie/compare/v0.11.1...v0.11.2
Source code(tar.gz)Simulation
Mission Modeling
Automated Scheduling
Deployment
Activity Command Expansion
Full Changelog: https://github.com/NASA-AMMOS/aerie/compare/v0.11.0...v0.11.1
Source code(tar.gz)MissionModelFactory now takes a concrete config object
MissionModelTest is the sameMissionModelBuilder and associated test take directive registry now
return builder.build(model, registry.taskSpecTypes());return builder.build(model, registry);Mission model now needs a gov.nasa.jpl.aerie.merlin.protocol.model.SchedulerPluginfile in the META-INF)/services directory. This will live alongside the already existing gov.nasa.jpl.aerie.merlin.protocol.model.GeneratedMerlinPlugin. It's contents will be E.g. gov.nasa.jpl.aerie.banananation.generated.GeneratedSchedulerPlugin
Mission Modeling
Activity Command Expansion
scheduler-server by @mattdailis in https://github.com/NASA-AMMOS/aerie/pull/63put-expansion endpoint by @pcrosemurgy in https://github.com/NASA-AMMOS/aerie/pull/92Configurable Logging
INFO-level Hikari logs in dev stack by @pcrosemurgy in https://github.com/NASA-AMMOS/aerie/pull/124Automated Scheduling
Multiple Concurrent Simulation Execution
node_modules/ directory upon gradle clean by @pcrosemurgy in https://github.com/NASA-AMMOS/aerie/pull/88boolean by @goetzrrGit in https://github.com/NASA-AMMOS/aerie/pull/94expansion_set, auto-update expansion_set_to_rule join table by @dyst5422 in https://github.com/NASA-AMMOS/aerie/pull/83Full Changelog: https://github.com/NASA-AMMOS/aerie/compare/v0.10.1...v0.11.0
Source code(tar.gz)int data types rather than string.gov.nasa.jpl.aerie.merlin.framework.annotations.Export class
psql prereq. to building.md by @pcrosemurgy in https://github.com/NASA-AMMOS/aerie/pull/22request_query field by @pcrosemurgy in https://github.com/NASA-AMMOS/aerie/pull/44Full Changelog: https://github.com/NASA-AMMOS/aerie/commits/v0.10.1
Source code(tar.gz)The iFogSimToolkit (with its new release iFogSim2) for Modeling and Simulation of Resource Management Techniques in Internet of Things, Edge and Fog Computing Environments. In the new release Mobili Management, Microservice Management, and Dynamic Clustering mechanisms are added as new features.
NOTE This is a rewritten version of Grasscutter. Find the original project at Grasscutters/Grasscutter. Grasscutter TODO: Write README.md Players Guid
TransRot Version 1.5.3 Steven L. Topper and Robert Q. Topper School of Engineering The Cooper Union ββfor the Advancement of Science and Art New York,
Critter Chronologer a Software as a Service application that provides a scheduling interface for a small business that takes care of animals. This Spring Boot project will allow users to create pets, owners, and employees, and then schedule events for employees to provide services for pets.
A fast and reliable Java micro-library which chooses the sorting algorithm that best fits your needs and sorts the parameter.
react-native-jitsi-meet-sdk React native wrapper for Jitsi Meet SDK Library. This Library implements the Jitsi SDK with a native activity on the Andro
OnClickListenerExample This application shows how to pass adapter items into an activity using interfaces. The sample data set contains two fields rep
StackOperations Download this two java files and implement the methods which are mentioned inside the class. Just use the basic things that I have tau
SimpleArgumentParser Maven <repositories> <repository> <id>jitpack.io</id> <url>https://jitpack.io</url> </repository> </repositories> <de
Netflix Hexagonal Architecture Table of contents About the project Description Built with Installation Requirements to run Usage information Run Licen
ClinQ Simple yet interesting validation mini-framework Features Declarative checks ClinQ.checker(Integer.class) .with(i -> i % 2 == 0) .with(i
one This unit uses Spoon to find program constructs from a Java source file, based on their visibility. It currently supports public and private class
VideoStreamingApplication Purpose Of This Application These days trend of short videos are on rise youtube recently realsed "Shorts" . So , taking ins
English | δΈζη tuya-spring-boot-starter helps you efficiently create cloud development projects regarding the OpenAPI or message subscription capabilit
Zenitsu-Bluetooth Chat Application This sample shows how to implement two-way text chat over Bluetooth between two Android devices, using all the fund
Tasks Planner β¨ Overview Tasks planner is a minimalist collaborative app for planning and managing your tasks with the team and get notifications thro
IRPact IRPact is a framework for agent-based modelling of innovation diffusion of sustainable products in private households. It is written in the Jav
BearSwerve BearSwerve is intended to be an all in one swerve solution including: teleop driving, simulation, trajectory following and more. It combine
Implementation of Greedy Particle Swarm Optimization, HSGA and Hybrid(GA+PSO) for the purpose of Task Scheduling in cloud computing environment using CloudSim
69 Dec 17, 2022
11 Dec 1, 2022
5 Dec 14, 2022
1 Jan 28, 2022
2 Feb 19, 2022
7 May 2, 2022
1 Feb 2, 2022
4 Apr 26, 2022
6 Sep 30, 2022
12 Dec 20, 2022
13 Sep 27, 2022
2 Oct 13, 2021
57 Nov 13, 2022
37 Dec 26, 2022
1 Jan 16, 2022
7 Dec 1, 2022
3 Dec 16, 2021
7 Dec 28, 2022
5 Dec 18, 2022