Skip to main content
Version: Next

Automating Orchestration

Previously, we've demonstrated using Ax for ask-tell optimization, a paradigm in which we "ask" Ax for candidate configurations and "tell" Ax our observations. This can be effective in many scenerios, and it can be automated through use of flow control statements like for and while loops. However there are some situations where it would be beneficial to allow Ax to orchestrate the entire optimization: deploying trials to external systems, polling their status, and reading reading their results. This can be common in a number of real world engineering tasks, including:

  • Large scale machine learning experiments running workloads on high-performance computing clusters
  • A/B tests conducted using an external experimentation platform
  • Materials science optimizations utilizing a self-driving laboratory

Ax's Client can orchestrate automated adaptive experiments like this using its method run_trials. Users create custom classes which implement Ax's IMetric and IRunner protocols to handle data fetching and trial deployment respectively. Then, users simply configure their Client as they would normally and call run_trials; Ax will deploy trials, fetch data, generate candidates, and repeat as necessary. Ax can manage complex orchestration tasks including launching multiple trials in parallel while still respecting a user-defined concurrency limit, and gracefully handling trial failure by allowing the experiment to continue even if some trials do not complete successfully or data fetching fails.

In this tutorial we will optimize the Hartmann6 function as before, but we will configure custom Runners and Metrics to mimic an external execution system. The Runner will calculate Hartmann6 with the appropriate parameters, write the result to a file, and tell Ax the trial is ready after 5 seconds. The Metric will find the appropriate file and report the results back to Ax.

Learning Objectives

  • Learn when it can be appropriate and/or advantageous to run Ax in a closed-loop
  • Configure custom Runners and Metrics, allowing Ax to deploy trials and fetch data automatically
  • Understand tradeoffs between parallelism and optimization performance

Prerequisites

Step 1: Import Necessary Modules

First, ensure you have all the necessary imports:

import os
import time
from typing import Any, Mapping

import numpy as np
from ax.api.client import Client
from ax.api.configs import RangeParameterConfig
from ax.api.protocols.metric import IMetric
from ax.api.protocols.runner import IRunner, TrialStatus
from ax.api.types import TParameterization

Step 2: Defining our custom Runner and Metric

As stated before, we will be creating custom Runner and Metric classes to mimic an external system. Let's start by defining our Hartmann6 function as before.

# Hartmann6 function
def hartmann6(x1, x2, x3, x4, x5, x6):
alpha = np.array([1.0, 1.2, 3.0, 3.2])
A = np.array([
[10, 3, 17, 3.5, 1.7, 8],
[0.05, 10, 17, 0.1, 8, 14],
[3, 3.5, 1.7, 10, 17, 8],
[17, 8, 0.05, 10, 0.1, 14]
])
P = 10**-4 * np.array([
[1312, 1696, 5569, 124, 8283, 5886],
[2329, 4135, 8307, 3736, 1004, 9991],
[2348, 1451, 3522, 2883, 3047, 6650],
[4047, 8828, 8732, 5743, 1091, 381]
])

outer = 0.0
for i in range(4):
inner = 0.0
for j, x in enumerate([x1, x2, x3, x4, x5, x6]):
inner += A[i, j] * (x - P[i, j])**2
outer += alpha[i] * np.exp(-inner)
return -outer

hartmann6(0.1, 0.45, 0.8, 0.25, 0.552, 1.0)
Output:
np.float64(-0.4878737485613134)

Next, we will define the MockRunner. The MockRunner requires two methods: run_trial and poll_trial.

run_trial deploys a trial to the external system with the given parameters. In this case, we will simply save a file containing the result of a call to the Hartmann6 function.

poll_trial queries the external system to see if the trial has completed, failed, or if it's still running. In this mock example, we will check to see how many seconds have elapsed since the run_trial was called and only report a trial as completed once 5 seconds have elapsed.

Runner's may also optionally implement a stop_trial method to terminate a trial's execution before it has completed. This is necessary for using early stopping in closed-loop experimentation, but we will skip this for now.

class MockRunner(IRunner):
def run_trial(
self, trial_index: int, parameterization: TParameterization
) -> dict[str, Any]:
file_name = f"{int(time.time())}.txt"

x1 = parameterization["x1"]
x2 = parameterization["x2"]
x3 = parameterization["x3"]
x4 = parameterization["x4"]
x5 = parameterization["x5"]
x6 = parameterization["x6"]

result = hartmann6(x1, x2, x3, x4, x5, x6)

with open(file_name, "w") as f:
f.write(f"{result}")

return {"file_name": file_name}

def poll_trial(
self, trial_index: int, trial_metadata: Mapping[str, Any]
) -> TrialStatus:
file_name = trial_metadata["file_name"]
time_elapsed = time.time() - int(file_name[:4])

if time_elapsed < 5:
return TrialStatus.RUNNING

return TrialStatus.COMPLETED

It's worthwhile to instantiate your Runner and test it is behaving as expected. Let's deploy a mock trial by manually calling run_trial and ensuring it creates a file.

runner = MockRunner()

trial_metadata = runner.run_trial(
trial_index=-1,
parameterization={
"x1": 0.1,
"x2": 0.45,
"x3": 0.8,
"x4": 0.25,
"x5": 0.552,
"x6": 1.0,
},
)

os.path.exists(trial_metadata["file_name"])
Output:
True

Now, we will implement the Metric. Metrics only need to implement a fetch method, which returns a progression value (i.e. a step in a timeseries) and an observation value. Note that the observation can either be a simple float or a (mean, SEM) pair if the external system can report observed noise.

In this case, we have neither a relevant progression value nor observed noise so we will simply read the file and report (0, value).

class MockMetric(IMetric):
def fetch(
self,
trial_index: int,
trial_metadata: Mapping[str, Any],
) -> tuple[int, float | tuple[float, float]]:
file_name = trial_metadata["file_name"]

with open(file_name, 'r') as file:
value = float(file.readline())
return (0, value)

Again, let's validate the Metric created above by instantiating it and reporting the value from the file generated during testing of the Runner.

# Note: all Metrics must have a name. This will become relevant when attaching metrics to the Client
hartmann6_metric = MockMetric(name="hartmann6")

hartmann6_metric.fetch(trial_index=-1, trial_metadata=trial_metadata)
Output:
(0, -0.4878737485613134)

Step 3: Initialize the Client and Configure the Experiment

Finally, we can initialize the Client and configure the experiment as before. This will be familiar to readers of the Getting Started with Ax tutorial -- the only difference is we will attach the previously defined Runner and Metric by calling configure_runner and configure_metrics respectively.

Note that when initializing hartmann6_metric we set name=hartmann6, matching the objective we now set in configure_optimization. The configure_metrics method uses this name to ensure that data fetched by this Metric is used correctly during the experiment. Be careful to correctly set the name of the Metric to reflect its use as an objective or outcome constraint.

client = Client()
# Define six float parameters for the Hartmann6 function
parameters = [
RangeParameterConfig(name=f"x{i + 1}", parameter_type="float", bounds=(0, 1))
for i in range(6)
]

client.configure_experiment(
parameters=parameters,
# The following arguments are only necessary when saving to the DB
name="hartmann6_experiment",
description="Optimization of the Hartmann6 function",
owner="developer",
)
client.configure_optimization(objective="-hartmann6")
client.configure_runner(runner=runner)
client.configure_metrics(metrics=[hartmann6_metric])

Step 5: Run trials

Once the Client has been configured, we can begin running trials.

Internally, Ax uses a class named Scheduler to orchestrate the trial deployment, polling, data fetching, and candidate generation.

Scheduler state machine

The run_trials method provides users with control over various orchestration settings as well as the total maximum number of trials to evaluate:

  • parallelism defines the maximum number of trials that may be run at once. If your external system supports multiple evaluations in parallel, increasing this number can significantly decrease experimentation time. However, it is important to note that as parallelism increases, optimiztion performance often decreases. This is because adaptive experimentation methods rely on previously observed data for candidate generation -- the more tirals that have been observed prior to generation of a new candidate, the more accurate Ax's model will be for generation of that candidate.
  • tolerated_trial_failure_rate sets the proportion of trials are allowed to fail before Ax raises an Exception. Depending on how expensive a single trial is to evaluate or how unreliable trials are expected to be, the experimenter may want to be notified as soon as a single trial fails or they may not care until more than half the trials are failing. Set this value as is appropriate for your context.
  • initial_seconds_between_polls sets the frequency at which the status of a trial is checked and the results are attempted to be fetched. Set this to be low for trials that are expected to complete quickly or high for trials the are expected to take a long time.
client.run_trials(
max_trials=30,
parallelism=3,
tolerated_trial_failure_rate=0.1,
initial_seconds_between_polls=1,
)
Output:
[INFO 05-24 05:04:35] Scheduler: Scheduler requires experiment to have immutable search space and optimization config. Setting property immutable_search_space_and_opt_config to True on experiment.
[INFO 05-24 05:04:35] Scheduler: Running trials [0]...
[INFO 05-24 05:04:36] Scheduler: Running trials [1]...
[INFO 05-24 05:04:37] Scheduler: Running trials [2]...
[INFO 05-24 05:04:38] Scheduler: Retrieved COMPLETED trials: 0 - 2.
[INFO 05-24 05:04:38] Scheduler: Running trials [3]...
[INFO 05-24 05:04:39] Scheduler: Running trials [4]...
[INFO 05-24 05:04:41] Scheduler: Running trials [5]...
[INFO 05-24 05:04:42] Scheduler: Retrieved COMPLETED trials: 3 - 5.
[INFO 05-24 05:04:43] Scheduler: Running trials [6]...
[INFO 05-24 05:04:47] Scheduler: Running trials [7]...
[INFO 05-24 05:04:50] Scheduler: Running trials [8]...
[INFO 05-24 05:04:51] Scheduler: Retrieved COMPLETED trials: 6 - 8.
[INFO 05-24 05:04:52] Scheduler: Running trials [9]...
[INFO 05-24 05:04:56] Scheduler: Running trials [10]...
[INFO 05-24 05:04:59] Scheduler: Running trials [11]...
[INFO 05-24 05:05:00] Scheduler: Retrieved COMPLETED trials: 9 - 11.
[INFO 05-24 05:05:02] Scheduler: Running trials [12]...
[INFO 05-24 05:05:06] Scheduler: Running trials [13]...
[INFO 05-24 05:05:09] Scheduler: Running trials [14]...
[INFO 05-24 05:05:10] Scheduler: Retrieved COMPLETED trials: 12 - 14.
[INFO 05-24 05:05:11] Scheduler: Running trials [15]...
[INFO 05-24 05:05:16] Scheduler: Running trials [16]...
[INFO 05-24 05:05:19] Scheduler: Running trials [17]...
[INFO 05-24 05:05:20] Scheduler: Retrieved COMPLETED trials: 15 - 17.
[INFO 05-24 05:05:22] Scheduler: Running trials [18]...
[INFO 05-24 05:05:27] Scheduler: Running trials [19]...
[INFO 05-24 05:05:29] Scheduler: Running trials [20]...
[INFO 05-24 05:05:30] Scheduler: Retrieved COMPLETED trials: 18 - 20.
[INFO 05-24 05:05:33] Scheduler: Running trials [21]...
[INFO 05-24 05:05:35] Scheduler: Running trials [22]...
[INFO 05-24 05:05:37] Scheduler: Running trials [23]...
[INFO 05-24 05:05:38] Scheduler: Retrieved COMPLETED trials: 21 - 23.
[INFO 05-24 05:05:40] Scheduler: Running trials [24]...
[INFO 05-24 05:05:43] Scheduler: Running trials [25]...
[INFO 05-24 05:05:45] Scheduler: Running trials [26]...
[INFO 05-24 05:05:46] Scheduler: Retrieved COMPLETED trials: 24 - 26.
[INFO 05-24 05:05:47] Scheduler: Running trials [27]...
[INFO 05-24 05:05:50] Scheduler: Running trials [28]...
[INFO 05-24 05:05:52] Scheduler: Running trials [29]...
[INFO 05-24 05:05:53] Scheduler: Retrieved COMPLETED trials: 27 - 29.

Step 6: Analyze Results

As before, Ax can compute the best parameterization observed and produce a number of analyses to help interpret the results of the experiment.

It is also worth noting that the experiment can be resumed at any time using Ax's storage functionality. When configured to use a SQL databse, the Client saves a snapshot of itself at various points throughout the call to run_trials, making it incredibly easy to continue optimization after an unexpected failure. You can learn more about storage in Ax here.

best_parameters, prediction, index, name = client.get_best_parameterization()
print("Best Parameters:", best_parameters)
print("Prediction (mean, variance):", prediction)
Output:
Best Parameters: {'x1': 0.0, 'x2': 0.05586863264629562, 'x3': 0.624023847483389, 'x4': 0.33020902161668236, 'x5': 0.33558120032555894, 'x6': 0.7070757188322988}
Prediction (mean, variance): {'hartmann6': (np.float64(-2.4049202968572274), np.float64(0.0017650054334269775))}
# display=True instructs Ax to sort then render the resulting analyses
cards = client.compute_analyses(display=True)

Parallel Coordinates for hartmann6

The parallel coordinates plot displays multi-dimensional data by representing each parameter as a parallel axis. This plot helps in assessing how thoroughly the search space has been explored and in identifying patterns or clusterings associated with high-performing (good) or low-performing (bad) arms. By tracing lines across the axes, one can observe correlations and interactions between parameters, gaining insights into the relationships that contribute to the success or failure of different configurations within the experiment.

loading...

Summary for hartmann6_experiment

High-level summary of the Trial-s in this Experiment

trial_indexarm_nametrial_statusgeneration_nodehartmann6x1x2x3x4x5x6
000_0COMPLETEDCenterOfSearchSpace-0.5053150.50.50.50.50.50.5
111_0COMPLETEDSobol-0.1057110.307310.5397780.0019810.0889180.6406620.450834
222_0COMPLETEDSobol-0.0579920.8606870.1358060.5678450.9688360.4010770.827535
333_0COMPLETEDSobol-0.0993830.5868840.7891380.4871240.4394520.0057870.723689
444_0COMPLETEDSobol-0.035240.0185570.3864470.9274250.6200120.764980.101367
555_0COMPLETEDMBM-0.0296710.7495160.4982840.5374560.4916650.7916350.397176
666_0COMPLETEDMBM-0.6199380.4528050.6079140.566890.45190.4509180.451903
777_0COMPLETEDMBM-0.6822370.4912660.3325040.2732330.5065250.5068250.619221
888_0COMPLETEDMBM-0.1093780.7482670.6099780.6585290.5556150.5263180.487513
999_0COMPLETEDMBM-0.8418770.4510340.2798460.1996950.503940.4892260.656081
101010_0COMPLETEDMBM-0.2390.4653330.454060.1029860.2591370.6319720.521083
111111_0COMPLETEDMBM-0.1355660.4530280.4103490.2664250.7034590.453340.947527
121212_0COMPLETEDMBM-0.7944630.4175450.1657830.0924420.4734610.517560.639551
131313_0COMPLETEDMBM-0.2120880.4187860.4833780.0553610.481980.5725730.890547
141414_0COMPLETEDMBM-0.4369490.4228970.0484390.1982640.4874120.0291140.567154
151515_0COMPLETEDMBM-1.524360.3618540.2371380.2018240.50380.3838540.64405
161616_0COMPLETEDMBM-1.797130.418604000.2805360.3909220.66915
171717_0COMPLETEDMBM-0.0873760.3464940.4557020.1085250.8273480.4099660.647018
181818_0COMPLETEDMBM-2.017580.3535430.0814980.1034950.3429910.3308370.507827
191919_0COMPLETEDMBM-2.4217800.0558690.6240240.3302090.3355810.707076
202020_0COMPLETEDMBM-0.26790410.08379300.3515780.3337180.446833
212121_0COMPLETEDMBM-2.012900.0951980.0897520.2406470.3120370.770074
222222_0COMPLETEDMBM-0.9811040.073066010.3064480.3268680.485727
232323_0COMPLETEDMBM-0.6717920.103870.03977610.2485380.308331
242424_0COMPLETEDMBM-2.071260.04081200.4240520.315160.3441110.476425
252525_0COMPLETEDMBM-1.833180.11956700.3968080.2669850.3517980.894801
262626_0COMPLETEDMBM-0.235249000.4409220.3768420.3213470.116419
272727_0COMPLETEDMBM-2.800230.06932500.3787950.2769120.3198780.654954
282828_0COMPLETEDMBM-2.46575000.3866190.2900040.3622590.667798
292929_0COMPLETEDMBM-2.861930.14908500.3988380.2099980.297040.650269

Sensitivity Analysis for hartmann6

Understand how each parameter affects hartmann6 according to a second-order sensitivity analysis.

loading...

x5 vs. hartmann6

The slice plot provides a one-dimensional view of predicted outcomes for hartmann6 as a function of a single parameter, while keeping all other parameters fixed at their status_quo value (or mean value if status_quo is unavailable). This visualization helps in understanding the sensitivity and impact of changes in the selected parameter on the predicted metric outcomes.

loading...

x4 vs. hartmann6

The slice plot provides a one-dimensional view of predicted outcomes for hartmann6 as a function of a single parameter, while keeping all other parameters fixed at their status_quo value (or mean value if status_quo is unavailable). This visualization helps in understanding the sensitivity and impact of changes in the selected parameter on the predicted metric outcomes.

loading...

x5, x6 vs. hartmann6

The contour plot visualizes the predicted outcomes for hartmann6 across a two-dimensional parameter space, with other parameters held fixed at their status_quo value (or mean value if status_quo is unavailable). This plot helps in identifying regions of optimal performance and understanding how changes in the selected parameters influence the predicted outcomes. Contour lines represent levels of constant predicted values, providing insights into the gradient and potential optima within the parameter space.

loading...

x6 vs. hartmann6

The slice plot provides a one-dimensional view of predicted outcomes for hartmann6 as a function of a single parameter, while keeping all other parameters fixed at their status_quo value (or mean value if status_quo is unavailable). This visualization helps in understanding the sensitivity and impact of changes in the selected parameter on the predicted metric outcomes.

loading...

x4, x5 vs. hartmann6

The contour plot visualizes the predicted outcomes for hartmann6 across a two-dimensional parameter space, with other parameters held fixed at their status_quo value (or mean value if status_quo is unavailable). This plot helps in identifying regions of optimal performance and understanding how changes in the selected parameters influence the predicted outcomes. Contour lines represent levels of constant predicted values, providing insights into the gradient and potential optima within the parameter space.

loading...

Cross Validation for hartmann6

The cross-validation plot displays the model fit for each metric in the experiment. It employs a leave-one-out approach, where the model is trained on all data except one sample, which is used for validation. The plot shows the predicted outcome for the validation set on the y-axis against its actual value on the x-axis. Points that align closely with the dotted diagonal line indicate a strong model fit, signifying accurate predictions. Additionally, the plot includes 95% confidence intervals that provide insight into the noise in observations and the uncertainty in model predictions. A horizontal, flat line of predictions indicates that the model has not picked up on sufficient signal in the data, and instead is just predicting the mean.

loading...

Conclusion

This tutorial demonstrates how to use Ax's Client for closed-loop optimization using the Hartmann6 function as an example. This style of optimization is useful in scenarios where trials are evaluated on some external system or when experimenters wish to take advantage of parallel evaluation, trial failure handling, or simply to manage long-running optimization tasks without human intervention. You can define your own Runner and Metric classes to communicate with whatever external systems you wish to interface with, and control optimization using the OrchestrationConfig.