ActivityTypes as activity type paremeters

[Alexander-Da-Great]

Problem

Currently aerie does not have infrastructure to make expressing parent activity types (activities which call other activities within their effect model) easy when trying to interact with the parameters of child activity calls. The current method of allowing users to control parameters used in child activity calls requires activity authors to create a parameter at the level of a parent just to pass through information to a child. For a small number of parameters this is not an issue, however, in cases where child activities have a few dozen or more parameters it quickly becomes difficult to write parent activities that have to duplicate many dozen parameters just to call child activities. The need to manually add parameters to the parent level creates complication / additional work for maintaining the definitions of these activities and opens up the possibility of typos at the definition or implementation for all this non-unique information.

Proposed Solution

One solution is to add support in the aerie core to auto-generate value mappers for activity types as part of the mission model processor. After generating value mappers for every activity type in a model, an activity author can create a parent activity type with parameters that are themselves activity types. This paradigm simplifies parent activity types greatly and makes them much easier to maintain. In addition, we can now clearly outline which parameters are used for parent level effect modeling and which are used to pass through info to child activity calls since the pass through information will just be an activity type parameter.

Prototype Demo

I have created a fork of the aerie repo to demo my approach. The main additions made to the code base include the addition of typeRules for activity types so that parameters can be processed correctly as well as the generation of value mappers for each activity type in a parallel way to how the ActivtyType Mappers are generated.

In addition to the core changes, I have forked the aerie-ui repo to demo UI support for using presets to update activity type parameters. To inform the UI whether a parameter is an activity type I include a new field to the activity type parameter metadata which is added via the getValueSchema method of the activity value mappers. For activity type parameters an additional SearchableDropdown will appear in the UI to which is populated with the presets for the activity in question. When a user selects a preset an event is kicked off which grabs the arguments for said preset and uses them to update the parameter.

Since presets are attached to directives I decided to only allow the selection of presets when interacting with activity type parameters and not allow addition, deletion, or editing of presets.

Selected Activity Interface:

Below we can see that activity type parameters have drop downs for presets. Also, compound types such as lists of activity types are valid parameters as seen with biteBananaActivity

When you select a preset, in this case 'Tip' we see that the activity arguments for peelBananaActivity have changed such that peelDirection is now fromTip

After simulating we can see that biteBananaActivity and peelBananaActivity were successfully used to call their corresponding child activities.

This is what a parent activity implementation for RussianBanana looks like with these changes:

/**
 * Russian Banana Encloses Banana
 *
 * This activity causes a piece of banana to be bitten off and consumed.
 *
 * @subsystem fruit
 * @contact John Doe
 */
@ActivityType("RussianBanana")
public final class RussianBanana {

  @Export.Parameter
  public List<Integer> testints;

  @Export.Parameter
  public List<BiteBananaActivity> biteBananaActivity;

  @Export.Parameter
  public PeelBananaActivity peelBananaActivity;


  @ActivityType.EffectModel
  public void run(final Mission mission) {
    for (final var bite : biteBananaActivity) {
      call(mission, bite);
      delay(Duration.of(30, Duration.MINUTE));
    }
    call(mission, peelBananaActivity);
  }

}

Potential Issues

• Auto-generating value mappers for each activity may be undesirable to some. If that is the case we could include another annotation for activities we would like to use as parameters.
• There may be a better way to inform the UI if a parameter is an activity type rather than using metadata fields.
• There could be issues with circular dependencies, eg. a parent that calls a child activity type which in turn calls the parent type in a parameter. Similar issues could arise with an activity type calling itself in its own parameter. These breaking edge cases would fall on the responsibility of activity authors to not implement, but I would like to get some thoughts on potential ways to avoid / handle these situations.
• The UI updates I made are very much in a demo stage and need more rigorous testing. I can imagine that people involved with UI development will have strong opinions on the implementation of preset drop-downs for parameters.
• Right now there is not back-end support for the presets that are being applied to activity type parameters so when you click away from the activity selection panel and click back the values applied from a preset will still be preset, but the preset that was used will not be selected in the drop-down.

Next Steps

After a discussion between @mattdailis, @bradNASA , @Mythicaeda, @joswig and @Alexander-Da-Great we have a list of questions that need to be answered before going forward with the prototype.

1. Can we move forward effectively with value mappers written in adaptions and work with the UI elements that already exist - parent level presets for updating children activity parameters? This will be partially answered by investigating the following questions.
2. Do need to generate separate files for the ActivityValueMappers or is there a way to form them from the ActivityMappers which would result in the addition of one file for the ActivityValueMapper instances?
3. Can we combine the ActivityMappers and these new ActivityValueMappers so we do not need to auto-generate a new directory containing new files per activity?
4. Stemming from question 3, is there some combination of extending / implementing classes in the region of the ActivityMappers which stream lines the inheritance of these updates and overcomes any potential dependency cycles?
5. Do we need support from the UI to select presets for the children activity type parameters?
6. If we include support for preset application on these new parameters what backend work will need to be applied to accomplish tasks like nesting presets of children in a preset for a parent?
7. What is the best way to inform the front end that an activity parameter is an activity type and how should we store info on what preset was applied to a given parameter (assuming that we have agreed that UI support for parameter preset selection is needed)

[Alexander-Da-Great]

This work also allows for scheduling goals to be written with activity presets as demonstrated below:

export default (): Goal => {
  return Goal.ActivityRecurrenceGoal({
    activityTemplate: ActivityTemplates.RussianBanana({
      testints: [1],
      biteBananaActivity: [ActivityPresets.BiteBanana["One"]],
      peelBananaActivity: ActivityPresets.PeelBanana["Tip"]
    }),
    interval: Temporal.Duration.from({ days: 2 }),
  });
}

One downside of my current prototype is that you cannot tell if an activity was produced via a preset since we do not have separate directives for each of the children.

[mattdailis]

@Alexander-Da-Great here's what I had in mind in terms of leveraging existing functionality:

https://github.com/NASA-AMMOS/aerie/compare/example/activity-type-as-parameter

I'll add my notes from this morning's meeting - though I think you had a better list of open questions

Notes from our meeting this morning:

• Use case: makes it easier to give users some control over child activities
  • Is this okay? Yes, it doesn't violate any Aerie principles
• Uses value schema metadata to tell the UI that this is an activity
• Override some parameters
• Preference not to auto-generate validations: manual control is useful for things like overrides

Open questions:

• Can we consolidate these value mappers with activity mappers?
• What about presets?
• What about validations?
• How much of this can be achieved with existing functionality?
• Are recursive value mappers a problem?
• How does this impact scheduling?

[Alexander-Da-Great]

@mattdailis , I added my questions in the Next Steps section of the initial discussion thread above. Maybe we can just tag on to that section and then respond in the comments?

[Alexander-Da-Great]

Also that is a clean implementation. This would definitely simplify the changes I have thus far to only need one additional file in the generated classes.

[mattdailis]

Right... I would also suggest that a one-liner method per child activity type is a small price to pay to use this feature (as long as a small fraction of activities are expected to leverage this feature), and should satisfy the "MVP" portion of our use cases. Extending this feature to include specialized UI support, presets, validations, and scheduling support is all on the table, but it appears to me that the base feature is already supported with minimal work on the mission model side (as a partial answer to question 1)

[mattdailis]

Could you describe the "override" use case one more time? I want to make sure I understand how that mechanic is expected to work

[Alexander-Da-Great]

What do you mean by override use case? Are your referring to question 4?

[mattdailis]

Apologies, I should have specified - we talked about how sometimes you would want to take a child activity as a parameter, but also take an additional parameter that "overrides" one of the parameters in the child. Did I understand that correctly?

[Alexander-Da-Great]

Yes that is one use case I brought up. Here is an example to illustrate what I am talking about: Imagine we have a parent with an optional type parameter of Optional<Data>. Maybe we have a child which has a Data type parameter and in the parent we have logic which says "if the Optional<Data> type parameter is empty, call the child with default parameters, else call the child with the parent type Optional<Data> value".

[Alexander-Da-Great]

In this case we have a child activity type parameter that has arguments used to construct the child call. However, the parent can have a parameter separate to this child activity type parameter which is used in the construction of the call method and may or may not override whatever arguments are found in said child.

[Alexander-Da-Great]

Comment to address the questions at the end of the first post:

1. While we could move forward with adaptation specific (manual) implementations of value mappers, it would not be advisable since it would not allow for further UI development / support and since auto-gen value mappers have been simplified.
2. No we do not ; we can get them from the value mappers by writing a record which implements ValueMapper and takes a parameter of ActivityMapper
3. Yes, see question 2 response.
4. Kind of, the solution proposed now still calls for a new record type to be implemented but it is a very small addition and is relatively clean.
5. Defer Answering till I can talk with UI members.
6. Deferred till 5 in answered.
7. Deferred till 6 is answered.