Prevent dynamic allocation for plans with negative utility threshold

[bjoernschroeder]

• Prevents dynamic allocation for plans with negative utility threshold
• Skips the creation of RunningPlans and unnecessary calculations

[veerajsk]

Some background:

• The engine invokes the dynamic allocation rule for every running plan for every engine tick
• The rule basically computes the next best assignment & if the utility of this assignment is > utility threshold, then it switches the assignment for the current agent. Note, this is different from the allocation rule which computes the initial assignment for the agent.
• Since most plans have a single entry point & we don't use any special task assignment we don't expect the assignment to ever change after the initial assignment is made by the allocation rule, this means that we unnecessarily execute this rule multiple times a second solving an entire task assignment problem & allocating running plans (1 for each plan that is currently active in the entire plan tree) repeatedly
• This also magnified the memory leak that is fixed in Deactivate config change listener after starting the engine #482

[Dale-Koenig]

Does "utilityThreshold": -1.0 already have the meaning that assignments hsould never be changed?
no, but a utility of -1 means that the assignment is invalid

[Dale-Koenig]

Would it be possible to more generally always skip dynamic allocation for plans where you can guarantee that utility threshold cannot be hit? Like if utility is bounded to [0,1], and current utility is 0.95, then even if utility threshold is 0.1 we already know there is no reason to try dynamic allocation

[veerajsk]

Would it be possible to more generally always skip dynamic allocation for plans where you can guarantee that utility threshold cannot be hit? Like if utility is bounded to [0,1], and current utility is 0.95, then even if utility threshold is 0.1 we already know there is no reason to try dynamic allocation

I tried to look if utility is restricted to [-1,1] anywhere in alica currently, but I couldn't confirm that it indeed is. Atleast there seems to be no limit for max value. But I also think it makes sense to restrict between [-1,1] so let me dig a bit more to explore in this direction

[Prajapati-Pawan]

.