AMPL File Generation with Performance Indicator Topological Sorting

[martaroz]

Currently, performance indicators in the generated AMPL file are defined separately from their formulas. This results in a multi-step definition process, as seen below:

# Performance indicators = composite metrics that have at least one variable in their formula
var mean_cpu_consumption_all;
var mean_requests_per_second;

# Performance indicator formulas
subject to define_mean_cpu_consumption_all : mean_cpu_consumption_all = sum_cpu_consumption_all/spec_components_1_traits_0_properties_replicas;
subject to define_mean_requests_per_second : mean_requests_per_second = sum_requests_per_second/spec_components_0_traits_0_properties_replicas;

This formulation is inefficient from the solver perspective, because solver will treat the performance indicators as variables. Therefore, performance indicators should be defined directly within the formula:

var mean_cpu_consumption_all = sum_cpu_consumption_all/spec_components_1_traits_0_properties_replicas;
var mean_requests_per_second = sum_requests_per_second/spec_components_0_traits_0_properties_replicas;

It is important to note that AMPL loads the file line by line. If a performance indicator is used in a formula, it must be defined before its usage to avoid reference errors. This necessitates an approach to ensure the correct order of variable declarations through topological sorting of dependencies.

[GeirHo]

As I thought, the original way to define the performance indicators was legal, but not working AMPL! The malformed performance indicator definitions now blocks reconfigurations in the FIRE use case. The AMPL file generated now is as follows:

# Variables
var spec_components_4_properties_traits_0_properties_replicas integer >= 1.0, <= 4.0 := 1;

# Metrics.  Note that we only emit metrics that are in use.  Values will be provided by the solver.
## Raw metrics
param messages_per_minute;  # messages_per_minute
## Composite metrics
param messages_per_minute_promille;  # messages_per_minute_promille

# Constants
param replicas;

# Performance indicators = composite metrics that have at least one variable in their formula
var loadfactor;
# Performance indicator formulas
subject to define_loadfactor : loadfactor = messages_per_minute / spec_components_4_properties_traits_0_properties_replicas;

# Cost parameters - for all components, and use of node-candidates tensor
# Utility functions
maximize uf :
  exp( -(messages_per_minute_promille/spec_components_4_properties_traits_0_properties_replicas -1)^2 );

# Default utility function: specified in message to solver

# Constraints extracted from `/sloViolations`. For these we don't have name from GUI, must be created
# For the solver, SLOs must be negated and operators must be >=, <= (not '>', '<')
subject to constraint_0 : loadfactor <= 1000.0;
# Constraints specified with `type: constraint` in `/utilityFunctions` 

However, the variable 'loadfactor' never gets a value from the solver, and the solver concludes that the problem is 'infeasible' since it cannot satisfy the 'constraint_0'. Changing the definition of the performance indicator to what it should have been makes the solver correctly solve the problem and provide the expected solution to the FIRE reconfiguration.

# Variables
var spec_components_4_properties_traits_0_properties_replicas integer >= 1.0, <= 4.0 := 1;

# Metrics.  Note that we only emit metrics that are in use.  Values will be provided by the solver.
## Raw metrics
param messages_per_minute;  # messages_per_minute
## Composite metrics
param messages_per_minute_promille; # messages_per_minute_promille

# Constants
param replicas;

# Performance indicators = composite metrics that have at least one variable in their formula
var loadfactor = messages_per_minute / spec_components_4_properties_traits_0_properties_replicas;

# Cost parameters - for all components, and use of node-candidates tensor
# Utility functions
maximize uf :
    exp( -(messages_per_minute_promille/spec_components_4_properties_traits_0_properties_replicas -1)^2 );

# Default utility function: specified in message to solver

# Constraints extracted from `/sloViolations`. For these we don't have name from GUI, must be created
# For the solver, SLOs must be negated and operators must be >=, <= (not '>', '<')
subject to constraint_0 : loadfactor <= 1000.0;
# Constraints specified with `type: constraint` in `/utilityFunctions` '''