From 3a4b10e43b88685564b6285353abcc99ce38f0e2 Mon Sep 17 00:00:00 2001 From: pollfly <75068813+pollfly@users.noreply.github.com> Date: Mon, 9 Oct 2023 15:48:19 +0300 Subject: [PATCH] Small edits (#689) --- docs/clearml_agent.md | 2 +- docs/clearml_data/best_practices.md | 2 +- docs/clearml_data/clearml_data.md | 2 +- docs/clearml_data/clearml_data_sdk.md | 2 +- .../data_man_cifar_classification.md | 4 +-- .../data_man_simple.md | 2 +- docs/clearml_sdk/apiclient_sdk.md | 4 +-- docs/clearml_sdk/clearml_sdk.md | 2 +- docs/clearml_sdk/model_sdk.md | 4 +-- docs/configs/env_vars.md | 2 +- .../advanced/multiple_tasks_single_process.md | 2 +- docs/hyperdatasets/task.md | 2 +- docs/pipelines/pipelines.md | 18 +++++------ .../pipelines_sdk_function_decorators.md | 8 ++--- docs/pipelines/pipelines_sdk_tasks.md | 30 +++++++++---------- .../applications/apps_aws_autoscaler.md | 12 ++++---- .../applications/apps_gcp_autoscaler.md | 12 ++++---- docs/webapp/applications/apps_gpu_compute.md | 8 ++--- docs/webapp/applications/apps_hpo.md | 6 ++-- docs/webapp/applications/apps_overview.md | 2 +- .../applications/apps_trigger_manager.md | 2 +- .../webapp/pipelines/webapp_pipeline_table.md | 6 ++-- .../pipelines/webapp_pipeline_viewing.md | 16 +++++----- docs/webapp/webapp_exp_comparing.md | 2 +- docs/webapp/webapp_exp_table.md | 2 +- docs/webapp/webapp_model_comparing.md | 4 +-- docs/webapp/webapp_model_table.md | 2 +- docs/webapp/webapp_profile.md | 4 +-- docs/webapp/webapp_projects_page.md | 4 +-- docs/webapp/webapp_reports.md | 6 ++-- docs/webapp/webapp_workers_queues.md | 18 +++++------ 31 files changed, 95 insertions(+), 97 deletions(-) diff --git a/docs/clearml_agent.md b/docs/clearml_agent.md index e2fb3cac..da1744f3 100644 --- a/docs/clearml_agent.md +++ b/docs/clearml_agent.md @@ -356,7 +356,7 @@ ClearML Agent supports working with one of the following package managers: * [`conda`](https://docs.conda.io/en/latest/) * [`poetry`](https://python-poetry.org/) -To change the package manager used by the agent, edit the [`package_manager.type`](configs/clearml_conf.md#agentpackagemanager) +To change the package manager used by the agent, edit the [`package_manager.type`](configs/clearml_conf.md#agentpackage_manager) field in the of the `clearml.conf`. If extra channels are needed for `conda`, add the missing channels in the `package_manager.conda_channels` field in the `clearml.conf`. diff --git a/docs/clearml_data/best_practices.md b/docs/clearml_data/best_practices.md index 18ad34df..966e396c 100644 --- a/docs/clearml_data/best_practices.md +++ b/docs/clearml_data/best_practices.md @@ -34,7 +34,7 @@ most recent dataset in a project. The same is true with tags; if a tag is specif In cases where you use a dataset in a task (e.g. consuming a dataset), you can easily track which dataset the task is using by using `Dataset.get`'s `alias` parameter. Pass `alias=`, and the task using the dataset -will store the dataset’s ID in the `dataset_alias_string` parameter under the task's **CONFIGURATION > HYPERPARAMETERS > +will store the dataset's ID in the `dataset_alias_string` parameter under the task's **CONFIGURATION > HYPERPARAMETERS > Datasets** section. diff --git a/docs/clearml_data/clearml_data.md b/docs/clearml_data/clearml_data.md index 4399d090..b0608b61 100644 --- a/docs/clearml_data/clearml_data.md +++ b/docs/clearml_data/clearml_data.md @@ -20,7 +20,7 @@ ClearML Data Management solves two important challenges: Moreover, it can be difficult and inefficient to find on a git tree the commit associated with a certain version of a dataset. Use ClearML Data to create, manage, and version your datasets. Store your files in any storage location of your choice -(S3 / GS / Azure / Network Storage) by setting the dataset’s upload destination (see [`--storage`](clearml_data_cli.md#upload) +(S3 / GS / Azure / Network Storage) by setting the dataset's upload destination (see [`--storage`](clearml_data_cli.md#upload) CLI option or [`output_url`](clearml_data_sdk.md#uploading-files) parameter). Datasets can be set up to inherit from other datasets, so data lineages can be created, and users can track when and how diff --git a/docs/clearml_data/clearml_data_sdk.md b/docs/clearml_data/clearml_data_sdk.md index 75615d8b..c14e0794 100644 --- a/docs/clearml_data/clearml_data_sdk.md +++ b/docs/clearml_data/clearml_data_sdk.md @@ -8,7 +8,7 @@ See [Hyper-Datasets](../hyperdatasets/overview.md) for ClearML's advanced querya ::: Datasets can be created, modified, and managed with ClearML Data's python interface. You can upload your dataset to any -storage service of your choice (S3 / GS / Azure / Network Storage) by setting the dataset’s upload destination (see +storage service of your choice (S3 / GS / Azure / Network Storage) by setting the dataset's upload destination (see [`output_url`](#uploading-files) parameter of `Dataset.upload()`). Once you have uploaded your dataset, you can access it from any machine. diff --git a/docs/clearml_data/data_management_examples/data_man_cifar_classification.md b/docs/clearml_data/data_management_examples/data_man_cifar_classification.md index e627c9c7..88ed6a00 100644 --- a/docs/clearml_data/data_management_examples/data_man_cifar_classification.md +++ b/docs/clearml_data/data_management_examples/data_man_cifar_classification.md @@ -97,8 +97,8 @@ trainset = datasets.CIFAR10( ) ``` -In cases like this, where you use a dataset in a task, you can have the dataset's ID stored in the task’s -hyperparameters. Passing `alias=` stores the dataset’s ID in the +In cases like this, where you use a dataset in a task, you can have the dataset's ID stored in the task's +hyperparameters. Passing `alias=` stores the dataset's ID in the `dataset_alias_string` parameter in the experiment's **CONFIGURATION > HYPERPARAMETERS > Datasets** section. This way you can easily track which dataset the task is using. diff --git a/docs/clearml_data/data_management_examples/data_man_simple.md b/docs/clearml_data/data_management_examples/data_man_simple.md index acad2637..6dcfdea7 100644 --- a/docs/clearml_data/data_management_examples/data_man_simple.md +++ b/docs/clearml_data/data_management_examples/data_man_simple.md @@ -118,7 +118,7 @@ You'll need to input the Dataset ID you received when created the dataset above ```bash clearml-data add --files new_data.txt ``` - Which should return this output: + The console should display this output: ```console clearml-data - Dataset Management & Versioning CLI diff --git a/docs/clearml_sdk/apiclient_sdk.md b/docs/clearml_sdk/apiclient_sdk.md index afde54f2..652f1a6e 100644 --- a/docs/clearml_sdk/apiclient_sdk.md +++ b/docs/clearml_sdk/apiclient_sdk.md @@ -3,7 +3,7 @@ title: APIClient --- The `APIClient` class provides a Pythonic interface to access ClearML's backend REST API. It is a convenient low-level access tool. -Through an `APIClient` instance, you can access ClearML’s REST API services: +Through an `APIClient` instance, you can access ClearML's REST API services: * [authentication](../references/api/login.md) - Authentication management, authorization and administration for the entire system * [debug](../references/api/debug.md) - Debugging utilities * [projects](../references/api/projects.md) - Support for defining Projects containing tasks, models, datasets, and/or pipelines @@ -15,7 +15,7 @@ Through an `APIClient` instance, you can access ClearML’s REST API services: ## Using APIClient -`APIClient` makes the ClearML Server’s REST API endpoints available as Python methods. +`APIClient` makes the ClearML Server's REST API endpoints available as Python methods. To use `APIClient`, create an instance of it then call the method corresponding to the desired REST API endpoint, with its respective parameters as described in the [REST API reference page](../references/api/index.md). diff --git a/docs/clearml_sdk/clearml_sdk.md b/docs/clearml_sdk/clearml_sdk.md index 9050eee9..c74c9ae3 100644 --- a/docs/clearml_sdk/clearml_sdk.md +++ b/docs/clearml_sdk/clearml_sdk.md @@ -10,7 +10,7 @@ and other workflows. For installation instructions, see [Getting Started](../getting_started/ds/ds_first_steps.md#install-clearml). ::: -The ClearML Python Package collects the scripts’ entire execution information, including: +The ClearML Python Package collects the scripts' entire execution information, including: * Git repository (branch, commit ID, and uncommitted changes) * Working directory and entry point * Hyperparameters diff --git a/docs/clearml_sdk/model_sdk.md b/docs/clearml_sdk/model_sdk.md index a97e00ba..f52c16cc 100644 --- a/docs/clearml_sdk/model_sdk.md +++ b/docs/clearml_sdk/model_sdk.md @@ -40,7 +40,7 @@ output_model.update_labels({'background': 0, 'label': 255}) ``` ### Updating Models -ClearML doesn’t automatically log the snapshots of manually logged models. To update an experiment’s model use the +ClearML doesn't automatically log the snapshots of manually logged models. To update an experiment's model use the [OutputModel.update_weights](../references/sdk/model_outputmodel.md#update_weights) method. ```python @@ -106,7 +106,7 @@ task.connect(input_model) Retrieve a list of model objects by querying the system by model names, projects, tags, and more, using the [`Model.query_models`](../references/sdk/model_model.md#modelquery_models) and/or the [`InputModel.query_models`](../references/sdk/model_inputmodel.md#inputmodelquery_models) class methods. These -methods return a list of model objects that match the queries. The list is ordered according to the models’ last update +methods return a list of model objects that match the queries. The list is ordered according to the models' last update time. ```python diff --git a/docs/configs/env_vars.md b/docs/configs/env_vars.md index 3ab2213c..7c3f0039 100644 --- a/docs/configs/env_vars.md +++ b/docs/configs/env_vars.md @@ -14,7 +14,7 @@ but can be overridden by command-line arguments. ### General |Name| Description | |---|--------------------------------------------------------------------------------| -|**CLEARML_LOG_ENVIRONMENT** | List of Environment variable names. These environment variables will be logged in the ClearML task’s configuration hyperparameters `Environment` section. When executed by a ClearML agent, these values will be set in the task’s execution environment. | +|**CLEARML_LOG_ENVIRONMENT** | List of Environment variable names. These environment variables will be logged in the ClearML task's configuration hyperparameters `Environment` section. When executed by a ClearML agent, these values will be set in the task's execution environment. | |**CLEARML_TASK_NO_REUSE** | Boolean.
When set to `true`, a new task is created for every execution (see Task [reuse](../clearml_sdk/task_sdk.md#task-reuse)). | |**CLEARML_CACHE_DIR** | Set the path for the ClearML cache directory, where ClearML stores all downloaded content. | |**CLEARML_DOCKER_IMAGE** | Sets the default docker image to use when running an agent in [Docker mode](../clearml_agent.md#docker-mode). | diff --git a/docs/guides/advanced/multiple_tasks_single_process.md b/docs/guides/advanced/multiple_tasks_single_process.md index cb968888..e28b8706 100644 --- a/docs/guides/advanced/multiple_tasks_single_process.md +++ b/docs/guides/advanced/multiple_tasks_single_process.md @@ -9,7 +9,7 @@ In order to log a script in multiple tasks, each task needs to be initialized us method with the `task_name` and `project_name` parameters input. Before initializing an additional task in the same script, the previous task must be manually shut down with the [`close`](../../references/sdk/task.md#close) method. -When the script is executed, it should return something like this: +When the script is executed, the console should display the following output: ```text ClearML Task: created new task id=5c4d2d3674a94e35b10f04d9d2180l62 diff --git a/docs/hyperdatasets/task.md b/docs/hyperdatasets/task.md index ca3deffc..123bb5bb 100644 --- a/docs/hyperdatasets/task.md +++ b/docs/hyperdatasets/task.md @@ -22,7 +22,7 @@ task.connect(dataview) ### Accessing a Task's Dataviews -Use the `Task.get_dataviews` method to access the Dataviews that are connected to a Task. +Use `Task.get_dataviews()` to access the Dataviews that are connected to a Task. ```python task.get_dataviews() diff --git a/docs/pipelines/pipelines.md b/docs/pipelines/pipelines.md index a0604013..e1e4d603 100644 --- a/docs/pipelines/pipelines.md +++ b/docs/pipelines/pipelines.md @@ -14,8 +14,8 @@ can be executed locally, or on any machine using the [clearml-agent](../clearml_ ![Pipeline UI](../img/pipelines_DAG.png) -The [Pipeline Run](../webapp/pipelines/webapp_pipeline_viewing.md) page in the web UI displays the pipeline’s structure -in terms of executed steps and their status, as well as the run’s configuration parameters and output. See [pipeline UI](../webapp/pipelines/webapp_pipeline_page.md) +The [Pipeline Run](../webapp/pipelines/webapp_pipeline_viewing.md) page in the web UI displays the pipeline's structure +in terms of executed steps and their status, as well as the run's configuration parameters and output. See [pipeline UI](../webapp/pipelines/webapp_pipeline_page.md) for more details. ClearML pipelines are created from code using one of the following: @@ -47,7 +47,7 @@ the pipeline via the ClearML Web UI. See [Pipeline Runs](#pipeline-runs). ## Pipeline Features ### Artifacts and Metrics Each pipeline step can log additional artifacts and metrics on the step task with the usual flows (TB, Matplotlib, or with -[ClearML Logger](../fundamentals/logger.md)). To get the instance of the step’s Task during runtime, use the class method +[ClearML Logger](../fundamentals/logger.md)). To get the instance of the step's Task during runtime, use the class method [Task.current_task](../references/sdk/task.md#taskcurrent_task). Additionally, pipeline steps can directly report metrics or upload artifacts / models to the pipeline using these @@ -70,7 +70,7 @@ section) By default, pipeline steps are not cached. Enable caching when creating a pipeline step (for example, see [@PipelineDecorator.component](pipelines_sdk_function_decorators.md#pipelinedecoratorcomponent)). -When a step is cached, the step code is hashed, alongside the step’s parameters (as passed in runtime), into a single +When a step is cached, the step code is hashed, alongside the step's parameters (as passed in runtime), into a single representing hash string. The pipeline first checks if a cached step exists in the system (archived Tasks will not be used as a cached instance). If the pipeline finds an existing fully executed instance of the step, it will plug its output directly, allowing the pipeline logic to reuse the step outputs. @@ -87,13 +87,13 @@ configuration, installed packages, uncommitted changes etc.). You can rerun the pipeline via the [ClearML Web UI](../webapp/pipelines/webapp_pipeline_table.md). To launch a new run for a pipeline, click **+ NEW RUN** on the top left of the pipeline runs page. This opens a **NEW RUN** modal, where you -can set the run’s parameters and execution queue. +can set the run's parameters and execution queue. ![Pipeline params UI](../img/pipelines_new_run.png) The new pipeline run will be executed through the execution queue by a ClearML agent. The agent will rebuild the pipeline according to the configuration and DAG that was captured in the original run, and override the original -parameters’ value with those input in the **NEW RUN** modal. +parameters' value with those input in the **NEW RUN** modal. One exception is for pipelines [created from functions](pipelines_sdk_tasks.md#steps-from-functions) (adding steps to a pipeline controller using [`PipelineController.add_function_step()`](../references/sdk/automation_controller_pipelinecontroller.md#add_function_step)): @@ -107,14 +107,14 @@ lets you modify the pipeline configuration via the UI, without changing the orig ### Pipeline Versions Each pipeline must be assigned a version number to help track the evolution of your pipeline structure and parameters. -If you pass `auto_version_bump=True` when instantiating a PipelineController, the pipeline’s version automatically bumps up +If you pass `auto_version_bump=True` when instantiating a PipelineController, the pipeline's version automatically bumps up if there is a change in the pipeline code. If there is no change, the pipeline retains its version number. ### Tracking Pipeline Progress -ClearML automatically tracks a pipeline’s progress percentage: the number of pipeline steps completed out of the total +ClearML automatically tracks a pipeline's progress percentage: the number of pipeline steps completed out of the total number of steps. For example, if a pipeline consists of 4 steps, after the first step completes, ClearML automatically sets its progress value to 25. Once a pipeline has started to run but is yet to successfully finish, the WebApp will -show the pipeline’s progress indication in the pipeline runs table, next to the run’s status. +show the pipeline's progress indication in the pipeline runs table, next to the run's status. ## Examples diff --git a/docs/pipelines/pipelines_sdk_function_decorators.md b/docs/pipelines/pipelines_sdk_function_decorators.md index bc100f5b..7f7d8513 100644 --- a/docs/pipelines/pipelines_sdk_function_decorators.md +++ b/docs/pipelines/pipelines_sdk_function_decorators.md @@ -62,7 +62,7 @@ def main(pickle_url, mock_parameter='mock'): `services` queue. To run the pipeline logic locally while the components are executed remotely, pass `pipeline_execution_queue=None` -When the function is called, a corresponding ClearML Controller Task is created: its arguments are logged as the task’s +When the function is called, a corresponding ClearML Controller Task is created: its arguments are logged as the task's parameters. When launching a new pipeline run from the [UI](../webapp/pipelines/webapp_pipeline_page.md), you can modify their values for the new run. ![Pipeline new run](../img/pipelines_new_run.png) @@ -94,7 +94,7 @@ def step_one(pickle_data_url: str, extra: int = 43): ``` ### Arguments -* `return_values` - The artifact names for the step’s corresponding ClearML task to store the step’s returned objects. +* `return_values` - The artifact names for the step's corresponding ClearML task to store the step's returned objects. In the example above, a single object is returned and stored as an artifact named `data_frame` * `name` (optional) - The name for the pipeline step. If not provided, the function name is used * `cache` - If `True`, the pipeline controller checks if a step with the same code (including setup, see task [Execution](../webapp/webapp_exp_track_visual.md#execution) @@ -139,7 +139,7 @@ def step_one(pickle_data_url: str, extra: int = 43): * Callbacks - Control pipeline execution flow with callback functions * `pre_execute_callback` and `post_execute_callback` - Control pipeline flow with callback functions that can be called - before and/or after a step’s execution. See [here](pipelines_sdk_tasks.md#pre_execute_callback-and-post_execute_callback). + before and/or after a step's execution. See [here](pipelines_sdk_tasks.md#pre_execute_callback-and-post_execute_callback). * `status_change_callback` - Callback function called when the status of a step changes. Use `node.job` to access the `ClearmlJob` object, or `node.job.task` to directly access the Task object. The signature of the function must look like this: ```python @@ -151,7 +151,7 @@ def step_one(pickle_data_url: str, extra: int = 43): pass ``` -Additionally, you can enable automatic logging of a step’s metrics / artifacts / models to the pipeline task using the +Additionally, you can enable automatic logging of a step's metrics / artifacts / models to the pipeline task using the following arguments: * `monitor_metrics` (optional) - Automatically log the step's reported metrics also on the pipeline Task. The expected format is one of the following: diff --git a/docs/pipelines/pipelines_sdk_tasks.md b/docs/pipelines/pipelines_sdk_tasks.md index 7cdbe367..afa0be3a 100644 --- a/docs/pipelines/pipelines_sdk_tasks.md +++ b/docs/pipelines/pipelines_sdk_tasks.md @@ -33,10 +33,10 @@ pipe.add_parameter( ``` * `name` - Parameter name -* `default` - Parameter’s default value (this value can later be changed in the UI) +* `default` - Parameter's default value (this value can later be changed in the UI) * `description` - String description of the parameter and its usage in the pipeline -These parameters can be programmatically injected into a step’s configuration using the following format: `"${pipeline.}"`. +These parameters can be programmatically injected into a step's configuration using the following format: `"${pipeline.}"`. When launching a new pipeline run from the [UI](../webapp/pipelines/webapp_pipeline_table.md), you can modify their values for the new run. @@ -56,7 +56,7 @@ config_file = pipe.connect_configuration(configuration=config_file_path, name="M my_params = json.load(open(config_file,'rt')) ``` -You can view the configuration in the pipeline’s task page's **CONFIGURATION** tab, in the section specified in the +You can view the configuration in the pipeline's task page's **CONFIGURATION** tab, in the section specified in the `name` parameter. @@ -67,11 +67,10 @@ to the specified structure. ### Steps from Tasks Creating a pipeline step from an existing ClearML task means that when the step is run, the task will be cloned, and a -new task will be launched through the configured execution queue (the original task is unmodified). The new task’s +new task will be launched through the configured execution queue (the original task is unmodified). The new task's parameters can be [specified](#parameter_override). -Task steps are added using the [`PipelineController.add_step`](../references/sdk/automation_controller_pipelinecontroller.md#add_step) -method: +Task steps are added using [`PipelineController.add_step()`](../references/sdk/automation_controller_pipelinecontroller.md#add_step): ```python pipe.add_step( @@ -103,8 +102,8 @@ pipe.add_step( See [add_step](../references/sdk/automation_controller_pipelinecontroller.md#add_step) for all arguments. #### parameter_override -Use the `parameter_override` argument to modify the step’s parameter values. The `parameter_override` dictionary key is -the task parameter’s full path, which includes the parameter section's name and the parameter name separated by a slash +Use the `parameter_override` argument to modify the step's parameter values. The `parameter_override` dictionary key is +the task parameter's full path, which includes the parameter section's name and the parameter name separated by a slash (e.g. `'General/dataset_url'`). Passing `"${}"` in the argument value lets you reference input/output configurations from other pipeline steps. For example: `"${.id}"` will be converted to the Task ID of the referenced pipeline step. @@ -116,7 +115,7 @@ Examples: * Pipeline parameters (see adding pipeline parameters): `'${pipeline.}'` #### configuration_overrides -You can override a step’s configuration object by passing either a string representation of the content of the configuration +You can override a step's configuration object by passing either a string representation of the content of the configuration object, or a configuration dictionary. Examples: @@ -132,8 +131,7 @@ As each function is transformed into an independently executed step, it needs to all package imports inside the function are automatically logged as required packages for the pipeline step. ::: -Function steps are added using the [`PipelineController.add_function_step`](../references/sdk/automation_controller_pipelinecontroller.md#add_function_step) -method: +Function steps are added using [`PipelineController.add_function_step()`](../references/sdk/automation_controller_pipelinecontroller.md#add_function_step): ```python pipe.add_function_step( @@ -154,11 +152,11 @@ pipe.add_function_step( ) ``` -* `name` - The pipeline step’s name. This name can be referenced in subsequent steps +* `name` - The pipeline step's name. This name can be referenced in subsequent steps * `function` - A global function to be used as a pipeline step, which will be converted into a standalone task * `function_kwargs` (optional) - A dictionary of function arguments and default values which are translated into task hyperparameters. If not provided, all function arguments are translated into hyperparameters. -* `function_return` - The names for storing the pipeline step’s returned objects as artifacts in its ClearML task. +* `function_return` - The names for storing the pipeline step's returned objects as artifacts in its ClearML task. * `cache_executed_step` - If `True`, the controller will check if an identical task with the same code (including setup, see task [Execution](../webapp/webapp_exp_track_visual.md#execution) section) and input arguments was already executed. If found, the cached step's @@ -166,7 +164,7 @@ pipe.add_function_step( * `parents` – Optional list of parent steps in the pipeline. The current step in the pipeline will be sent for execution only after all the parent steps have been executed successfully. * `pre_execute_callback` and `post_execute_callback` - Control pipeline flow with callback functions that can be called - before and/or after a step’s execution. See [here](#pre_execute_callback-and-post_execute_callback). + before and/or after a step's execution. See [here](#pre_execute_callback-and-post_execute_callback). * `monitor_models`, `monitor_metrics`, `monitor_artifacts` - see [here](#models-artifacts-and-metrics). See [add_function_step](../references/sdk/automation_controller_pipelinecontroller.md#add_function_step) for all @@ -195,7 +193,7 @@ def step_created_callback( pass ``` -A `post_execute_callback` function is called when a step is completed. It lets you modify the step’s status after completion. +A `post_execute_callback` function is called when a step is completed. It lets you modify the step's status after completion. ```python def step_completed_callback( @@ -207,7 +205,7 @@ def step_completed_callback( #### Models, Artifacts, and Metrics -You can enable automatic logging of a step’s metrics /artifacts / models to the pipeline task using the following arguments: +You can enable automatic logging of a step's metrics /artifacts / models to the pipeline task using the following arguments: * `monitor_metrics` (optional) - Automatically log the step's reported metrics also on the pipeline Task. The expected format is one of the following: diff --git a/docs/webapp/applications/apps_aws_autoscaler.md b/docs/webapp/applications/apps_aws_autoscaler.md index 6483b084..082976c7 100644 --- a/docs/webapp/applications/apps_aws_autoscaler.md +++ b/docs/webapp/applications/apps_aws_autoscaler.md @@ -35,7 +35,7 @@ For more information about how autoscalers work, see [Autoscalers Overview](../. * Git Password / Personal Access Token * **Max Idle Time** (optional) - Maximum time in minutes that an EC2 instance can be idle before the autoscaler spins it down -* **Workers Prefix** (optional) - A Prefix added to workers’ names, associating them with this autoscaler +* **Workers Prefix** (optional) - A Prefix added to workers' names, associating them with this autoscaler * **Polling Interval** (optional) - Time period in minutes at which the designated queue is polled for new tasks * **Base Docker Image** (optional) - Default Docker image in which the ClearML Agent will run. Provide a Docker stored in a Docker artifactory so instances can automatically fetch it @@ -106,22 +106,22 @@ The autoscaler dashboard shows: * Queues and the resource type associated with them * Number of current running instances * Console: the application log containing everything printed to stdout and stderr appears in the console log. The log - shows polling results of the autoscaler’s associated queues, including the number of tasks enqueued, and updates EC2 + shows polling results of the autoscaler's associated queues, including the number of tasks enqueued, and updates EC2 instances being spun up/down. :::tip Console Debugging -To make the autoscaler console log show additional debug information, change an active app instance’s log level to DEBUG: -1. Go to the app instance task’s page > **CONFIGURATION** tab > **USER PROPERTIES** section +To make the autoscaler console log show additional debug information, change an active app instance's log level to DEBUG: +1. Go to the app instance task's page > **CONFIGURATION** tab > **USER PROPERTIES** section 1. Hover over the section > Click `Edit` > Click `+ADD PARAMETER` 1. Input `log_level` as the key and `DEBUG` as the value of the new parameter. ![Autoscaler debugging](../../img/webapp_autoscaler_debug_log.png) -The console’s log level will update in the autoscaler's next iteration. +The console's log level will update in the autoscaler's next iteration. ::: * Instance log files - Click to access the app instance's logs. This takes you to the app instance task's ARTIFACTS tab, - which lists the app instance’s logs. In a log’s `File Path` field, click Download + which lists the app instance's logs. In a log's `File Path` field, click Download to download the complete log. diff --git a/docs/webapp/applications/apps_gcp_autoscaler.md b/docs/webapp/applications/apps_gcp_autoscaler.md index cc2d0acc..933ba52b 100644 --- a/docs/webapp/applications/apps_gcp_autoscaler.md +++ b/docs/webapp/applications/apps_gcp_autoscaler.md @@ -48,7 +48,7 @@ For more information about how autoscalers work, see [Autoscalers Overview](../. * \+ Add Item - Define another resource type * **Autoscaler Instance Name** (optional) - Name for the Autoscaler instance. This will appear in the instance list * **Max Idle Time** (optional) - Maximum time in minutes that a VM instance can be idle before the autoscaler spins it down -* **Workers Prefix** (optional) - A Prefix added to workers’ names, associating them with this autoscaler +* **Workers Prefix** (optional) - A Prefix added to workers' names, associating them with this autoscaler * **Polling Interval** (optional) - Time period in minutes at which the designated queue is polled for new tasks * **Apply Task Owner Vault Configuration** - Select to apply values from the task owner's [ClearML vault](../webapp_profile.md#configuration-vault) when executing the task * **Warn if more than one instance is executing the same task** - Select to print warning to console when multiple @@ -91,22 +91,22 @@ The autoscaler dashboard shows: * Queues and the resource type associated with them * Number of current running instances * Console: the application log containing everything printed to stdout and stderr appears in the console log. The log - shows polling results of the autoscaler’s associated queues, including the number of tasks enqueued, and updates VM + shows polling results of the autoscaler's associated queues, including the number of tasks enqueued, and updates VM instances being spun up/down :::tip Console Debugging -To make the autoscaler console log show additional debug information, change an active app instance’s log level to DEBUG: -1. Go to the app instance task’s page > **CONFIGURATION** tab > **USER PROPERTIES** section +To make the autoscaler console log show additional debug information, change an active app instance's log level to DEBUG: +1. Go to the app instance task's page > **CONFIGURATION** tab > **USER PROPERTIES** section 1. Hover over the section > Click `Edit` > Click `+ADD PARAMETER` 1. Input `log_level` as the key and `DEBUG` as the value of the new parameter. ![Autoscaler debugging](../../img/webapp_autoscaler_debug_log.png) -The console’s log level will update in the autoscaler's next iteration. +The console's log level will update in the autoscaler's next iteration. ::: * Instance log files - Click to access the app instance's logs. This takes you to the app instance task's ARTIFACTS tab, - which lists the app instance’s logs. In a log’s `File Path` field, click Download + which lists the app instance's logs. In a log's `File Path` field, click Download to download the complete log. :::tip EMBEDDING CLEARML VISUALIZATION diff --git a/docs/webapp/applications/apps_gpu_compute.md b/docs/webapp/applications/apps_gpu_compute.md index f1daedd1..fd3ce60c 100644 --- a/docs/webapp/applications/apps_gpu_compute.md +++ b/docs/webapp/applications/apps_gpu_compute.md @@ -21,7 +21,7 @@ For more information about how autoscalers work, see [Autoscalers Overview](../. * **Machine Specification** * GPU Type - NVIDIA GPU on the machine * Number of GPUs - Number of GPUs in the cloud machine - * The rest of the machine’s available resources are dependent on the number and type of GPUs specified above: + * The rest of the machine's available resources are dependent on the number and type of GPUs specified above: * vCPUs - Number of vCPUs in the cloud machine * Memory - RAM available to the cloud machine * Hourly Price - Machine's hourly rate @@ -65,14 +65,14 @@ The GPU Compute dashboard shows: * Console - The log shows updates of cloud instances being spun up/down. :::tip Console Debugging -To make the autoscaler console log show additional debug information, change an active app instance’s log level to DEBUG: -1. Go to the app instance task’s page > **CONFIGURATION** tab > **USER PROPERTIES** section +To make the autoscaler console log show additional debug information, change an active app instance's log level to DEBUG: +1. Go to the app instance task's page > **CONFIGURATION** tab > **USER PROPERTIES** section 1. Hover over the section > Click `Edit` > Click `+ADD PARAMETER` 1. Input `log_level` as the key and `DEBUG` as the value of the new parameter. ![Autoscaler debugging](../../img/webapp_autoscaler_debug_log.png) -The console’s log level will update in the autoscaler's next iteration. +The console's log level will update in the autoscaler's next iteration. ::: :::tip EMBEDDING CLEARML VISUALIZATION diff --git a/docs/webapp/applications/apps_hpo.md b/docs/webapp/applications/apps_hpo.md index 01ad2a42..02c5deb7 100644 --- a/docs/webapp/applications/apps_hpo.md +++ b/docs/webapp/applications/apps_hpo.md @@ -25,8 +25,8 @@ limits. sample a different set of hyperparameters values * **Optimization Configuration** * Optimization Method - The optimization strategy to employ (e.g. random, grid, hyperband) - * Optimization Objective Metric’s Title - Title of metric to optimize - * Optimization Objective Metric’s Series - Metric series (variant) to optimize + * Optimization Objective Metric's Title - Title of metric to optimize + * Optimization Objective Metric's Series - Metric series (variant) to optimize * Optimization Objective Trend - Choose the optimization target, whether to maximize or minimize the value of the metric specified above * **Execution Queue** - The [ClearML Queue](../../fundamentals/agents_and_queues.md#what-is-a-queue) to which @@ -39,7 +39,7 @@ limits. * Step Size - Step size between samples * Discrete Parameters - A set of values to sample * Values - Comma separated list of values to sample - * Name - The original task’s configuration parameter name (including section name e.g. `Args/lr`)
+ * Name - The original task's configuration parameter name (including section name e.g. `Args/lr`)
:::tip Hydra Parameters For experiments using Hydra, input parameters from the OmegaConf in the following format: `Hydra/`. Specify `` using dot notation. For example, if your OmegaConf looks like this: diff --git a/docs/webapp/applications/apps_overview.md b/docs/webapp/applications/apps_overview.md index 0bff71ad..122c3b8e 100644 --- a/docs/webapp/applications/apps_overview.md +++ b/docs/webapp/applications/apps_overview.md @@ -54,7 +54,7 @@ Access app instance actions, by right-clicking an instance, or through the menu ![App context menu](../../img/app_context_menu.png) * **Rename** - Rename the instance -* **Configuration** - View an instance’s configuration +* **Configuration** - View an instance's configuration * **Export Configuration** - Export the app instance configuration as a JSON file, which you can later import to create a new instance with the same configuration * **Stop** - Shutdown the instance diff --git a/docs/webapp/applications/apps_trigger_manager.md b/docs/webapp/applications/apps_trigger_manager.md index 0bc0ed40..3791e976 100644 --- a/docs/webapp/applications/apps_trigger_manager.md +++ b/docs/webapp/applications/apps_trigger_manager.md @@ -52,7 +52,7 @@ The app monitors your workspace for trigger events and will launch copies of the ## Dashboard -The Trigger Manager app instance's dashboard displays its console log. The log shows the instance’s activity: periodic +The Trigger Manager app instance's dashboard displays its console log. The log shows the instance's activity: periodic polling, and events triggered ![Trigger dashboard](../../img/apps_trigger_manager_dashboard.png) \ No newline at end of file diff --git a/docs/webapp/pipelines/webapp_pipeline_table.md b/docs/webapp/pipelines/webapp_pipeline_table.md index 23cafdfa..2ae1e2b1 100644 --- a/docs/webapp/pipelines/webapp_pipeline_table.md +++ b/docs/webapp/pipelines/webapp_pipeline_table.md @@ -32,7 +32,7 @@ The models table contains the following columns: | Column | Description | Type | |---|---|---| | **RUN** | Pipeline run identifier | String | -| **VERSION** | The pipeline version number. Corresponds to the [PipelineController](../../references/sdk/automation_controller_pipelinecontroller.md#class-pipelinecontroller)'s and [PipelineDecorator](../../references/sdk/automation_controller_pipelinecontroller.md#class-automationcontrollerpipelinedecorator)’s `version` parameter | Version string | +| **VERSION** | The pipeline version number. Corresponds to the [PipelineController](../../references/sdk/automation_controller_pipelinecontroller.md#class-pipelinecontroller)'s and [PipelineDecorator](../../references/sdk/automation_controller_pipelinecontroller.md#class-automationcontrollerpipelinedecorator)'s `version` parameter | Version string | | **TAGS** | Descriptive, user-defined, color-coded tags assigned to run. | Tag | | **STATUS** | Pipeline run's status. See a list of the [task states and state transitions](../../fundamentals/task.md#task-states). For Running, Failed, and Aborted runs, you will also see a progress indicator next to the status. See [here](../../pipelines/pipelines.md#tracking-pipeline-progress). | String | | **USER** | User who created the run. | String | @@ -91,9 +91,9 @@ The following table customizations are saved on a per-pipeline basis: ## Create Run To launch a new run for a pipeline, click **+ NEW RUN** on the top left of the page. This opens a **NEW RUN** modal, where -you can set the run’s parameters. By default, the fields are pre-filled with the last run’s values. +you can set the run's parameters. By default, the fields are pre-filled with the last run's values. -Click **Advanced configurations** to change the run’s execution queue. +Click **Advanced configurations** to change the run's execution queue. ![New run modal](../../img/webapp_pipeline_new_run.png) diff --git a/docs/webapp/pipelines/webapp_pipeline_viewing.md b/docs/webapp/pipelines/webapp_pipeline_viewing.md index bfeefe4b..65bf262c 100644 --- a/docs/webapp/pipelines/webapp_pipeline_viewing.md +++ b/docs/webapp/pipelines/webapp_pipeline_viewing.md @@ -17,7 +17,7 @@ Each step shows: * Step log button - Hover over the step and click console to view the step's [details panel](#run-and-step-details-panel) -While the pipeline is running, the steps’ details and colors are updated. +While the pipeline is running, the steps' details and colors are updated. ## Run and Step Details ### Run and Step Info @@ -30,24 +30,24 @@ On the right side of the pipeline run panel, view the **RUN INFO** which shows: ![Run info](../../img/webapp_pipeline_run_info.png) -To view a run’s complete information, click **Full details**, which will open the pipeline’s controller [task page](../webapp_exp_track_visual.md). -View each list’s complete details in the pipeline task’s corresponding tabs: +To view a run's complete information, click **Full details**, which will open the pipeline's controller [task page](../webapp_exp_track_visual.md). +View each list's complete details in the pipeline task's corresponding tabs: * **PARAMETERS** list > **CONFIGURATION** tab * **METRICS** list > **SCALARS** tab * **ARTIFACTS** and **MODELS** lists > **ARTIFACTS** tab ![Pipeline task info](../../img/webapp_pipeline_task_info.png) -To view a specific step’s information, click the step on the execution graph, and the info panel displays its **STEP INFO**. -The panel displays the step’s name, task type, and status, as well as its parameters, metrics, artifacts, and models. +To view a specific step's information, click the step on the execution graph, and the info panel displays its **STEP INFO**. +The panel displays the step's name, task type, and status, as well as its parameters, metrics, artifacts, and models. ![Step info](../../img/webapp_pipeline_step_info.png) -To return to viewing the run’s information, click the pipeline graph, outside any of the steps. +To return to viewing the run's information, click the pipeline graph, outside any of the steps. ### Run and Step Details Panel -Click on **DETAILS** on the top left of the info panel to view the pipeline controller's details panel. To view a step’s +Click on **DETAILS** on the top left of the info panel to view the pipeline controller's details panel. To view a step's details panel, click **DETAILS** and then click on a step node, or hover over a step node and click details. The details panel includes three tabs: @@ -61,7 +61,7 @@ The details panel includes three tabs: * **Code** - For pipeline steps generated from functions using either [`PipelineController.add_function_step`](../../references/sdk/automation_controller_pipelinecontroller.md#add_function_step) or [`PipelineDecorator.component`](../../references/sdk/automation_controller_pipelinecontroller.md#pipelinedecoratorcomponent), -you can view the selected step’s code. +you can view the selected step's code. ![code](../../img/webapp_pipeline_step_code.png) diff --git a/docs/webapp/webapp_exp_comparing.md b/docs/webapp/webapp_exp_comparing.md index 50799dc7..006b6722 100644 --- a/docs/webapp/webapp_exp_comparing.md +++ b/docs/webapp/webapp_exp_comparing.md @@ -198,7 +198,7 @@ first. Use the viewer / player to inspect images, audio, video samples and do an Right arrow (new images), or right arrow, newest image (newest images). * Click Sync selection in order to synchronize iteration and metric selection across experiments. For example, if you select a metric for - one experiment’s debug samples, the same metric will be automatically selected for the rest of the experiments in the comparison. + one experiment's debug samples, the same metric will be automatically selected for the rest of the experiments in the comparison. ![image](../img/webapp_compare_30.png) diff --git a/docs/webapp/webapp_exp_table.md b/docs/webapp/webapp_exp_table.md index 582c4638..1f59a429 100644 --- a/docs/webapp/webapp_exp_table.md +++ b/docs/webapp/webapp_exp_table.md @@ -9,7 +9,7 @@ to monitor experimentation, and more). The experiments table's auto-refresh allo View the experiments table in table view Table view or in details view Details view, using the buttons on the top left of the page. Use the table view for a comparative view of your experiments according -to columns of interest. Use the details view to access a selected experiment’s details, while keeping the experiment list +to columns of interest. Use the details view to access a selected experiment's details, while keeping the experiment list in view. Details view can also be accessed by double-clicking a specific experiment in the table view to open its details view. You can archive experiments so the experiments table doesn't get too cluttered. Click **OPEN ARCHIVE** on the top of the diff --git a/docs/webapp/webapp_model_comparing.md b/docs/webapp/webapp_model_comparing.md index 8467129b..de083e58 100644 --- a/docs/webapp/webapp_model_comparing.md +++ b/docs/webapp/webapp_model_comparing.md @@ -43,7 +43,7 @@ The comparison tabs provides the following views: In the **Details**, **Network**, and **Scalars** (Values mode) tabs, you can view differences in the models' nominal values. **Details** displays the models' general information, labels, and metadata. **Network** displays the models' -configuration. **Scalars** (in Values mode) displays the models’ scalar values (min, max, or last). Each model's +configuration. **Scalars** (in Values mode) displays the models' scalar values (min, max, or last). Each model's information is displayed in a column, so each field is lined up side-by-side. The model on the left is used as the base model, to which the other models are compared. You can set a new base model @@ -67,7 +67,7 @@ models are combined. ![Merged plots](../img/webapp_compare_models_merge_plots.png) -The rest of the plots which can’t be merged are displayed separately for each model. +The rest of the plots which can't be merged are displayed separately for each model. ![Side-by-side plots](../img/webapp_compare_models_side_plots.png) diff --git a/docs/webapp/webapp_model_table.md b/docs/webapp/webapp_model_table.md index 89d563ec..6f3809a5 100644 --- a/docs/webapp/webapp_model_table.md +++ b/docs/webapp/webapp_model_table.md @@ -8,7 +8,7 @@ view model details, and modify, publish, archive, tag, and move models to other View the models table in table view Table view or in details view Details view, using the buttons on the top left of the page. Use the table view for a comparative view of your models according to -columns of interest. Use the details view to access a selected model’s details, while keeping the model list in view. +columns of interest. Use the details view to access a selected model's details, while keeping the model list in view. Details view can also be accessed by double-clicking a specific model in the table view to open its details view. You can archive models so the models table doesn't get too cluttered. Click **OPEN ARCHIVE** on the top of the diff --git a/docs/webapp/webapp_profile.md b/docs/webapp/webapp_profile.md index 2512669d..46ce138f 100644 --- a/docs/webapp/webapp_profile.md +++ b/docs/webapp/webapp_profile.md @@ -123,7 +123,7 @@ pending invitations are displayed. ### Leaving a Workspace -You can leave any workspace you’ve previously joined (except your personal workspace). +You can leave any workspace you've previously joined (except your personal workspace). When leaving a workspace, you lose access to its resources (tasks, models, etc.) and your previously created access credentials to that workspace are revoked. Tasks and associated artifacts that you logged to that workspace will remain @@ -223,7 +223,7 @@ To remove a user from a workspace: 1. Hover over the user's row on the table 1. Click the Trash can button -Removed users lose access to your workspace’s resources (tasks, models, etc.) and their existing access credentials are +Removed users lose access to your workspace's resources (tasks, models, etc.) and their existing access credentials are revoked. Tasks and associated artifacts logged to your workspace by a removed user will remain in your workspace. The user can only rejoin your workspace when you re-invite them. diff --git a/docs/webapp/webapp_projects_page.md b/docs/webapp/webapp_projects_page.md index 9d012ec6..cb7b71d7 100644 --- a/docs/webapp/webapp_projects_page.md +++ b/docs/webapp/webapp_projects_page.md @@ -6,12 +6,12 @@ Use the Projects Page for project navigation and management. Your projects are displayed like folders: click a folder to access its contents. The Projects Page shows the top-level projects in your workspace. Projects that contain nested subprojects are identified by an extra nested project tab. -An exception is the **All Experiments** folder, which shows all projects’ and subprojects’ contents in a single, flat +An exception is the **All Experiments** folder, which shows all projects' and subprojects' contents in a single, flat list. ![Projects page](../img/webapp_project_page.png) -If a project has any subprojects, clicking its folder will open its own project page. Access the projects’ top-level +If a project has any subprojects, clicking its folder will open its own project page. Access the projects' top-level contents (i.e. experiments, models etc.) via the folder with the bracketed (`[ ]`) project name. If a project does not contain any subprojects, clicking on its folder will open its experiment table (or [Project Overview](webapp_project_overview.md) diff --git a/docs/webapp/webapp_reports.md b/docs/webapp/webapp_reports.md index e6ba1025..da47bbf9 100644 --- a/docs/webapp/webapp_reports.md +++ b/docs/webapp/webapp_reports.md @@ -14,7 +14,7 @@ title: Reports
-With ClearML’s Reports you can write up notes, experiment findings, or really anything you want. You can create reports +With ClearML's Reports you can write up notes, experiment findings, or really anything you want. You can create reports in any of your ClearML projects. In addition to its main document, a report also contains a description field, which will appear in the report's card in @@ -76,7 +76,7 @@ A standard embed code is formatted like this: ``` The `src` parameter is made up of the following components: -* Your web server’s URL (e.g. `app.clear.ml`) +* Your web server's URL (e.g. `app.clear.ml`) * `/widget/` - The endpoint that serves the embedded data. * The query parameters for your visualization (the path and query are separated by a question mark `?`) @@ -105,7 +105,7 @@ resources will be displayed. See [Dynamic Queries](#dynamic-queries) below. * `timestamp` - Time from start * `iso_time` - Wall time * `metrics` - Metric name -* `variants` - Variant’s name +* `variants` - Variant's name * `company` - Workspace ID. Applicable to the ClearML hosted service, for embedding content from a different workspace * `light` - add parameter to switch visualization to light theme diff --git a/docs/webapp/webapp_workers_queues.md b/docs/webapp/webapp_workers_queues.md index 1b0ba36b..a86fb85d 100644 --- a/docs/webapp/webapp_workers_queues.md +++ b/docs/webapp/webapp_workers_queues.md @@ -58,14 +58,14 @@ The worker table shows the currently available workers and their current executi * Training iteration. -Clicking on a worker will open the worker’s details panel and replace the graph with that worker’s resource utilization -information. The resource metric being monitored can be selected through the menu at the graph’s top left corner: +Clicking on a worker will open the worker's details panel and replace the graph with that worker's resource utilization +information. The resource metric being monitored can be selected through the menu at the graph's top left corner: * CPU and GPU Usage * Memory Usage * Video Memory Usage * Network Usage. -The worker’s details panel includes the following two tabs: +The worker's details panel includes the following two tabs: * **INFO** - worker information: * Worker Name * Update time - The last time the worker reported data @@ -97,7 +97,7 @@ The queue table shows the following queue information: To create a new queue - Click **+ NEW QUEUE** (top left). Hover over a queue and click Copy -to copy the queue’s ID. +to copy the queue's ID. ![image](../img/4100.png) @@ -107,24 +107,24 @@ to access queue actions: ![Queue context menu](../img/webapp_workers_queues_context.png) * Delete - Delete the queue. Any pending tasks will be dequeued. -* Rename - Change the queue’s name +* Rename - Change the queue's name * Clear - Remove all pending tasks from the queue * Custom action - The ClearML Enterprise Server provides a mechanism to define your own custom actions, which will appear in the context menu. See [Custom UI Context Menu Actions](../deploying_clearml/clearml_server_config.md#custom-ui-context-menu-actions) -Clicking on a queue will open the queue’s details panel and replace the graphs with that queue’s statistics. +Clicking on a queue will open the queue's details panel and replace the graphs with that queue's statistics. -The queue’s details panel includes the following two tabs: +The queue's details panel includes the following two tabs: * **EXPERIMENTS** - A list of experiments in the queue. You can reorder and remove enqueued experiments. See [Controlling Queue Contents](#controlling-queue-contents). * **WORKERS** - Information about the workers assigned to the queue: * Name - Worker name - * IP - Worker’s IP + * IP - Worker's IP * Currently Executing - The experiment currently being executed by the worker ### Controlling Queue Contents -Click on an experiment’s menu button Dot menu +Click on an experiment's menu button Dot menu in the **EXPERIMENTS** tab to reorganize your queue: ![Queue experiment's menu](../img/workers_queues_experiment_actions.png)