scheduling mutex condition does not prevent overlap

[srschaffJPL]

Checked for duplicates

No - I haven't checked

Is this a regression?

No - This is a new bug

Version

2.2.1

Describe the bug

Using a mutex scheduling condition does not prevent scheduling of conflicting activities that have duration spans that overlap.

It does appear to prevent them from scheduling the same start time though. It also does work in some other priority orderings.

Reproduction

Create a plan:

• 2030-001T00:00:00 to 2030-005T00:00:00
• eurc model (g24 release)

This condition:

• A+B: export default (): GlobalSchedulingCondition => { return GlobalSchedulingCondition.mutex( [ActivityType.ECM_Power_ON, ActivityType.GENERIC_Power_Data], [ActivityType.ECM_Power_ON, ActivityType.GENERIC_Power_Data] ); }

These goals:

• B/6h: export default (): Goal => { return Goal.ActivityRecurrenceGoal({ interval: Temporal.Duration.from({hours: 6}), activityTemplate: ActivityTemplates.ECM_Power_ON() }) }
• A/1d: export default (): Goal => { return Goal.ActivityRecurrenceGoal({ interval: Temporal.Duration.from({days: 1}), activityTemplate: ActivityTemplates.GENERIC_Power_Data({ duration:"000T12:00:00", type: "A", loadWatts: 0, data: [] }) }) }

Press schedule. It places 16 activities for B (ECM_Power_On) as expected. Considering the mutex, this should leave no room at all to place a 12hr long A (GENERIC_Power_Data) anywhere in the plan. However, it also places 4 instances for A.

(Notably, the mutex works as expected in the reverse priority ordering, ie A then B)

Logs

No response

System Info

2023 M2 Macbook Pro Ventura 13.6.4 (22G513)
Chrome 121.0.6167.184
G24 eurc model release https://github.jpl.nasa.gov/Europa-PESS/clipper-aerie/releases

Severity

Moderate

Workaround

None currently outside of manually scheduling

[srschaffJPL]

I confirmed that the ECM_Power_On activity is not instantaneous, in case anyone else had the same hunch. It always delays at least a second.

And the GENERIC_Power_Data delays exactly as long as the duration parameter. However, it is not annotated as controllable duration.