Working with a Project Page

A project page contains all experiments and models associated with a project. Experiments appear in the experiments table, in the EXPERIMENTS tab. Models appear in the models table, in the MODELS tab.

The Trains Web-App (UI) also provides an All projects page containing all experiments and models in all projects.

Archived experiments and models

To assist you in focusing on active experimentation, the Trains Web-App (UI) provides an archive. Experiments and models in the archive do not appear on project pages or the All projects page. They are still associated with their projects, and can be restored to their projects, if the project has not been deleted.

The experiments table

The experiments table is a customizable list of all experiments associated with a project. Use it to open the experiment details pane containing all experiment information, and to work with experiments. Also, use it as tracking leaderboard to monitor experimentation.

The experiments table columns in their default order are below. Dynamically order the columns by dragging a column heading to a new position. By default, the DESCRIPTION column is hidden. To show it, click and then select the DESCRIPTION checkbox.

  • TYPE - Type of experiment. Trains supports multiple experiments for a variety of workflows, include:
    • training
    • testing
    • application
    • controller
    • data_processing
    • inference
    • monitor
    • optimizer
    • qc
    • service
    • custom
  • NAME - Experiment name.
  • TAGS - Descriptive, user-defined, color-coded tags assigned to the experiment. Use tags to classify experiments, and filter the list. See Using experiment tags.
  • STATUS - Experiment state (status), including:
    • Draft - The experiment is editable, not running locally, not in any stage of remote execution (Pending, Running, Completed, Failed, or Aborted), and can be run (see rerunning, reproducing, and tuning experiments).
    • Pending - The experiment in a queue, and is awaiting a worker to fetch and execute it. It can be dequeued.
    • Running - The experiment is running, either locally or remotely. It can be Published or Aborted.
    • Completed - The experiment terminated successfully. It can be Published or Reset.
    • Failed - The experiment terminated with an error. It can be Reset and may run successfully without changes, depending upon the reason for the failure.
    • Aborted - The experiment terminated. A user aborted the experiment, or it was terminated programmatically. It can be Reset and may run successfully without changes, depending upon the reason for the failure.
    • Published - The experiment is not running, locally or remotely, and is read-only. Its model is in a shared library, and can be used by other experiments. The experiment can be cloned.
  • PROJECT - Experiment's project.
  • USER - User creating or cloning the experiment. This is the only default column that is neither sortable nor a filter.
  • STARTED - Elapsed time since the experiment started. To view the date and time, hover over the elapsed time.
  • UPDATES - Elapsed time since the last update to the experiment. To view the date and time, hover over the elapsed time.
  • ITERATION - Last or most recent iteration of the experiment.
  • DESCRIPTION - A description of the experiment. For cloned experiments, the description indicates it is auto generated with a timestamp. By default, the DESCRIPTION column is hidden. To show it, click and then select the DESCRIPTION checkbox.

Customizing the experiments table

You can customize the experiments table by adding and hiding columns, sorting, and filtering. Changes are persistent (cached in the browser), and represented in the URL so that you can save customized settings in a browser bookmark and share it with teammates.

Use experiment table customization for various use cases, including:

  • Sorting models by metrics - Models are associated with the experiments that created them. To sort models by metrics, we use the experiments table. For each metric, use the last value, the minimal value, and / or the maximal value.
  • Tracking hyperparameters - Track hyperparameters by adding them as columns, and applying filters and sorting.

Customize any combination of the following:

  • Add metrics - Click + METRICS > Expand a metric > Select the LAST (value), MIN (minimal value), and / or MAX (maximal value) checkboxes.
  • Add hyperparameters - Click > Click CUSTOMIZE COLUMNS > HYPER PARAMETERS > select the hyperparameter checkboxes.
  • Dynamic column ordering - Drag a column title to a different position.
  • Hide columns - Click > clear the checkboxes of columns to hide.
  • Filter columns - Type of experiment, experiment status (state), user
  • Sort columns - Metrics and hyperparameters, type of experiment, experiment name, start and last update elapsed time, and last iteration.

Auto refresh

Auto refresh allows you to continually monitor experiments by providing regular updates to the experiments table. The Trains Web-App (UI) keeps your auto refresh setting consistent between the experiments table, and the experiments comparison page.

Go to experiment details

  • On a project page, in the experiments table, click the experiment. The experiment's details pane slides open. The details pane contains execution and general information, hyperparameters, artifacts, and experiment results.

Go to resources utilization monitoring

If an experiment is running in a worker, you can view resource utilization by the experiment.

  • In the experiments table, right click the experiment > View worker. The Workers & Queues page opens, showing the Workers tab containing the metrics chart and worker information, see the Workers and Queues documentation page.

Go to queues management

If an experiment is enqueued, you manage that queue, including reordering experiments in it, moving experiments to other queues, and removing experiments. This opens the Workers & Queues page, in the Queues tab, where you can also view resource metrics for queues.

An enqueued experiment has a status of Pending, and is awaiting a worker to fetch and execute it.

  • In the experiments table, right click the experiment > Click Manage Queue.

Archiving experiments

Archive experiments so that they do not appear on the active experiments table. They only appear in the archive. You can restore from the archive later.

To archive an experiment:

Archive experiments using one of the following methods:

  • In the experiments table, archive one experiment - Right click the experiment Archive > ARCHIVE.
  • In the experiments table, archive multiple experiments - Select the experiment checkboxes > Archive > ARCHIVE.
  • In the details pane, archive one experiment - Click (menu) > Archive > ARCHIVE.

Ignore the comparison footer

The comparison footer appears when you select more than one experiment. For archiving and restoring, ignore it.

To restore an experiment:

Restore experiments from the archive using one of the following methods:

  1. Click OPEN ARCHIVE
  2. Restore one or multiple experiments:
    • In the experiments table, restore one experiment - Right click the experiment Restore > RESTORE.
    • In the experiments table, restore multiple experiments - Select the experiment checkboxes > Restore > RESTORE.
    • In the details pane, restore one experiment - Click (menu) > Restore > RESTORE.

Moving experiments to projects

To better organize experimentation, you can change the project with which an experiment is associated by moving it to another project.

To move an experiment to another project:

  • In the experiments table, right click the experiment > Click Moving To Project > Select a project > Click MOVE.

You can also move experiments from one project to another from the experiment's details pane menu.