ProActive Workflows & Scheduling (PWS)

ProActive Machine Learning (PML)

  • PML User Guide

     (a complete Data Science and Machine Learning platform, with Studio & MLOps)

1. Overview

1.1. What is ProActive Machine Learning (PML)?

Proactive Machine Learning (PML) is a complete DSML platform (Data Science and Machine Learning) including a ML Studio, AutoML, Data Science Orchestration and MLOps for the deployment, training, execution and scalability of artificial intelligence and machine learning models on any type of infrastructure. Created for data scientists and ML engineers, the solution is simple to use and accelerate the development and deployment of machine learning models.

PML overview

Proactive Machine Learning platform provides a rich catalog of generic machine learning tasks that can be connected together to build either basic or advanced machine learning workflows for various use cases such as: fraud detection, text analysis, online offer recommendations, prediction of equipment failures, facial expression analysis, etc. PML workflows enable users to manage machine learning pipelines through the different phases of the development lifecycle and allow them to better control tasks parallelization, by running the tasks on resources matching constraints (Multi-CPU, GPU, FPGA, data locality, libraries, etc).

ML Open Studio ActiveEon

The Proactive Machine Learning platform is an open source solution, and it can be tested online without installation on our try platforms here.

1.2. Glossary

The following terms are used throughout the documentation:

ProActive Workflows & Scheduling

The full distribution of ProActive for Workflows & Scheduling, it contains the ProActive Scheduler server, the REST & Web interfaces, the command line tools. It is the commercial product name.

ProActive Scheduler

Can refer to any of the following:

  • A complete set of ProActive components.

  • An archive that contains a released version of ProActive components, for example activeeon_enterprise-pca_server-OS-ARCH-VERSION.zip.

  • A set of server-side ProActive components installed and running on a Server Host.

Resource Manager

ProActive component that manages ProActive Nodes running on Compute Hosts.

Scheduler

ProActive component that accepts Jobs from users, orders the constituent Tasks according to priority and resource availability, and eventually executes them on the resources (ProActive Nodes) provided by the Resource Manager.

Please note the difference between Scheduler and ProActive Scheduler.
REST API

ProActive component that provides RESTful API for the Resource Manager, the Scheduler and the Catalog.

Resource Manager Web Interface

ProActive component that provides a web interface to the Resource Manager.

Scheduler Web Interface

ProActive component that provides a web interface to the Scheduler.

Workflow Studio

ProActive component that provides a web interface for designing Workflows.

Machine Learning Open Studio

PML component that provides a web interface for designing and composing ML Workflows with drag and drop.

Job Planner Portal

ProActive component that provides a web interface for planning Workflows, and creating Calendar Definitions

Catalog

ProActive component that provides storage and versioning of Workflows and other ProActive Objects. It is also possible to query the Catalog for specific Workflows through a REST API and also with Graphql API.

Job Planner

A ProActive component providing advanced scheduling options for Workflows.

Bucket

ProActive notion used with the Catalog to refer to a specific collection of ProActive Objects and in particular ProActive Workflows.

Server Host

The machine on which ProActive Scheduler is installed.

SCHEDULER_ADDRESS

The IP address of the Server Host.

ProActive Node

One ProActive Node can execute one Task at a time. This concept is often tied to the number of cores available on a Compute Host. We assume a task consumes one core (more is possible, so on a 4 cores machines you might want to run 4 ProActive Nodes. One (by default) or more ProActive Nodes can be executed in a Java process on the Compute Hosts and will communicate with the ProActive Scheduler to execute tasks. We distinguish two types of ProActive Nodes:

  • Server ProActive Nodes: Nodes that are running in the same host as ProActive server;

  • Remote ProActive Nodes: Nodes that are running on machines other than ProActive Server.

Compute Host

Any machine which is meant to provide computational resources to be managed by the ProActive Scheduler. One or more ProActive Nodes need to be running on the machine for it to be managed by the ProActive Scheduler.

Examples of Compute Hosts:

PROACTIVE_HOME

The path to the extracted archive of ProActive Scheduler release, either on the Server Host or on a Compute Host.

Workflow

User-defined representation of a distributed computation. Consists of the definitions of one or more Tasks and their dependencies.

Generic Information

Are additional information which are attached to Workflows.

Job

An instance of a Workflow submitted to the ProActive Scheduler. Sometimes also used as a synonym for Workflow.

Job Icon

An icon representing the Job and displayed in portals. The Job Icon is defined by the Generic Information workflow.icon.

Task

A unit of computation handled by ProActive Scheduler. Both Workflows and Jobs are made of Tasks.

Task Icon

An icon representing the Task and displayed in the Studio portal. The Task Icon is defined by the Task Generic Information task.icon.

ProActive Agent

A daemon installed on a Compute Host that starts and stops ProActive Nodes according to a schedule, restarts ProActive Nodes in case of failure and enforces resource limits for the Tasks.

2. Get Started

To submit your first Machine Learning (ML) workflow to ProActive Scheduler, install it in your environment (default credentials: admin/admin) or just use our demo platform try.activeeon.com.

ProActive Scheduler provides comprehensive interfaces that allow to:

We also provide a REST API and command line interfaces for advanced users.

3. Create a First Predictive Solution

Suppose you need to predict houses prices based on this information (features) provided by the estate agency:

  • CRIM per capita crime rate by town

  • ZN proportion of residential lawd zoned for lots over 25000

  • INDUS proportion of non-retail business acres per town

  • CHAS Charles River dummy variable

  • NOX nitric oxides concentration

  • RM average number of rooms per dwelling

  • AGE proportion of owner-occupied units built prior to 1940

  • DIS weighted distances to five Boston Employment centres

  • RAD index of accessibility to radial highways

  • TAX full-value property-tax rate per $10 000

  • PTRATIO pupil-teacher ratio by town

  • B 1000(Bk - 0.63)^2 where Bk is the proportion of blacks by town

  • LSTAT % lower status of the population

  • MDEV Median value of owner-occupied homes in $1000' s

Predicting houses prices is a complex problem, but we can simplify it a bit for this step by step example. We’ll show you how you can easily create a predictive analytics solution using PML.

3.1. Manage the Canvas

To use PML, you need to add the Machine Learning Bucket as main catalog in the ProActive Studio. This bucket contains a set of generic tasks that enables you to upload and prepare data, train a model and test it.

  1. Open ProActive Workflow Studio home page.

  2. Create a new workflow.

  3. Change palette preset to Machine Learning.

  4. Click on machine-learning catalog and pin it open, and same for the data-visualization catalog.

  5. Organize your canvas.

Change palette preset allows the user to visualise different set of catalogs in the studio. 
100000

3.2. Upload Data

To upload data into the Workflow, you need to use a dataset stored in a CSV file.

  1. Once dataset has been converted to CSV format, upload it into a cloud storage service for example Amazon S3. For this tutorial, we will use Boston house prices dataset available on this link: https://s3.eu-west-2.amazonaws.com/activeeon-public/datasets/boston-houses-prices.csv

  2. Drag and drop the Import_Data task from the machine-learning bucket in the Machine Learning Open Studio.

  3. Click on the task and click General Parameters in the left to change the default parameters of this task.

  4. Put in FILE_URL variable the S3 link to upload your dataset.

  5. Set the other parameters according to your dataset format.

This task uploads the data into the workflow that we can for model training and testing.

If you want to skip these steps, you can directly use the Load_Boston_Dataset Task by a simple drag and drop.

100000

3.3. Prepare Data

This step consists of preparing the data for the training and testing of the predictive model. So in this example, we will simply split our datset into two separate datasets: one for training and one for testing.

To do this, we use the Split_Data Task in the machine_learning bucket.

  1. Drag and drop the Split_Data Task into the canvas, and connect it to the Import_Data or Load_Boston_Dataset Task.

  2. By default, the ratio is 0.7 this means that 70% of the dataset will be used for training the model and 0.3 for testing it.

  3. Click the Split_Data Task and set the TRAIN_SIZE variable to 0.6.

100000

3.4. Train a Predictive Model

Using PML, you can easily create different ML models in a single experiment and compare their results. This type of experimentation helps you find the best solution for your problem. You can also enrich the machine-learning bucket by adding new ML algorithms and publish or customize an existing task according to your requirements as the tasks are open source.

To change the code of a task click on it and click the Task Implementation. You can also add new variables to a specific task.

In this step, we will create two different types of models and then compare their scores to decide which algorithm is most suitable to our problem. As the Boston dataset used for this example consists of predicting price of houses (continuous label). As such, we need to deal with a regression predictive problem.

To solve this problem, we have to choose a regression algorithm to train the predictive model. To see the available regression algorithms available on the PML, see ML Regression Section in the machine-learning bucket.

For this example, we will use Linear_Regression Task and Support_Vector_Regression Task.

  1. Find the Linear_Regression Task and Support_Vector_Regression Task and drag them into the canvas.

  2. Find the Train_Model Task and drag it twice into the canvas and set its LABEL_COLUMN variable to LABEL.

  3. Connect the Split_Data Task to the two Train_Model Tasks in order to give it access to the training data. Connect then the Linear_Regression Task to the first Train_Model Task and Support_Vector_Regression to the second Train_Model Task.

  4. To be able to download the model learned by each algorithm, drag two Download_Model Tasks and connect them to each Train_Model Task.

100000

3.5. Test the Predictive Model

To evaluate the two learned predictive models, we will use the testing data that was separated out by the Split_Data Task to score our trained models. We can then compare the results of the two models to see which generated better results.

  1. Find the Predict_Model Task and drag and drop it twice into the canvas and set its LABEL_COLUMN variable to LABEL.

  2. Connect the first Predict_Model Task to the Train_Model Task that is connected to Support_Vector_Regression Task.

  3. Connect the second Predict_Model Task to the Train_Model Task that is connected to Linear_Regression Task.

  4. Connect both Predict_Model Tasks to the Split_Data Task.

  5. Find the Preview_Results Task in the ML bucket and drag and drop it twice into the canvas.

  6. Connect each Preview_Results Task with Predict_Model.

100000
if you have a pickled file (.pkl) containing a predictive model that you have learned using another platform and you need to test it in the PML, you can load it using Import_Model Task.

3.6. Run the Experiment and Preview the Results

Now the workflow is completed, let’s execute it by:

  1. Click the Execute button on the menu to run the workflow.

  2. Click the Scheduling & Orchestration button to track the workflow execution progress.

  3. Click the Visualization tab and track the progress of your workflow execution (a green check mark appears on each Task when its execution is finished).

  4. Visualize the output logs by clicking on the output tab and check the streaming check box.

  5. Click the Tasks tab, select an Preview_Results task and click on the Preview tab, then click either on Open in browser to preview the results on your browser or on Save as file to download the results locally.

100000

4. AutoML

The auto-ml-optimization bucket contains the Multi_Tuners_AutoML workflow that can be easily used to find the operating parameters for any system whose performance can be measured as a function of adjustable parameters. It is an estimator that minimizes the posterior expected value of a loss function. This bucket also comes with a set of workflows' examples that demonstrates how we can optimize mathematical functions, PML workflows and machine/deep learning algorithms from scripts using AutoML tuners. In the following subsections, several tables represent the main variables that characterize the AutoML workflows. In addition to the variables mentioned below, there is a set of generic variables that are common between all workflows which can be found in the subsection AI Workflows Common Variables.

4.1. Multi_Tuners_Auto_ML

Multi_Tuners_Auto_ML proposes six algorithms for hyperparameters' optimization. The choice of the sampling/search strategy depends strongly on the tackled problem. Multi_Tuners_Auto_ML comes with specific pipelines (parallel or sequential) and visualization tools (Visdom or Tensorboard) as described in the subsections below.

Variables:

Table 1. Multi_Tuners_Auto_ML Variables

Variable name

Description

Type

TUNING_ALGORITHM

Specifies the tuner algorithm that will be used for hyperparameters optimization.

List [Bayes, Grid, Random, QuasiRandom, CMAES, MOCMAES] (default=Bayes)

WORKFLOW_TO_OPTIMIZE

Specifies the catalog path of the workflow that we need to optimize.

String (default=auto-ml-optimization/Himmelblau_Function)

MAX_ITERATIONS

Specifies the number of maximum iterations.

Int (default=2)

PARALLEL_SAMPLES_PER_LOOP

Specifies the number of samples per iteration.

Int (default=2)

VISDOM_ENABLED

If True, the user can visualize the data using the Visdom web interface.

Boolean (default=False)

VISDOM_PROXYFIED

If True, requests to Visdom are sent via a proxy server.

Boolean (default=False)

VISDOM_ENABLE_LOGIN

If True, the user will be asked to insert a username and password to access the Visdom web interface.

Boolean (default=False)

VISDOM_USERNAME

The username used to access the Visdom web interface.

String (default=empty)

VISDOM_PASSWORD

The password used to access the Visdom web interface.

String (default=empty)

VISDOM_INSTANCE_NAME

Specifies the name of the container that will run Visdom.

String (default=visdom-server)

TENSORBOARD_ENABLED

If True, the user can visualize the data using the Tensorboard web interface.

Boolean (default=False)

TENSORBOARD_INSTANCE_NAME

Specifies the name of the container that will run Tensorboard.

String (default=tensorboard-server)

TENSORBOARD_LOG_PATH

Specifies the path where Tensorboard logs are created and stored on the host.

String (default=/shared/$TENSORBOARD_INSTANCE_NAME)

TENSORBOARD_DOCKER_LOG_PATH

Specifies the path where Tensorboard logs are created and stored on the docker container.

String (default=/graphs/$TENSORBOARD_INSTANCE_NAME)

PROPAGATE_CONTAINER_PLATFORM

If True, the selected container platform (docker, singularity, etc..) will propagate to the workflow that should be optimized.

(default=True)

1000

How to define the search space:

This subsection describes common building blocks to define a search space:

  • uniform: Uniform continuous distribution.

  • quantized_uniform: Uniform discrete distribution.

  • log: Logarithmic uniform continuous distribution.

  • quantized_log: Logarithmic uniform discrete distribution.

  • choice: Uniform choice distribution between non-numeric samples.

Which tuner algorithm to choose?

The choice of the tuner depends on the following aspects:

  • Time required to evalute the model.

  • Number of hyperparameters to optimize.

  • Type of variable.

  • The size of the search space.

In the following, we briefly describe the different tuners proposed by the Multi_Tuners_AutoML workflow:

  • Grid sampling applies when all variables are discrete and the number of possibilities is low. A grid search is a naive approach that will simply try all possibilities making the search extremely long even for medium sized problems.

  • Random sampling is an alternative to grid search when the number of discrete parameters to optimize and the time required for each evaluation is high. Random search picks the point randomly from the configuration space.

  • QuasiRandom sampling ensures a much more uniform exploration of the search space than traditional pseudo random. Thus, quasi random sampling is preferable when not all variables are discrete, the number of dimensions is high and the time required to evaluate a solution is high.

  • Bayes search models the search space using gaussian process regression, which allows to have an estimate of the loss function and the uncertainty on that estimate at every point of the search space. Modeling the search space suffers from the curse of dimensionality, which makes this method more suitable when the number of dimensions is low.

  • CMAES search is one of the most powerful black-box optimization algorithm. However, it requires a significant number of model evaluation (in the order of 10 to 50 times the number of dimensions) to converge to an optimal solution. This search method is more suitable when the time required for a model evaluation is relatively low.

  • MOCMAES search is a multi-objective algorithm optimizing multiple tradeoffs simultaneously. To do that, MOCMAES employs a number of CMAES algorithms.

4.2. Objective Functions

The following workflows represent some mathematical functions that can be optimized by the AutoML tuners.

Himmelblau_Function: is a multi-modal function, used to test the performance of optimization algorithms.

4.3. Hyperparameter Optimization

The following workflows represent some machine learning and deep learning algorithms that can be optimized. These workflows have several common variables as in Multi_Tuners_Auto_ML. Some of the workflows are characterized by few additional variables.

CIFAR_10_Image_Classification: trains a simple deep CNN on the CIFAR10 images dataset using the Keras library.

Table 2. CIFAR_10_Image_Classification Variables

Variable name

Description

Type

NUM_EPOCHS

The number of times data is passed forward and backward through the training algorithm.

Integer (default=3)

INPUT_VARIABLES

A set of specific variables (usecase-related) that are used in the model training process.

JSON format

SEARCH_SPACE

Specifies the representation of the search space which has to be defined using dictionaries or by entering the path of a json file stored in the catalog.

JSON format

INSTANCE_NAME

Specifies the name to be provided for the instance.

String (default=tensorboard-server)

CONTAINER_LOG_PATH

Specifies the path where the docker logs are created and stored on the docker container.

String (default=/graphs/$INSTANCE_NAME)

CONTAINER_ROOTLESS_ENABLED

If True, the user will be able to run the workflow in a rootless mode.

(default=True)

The following workflows have common variables with the above illustred workflows.

CIFAR_10_Image_Classification: trains a simple deep CNN on the CIFAR10 images dataset using the Keras library.

CIFAR_100_Image_Classification: trains a simple deep CNN on the CIFAR100 images dataset using the Keras library.

Image_Object_Detection: trains a YOLO model on the coco dataset using PML deep learning generic tasks.

Iris_Classification: trains multiple types of SVM models on the Iris flower dataset.

Text_Generation: trains a simple Long Short-Term Memory (LSTM) to learn sequences of characters from 'The Alchemist' book. It’s a novel by Brazilian author Paulo Coelho that was first published in 1988.

The following workflows contain a search space containing a set of possible neural networks architectures that can be used by the AutoML tuners to automatically find the best combinations of neural architectures within the search space.

Handwritten_Digit_Classification: train a simple deep CNN on the MNIST dataset using the Pytorch library.

4.5. Templates

The following workflows represent python templates that can be used to implement a generic machine learning task.

Python_Task: is a simple PyTorch task template.

5. Model as a Service for Machine Learning (MaaS_ML)

Once a predictive model is built, tested and validated, you can easily use it in real world production pipelines by deploying it as a REST Web Service via the MaaS_ML service. MaaS_ML is dedicated to make deployments of lightweight machine learning (ML) models simple, portable, and scalable, and to easily manage their lifetimes. This will be particularly useful for engineering or business teams that want to take advantage of this model.

The life cycle of any MaaS_ML instance (i.e., from starting the generic service instance, deploying an AI specific model to pausing or deleting the instance) can be managed in three different ways in PML :

  • Using the Studio Portal and more specifically the bucket model-as-a-service where specific generic tasks are provided to process all the possible actions (i.e., MaaS_ML_Service_Start, Deploy_ML_Model, Call_Prediction_Endpoint, MaaS_ML_Actions[Finish/Pause/Resume]). These tasks can be easily integrated to your AI pipelines/workflows as you can see in this Deployment Pipeline Example.

  • Using the Service Automation Portal by executing the different actions associated to MaaS_ML (i.e. Deploy_ML_Model, Pause_MaaS_ML, Update_MaaS_ML, Finish_MaaS_ML.)

  • Using the Swagger UI which is accessible once the MaaS_ML instance is up and running.

Once a MaaS_ML instance is up and running, it could be used for:

  • AI Model Deployment or Update: the user has to provide a valid specific AI Model identifier in order to deploy the model of his/her choice.

  • Call of Predictions: when a specific AI model is running, the user can request predictions for a specific payload. This latter has to be converted into json data in order to get prediction values.

  • Deploy a New Specific AI Model: the running generic AI model can be used to deploy a new specific AI model.

Using MaaS_ML, you can easily deploy and use any machine learning model as a REST Web Service on a physical or a virtual compute host on which there is an available Proactive Node. Going through the Proactive Scheduler, you can also trigger the deployment of a specific VM using the Resource Manager elastic policies, and eventually, deploy a Model-Service on that specific node.

In the following subsections, we will illustrate the life cycle of a MaaS_ML instance, from starting the generic service instance, deploying a specific model, pausing it, to deleting the instance. We will also talk about how the life cycle of a MaaS_ML instance can be managed via three different ways in PML:

In the description below, multiple tables represent the main variables that characterize the MaaS_ML workflows. In addition to the variables mentioned below, there is a set of generic variables that are common between all workflows which can be found in the subsection AI Workflows Common Variables. The management of the life cycle of MaaS_ML will be detailed in the next sub-sections.

5.1. Via Studio Portal

5.1.1. Start a Generic Service Instance

Open the Studio Portal.

Create a new workflow.

Add the model_as_a_service bucket by clicking in the View menu field > Add Bucket Menu to the Palette > model_as_a_service..

Drag and drop the MaaS_ML_Service_Start task from the bucket.

Execute the workflow by setting the different workflow’s variables as described in the Table below.

Table 3. MaaS_ML_Service_Start variables

Variable name

Description

Type

Workflow variables

MODEL_SERVICE_INSTANCE_NAME

Service instance name.

String (default="maas_ml-${PA_JOB_ID}").

MODEL_SERVICE_PROXIFIED

Allows access to the endpoint through an Http(s) Proxy.

Boolean (default=False).

MODEL_SERVICE_ENTRYPOINT

This entry script starts the service and defines the different functions to deploy the model, scores the prediction requests based on the deployed model, and returns the results. This script is specific to your model. This file should be stored in the Catalog under the model_as_service_resources bucket. More information about this file can be found in the Customize the Service section.

String (default="ml_service").

MODEL_SERVICE_YAML_FILE

A YAML file that describes the OpenAPI Specification ver. 2 (known as Swagger Spec) of the service. This file should be stored in the catalog under the model_as_service_resources bucket. More information about the structure of this file can be found in the section Customize the Service.

String (default="ml_service-api").

MODEL_SERVICE_USER_NAME

A valid user name having the needed privileges to execute this action.

String (default="user").

MODEL_SERVICE_NODE_NAME

The name of the node where the service will be deployed. If empty, the service will be deployed on an available node selected randomly.

String (default=Empty)

Task variables

SERVICE_ID

The name of the service. Please keep the default value for this variable.

String (default="MaaS_ML")

INSTANCE_NAME

The name of the service that will be deployed.

String (default="maas-ml-${PA_JOB_ID}")

ENGINE

Container engine.

String (default="$CONTAINER_PLATFORM")

PROXIFIED

It takes by default the value of MODEL_SERVICE_PROXYFIED workflow variable.

String (default="$MODEL_SERVICE_PROXYFIED")

PYTHON_ENTRYPOINT

It takes by default the value of MODEL_SERVICE_ENTRYPOINT workflow variable.

String (default="$MODEL_SERVICE_ENTRYPOINT")

YAML_FILE

It takes by default the value of MODEL_SERVICE_YAML_FILE workflow variable.

String (default="$MODEL_SERVICE_YAML_FILE")

USER_NAME

It takes by default the value of MODEL_SERVICE_USER_NAME workflow variable.

String (default="$MODEL_SERVICE_USER_NAME")

NODE_NAME

It takes by default the value of MODEL_SERVICE_NODE_NAME workflow variable.

String (default="$MODEL_SERVICE_NODE_NAME")

5.1.2. Deploy a Specific ML Model

You can also deploy a specific ML model directly from the Studio Portal.

Drag and drop the Deploy_ML_Model task from the MaaS_ML bucket.

Execute the workflow and set the different workflow’s variables as follows:

Table 4. Deploy_ML_Model variables

Variable name

Description

Type

Workflow variables

CONTAINER_PLATFORM

Specifies the type of container platform to be used (no container, docker, singularity, or podman).

String (default=docker)

CONTAINER_GPU_ENABLED

If True, containers will run based on images containing libraries that are compatible with GPU.

Boolean (default=False)

CONTAINER_IMAGE

Specifies the name of the image that will be used to run the different workflow tasks.

String (default=Empty).

SERVICE_TOKEN

A valid token generated by the MaaS_ML Service for user authentication.

String (default=Empty).

Task variables

DEPLOY_MODEL_ENDPOINT

A URL endpoint defined by the user where the AI Model was deployed

URL (default=Empty).

API_EXTENSION

The base path to access the deployment endpoint.

String (default="/api/deploy")

MODEL_URL

A valid URL specified by the user referencing the model that needs to be deployed.

URL (default= https://activeeon-public.s3.eu-west-2.amazonaws.com/models )

SERVICE_TOKEN

A valid token generated by the MaaS_ML Service for user authentication.

String (default=Empty).

DRIFT_DETECTION_WINDOW_SIZE

The size of the data to be extracted from the old training dataset to be used as a baseline data for the drift detection.

Integer (default=50).

5.1.3. Call the Service for Predicition

Once the model is deployed, you can also call the service for prediction directly from the Studio Portal.

Drag and drop the Call_Prediction_Endpoint task from the MaaS_ML bucket.

Execute the Workflow and set the different workflow’s variables as follows:

Table 5. Call_Prediction_Endpoint variables

Variable name

Description

Type

Workflow variables

CONTAINER_PLATFORM

Specifies the type of container platform to be used (no container, docker, singularity, or podman).

String (default=docker)

CONTAINER_GPU_ENABLED

If True, containers will run based on images containing libraries that are compatible with GPU.

Boolean (default=False)

CONTAINER_IMAGE

Specifies the name of the image that will be used to run the different workflow tasks.

String (default=Empty).

SERVICE_TOKEN

A valid token generated by the MaaS_ML Service for user authentication.

String (default=Empty).

Task variables

PREDICT_MODEL_ENDPOINT

The endpoint of the started service.

URL (default=Empty)

SERVICE_TOKEN

A valid token generated by the MaaS_ML Service for user authentication.

String (default=Empty).

PREDICT_EXTENSION

The base path to access the prediction endpoint.

String (default="/api/predict")

INPUT_DATA

Entry data that needs to be scored by the deployed model.

JSON (default=Empty)

LABEL_COLUMN

Name of the label column. It needs to be set if data is labeled.

String (default=Empty)

DATA_DRIFT_DETECTOR

Name of the data drift detector to be used in the drift detection process.

List [HDDM,Page Hinkley, ADWIN] (default="HDDM")

5.1.4. Delete/Finish the Service

You can also delete the service instance using the Studio Portal.

Drag and drop the MaaS_ML_Actions task from the MaaS_ML bucket.

Execute the Workflow and set the different workflow’s variables as follows:

Table 6. MaaS_ML_Actions variables

Variable name

Description

Type

Task variables

ACTION

The action that will be processed regarding the service status.

List [Pause_MaaS_ML, Resume_MaaS_ML, Finish_MaaS_ML] (default="Finish_MaaS_ML")

INSTANCE_NAME

The name of the service that the action will be processed on.

String (default="maas-ml-${PA_JOB_ID}")

INSTANCE_ID

The service instance ID.

String (default=Empty)

5.2. Via Service Automation Portal

5.2.1. Start a Generic Service Instance

Search for MaaS_ML in Services Workflows List.

Set the following variables:

Table 7. MaaS_ML variables

Variable name

Description

Type

BUILD_IMAGE_IF_NOT_EXISTS

Pull and build the singularity image if the Singularity Image File (SIF) file is not available.

Boolean (default=True)

DEBUG_ENABLED

If True, the user will be able to examine the stream of output results of each task.

Boolean (default=True)

DOCKER_IMAGE

Specifies the name of the Docker image that will be used to run the different workflow tasks.

String (default="activeeon/maas_ml")

DRIFT_ENABLED

True if a detector is needed to check for drifts in the input datasets compared to the training datasets.

Boolean (default=True)

DRIFT_THRESHOLD

The level or point at which the data drift is detected and the user is notified.

Float (default=1.9)

ENDPOINT_ID

The endpoint_id that will be used if PROXYFIED is set to True.

String (default="maas-ml-gui")

ENGINE

Container engine.

List (default="docker")

HTTPS_ENABLED

True if the protocol https is needed for the defined model-service.

Boolean (default=False)

INSTANCE_NAME

The name of the service that will be deployed.

String (default="maas-ml")

NODE_NAME

The name of the node where the service will be deployed. If empty, the service will be deployed on an available node selected randomly.

String (default=Empty)

PROXYFIED

True if a proxy is needed to protect the access to this model-service endpoint.

Boolean (default=False)

PYTHON_ENTRYPOINT

This entry script starts the service and defines the different functions to deploy the model, scores the prediction requests based on the deployed model, and returns the results. This script is specific to your model. This file should be stored in the Catalog under the model_as_service_resources bucket. More information about this file can be found in the Customize the Service section.

String (default="ml_service").

SERVICE_PORT

Controls the port used to start the Model Service from the Service Automation Portal. -1 for random port allocation.

Integer (default="-1").

SINGULARITY_IMAGE_PATH

Location of the singularity image on the node file system (this path will be used to either store the singularity image or the image will be directly used if the file is present).

String (default="/tmp/maas_ml.sif")

TRACE_ENABLED

True if the user wants to keep a trace on the different changes occurring in the service.

Boolean (default=True)

YAML_FILE

A YAML file that describes the OpenAPI Specification ver. 2 (known as Swagger Spec) of the service. This file should be stored in the catalog under the model_as_service_resources bucket. More information about the structure of this file can be found in the section Customize the Service.

String (default="ml_service-api").

Click on Execute Action and follow the progress of the service creation.

500

5.2.2. Deploy a Specific ML Model

Once the status of your generic model service is displayed as RUNNING on Service Automation, you can deploy your model by following the steps below :

Select and execute the Deploy_ML_Model from Actions to deploy your model.

Set the Following variables:

Table 8. Deploy_ML_Model variables

Variable name

Description

Type

BASELINE_DATA_URL

URL of the dataset to be deployed and used in the data drift detection process.

URL (default= https://activeeon-public.s3.eu-west-2.amazonaws.com/datasets/baseline_data.csv)

DEVIATION_DETECTION

If True, the data drift will be detected and the user will be notified about the drift.

Boolean (default=True)

DEVIATION_THRESHOLD

It represents the data drift threshold, the level or point at which the data drift is detected and the user is notified.

Float (default=1.9)

LOGGING_PREDICTION

If True, the predictions will be stored and the user will be able to preview them.

Boolean (default=True)

MODEL_URL

A valid URL specified by the user referencing to the model that needs to be deployed.

URL (default= https://activeeon-public.s3.eu-west-2.amazonaws.com/models/model.pkl)

MODEL_METADATA

This variable contains some statistical features such as the mean and the standard deviation extracted from the training data used to build the model that should be deployed. This metadata is used for the purpose of detecting drifts.

Numerical vector (default= [[5.8216666667,3.0658333333,3.695,1.1766666667],[0.8128364419,0.4385797999,1.7614380107,0.7581194484]])

USER_NAME

A valid user name having the needed privileges to execute this action.

String (default="user")

Click on Execute Action and follow the progress of the model deployment.

Check that the status correctly evolves to AI_MODEL_DEPLOYED.

5.2.3. Delete (Finish)/Update/Pause the Service

You can delete the launched service instance directly from the Service Automation Portal:

Set the action Finish under Actions and click on Execute Action.

MAAS ML Delete Service

There are also two other actions that can be executed from the Service Automation Portal which are:

  • Deploy_ML_Model: This action will put the service instance into deployment.

  • Update_MaaS_ML: This action will update the deployed instance according to the updated variables.

  • Pause_MaaS_ML: This action will pause the service instance.

When running the Model Service with Singularity as an Engine, the Pause_MaaS_ML action can not be executed.

5.2.4. Audit and Traceability

To access the Audit and Traceability page, click on the endpoint under the Endpoint list.

In this page, you are able to check the different values of the model variables. You can also track the traceability information of the token during several date/time(s) as shown in the below image.

traceability1

It is possible to visualize the model predictions by clicking on the first link in the top of the page. This link will take you to a Predictions Preview page that lists the set of predictions corresponding to the input dataset.

5.3. Via Swagger UI

To access the Swagger UI, click on the second link in the top of the Traceability & Audit page.

Through this Swagger UI, you are now able to:

  • Ask for an api_token

  • Deploy a model

  • List the deployed models

  • Make predictions

  • Return stored predictions

  • Redeploy a previous deployed model

  • Return the stored traceability information

  • Remove deployed model

  • Update the service parameter

5.3.1. Deploy/Undeploy/Redeploy a Specific ML Model

You can also deploy a specific ML model using the Swagger UI:

Open the Swagger UI.

Open the get_token operation and get an api_token by entering your username (default value is user).

Open the deploy operation and set the provided token and upload the model that need to be deployed.

NEW MAS Deploy Swagger

Open list_models to return the list of all already deployed models.

Open redeploy to redeploy a previously deployed model using its token.

Open undeploy to remove a deployed model using its token.

5.3.2. Call the Service for Predictions

Once the model is deployed, you can call the service for predictions using the Swagger UI:

Open the Swagger UI.

Open the get_token operation and get an api_token by entering your username (default value is user).

Open the predict operation and set the provided token and the data that you need to score.

MAS Predict Swagger

5.4. Deployment Pipeline Example

You can connect the different tasks in a single workflow to get the full pipeline from the model training step to the model deployment and consumption steps. Each task will propagate the acquired variables to its children tasks. The following workflow example is available on the model_as_a_service bucket under the name of IRIS_Deploy_Flower_Classifier_Model. This example trains an Iris Flower Classifier, starts a service instance where the trained model is deployed and the input data is scored by consuming the endpoints exposed by the maas_ml service.

NEW MAAS ML IRIS Workflow Example

5.5. Customize the Service

It is possible to customize the model as a service defined by default and adapt it to your specific needs. Indeed, you can customize the following elements according to your needs:

  • The file specified in the PYTHON_ENTRYPOINT variable

  • The file specified in the YAML_FILE variable

  • The docker image specified in the DOCKER_IMAGE variable

In the following, we describe in depth the content of each element:

PYTHON_ENTRYPOINT file: The following python script refers to the ml_service.py file stored in the catalog under the model_as_a_service_resources bucket. This script defines the different functions needed to deploy the model, score data and generate tokens. It is possible to edit this script to make it more customized to your model. The entry script must take into consideration the:

  • List of users that are allowed to consume the service endpoints

  • Format of the model expected by the deployment and the prediction functions (e.g., pickle, joblib, etc.)

  • Format of the incoming data (e.g., JSON, Array, Matrix, etc.)

  • Data format expected by the model (e.g., JSON, Array, Matrix, etc.)

The model_as_a_service_resources bucket can be found under the Catalog section in the Automation Dashboard portal.

YAML_FILE file: The following YAML script refers to the ml_service-api.yml file stored in the catalog under the model_as_a_service_resources bucket. This script defines the OpenAPI specification describing the entire API built once a model_service is started. You can adapt and edit this script in order to customize your service.

DOCKER_IMAGE name: Choose your own image containing the different dependencies required to run your ENTRYPOINT_SCRIPT. Activeeon provides a pre-built image activeeon/model_as_a_service ìncluding different machine learning and deep learning libraries. If you need to use your own docker image to start the service, you need to install the following libraries in your image:

# install java
apt-get update && apt-get install -y openjdk-11-jdk
apt-get install ca-certificates-java && update-ca-certificates -f
JAVA_HOME /usr/lib/jvm/java-11-openjdk-amd64/
export JAVA_HOME
apt-get clean

# install python libraries
pip install connexion[swagger-ui](1)
pip install py4j(2)

# install your dependent libraries
...
1 Connexion allows you to write an OpenAPI specification, then maps the endpoints to your Python functions.
2 py4j enables Python programs running in a Python interpreter to dynamically access Java objects in a Java Virtual Machine.

5.6. Data Drift Detection (DDD)

The data evolves over time and can therefore cause degradations affecting the intrinsic characteristics and behavior of the learning model. Data drift is one of the main reasons why the accuracy of the model degrades over time. Therefore, it is important that the model is able to adapt to these changes. Monitoring data drifts allows to detect the model performance drops (as in the figure below) to take actions accordingly. To deal with this problem, we have integrated a data drift detection mechanism in the Machine Learning as a Service module of ProActive.

drift

This mechanism enables the discovery of data drifts at a fine level of granularity. We have developed a DDD mechanism that not only allows us to discover that a drift has occurred, but also to indicate the exact location of the drift in the input dataset. It can specify on which attributes or characteristics and more precisely on which lines the drift occurred.

This allows the user to better manage the drift and to act accordingly. In fact, the input data set is monitored using different methods of data drift detection in which the user is free to choose the one that best suits his needs. Currently, we use three well-known methods for this purpose: HDDM, Page Hinkley and ADWIN. This list is likely to be expanded in the future to include other drift detection methods. To detect drift in a new dataset, it is necessary to compare it to the old training dataset on which the model was trained. Thus, any detected drift indicates that the model is not the best predictor and that new training on the new dataset should take place.

As the DDD function is part of the MaaS_ML module, it can also be launched from different Proactive portals.

5.6.1. Via Studio Portal

The data drift detection mechanism is added to the tasks and workflows of the bucket model_as_a_service. This mechanism is directly linked to the deployment of the model in MaaS_ML (where the user deploys the model and a part of the old training dataset to be used for drift detection in the new input data set), and to the call of the prediction service in MaaS_ML (where the drift detector is chosen and the detection process is started using the chosen detector).

The workflow IRIS_Deploy_Predict_Flower_Classifier_Model, found in the model_as_a_service bucket in the Proactive Studio Portal, shows an example of pipeline using the generic tasks Deploy_ML_Model and Call_Prediction_Service including the DDD mechanism.

In particular, in the Deploy_ML_Model task, the user is asked to enter DRIFT_DETECTION_WINDOW_SIZE which is a task variable specifying the size of the data to be extracted from the old training dataset (the dataset on which the model was initially trained). For example, if the user chooses a value = 50 for this variable, the algorithm will randomly choose 50 lines from the old training dataset. This subset of data (we call it baseline data) will be saved in the service in order to be used afterward for the data drift detection process which will be enacted in the Call_Prediction_Service.

In the Call_Prediction_Service, the user is asked to choose the data drift detector to be used in the drift detection process. This can be chosen using the task variable DATA_DRIFT_DETECTOR in which the user can choose one of HDDM, Page Hinkley or ADWIN as a drift detector. The algorithm here concatenates the deployed baseline_data to the new input (to be predicted) dataset. The chosen drift detector then will use the concatenated data to extract the rows and columns where the drift took place in the new data. These drift detection algorithms are enhanced in Proactive to be able to detect the attributes where the drift occurred (the columns).

The obtained predictions and drifts can be viewed in the resulting output of the Proactive Scheduler Portal.

5.6.2. Via Service Automation Portal and Swagger UI

As we have mentioned earlier in this documentation, a model can be deployed using the MaaS_ML in the Service_Automation of the Automation Dashboard Portal. To enable the data drift detection process, the DRIFT_ENABLED variable should be set to True. Once the service is launched, the model can be deployed by choosing Deploy_MaaS_ML action. In the Deploy_MaaS_ML variables, the user can specify the url of the baseline_data using the BASELINE_DATA_URL variable that appears in the popup window of Deploy_Model_Service action. In case you need to change the baseline data, it can be updated using the BASELINE_DATA_URL variable of the Update_MaaS_ML action of MaaS_ML.

Once the model is deployed via the Service Automation portal, the Swagger user interface can be opened via the MaaS_ML instance api, offering different endpoints to help the user manage the drift detection mechanism. This mechanism has been particularly integrated into the following three endpoints:

  • In the /deploy() endpoint, a user can choose the model (using model_file variable) and its associated baseline data (using baseline_data variable) to be deployed.

  • In the /predict() endpoint, the user specifies the drift detection method and the input data to be predicted. Using the baseline data and the specified drift detector method, our algorithm can detect in which attributes and particularly which rows the drift took place in the input data. The results are shown in Response Body of the /predict() endpoint and in the Traceability and Audit page.

  • In the /update endpoint, the user is able to update the baseline data deployed with the model using the baseline_data variable.

In case a data drift has occurred, a user will receive a notification using the Proactive Notification service in the Automation Dashboard.

6. Model as a Service for Deep Learning (MaaS_DL)

MaaS_DL is a model deployment service for putting AI models to production. MaaS_DL comes with new capabilities, compared to MaaS_ML, enabling users to deploy deep learning models, to update the deployed models with an updated version and to easily rollback to any previous version(s). It provides out-of-the-box integration with TensorFlow Serving TFX taking advantage of its flexibility and high-performance serving system.

The life cycle of any MaaS_DL instance (i.e., from starting the generic service instance, deploying an AI specific model to pausing or deleting the instance) can be managed in three different ways in PML :

  • Using the Studio Portal and more specifically the bucket model-as-a-service where specific generic tasks are provided to process all the possible actions (i.e., MaaS_DL_Service_Start, Deploy_DL_Model, MaaS_DL_Actions[Finish/Pause/Resume], Undeploy_DL_Model). These tasks can be easily integrated to your AI pipelines/workflows as you can see in this Deployment Pipeline Example.

  • Using the Service Automation Portal by executing the different actions associated to MaaS_DL (i.e. Deploy_DL_Model, Redeploy_DL_Model, Undeploy_DL_Model)

  • Using the Swagger UI which is accessible once the MaaS_DL instance is up and running.

Using MaaS_DL, you can easily deploy and use any machine or deep learning model as a REST Web Service on a physical or a virtual compute host on which there is an available Proactive Node. Going through the Proactive Scheduler, you can also trigger the deployment of a specific VM using the Resource Manager elastic policies, and eventually, deploy a Model-Service on that specific node.

In the following subsections, we will illustrate the life cycle of a MaaS_DL instance, from starting the generic service instance, deploying a specific model, undeploying it, to deleting the instance. We will also talk about how the life cycle of a MaaS_DL instance can be managed via three different ways in PML:

In the description below, multiple tables represent the main variables that characterize the MaaS_DL workflows. In addition to the variables mentioned below, there is a set of generic variables that are common between all workflows which can be found in the subsection AI Workflows Common Variables. The management of the life cycle of MaaS_DL will be detailed in the next sub-sections.

6.1. Via Studio Portal

6.1.1. Start a Generic Service Instance

Open the Studio Portal.

Create a new workflow.

Add the model_as_a_service bucket by clicking in the View menu field > Add Bucket Menu to the Palette > model_as_a_service.

Drag and drop the MaaS_DL_Service_Start task from the bucket.

Execute the workflow by setting the different workflow’s variables as described in the Table below.

Table 9. MaaS_DL_Service_Start variables

Variable name

Description

Type

Workflow variables

MODEL_SERVICE_INSTANCE_NAME

Service instance name.

String (default="maas_dl-${PA_JOB_ID}").

MODEL_SERVICE_PROXIFIED

Allows access to the endpoint through an Http(s) Proxy.

Boolean (default=False).

MODEL_SERVICE_ENTRYPOINT

This entry script starts the service and defines the different functions to deploy the model, scores the prediction requests based on the deployed model, and returns the results. This script is specific to your model. This file should be stored in the Catalog under the model_as_service_resources bucket. More information about this file can be found in the Customize the Service section.

String (default="dl_service").

MODEL_SERVICE_YAML_FILE

A YAML file that describes the OpenAPI Specification ver. 2 (known as Swagger Spec) of the service. This file should be stored in the catalog under the model_as_service_resources bucket. More information about the structure of this file can be found in the section Customize the Service.

String (default="dl_service-api").

MODEL_SERVICE_USER_NAME

A valid user name having the needed privileges to execute this action.

String (default="user").

6.1.2. Deploy a Specific DL Model

You can also deploy a specific DL model directly from the Studio Portal.

Drag and drop the Deploy_DL_Model task from the MaaS_DL bucket.

Execute the workflow and set the different workflow’s variables as follows:

Table 10. Deploy_DL_Model variables

Variable name

Description

Type

Workflow variables

CONTAINER_PLATFORM

Specifies the type of container platform to be used (no container, docker, singularity, or podman).

String (default=docker)

CONTAINER_GPU_ENABLED

If True, containers will run based on images containing libraries that are compatible with GPU.

Boolean (default=False)

CONTAINER_IMAGE

Specifies the name of the image that will be used to run the different workflow tasks.

String (default=Empty).

SERVICE_TOKEN

A valid token generated by the MaaS_DL Service for user authentication.

String (default=Empty).

Task variables

DEPLOY_MODEL_ENDPOINT

A URL endpoint defined by the user where the AI Model was deployed

URL (default=Empty).

API_EXTENSION

The base path to access the deployment endpoint.

String (default="/api/deploy")

MODEL_URL

A valid URL specified by the user referencing the model that needs to be deployed.

URL (default=Empty )

MODEL_VERSION

The version number of the model that will be deployed.

Integer (default=Empty )

SERVICE_TOKEN

A valid token generated by the MaaS_DL Service for user authentication.

String (default=Empty).

USER_NAME

A valid user name having the needed privileges to execute this action.

String (default=Empty)

APPEND

If True, the model will be appended to the list of already deployed models.

Boolean (default=True).

6.1.3. Undeploy a Specific DL Model

You can also undeploy a specific DL model directly from the Studio Portal.

Drag and drop the Undeploy_DL_Model task from the MaaS_DL bucket.

Execute the Workflow and set the different workflow’s variables as follows:

Table 11. Undeploy_DL_Model variables

Variable name

Description

Type

Task variables

DEPLOY_MODEL_ENDPOINT

A URL endpoint defined by the user where the AI Model was deployed

URL (default=Empty).

API_EXTENSION

The base path to access the deployment endpoint.

String (default="/api/deploy")

MODEL_NAME

The name of the model to be undeployed.

String (default=Empty )

MODEL_VERSION

The version number of the model that will be undeployed.

Integer (default=Empty )

USER_NAME

A valid user name having the needed privileges to execute this action.

String (default=Empty)

6.1.4. Delete/Finish the Service

You can also delete the service instance using the Studio Portal.

Drag and drop the MaaS_DL_Actions task from the MaaS_DL bucket.

Execute the Workflow and set the different workflow’s variables as follows:

Table 12. MaaS_DL_Actions variables

Variable name

Description

Type

Task variables

ACTION

The action that will be processed regarding the service status.

List [Pause_MaaS_DL, Resume_MaaS_DL, Finish_MaaS_DL] (default="Finish_MaaS_DL")

INSTANCE_NAME

The name of the service that the action will be processed on.

String (default="maas-dl-${PA_JOB_ID}")

INSTANCE_ID

The service instance ID.

String (default=Empty)

6.2. Via Service Automation Portal

6.2.1. Start a Generic Service Instance

Search for MaaS_DL in Services Workflows List.

Set the following variables:

Table 13. MaaS_DL variables

Variable name

Description

Type

BUILD_IMAGE_IF_NOT_EXISTS

Pull and build the singularity image if the Singularity Image File (SIF) file is not available.

Boolean (default=True)

DEBUG_ENABLED

If True, the user will be able to examine the stream of output results of each task.

Boolean (default=True)

DOCKER_IMAGE

Specifies the name of the Docker image that will be used to run the different workflow tasks.

String (default="activeeon/maas_dl")

ENDPOINT_ID

The endpoint_id that will be used if PROXYFIED is set to True.

String (default="maas_dl-gui")

ENGINE

Container engine.

List (default="docker")

HTTPS_ENABLED

True if the protocol https is needed for the defined model-service.

Boolean (default=False)

INSTANCE_NAME

The name of the service that will be deployed.

String (default="maas_dl")

MODEL_BASE_PATH

Location of the model on the node file system (this path will be used to store the model).

String (default="/tmp")

MODELS_DEPLOYMENT_REFRESH

The amount of seconds to periodically poll for updated versions of the model configuration file.

Integer (default = 30)

NATIVE_SCHEDULER

Name of the Native Scheduler node source to use when the workflow tasks must be deployed inside a cluster such as SLURM, LSF, etc.

String (default=Empty)

NATIVE_SCHEDULER_PARAMS

Parameters given to the native scheduler (SLURM, LSF, etc) while requesting a ProActive node used to deploy the workflow tasks.

String (default=Empty)

NODE_NAME

The name of the node where the service will be deployed. If empty, the service will be deployed on an available node selected randomly.

String (default=Empty)

PROXYFIED

True if a proxy is needed to protect the access to this model-service endpoint.

Boolean (default=False)

PYTHON_ENTRYPOINT

This entry script starts the service and defines the different functions to deploy the model, scores the prediction requests based on the deployed model, and returns the results. This script is specific to your model. This file should be stored in the Catalog under the model_as_service_resources bucket. More information about this file can be found in the Customize the Service section.

String (default="dl_service").

SERVICE_PORT

Controls the port used to start the Model Service from the Service Automation Portal. -1 for random port allocation.

Integer (default="-1").

SINGULARITY_IMAGE_PATH

Location of the singularity image on the node file system (this path will be used to either store the singularity image or the image will be directly used if the file is present).

String (default="/tmp/maas_dl.sif")

TRACE_ENABLED

True if the user wants to keep a trace on the different changes occurring in the service.

Boolean (default=True)

YAML_FILE

A YAML file that describes the OpenAPI Specification ver. 2 (known as Swagger Spec) of the service. This file should be stored in the catalog under the model_as_service_resources bucket. More information about the structure of this file can be found in the section Customize the Service.

String (default="dl_service-api").

Click on Execute Action and follow the progress of the service creation.

500

6.2.2. Deploy a Specific DL Model

Once the status of your generic model service is displayed as RUNNING on Service Automation, you can deploy your model by following the steps below :

Select and execute the Deploy_DL_Model from Actions to deploy your model.

Set the Following variables:

Table 14. Deploy_DL_Model variables

Variable name

Description

Type

APPEND

If True, the model will be appended to the list of already deployed models.

Boolean (default= True)

MODEL_NAME

The name of the model to be deployed.

String (default= "mnist_model")

MODEL_URL

A valid URL specified by the user referencing to the model that needs to be deployed.

URL (default= Empty)

MODEL_VERSION

The version number of the model that will be deployed.

Integer (default= 1)

USER_NAME

A valid user name having the needed privileges to execute this action.

String (default= "user")

Click on Execute Action and follow the progress of the model deployment.

6.2.3. Redeploy a Specific DL Model

It is also possible to redeploy a specific DL model version that has been already deployed and saved at least once in this service instance by following the steps below :

Select and execute the Redeploy_DL_Model from Actions to redeploy your model.

Set the Following variables:

Table 15. Redeploy_DL_Model variables

Variable name

Description

Type

APPEND

If True, the model will be appended to the list of already deployed models.

Boolean (default= True)

MODEL_NAME

The name of the model to be redeployed.

String (default= "mnist_model")

MODEL_VERSION

The version number of the model that will be redeployed.

Integer (default= 1)

USER_NAME

A valid user name having the needed privileges to execute this action.

String (default= "user")

Click on Execute Action and follow the progress of the model deployment.

6.2.4. Delete (Finish)/Update/Pause the Service

You can delete the launched service instance directly from the Service Automation Portal:

Set the action Finish under Actions and click on execute.

MAAS DL Delete Service

6.3. Via Swagger UI

To access the Swagger UI, click on the second link in the top of the Traceability & Audit page.

Through this Swagger UI, you are now able to:

  • Ask for an api_token

  • Deploy a model

  • List the deployed models

  • List the saved models in MODELS_PATH repository

  • Delete the saved models in MODELS_PATH repository

  • Make predictions

  • Redeploy a previous deployed model

  • Return the stored traceability information

  • Remove deployed model

  • Upload a new model config that will be used by Tensorflow model server

  • Return the model config used by the Tensorflow model server

6.3.1. Deploy/Undeploy/Redeploy a Specific DL Model

You can also deploy a specific DL model using the Swagger UI:

Open the Swagger UI.

Open the get_token operation and get an api_token by entering your username (default value is user).

Open the deploy operation and set the provided token and upload the model that need to be deployed.

NEW MAAS DL Deploy Swagger

Open list_deployed_models to return the list of all already deployed models.

Open list_saved_models to return the list of saved models in MODELS_PATH repository.

Open redeploy to redeploy a previously deployed model using its token.

Open undeploy to remove a deployed model using its token.

Open clean_saved_models to delete the list of saved models in MODELS_PATH repository.

6.3.2. Call the Service for Predictions

Once the model is deployed, you can call the service for predictions using the Swagger UI:

Open the Swagger UI.

Open the get_token operation and get an api_token by entering your username (default value is user).

Open the predict operation and set the provided token and the data that you need to score.

MAAS DL Predict Swagger

6.3.3. Upload/Download Model Configuration

Once the model is deployed, you can download and/or upload the model configuration file using the Swagger UI: Open the Swagger UI.

Open the get_token operation and get an api_token by entering your username (default value is user).

Open the download_model_config to return the model config used by the Tensorflow model server.

Open the upload_model_config operation and set the provided token and the new model config file that will be used by Tensorflow model serve.

MAAS DL model config

6.4. Deployment Pipeline Example

You can connect the different tasks in a single workflow to get the full pipeline from the model training step to the model deployment and consumption steps. Each task will propagate the acquired variables to its children tasks. The following workflow example is available on the model_as_a_service bucket under the name of MNIST_Model_Training_and_Deployment. This example trains a Mnist model, starts a service instance where the trained model is deployed as a service using the Maas_DL PSA service.

NEW MAAS DL MNIST Workflow Example

7. Job Analytics

The ProActive Job Analytics is a dashboard that provides an overview of executed workflows along with their input variables and results.

It offers several functionalities, including:

  • Advanced search by name, user, date, state, etc.

  • Execution metrics summary about durations, encountered issues, etc.

  • Charts to track variables and results evolution and correlation.

  • Export data in multiple formats for further use in analytics tools.

The screenshot below shows an overview of the Job Analytics Portal.

JA overview

Job Analytics is very useful to compare metrics and charts of workflows that have common variables and results. For example, a ML algorithm might take different variable values and produce multiple results. It would be interesting to analyze the correlation and evolution of algorithm results regarding the input variation (See also a similar example of AutoML). The following sections will show you some key features of the dashboard and how to use them for a better understanding of your job executions.

Job Analytics Portal includes a search window that allows users to search for jobs based on specific criteria (see screenshot below). The job search panel allows to select multi-value filters for the following job parameters:

  • Workflow Name(s): Jobs can be filtered by workflow name. Selecting/Typing one or more workflow names is provided by a built-in auto-complete feature that helps you search for workflows or buckets from the ProActive Catalog.

  • Project Name(s): You can also filter by one or more project names. You just have to specify the project names for the jobs you would like to analyze.

  • Job Status: You can specify the state of jobs you are looking for. The possible job status are: Pending, Running, Stalled, Paused, In_Error, Finished, Canceled, Failed, and Killed. For more information about job status, check the documentation here. Multiple values are accepted as well.

  • User(s): This filter allows to either select only the jobs of the connected/current user or to specify a list of users that have executed the jobs. By default, the toggle filter is activated to select only the user jobs.

  • Submission Time: From the dropdown list, users can select a submission time frame (e.g., yesterday, last week, this month, etc.), or choose custom dates.

  • Variables and results: It is possible to choose whether to display or not the workflow’s variables and results. When deactivated, the charts related to variables and results evolution/correlation will not be displayed in the dashboard.

More advanced search options (highlighted in advanced search hints) could be used to provide filter values such as wildcards. For example, names that start with a specific string value are selected using value*. Other supported expressions are: *value for Ends with, *value* for Contains, !value for Not equals, and !*value* for Not contains.

Now you can hit the search button to request jobs from the scheduler database according to the provided filter values. The search bar at the top shows a summary of the active search filters.

JA search

7.2. Execution Metrics

As shown in the screenshot below, Job Analytics Portal provides a summary of the most important job execution metrics. For instance, the dashboard shows:

  • A first panel that displays the number of total jobs that correspond to the search query. It also shows the ratio of successful jobs over the total number, and the number of jobs that are in progress and not yet finished. Please note that the number of in-progress jobs corresponds to the moment when the search query is executed and it is not automatically refreshed.

  • A second summary panel that displays the number of jobs with issues. We distinguish two types of issues: jobs that are finished but have encountered issues during their execution and interrupted jobs that did not finish their execution and were stopped due to diverse causes, such as insufficient resources, manual interruption, etc. Interrupted jobs include four status: In-Error, Failed, Canceled, and Killed.

  • The last metric gives an overview of the average duration of the selected jobs.

JA metrics

7.3. Job Charts

Job Analytics includes three types of charts:

  • Job duration chart: This chart shows durations per job. The x-axis shows the job ID and the y-axis shows the job duration. Hovering over the lines will also display the same information as a tooltip (see screenshot below). Using the duration chart will eventually help the users to identify any abnormal performance behaviour among several workflow executions.

JA duration
  • Job variables chart: This chart is intended to show all variable values of selected jobs. It represents the evolution chart for all numeric-only variables of the selected jobs. The chart provides the ability to hide or show specific input variables by clicking on the variable name in the legend, as shown in the figure below.

  • Job results chart: This chart is intended to show all result values of selected jobs. It represents the evolution chart for all numeric-only results of the selected jobs. The chart provides also the ability to hide or show specific results by clicking on the variable name in the legend, as shown in the figure below.

JA chart

All charts provide some advanced features such as "maximize" and "enlarge" to better visualize the results, and "move" to customize the dashboard layout (see top left side of charts). All of them provide the hovering feature as previously described and two types of charts to display: line and bar charts. Switching from one to the other can be activated through a toggle button located at the top right of the chart. Same for show/hide variables and results.

7.4. Job Execution Table

The last element of the Job Analytics dashboard shows a summary table that contains all job executions returned by the search query. It includes the job ID, status, duration, submission time, variables, results, etc. The jobs table provides many features:

  • Filtering: users can specify filter values for every column. For instance, the picture below applies a filter on the duration where we filter only jobs that last more than 30s. For string values, we can apply string-related filters such as Contains. For dates, a calendar is displayed to help users select the right date. Please note that variables and results types are not automatically detected. Therefore users can choose either the Contains filter or the Greater than and Less than filters.

  • Sort, hide, pin left and right columns: allows users to easily handle and display data with respect to their needs.

  • Export the job data to CSV format: enables users to exploit and process job data using other analytics tools such as R, Matlab, BI tools, ML APIs, etc.

  • Clear and apply filters: When filters are applied, the displayed data is updated. Therefore, we provide a button (see apply filters to charts on the top left of the of the table screenshot) that allows to synchronize the charts with the filtered data in the table. Finally, it is possible to clear all filters. This will automatically deactivate the synchronization.

  • Link to scheduler jobs: data in the job ID column is linked to the job executions in the scheduler. For example, if users want to access to the logs of a failing job, they can click on the corresponding job ID to be redirected to the job location in the Scheduling Portal.

We note also that clicking on the issue types and charts described in the previous sections filters the table to show the corresponding jobs.

It is important to notice that the dashboard layout and search preferences are saved in the browser cache so that users can have access to their last dashboard and search settings.
JA table

8. ProActive Jupyter Kernel

The ActiveEon Jupyter Kernel adds a kernel backend to Jupyter. This kernel interfaces directly with the ProActive scheduler and constructs tasks and workflows to execute them on the fly.

With this interface, users can run their code locally and test it using a native python kernel, and by a simple switch to ProActive kernel, run it on remote public or private infrastructures without having to modify the code. See the example below:

Direct execution from Jupyter with ActiveEon Kernel

8.1. Installation

8.1.1. Requirements

Python 2 or 3

8.1.2. Using PyPi

  • open a terminal

  • install the ProActive jupyter kernel with the following commands:

$ pip install proactive proactive-jupyter-kernel --upgrade
$ python -m proactive-jupyter-kernel.install

8.1.3. Using source code

  • open a terminal

  • clone the repository on your local machine:

$ git clone git@github.com:ow2-proactive/proactive-jupyter-kernel.git
  • install the ProActive jupyter kernel with the following commands:

$ pip install proactive-jupyter-kernel/
$ python -m proactive-jupyter-kernel.install

8.2. Platform

You can use any jupyter platform. We recommend to use jupyter lab. To launch it from your terminal after having installed it:

$ jupyter lab

or in daemon mode:

$ nohup jupyter lab &>/dev/null &

When opened, click on the ProActive icon to open a notebook based on the ProActive kernel.

8.3. Help

As a quick start, we recommend the user to run the #%help() pragma using the following script:

#%help()

This script gives a brief description of all the different pragmas that the ProActive Kernel provides.

To get a more detailed description of a needed pragma, the user can run the following script:

#%help(pragma=PRAGMA_NAME)

8.4. Connection

8.4.1. Using connect()

If you are trying ProActive for the first time, sign up on the try platform. Once you receive your login and password, connect to the trial platform using the #%connect() pragma:

#%connect(login=YOUR_LOGIN, password=YOUR_PASSWORD)

To connect to another ProActive server host, use the later pragma this way:

#%connect(host=YOUR_HOST, [port=YOUR_PORT], login=YOUR_LOGIN, password=YOUR_PASSWORD)
Notice that the port parameter is optional. The default connexion port is 8080.

You can also connect to a distant server by providing its url in the following way:

#%connect(url=YOUR_SERVER_URL, login=YOUR_LOGIN, password=YOUR_PASSWORD)

By providing the complete url of the server, users can eventually connect through the secure HTTPS protocol.

8.4.2. Using a configuration file

For automatic sign in, create a file named proactive_config.ini in your notebook working directory.

Fill your configuration file according to one of the following two formats:

  • By providing the server host and port:

[proactive_server]
host=YOUR_HOST
port=YOUR_PORT
[user]
login=YOUR_LOGIN
password=YOUR_PASSWORD
  • By providing the server url:

[proactive_server]
url=YOUR_SERVER_URL
[user]
login=YOUR_LOGIN
password=YOUR_PASSWORD

Save your changes and restart the ProActive kernel.

You can also force the current kernel to connect using any .ini config file through the #%connect() pragma:

#%connect(path=PATH_TO/YOUR_CONFIG_FILE.ini)

(For more information about this format please check configParser)

8.5. Usage

8.5.1. Creating a Python task

To create a new task, use the pragma #%task() followed by the task implementation script written into a notebook block code. To use this pragma, a task name has to be provided at least. Example:

#%task(name=myTask)
print('Hello world')

General usage:

#%task(name=TASK_NAME, [language=SCRIPT_LANGUAGE], [dep=[TASK_NAME1,TASK_NAME2,...]], [generic_info=[(KEY1,VAL1), (KEY2,VALUE2),...]], [variables=[(VAR1,VAL1), (VAR2,VALUE2),...]], [export=[VAR_NAME1,VAR_NAME2,...]], [import=[VAR_NAME1,VAR_NAME2,...]], [path=IMPLEMENTATION_FILE_PATH])\n'

Users can also provide more information about the task using the pragma’s options. In the following, we give more details about the possible options:

Language

The language parameter is needed when the task script is not written in native Python. If not provided, Python will be selected as the default language. The supported programming languages are:

  • Linux_Bash

  • Windows_Cmd

  • DockerCompose

  • Scalaw

  • Groovy

  • Javascript

  • Jython

  • Python

  • Ruby

  • Perl

  • PowerShell

  • R

Here is an example that shows a task implementation written in Linux_Bash:

#%task(name=myTask, language=Linux_Bash)
echo 'Hello, World!'
Dependencies

One of the most important notions in workflows is the dependencies between tasks. To specify this information, use the dep parameter. Its value should be a list of all tasks on which the new task depends. Example:

#%task(name=myTask,dep=[parentTask1,parentTask2])
print('Hello world')
Variables

To specify task variables, you should provide the variables parameter. Its value should be a list of tuples (key,value) that corresponds to the names and adequate values of the corresponding task variables. Example:

#%task(name=myTask, variables=[(var1,value1),(var2,value2)])
print('Hello world')
Generic information

To specify the values of some advanced ProActive variables called Generic Information, you should provide the generic_info parameter. Its value should be a list of tuples (key,value) that corresponds to the names and adequate values of the Generic Information. Example:

#%task(name=myTask, generic_info=[(var1,value1),(var2,value2)])
print('Hello world')
Export/import variables

The export and import parameters ensure variables propagation between the different tasks of a workflow. If myTask1 variables var1 and var2 are needed in myTask2, both pragmas have to specify this information as follows:

  • myTask1 should include an export parameter with a list of these variable names,

  • myTask2 should include an import parameter with a list including the same names.

Example:

myTask1 implementation block would be:

#%task(name=myTask1, export=[var1,var2])
var1 = "Hello"
var2 = "ActiveEon!"

and myTask2 implementation block would be:

#%task(name=myTask2, dep=[myTask1], import[var1,var2])
print(var1 + " from " + var2)
Implementation file

It is also possible to use an external implementation file to define the task implementation. To do so, the option path should be used.

Example:

#%task(name=myTask,path=PATH_TO/IMPLEMENTATION_FILE.py)

8.5.2. Importing libraries

The main difference between the ProActive and 'native language' kernels resides in the way the memory is accessed during blocks execution. In a common native language kernel, the whole script code (all the notebook blocks) is locally executed in the same shared memory space; whereas the ProActive kernel will execute each created task in an independent process. In order to facilitate the transition from native language to ProActive kernels, we included the pragma #%import(). This pragma gives the user the ability to add libraries that are common to all created tasks, and thus relative distributed processes, that are implemented in the same native script language.

The import pragma is used as follows:

#%import([language=SCRIPT_LANGUAGE]).

Example:

#%import(language=Python)
import os
import pandas
If the language is not specified, Python is considered as default language.

8.5.3. Adding a fork environment

To configure a fork environment for a task, use the #%fork_env() pragma. To do so, you have to provide the name of the corresponding task and the fork environment implementation.

Example:

#%fork_env(name=TASK_NAME)
dockerImageName = 'activeeon/dlm3'
dockerRunCommand =  'docker run '
dockerParameters = '--rm '
paHomeHost = variables.get("PA_SCHEDULER_HOME")
paHomeContainer = variables.get("PA_SCHEDULER_HOME")
proActiveHomeVolume = '-v '+paHomeHost +':'+paHomeContainer+' '
workspaceHost = localspace
workspaceContainer = localspace
workspaceVolume = '-v '+localspace +':'+localspace+' '
containerWorkingDirectory = '-w '+workspaceContainer+' '
preJavaHomeCmd = dockerRunCommand + dockerParameters + proActiveHomeVolume + workspaceVolume + containerWorkingDirectory + dockerImageName

Or, you can provide the task name and the path of a .py file containing the fork environment code:

#%fork_env(name=TASK_NAME, path=PATH_TO/FORK_ENV_FILE.py)

8.5.4. Adding a selection script

To add a selection script to a task, use the #%selection_script() pragma. To do so, you have to provide the name of the corresponding task and the selection code implementation.

Example:

#%selection_script(name=TASK_NAME)
selected = True

Or, you can provide the task name and the path of a .py file containing the selection code:

#%selection_script(name=TASK_NAME, path=PATH_TO/SELECTION_CODE_FILE.py)

8.5.5. Adding job fork environment and/or selection script

If the selection scripts and/or the fork environments are the same for all job tasks, we can add them just once using the job_selection_script and/or the job_fork_env pragmas.

Usage:

For a job selection script, please use:

#%job_selection_script([language=SCRIPT_LANGUAGE], [path=./SELECTION_CODE_FILE.py], [force=on/off])

For a job fork environment, use:

#%job_fork_env([language=SCRIPT_LANGUAGE], [path=./FORK_ENV_FILE.py], [force=on/off])

The force parameter defines whether the pragma has to overwrite the task selection scripts or the fork environment already set.

8.5.6. Adding pre and/or post scripts

Sometimes, specific scripts has to be executed before and/or after a particular task. To do that, the solution provides pre_script and post_script pragmas.

To add a pre-script to a task, please use:

#%pre_script(name=TASK_NAME, language=SCRIPT_LANGUAGE, [path=./PRE_SCRIPT_FILE.py])

To add a post-script to a task, use:

#%post_script(name=TASK_NAME, language=SCRIPT_LANGUAGE, [path=./POST_SCRIPT_FILE.py])

8.5.7. Branch control

The branch control provides the ability to choose between two alternative task flows, with the possibility to merge back to a common one.

To add a branch control to the current workflow, four specific tasks and one control condition should be added in accordance with the following order:

  1. a branch task,

  2. the related branching condition script,

  3. an if task that should be executed if the result of the condition task if true,

  4. an else task that should be executed if the result of the condition task if false,

  5. a continuation task that should be executed after the if or the else tasks.

To add a branch task, you can rely on the following macro:

#%branch([name=TASK_NAME], [dep=[TASK_NAME1,TASK_NAME2,...]], [generic_info=[(KEY1,VAL1), (KEY2,VALUE2),...]], [language=SCRIPT_LANGUAGE], [path=./FORK_ENV_FILE.py])

For the branching condition script, use:

#%condition()

For an if task, please use:

#%if([name=TASK_NAME], [generic_info=[(KEY1,VAL1),(KEY2,VALUE2),...]], [language=SCRIPT_LANGUAGE], [path=./FORK_ENV_FILE.py])

For an else task, use:

#%else([name=TASK_NAME], [generic_info=[(KEY1,VAL1),(KEY2,VALUE2),...]], [language=SCRIPT_LANGUAGE], [path=./FORK_ENV_FILE.py])

And finally, for the continuation task:

#%continuation([name=TASK_NAME], [generic_info=[(KEY1,VAL1),(KEY2,VALUE2),...]], [language=SCRIPT_LANGUAGE], [path=./FORK_ENV_FILE.py])

8.5.8. Loop control

The loop control provides the ability to repeat a set of tasks.

To add a loop control to the current workflow, two specific tasks and one control condition should be added in the following order:

  1. a start task,

  2. the related looping condition script,

  3. a loop task.

For a start task, use:

#%start([name=TASK_NAME], [dep=[TASK_NAME1,TASK_NAME2,...]], [generic_info=[(KEY1,VAL1), (KEY2,VALUE2),...]], [language=SCRIPT_LANGUAGE], [path=./FORK_ENV_FILE.py])

For the looping condition script, use:

#%condition()

For a loop task, please use:

#%loop([name=TASK_NAME], [generic_info=[(KEY1,VAL1),(KEY2,VALUE2),...]], [language=SCRIPT_LANGUAGE], [path=./FORK_ENV_FILE.py])

8.5.9. Replicate control

The replication allows the execution of multiple tasks in parallel when only one task is defined, and the number of tasks to run could change.

Through the ProActive Jupyter Kernel, users can add replicate controls in two main ways, a generic and a straight forward way.

Generic usage

To add a replicate control to the current workflow in the generic method, three specific tasks and one control runs script should be added according to the following order:

  1. a split task,

  2. the related replication runs script,

  3. a process task,

  4. a merge task.

For a split task, use:

#%split([name=TASK_NAME], [dep=[TASK_NAME1,TASK_NAME2,...]], [generic_info=[(KEY1,VAL1), (KEY2,VALUE2),...]], [language=SCRIPT_LANGUAGE], [path=./FORK_ENV_FILE.py])

For the replication runs script, use:

#%runs()

For a process task, please use:

#%process([name=TASK_NAME], [generic_info=[(KEY1,VAL1),(KEY2,VALUE2),...]], [language=SCRIPT_LANGUAGE], [path=./FORK_ENV_FILE.py])

And finally, for a merge task, use:

#%merge([name=TASK_NAME], [generic_info=[(KEY1,VAL1),(KEY2,VALUE2),...]], [language=SCRIPT_LANGUAGE], [path=./FORK_ENV_FILE.py])
Straight forward usage

The straight forward method to add a replication is most of all useful when the parallelism that should be implemented is a task parallelism (the generic usage is more adapted to data parallelism).

To add a replication to a task, just add the runs control script by providing the runs option of the task pragma. Example:

#%task(name=T2,dep=[T1],runs=3)
print("This output should be displayed 3 times ...")
To construct a valid workflow, straight forward replicated tasks must have one and only one parent task and one child task at most. (More information about replicate validation criteria are available here).

8.5.10. Delete a task

To delete a task from the workflow, the user should run the pragma #%delete_task() in the following way:

#%delete_task(name=TASK_NAME)

8.5.11. Create a job

To create a job, specify job variables and/or job generic information, use the #%job() pragma:

#%job(name=JOB_NAME, [generic_info=[(KEY1,VAL1), (KEY2,VALUE2),...]], [variables=[(VAR1,VAL1), (VAR2,VALUE2),...]])
It is not necessary to create and assign a name explicitly to the job. If not done by the user, this step is implicitly performed when the job is submitted (check section Submit your job to the scheduler for more information).

8.5.12. Visualize job

To visualize the created workflow, use the #%draw_job() pragma to plot the workflow graph that represents the job into a separate window:

#%draw_job()

Two optional parameters can be used to configure the way the kernel plots the workflow graph.

inline plotting:

If this parameter is set to off, plotting the workflow graph is done through a Matplotlib external window. The default value is on.

#%draw_job(inline=off)

save the workflow graph locally:

To be sure that the workflow is saved into a .png file, this option needs to be set to on. The default value is off.

#%draw_job(save=on)

Note that the job’s name can take one of the following possible values:

  1. The parameter name 's value, if provided

  2. The job’s name, if created

  3. The notebook’s name, if the kernel can retrieve it

  4. Unnamed_job, otherwise

General usage:

#%draw_job([name=JOB_NAME], [inline=off], [save=on])

8.5.13. Export the workflow graph in dot format

To export the created workflow into a GraphViz .dot format, use the #%write_dot() pragma:

#%write_dot(name=FILE_NAME)

8.5.14. Import a workflow from a dot file

To create a workflow according to a GraphViz .dot file, use the pragma #%import_dot():

#%import_dot(path=PATH_TO/FILE_NAME.dot)

By default, the workflow will contain Python tasks with empty implementation scripts. If you want to modify or add any information to a specific task, please use, as explained in Creating a Python task, the #%task() pragma.

8.5.15. Submit your job to the scheduler

To submit the job to the ProActive Scheduler, the user has to use the #%submit_job() pragma:

#%submit_job()

If the job is not created, or is not up-to-date, the #%submit_job() creates a new job named as the old one. To provide a new name, use the same pragma and provide a name as parameter:

#%submit_job([name=JOB_NAME])

If the job’s name is not set, the ProActive kernel uses the current notebook name, if possible, or gives a random one.

8.5.16. List all submitted jobs

To get all submitted job IDs and names, use list_submitted_jobs pragma this way:

#%list_submitted_jobs()

8.5.17. Export the workflow in XML format

To export the created workflow in .xml format, use the #%export_xml() pragma:

#%export_xml([name=FILENAME])

Notice that the .xml file will be saved under one of the following names:

  1. The parameter name 's value, if provided

  2. The job’s name, if created

  3. The notebook’s name, if the kernel can retrieve it

  4. Unnamed_job, otherwise

8.5.18. Get results

After the execution of a ProActive workflow, two outputs can be obtained:

  • results: values that have been saved in the task result variable,

  • console outputs: classic outputs that have been displayed/printed.

To get task results, please use the #%get_task_result() pragma by providing the task name, and either the job ID or the job name:

#%get_task_result([job_id=JOB_ID], [job_name=JOB_NAME], task_name=TASK_NAME)

The result(s) of all the tasks of a job can be obtained with the #%get_job_result() pragma, by providing the job name or the job ID:

#%get_job_result([job_id=JOB_ID], [job_name=JOB_NAME])

To get and display console outputs of a task, you can use the #%print_task_output() pragma in the following way:

#%print_task_output([job_id=JOB_ID], [job_name=JOB_NAME], task_name=TASK_NAME)

Finally, the #%print_job_output() pragma allows to print all job outputs, by providing the job name or the job ID:

#%print_job_output([job_id=JOB_ID], [job_name=JOB_NAME])
If neither job_name nor the job_id are provided, the last submitted job is selected by default.

8.6. Display and use ActiveEon Portals directly in Jupyter

Finally, to have the hand on more parameters and features, the user should use ActiveEon Studio portals. The main ones are the Resource Manager, the Scheduling Portal and the Workflow Automation.

The example below shows how the user can directly monitor his submitted job’s execution in the scheduling portal:

Directly in Jupyter: Submit

To show the resource manager portal related to the host you are connected to, just run:

#%show_resource_manager([host=YOUR_HOST], [height=HEIGHT_VALUE], [width=WIDTH_VALUE])

For the related scheduling portal:

#%show_scheduling_portal([host=YOUR_HOST], [height=HEIGHT_VALUE], [width=WIDTH_VALUE])

And, for the related workflow automation:

#%show_workflow_automation([host=YOUR_HOST], [height=HEIGHT_VALUE], [width=WIDTH_VALUE])
The parameters height and width allow the user to adjust the size of the window inside the notebook.

9. Customize the ML Bucket

9.1. Create or Update a ML Task

Machine Learning Bucket contains various open source tasks that can be easily used by a simple drag and drop.

It is possible to enrich the ML Bucket by adding your own tasks. (see section 4.3)

It is also possible to customize the code of the generic ML tasks. In this case, you need to drag and drop the targeted task to modify its code in the Task Implementation section.

It is also possible to add or/and delete variables of each task, set your own fork environments, etc. More details available on ProActive User Guide

9.2. Set the Fork Environment

A fork execution environment is a new Java Virtual Machine (JVM) which is started exclusively to execute a task. Starting a new JVM means that the task inside it will run in a new environment. This environment can be set up by the creator of the task. A new JVMs is set up with a new classpath, new system properties and more customization.

We used a Docker fork environment for all the ML tasks. activeeon/dlm3 was used as a docker container for all tasks. If your task needs to install new ML libraries which are not available in this container, then, use your own docker container or an appropriate environment with the needed libraries.

The use of docker containers is recommended as that way other tasks will not be affected by change. Docker containers provide isolation so that the host machine’s software stays the same. More details available on ProActive User Guide

9.3. Publish a ML Task

The Catalog menu provides the possibility for a user to publish newly created or/and update tasks inside Machine Learning Bucket, you need just to click on Catalog Menu then Publish current Workflow to the Catalog. Choose machine-leaning Bucket to store your newly added workflow on it. If the Task with the same name already exists in the 'machine-leaning' bucket, then, it will be updated. We recommend to submit Tasks with a commit message for easier differentiation between the different submitted versions.

More details available on ProActive User Guide

9.4. Create a ML Workflow

The quickstart tutorial on try.activeeon.com shows you how to build a simple workflow using ProActive Studio.

We show below an example of a workflow created with the Studio:

ML Workflow Example

At the left part, are illustrated the General Parameters of the workflow with the following information:

  • Name: the name of the workflow.

  • Project: the project name to which belongs the workflow.

  • Description: the textual description of the workflow.

  • Documentation: if the workflow has a Generic Information named "Documentation", then its URL value is displayed as a link.

  • Job Priority: the priority assigned to the workflow. It is by default set to NORMAL, but can be increased or decreased once the job is submitted.

The workflow represented in the above is available on the 'machine-learning-workflows' bucket.

10. ML Workflows Examples

The PML provides a fast, easy and practical way to execute different workflows using the ML bucket. We present useful ML workflows for different applications in the following sub-sections.

To test these workflows, you need to add the machine-Learning-workflows Bucket as main catalog in the ProActive Studio.

  1. Open Machine Learning Open Studio home page.

  2. Create a new workflow.

  3. Change palette preset to Machine Learning.

  4. Click on machine-learning catalog and pin it open.

  5. Drag and drop the workflow example of your choice.

  6. Execute the chosen workflow, track its progress and preview its results.

More details about these workflows are available in this in ActiveEon’s Machine Learning Documentation

10.1. Basic ML

The following workflows present some ML basic examples. These workflows are built using generic ML and data visualization tasks available on the ML and Data Visualization buckets.

Diabetics_Detection_using_K_means: trains and tests a clustering model using Mean_shift algorithm.

House_Price_Prediction_using_Linear_Regression: trains and tests a regression model using Mean_shift algorithm.

Vehicle_Type_Using_Model_Explainability: predicts vehicle type based on silhouette measurements, and apply ELI5 and Kernel Explainer to understand the model’s global behavior or specific predictions.

Iris_Flowers_Classification_using_Logistic_Regression: trains and tests a predictive model using logistic_regressive algorithm.

Parallel_Classification_Model_Training: trains three different classification models.

Parallel_Regression_Model_Training: trains three different regression models.

10.2. Basic AutoML

The following workflows present some ML basic examples using AutoML generic tasks available in the machine-learning bucket.

Breast_Cancer_Detection_Using_AutoSklearn_Classifier: tests several ML pipelines and selects the best model for Cancer Breast detection.

California_Housing_Prediction_Using_TPOT_Regressor: tests several ML pipelines and selects the best model for California housing prediction.

10.3. Log Analysis

The following workflows are designed to detect anomalies in log files. They are constructed using generic tasks which are available on the machine-learning and data-visualization buckets.

Anomaly_Detection_in_Apache_Logs: detects intrusions in apache logs using a predictive model trained using Support Vector Machines algorithm.

Anomaly_detection_in_HDFS_Blocks: trains and test an anomaly detection model for detecting anomalies in HDFS Blocks.

Anomaly_detection_in_HDFS_Nodes: trains and test an anomaly detection model for detecting anomalies in HDFS Nodes.

Unsupervised_Anomaly_Detection: detects anomalies using an Unsupervised One-Class SVM.

10.4. Data Analytics

The following workflows are designed to feature engineering and fusion.

Data_Fusion_And_Encoding: fuses different data structures.

Data_Anomaly_Detection: detects anomalies on energy consumption by customers.

Diabetics_Results_Visualization_Using_Tableau: visualizes Diabetics Results Using Tableau.

10.5. In Memory Workflows

The following workflows are designed for in-memory execution.

In_Memory_Iris_Flowers_Classification: classifies Iris flowers using the logistic regression algorithm. This workflow uses an external IPython Engine for in-memory execution.

Start_IPython_Cluster: executes a IPython cluster.

10.6. GPU Accelerated Workflows

The following workflows are designed to train machine learning models on GPU using NVIDIA RAPIDS. This reduces the training time from days to minutes.

Train_Classification_Model_On_GPU: trains a machine learning model for data classification on GPU using NVIDIA RAPIDS.

Train_Multiple_Classification_Models_On_GPU: trains multiple machine learning models for data classification on GPU using NVIDIA RAPIDS.

Train_Multiple_Regression_Models_On_GPU: trains multiple machine learning models for data regression on GPU using NVIDIA RAPIDS.

Train_Regression_Model_On_GPU: trains a machine learning model for data regression on GPU using NVIDIA RAPIDS.

The following table identifies for each of the ML algorithms if it can be executed on GPU nodes or not.

Section

Algorithm

GPU Enabled

5.1 AutoML

AutoSklearn_Classifier

No

AutoSklearn_Regressor

No

TPOT_Classifier

No

TPOT_Regressor

No

5.2 ML Classification

Support_Vector_Machines

Yes

Logistic_Regression

Yes

Gaussian_Naive_Bayes

No

5.3 ML Regression

Support_Vector_Regression

Yes

Linear_Regression

Yes

Bayesian_Ridge_Regression

No

5.4 ML Clustering

K_Means

Yes

Mean_Shift

No

5.5 ML Anomaly Detection

One_Class_SVM

No

Isolation_Forest

No

5.6 ML Ensemble Learning

XGBoost

Yes

Random_Forest

Yes

Gradient_Boosting

No

AdaBoost

No

CatBoost

No

11. Deep Learning Workflows Examples

PML provides a fast, easy and practical way to execute deep learning workflows. In the following sub-sections, we present useful deep learning workflows for text and image classification and generation.

You can test these workflows by following these steps:

  1. Open Machine Learning Open Studio home page.

  2. Create a new workflow.

  3. Click on Catalog menu then Add Bucket as Extra Catalog Menu and select deep-learning-workflows bucket.

  4. Open this added extra catalog menu and drag and drop the workflow example of your choice.

  5. Execute the chosen workflow, track its progress and preview its results.

11.1. Azure Cognitive Services

The following workflows present useful examples composed by pre-built Azure cognitive services available on azure-cognitive-services bucket.

Emotion_Detection_in_Bing_News: is a mashup that searches for images of a person using Azure Bing Image Search then performs an emotion detection using Azure Emotion API.

Sentiment_Analysis_in_Bing_News: is a mashup that searches for news related to a given search term using Azure Bing News API then performs a sentiment analysis using Azure Text Analytics API.

11.2. Microsoft Cognitive Toolkit

The following workflows present useful examples for predictive models training and test using Microsoft Cognitive Toolkit (CNTK).

CNTK_ConvNet: trains a Convolutional Neural Network (CNN) on CIFAR-10 dataset.

CNTK_SimpleNet: trains a 2-layer fully connected deep neural network with 50 hidden dimensions per layer.

GAN_Generate_Fake_MNIST_Images: generates fake MNIST images using a Generative Adversarial Network (GAN).

DCGAN_Generate_Fake_MNIST_Images: generates fake MNIST images using a Deep Convolutional Generative Adversarial Network (DCGAN).

11.3. Mixed Workflows

The following workflow presents an example of a workflow built using pre-built Azure cognitive services tasks available on the azure-cognitive-services bucket and custom AI tasks available on the deep-learning bucket.

Custom_Sentiment_Analysis: is a mashup that searches for news related to a given search term using Azure Bing News API then performs a sentiment analysis using a custom deep learning based pretrained model.

11.4. Training Custom AI Workflows - PyTorch library

This section presents custom AI workflows using tasks available on the deep-learning bucket. Such tasks enable you to train your own AI models by a simple drag and drop of custom AI task.

IMDB_Sentiment_Analysis: trains a model to perform sentiment identification and categorization expressed in a piece of text, especially in order to determine the opinion of IMDB users regarding specific movies [positive or negative]. NOTE: Instead of training a model from scratch, a pre-trained sentiment analysis model is available on this link.

Language_Detection: build an RNN model to perform language detection from a text data.

Train_Image_Classification: trains a model to classify images from ants and bees.

Train_Image_Segmentation: trains a segmentation model using SegNet network on Oxford-IIIT Pet Dataset.

Train_Image_Object_Detection: trains objects using YOLOv3 model on COCO dataset proposed by Microsoft Research.

Deep_Model_Explainability: explains a ResNet-18 model using GradientExplainer.

Search_Train_Image_Classification: queries images from a search engine (Bing or DuckDuckGo) and trains a model to classify them.

11.5. Prediction Custom AI Workflows - PyTorch library

This section presents custom AI workflows using tasks available on the deep-learning bucket. Such tasks enable you to test your own AI models by a simple drag and drop of custom AI task.

Image_Classification: predicts a classification model using ResNet_18 network on Ants_vs_Bees Dataset. The pre-trained image classification model is available on this link.

Fake_Celebrity_Faces_Generation: generates a wild diversity of fake faces using a GAN model that was trained based on thousands of real celebrity photos. The pre-trained GAN model is available on this link.

Image_Segmentation: predicts a segmentation model using SegNet network on Oxford-IIIT Pet Dataset. The pre-trained image segmentation model is available on this link.

Image_Object_Detection: detects objects using a pre-trained YOLOv3 model on COCO dataset proposed by Microsoft Research. The pre-trained model is available on this link.

Search_Classify_Images: queries images into search engine (Bing or DuckDuckGo) and predicts a model to classify rocket_vs_plane images. The pre-trained image classiffication model is available on this link.

11.6. Templates

The following workflows represent python templates that can be used to implement a generic machine learning task.

Horovod_Job: is a template to implement a Horovod task with multi-gpu support.

Horovod_Job_Slurm: is a template to implement a Horovod task using a native SLURM scheduler with multi-gpu support.

Horovod_Job_Docker: is a template to implement a Horovod task using a Docker container with multi-gpu support.

TensorFlow_Task: is a simple TensorFlow task template.

Keras_Task: is a simple Keras task template.

PyTorch_Task: is a simple PyTorch task template.

It is recommended to use an enabled-GPU node to run the deep learning tasks.

12. References

12.1. AI Workflows Common Variables

In the following table, you can find the variables that are common between most of the available AI workflows in PML associated to their descriptions.

Variable name

Description

Type

NATIVE_SCHEDULER

Name of the Native Scheduler node source to use when the workflow tasks must be deployed inside a cluster such as SLURM, LSF, etc.

String (default=empty)

NATIVE_SCHEDULER_PARAMS

Parameters given to the native scheduler (SLURM, LSF, etc) while requesting a ProActive node used to deploy the workflow tasks.

String (default=empty)

NODE_ACCESS_TOKEN

If not empty, the workflow tasks will be run only on nodes that contains the specified token.

String (default=empty)

NODE_SOURCE_NAME

If not empty, the workflow tasks will be run only on nodes belonging to the specified node source.

String (default=empty)

CONTAINER_PLATFORM

Specifies the container platform to be used for executing the workflow tasks.

List [no-container, docker, podman, singularity] (default=docker)

CONTAINER_GPU_ENABLED

If True, it will activate the use of GPU on the selected container platform.

Boolean (default=True)

CONTAINER_IMAGE

Specifies the name of the container image that will be used to run the workflow tasks.

List [docker://activeeon/dlm3, docker://activeeon/cuda, docker://activeeon/cuda2, docker://activeeon/rapidsai, docker://activeeon/tensorflow:latest, docker://activeeon/tensorflow:latest-gpu] (default=empty)

12.2. ML Bucket

The machine-learning bucket contains diverse generic ML tasks that enable you to easily compose workflows for predictive models learning and testing. This bucket can be easily customized according to your needs. This bucket offers different options, you can customize it by adding new tasks or update the existing tasks.

All ML tasks were implemented using Scikit-learn library.

12.2.1. Public Datasets

Load_Boston_Dataset

Task Overview: Load and return the Boston House-Prices dataset.

Table 16. Boston Dataset Description
Features Targets Dimensionality Samples Total

Real, positive

Real 5. -50

13

506

Task Variables:

Table 17. Load_Boston_Dataset_Task variables

Variable name

Description

Type

TASK_ENABLED

If False, the task will be ignored, it will not be executed.

Boolean (default=True)

LIMIT_OUTPUT_VIEW

Specifies how many rows of the dataframe will be previewed in the browser to check each task results.

Int (default=-1) (-1 means preview all the rows)

Usage:

  • The Boston House-Prices is a dataset for regression, you can only use it with a regression algorithm, such as Linear Regression and Support Vector Regression.

  • After this task, you can use the Split_Data task to divide the dataset into training and testing sets.

More information about this dataset can be found here.
Load_Iris_Dataset

Task Overview: Load and return the iris dataset.

Table 18. Iris Dataset Description
Features Classes Dimensionality Samples per class Samples total

Real, positive

3

4

50

150

Task Variables:

Table 19. Load_Iris_Dataset_Task variables

Variable name

Description

Type

TASK_ENABLED

If False, the task will be ignored, it will not be executed.

Boolean (default=True)

LIMIT_OUTPUT_VIEW

Specifies how many rows of the dataframe will be previewed in the browser to check each task results.

Int (default=-1) (-1 means preview all the rows)

Usage:

  • The Iris is a dataset for classification, you can only use it with a classification algorithm, such as Support Vector Machines and Logistic Regression.

  • After this task, you can use the Split_Data task to divide the dataset into training and testing sets.

More information about this dataset can be found here.

12.2.2. Input and Output Data

Download_Model

Task Overview: Download a trained model on your computer device.

Task Variables:

Table 20. Download_Model_Task variables

Variable name

Description

Type

TASK_ENABLED

If False, the task will be ignored, it will not be executed.

Boolean (default=True)

Usage: It should be used after the task Train_Model.

Export_Data

Task Overview: Export the results of the predictions generated by a classification, clustering or regression algorithm.

Task Variables:

Table 21. Export_Data_Task variables

Variable name

Description

Type

TASK_ENABLED

If False, the task will be ignored, it will not be executed.

Boolean (default=True)

OUTPUT_FILE

Converts the prediction results to HTML, HYPER and CSV file.

String [CSV, JSON, HTML, TABLEAU]

LIMIT_OUTPUT_VIEW

Specifies how many rows of the dataframe will be previewed in the browser to check each task results.

Int (default=-1) (-1 means preview all the rows)

Usage: It should be used after the task Predict_Model.

Import_Data

Task Overview: Load data from external sources and predict its features types if enabled.

Task Variables:

Table 22. Import_Data_Task variables

Variable name

Description

Type

TASK_ENABLED

If False, the task will be ignored, it will not be executed.

Boolean (default=True)

LIMIT_OUTPUT_VIEW

Specifies how many rows of the dataframe will be previewed in the browser to check each task results.

Int (default=-1) (-1 means preview all the rows)

FILE_URL

Enter you URL of the CSV file.

String

FILE_DELIMITER

Delimiter to use.

String

DATA_TYPE_IDENTIFICATION

If True, the types of the dataset features will be predicted (as numerical or categorical).

Boolean (default=False)

Your CSV file should be in a table format. See the example below.
csv file organisation
Import_Model

Task Overview: Load a trained model, and use it to make predictions for new coming data.

Task Variables:

Table 23. Import_Model_Task variables

Variable name

Description

Type

TASK_ENABLED

If False, the task will be ignored, it will not be executed.

Boolean (default=True)

MODEL_URL

Type the URL to load your trained model. default: https://s3.eu-west-2.amazonaws.com/activeeon-public/models/pima-indians-diabetes.model

String

Usage: It should be used before Predict_Model to make predictions.

Preview_Results

Task Overview: Preview the HTML results of the predictions generated by a classification, clustering or regression algorithm.

Task Variables:

Table 24. Preview_Results_Task variables

Variable name

Description

Type

TASK_ENABLED

If False, the task will be ignored, it will not be executed.

Boolean (default=True)

LIMIT_OUTPUT_VIEW

Specifies how many rows of the dataframe will be previewed in the browser to check each task results.

Int (default=-1) (-1 means preview all the rows)

OUTPUT_FILE

Converts the prediction results to HTML or CSV file.

String [CSV, JSON or HTML]

Usage: It should be used after the task Predict_Model.

Log_Parser

Task Overview: Convert an unstructured raw log file into a structured one by matching a group of event patterns.

Task Variables:

Table 25. Log_Parser_Task variables

Variable name

Description

Type

LOG_FILE

Put the URL of the raw log file that you need to parse.

String

PATTERNS_FILE

Put the URL of the CSV file that contains the different RegEx expressions of each possible pattern and their corresponding variables. The csv file must contain three columns (See the example below):

A. id_pattern: Integer Specify the column containing the identifier of each pattern

B. Pattern: RegEx expression Define the regex expression of each pattern

C. Variables: String Specify the name of each variable included in the pattern. N.B: Use the symbol ‘*’ for variables that you need to neglect. (e.g., in the example below the 5th variable is neglected) N.B: All variables specified in each Regex expressions have to be mentioned in the column « Variables » in the right order (use ',' to separate the variable names).

String

STRUCTURED_LOG

Indicate the extension of the file where you will save the resulted structured logs.

String [CSV or HTML]

pattern file

Usage: Could be connected with the tasks Query_Data and Feature_Vector_Extractor.

12.2.3. Data Preprocessing

Append_Data

Task Overview: Append rows of other to the end of this frame, returning a new object. Columns not in this frame are added as new columns.

Task Variables:

Table 26. Append_Data_Task variables

Variable name

Description

*Type

TASK_ENABLED

If False, the task will be ignored, it will not be executed.

Boolean (default=True)

Drop_Columns

Task Overview: Drop the columns specified in COLUMNS_NAME variable.

Task Variables:

Table 27. Drop_Columns_Task variables

Variable name

Description

Type

TASK_ENABLED

If False, the task will be ignored, it will not be executed.

Boolean (default=True)

COLUMNS_NAME

The list of columns that need to be dropped. Columns names should be separated by a comma.

String

More details about the source code of this task can be found here.
Drop_NaNs

Task Overview: Replace inf values to NaNs in a first place then drop objects on a given axis where alternately any or all of the data are missing.

More details about the source code of this task can be found here.
Encode_Data

Task Overview: Encode the values of the columns specified in COLUMNS_NAME variable with integer values between 0 and "the number of unique variables"-1.

Task Variables:

Table 28. Encode_Data_Task variables

Variable name

Description

Type

TASK_ENABLED

If False, the task will be ignored, it will not be executed.

Boolean (default=True)

COLUMNS_NAME

The list of columns that need to be encoded. Columns names should be separated by a comma.

String

More details about the source code of this task can be found here.
Fill_NaNs

Task Overview: Fill NA/NaN values using the specified method.

Task Variables:

Table 29. Fill_NaNs_Task variables

Variable name

Description

Type

TASK_ENABLED

If False, the task will be ignored, it will not be executed.

Boolean (default=True)

FILL_MAP

Refers to the value to use to fill holes (e.g., 0).

Integer

More details about the source code of this task can be found here.
Filter_Columns

Task Overview: Subset columns of a dataframe according to the specified list of coluumns in the COLUMNS_NAME variable.

Task Variables:

Table 30. Filter_Columns_Task variables

Variable name

Description

Type

TASK_ENABLED

If False, the task will be ignored, it will not be executed.

Boolean (default=True)

COLUMNS_NAME

The list of columns to restrict to. Columns names should be separated by a comma.

String

More details about the source code of this task can be found here.
Merge_Data

Task Overview: Merge DataFrame objects by performing a database-style join operation based on a specific reference column specified in the REF_COLUMN variable.

Task Variables:

Table 31. Merge_Data_Task variables

Variable name

Description

Type

TASK_ENABLED

If False, the task will be ignored, it will not be executed.

Boolean (default=True)

REF_COLUMN

The list of columns to restrict to. Columns names should be separated by a comma.

String

More details about the source code of this task can be found here.
Scale_Data

Task Overview: Scale a dataset based on a robust scaler or standard scaler.

Task Variables:

Table 32. Scale_Data_Task variables

Variable name

Description

Type

TASK_ENABLED

If False, the task will be ignored, it will not be executed.

Boolean (default=True)

SCALER_NAME

The list of columns to restrict to. Columns names should be separated by a comma.

List [RobustScaler, StandardScaler] (default=RobustScaler)

LIMIT_OUTPUT_VIEW

Specifies how many rows of the dataframe will be previewed in the browser to check each task results.

Int (default=-1) (-1 means preview all the rows)

COLUMNS_NAME

The list of columns that will be scaled. Column names should be separated by a comma.

String

More details about the source code of this task can be found here.
Split_Data

Task Overview: Separate data into train and test subsets.

Task Variables:

Table 33. Split_Data_Task variables

Variable name

Description

Type

TASK_ENABLED

If False, the task will be ignored, it will not be executed.

Boolean (default=True)

TRAIN_SIZE

This parameter must be float within the range (0.0, 1.0), not including the values 0.0 and 1.0. default = 0.7

Float

Usage: It should be used before the tasks Train and Predict.

More details about the source code of this task can be found here.
Rename_Columns

Task Overview: Rename the columns of a data frame.

Task Variables:

Table 34. Rename_Columns_Task variables

Variable name

Description

Type

TASK_ENABLED

If False, the task will be ignored, it will not be executed.

Boolean (default=True)

COLUMNS_NAME

The list of columns that will be renamed. Column names should be separated by a comma.

String

Query_Data

Task Overview: Query the columns of your data with a boolean expression.

Task Variables:

Table 35. Query_Data_Task variables

Variable name

Description

Type

TASK_ENABLED

If False, the task will be ignored, it will not be executed.

Boolean (default=True)

QUERY

The query string to evaluate.

String

FILTERED_FILE_OUPUT

Refers to the extension of the file where the resulted filtered data will be saved..

String [CSV or HTML]

More details about the source code of this task can be found here.

12.2.4. Feature Extraction

Summarize_Data

Task Overview: Calculate the histogram of a dataframe based on a reference column that need to be specified in the variable REF_COLUMN.

Task Variables:

Table 36. Summarize_Data_Task variables

Variable name

Description

Type

TASK_ENABLED

If False, the task will be ignored, it will not be executed.

Boolean (default=True)

GLOBAL_MODEL_TYPE

The model that will be used to summarize data.

List [KMeans, PolynomialFeatures] (default=KMeans)

REF_COLUMN

The column that will be used to group by the different histogram measures.

String

More details about the source code of this task can be found here.
Tsfresh_Features_Extraction

Task Overview: Calculate a comprehensive number of time series features based on the library TSFRESH.

Task Variables:

Table 37. Tsfresh_Features_Extraction_Task variables

Variable name

Description

Type

TASK_ENABLED

If False, the task will be ignored, it will not be executed.

Boolean (default=True)

TIME_COLULN

The column that contains the values of the time series

String

REF_COLUMN

The column that will be used to group by the different features.

String

ALL_FEATURES

False if you do not need to extract all the possible features extractable by the library TSFRESH.

Boolean (default = False)

LIMIT_OUTPUT_VIEW

Specifies how many rows of the dataframe will be previewed in the browser to check each task results.

Int (default=-1) (-1 means preview all the rows)

More details about the source code of this task can be found here.
Feature_Vector_Extractor

Task Overview: Encode structured data into numerical feature vectors whereby ML models can be applied.

Task Variables:

Table 38. Feature_Vector_Extractor_Task variables

Variable name

Description

Type

TASK_ENABLED

If False, the task will be ignored, it will not be executed.

Boolean (default=True)

SESSION_COLUMN

The ID of the entity that you need to represent (to group by).

String

FILE_OUT_FEATURES

The extension of the file where the resulted features will be saved.

String [CSV or HTML]

PATTERN_COLUMN

The index of column containing the log patterns.[specific to features extraction from logs].

String

PATTERNS_COUNT_FEATURES

True if you need to extract count the number of occurrence of each pattern per session.

Boolean [True or False]

STATE_VARIABLES

The different variables that need to be considered to extract features according to their content.

N.B: separate the different variables with a comma ','

String

COUNT_VARIABLES

Refers to the different variables that need to be considered to count their distinct content..

String

N.B: separate the different variables with a comma ','

STATE_COUNT_FEATURES_VARIABLES

True if you nedd to extract state and count features per session.

Boolean [True or False]

Usage: Could be connected with Train_Model if you need to train a model using unsupervised ML techniques.

12.2.5. AutoML

TPOT_Classifier

Task Overview: TPOT_Classifier performs an intelligent search over ML pipelines that can contain supervised classification models, preprocessors, feature selection techniques, and any other estimator or transformer that follows the scikit-learn API.

Task Variables:

Table 39. TPOT_Classifier_Task variables

Variable name

Description

Type

TASK_ENABLED

If True, This task code will be executed.

Boolean (default=True)

GENERATIONS

Number of iterations to the run pipeline optimization process.

Integer (default=3)

SCORING

Function used to evaluate the quality of a given pipeline for the classification problem.

List (default=accuracy)

CV

Cross-validation strategy used when evaluating pipelines.

Integer (default=5)

VERBOSITY

How much information TPOT communicates while it’s running. Possible inputs: 0, 1, 2, 3.

Integer (default=1)

Usage: It should be connected with Train_Model.

More information about this task can be found here.
AutoSklearn_Classifier

Task Overview: AutoSklearn_Classifier leverages recent advantages in Bayesian optimization, meta-learning and ensemble construction to performs an intelligent search over ML classification algorithms.

Task Variables:

Table 40. AutoSklearn_Classifier_Task variables

Variable name

Description

Type

TASK_ENABLED

If True, This task code will be executed.

Boolean (default=True)

TASK_TIME

Time limit in seconds for the search of appropriate models. .

Integer (default=30)

RUN_TIME

Time limit for a single call to the ML model. Model fitting will be stopped if the ML algorithm runs over the time limit.

Integer (default=27)

SAMPLING

If True, the defined resampling strategy will be applied.

Boolean (default=True)

RESAMPLING_STRATEGY

Strategy to handle overfitting.

String (default='cv')

FOLDS

Number of folds fro cross-validation.

Integer (default=5)

Usage: It should be connected with Train_Model.

  1. The labels of the selected Dataset have to be numerical.

  2. More information about this task can be found here.

TPOT_Regressor

Task Overview: TPOT_Regressor performs an intelligent search over ML pipelines that can contain supervised regression models, preprocessors, feature selection techniques, and any other estimator or transformer.

Task Variables:

Table 41. TPOT_Regressor_Task variables

Variable name

Description

Type

TASK_ENABLED

If True, This task code will be executed.

Boolean (default=True)

GENERATIONS

Number of iterations to the run pipeline optimization process.

Integer (default=3)

SCORING

Function used to evaluate the quality of a given pipeline for the regression problem.

List (default=neg_mean_squared_error)

CV

Cross-validation strategy used when evaluating pipelines.

Integer (default=5)

VERBOSITY

How much information TPOT communicates while it’s running. Possible inputs: 0, 1, 2, 3.

Integer (default=1)

Usage: It should be connected with Train_Model .

More information about this task can be found here.
AutoSklearn_Regressor

Task Overview: AutoSklearn_Regressor leverages recent advantages in Bayesian optimization, meta-learning and ensemble construction to performs an intelligent search over ML regression algorithms.

Task Variables:

Table 42. AutoSklearn_Regressor_Task variables

Variable name

Description

Type

TASK_ENABLED

If True, This task code will be executed.

Boolean (default=True)

TASK_TIME

Time limit in seconds for the search of appropriate models. .

Integer (default=120)

RUN_TIME

Time limit for a single call to the ML model. Model fitting will be stopped if the ML algorithm runs over the time limit.

Integer (default=30)

SAMPLING

If True, the defined resampling strategy will be applied.

Boolean (default=False)

RESAMPLING_STRATEGY

Strategy to handle overfitting.

String (default='cv')

FOLDS

Number of folds for cross-validation.

Integer (default=5)

Usage: It should be connected with Train_Model .

More information about this task can be found here.

12.2.6. ML Classification

Gaussian_Naive_Bayes

Task Overview: Naive Bayes classifier is a family of simple probabilistic classifier based on applying Bayes' theorem with strong (naive) independence assumptions between the features.

Task Variables:

Table 43. Gaussian_Naive_Bayes_Task variables

Variable name

Description

Type

TASK_ENABLED

If False, the task will be ignored, it will not be executed.

Boolean (default=True)

INPUT_VARIABLES

Specifies the parameters' values of the gaussian naive bayes algorithm. Check the list of parameters here.

JSON format

Usage: It should be connected with Train_Model or Predict_Model.

More information about this task can be found here.
Logistic_Regression

Task Overview: Logistic Regression is a regression model where the Dependent Variable (DV) is categorical.

Task Variables:

Table 44. Logistic_Regression_Task variables

Variable name

Description

Type

TASK_ENABLED

If False, the task will be ignored, it will not be executed.

Boolean (default=True)

INPUT_VARIABLES

Specifies the parameters' values of the logistic regression algorithm. Check the list of parameters here.

JSON format

Usage: It should be connected with Train_Model and Predict_Model.

More information about the source code of this task can be found here.
Support_Vector_Machines

Task Overview: Support vector machines are supervised learning models with associated learning algorithms that analyze data used for classification.

Task Variables:

Table 45. Support_Vector_Machines_Task variables

Variable name

Description

Type

TASK_ENABLED

If False, the task will be ignored, it will not be executed.

Boolean (default=True)

INPUT_VARIABLES

Specifies the parameters' values of the support vector machines algorithm. Check the list of parameters here.

JSON format

Usage: It should be connected with Train_Model and Predict_Model.

More information about the source of this task can be found here.

12.2.7. ML Regression

Bayesian_Ridge_Regression

Task Overview: Bayesian linear regression is an approach to linear regression in which the statistical analysis is undertaken within the context of Bayesian inference.

Task Variables:

Table 46. Bayesian_Ridge_Regression_Task variables

Variable name

Description

Type

TASK_ENABLED

If False, the task will be ignored, it will not be executed.

Boolean (default=True)

INPUT_VARIABLES

Specifies the parameters' values of the bayesian ridge regression algorithm. Check the list of parameters here.

JSON format

Usage: It should be connected with Train_Model and Predict_Model.

More information about the source of this task can be found here.
Linear_Regression

Task Overview: Linear regression is a linear approach for modeling the relationship between a scalar dependent variable y and one or more explanatory variables (or independent variables) denoted X.

Task Variables:

Table 47. Linear_Regression_Task variables

Variable name

Description

Type

TASK_ENABLED

If False, the task will be ignored, it will not be executed.

Boolean (default=True)

INPUT_VARIABLES

Specifies the parameters' values of the linear regression algorithm. Check the list of parameters here.

JSON format

Usage: IT should be connected with Train_Model and Predict_Model.

More information about the source of this task can be found here.
Support_Vector_Regression

Task Overview: Support vector regression are supervised learning models with associated learning algorithms that analyze data used for regression.

Task Variables:

Table 48. Support_Vector_Regression_Task variables

Variable name

Description

Type

TASK_ENABLED

If False, the task will be ignored, it will not be executed.

Boolean (default=True)

INPUT_VARIABLES

Specifies the parameters' values of the support vector regression algorithm. Check the list of parameters here.

JSON format

Usage: It should be connected with Train_Model and Predict_Model.

More information about the source of this task can be found here.

12.2.8. ML Anomaly Detection

Isolation_Forest

Task Overview: Isolation Forest is an outlier detection method which returns the anomaly score of each sample using the IsolationForest algorithm. The IsolationForest ‘isolates’ observations by randomly selecting a feature and then randomly selecting a split value between the maximum and minimum values of the selected feature.

Task Variables:

Table 49. Isolation_Forest_Task variables

Variable name

Description

Type

TASK_ENABLED

If False, the task will be ignored, it will not be executed.

Boolean (default=True)

INPUT_VARIABLES

Specifies the parameters' values of the isolation forest algorithm. Check the list of parameters here.

JSON format

More information about the source of this task can be found here.
One_Class_SVM

Task Overview: One-class SVM is an algorithm that learns a decision function for novelty detection: classifying new data as similar or different to the training set.

Task Variables:

Table 50. One_Class_SVM_Task variables

Variable name

Description

Type

TASK_ENABLED

If False, the task will be ignored, it will not be executed.

Boolean (default=True)

INPUT_VARIABLES

Specifies the parameters' values of the one class algorithm. Check the list of parameters here.

JSON format

More information about the source of this task can be found here.

12.2.9. ML Clustering

K_Means

Task Overview: K-means clustering aims to partition n observations into k clusters in which each observation belongs to the cluster with the nearest mean, serving as a prototype of the cluster

Task Variables:

Table 51. K_Means_Task variables

Variable name

Description

Type

TASK_ENABLED

If False, the task will be ignored, it will not be executed.

Boolean (default=True)

INPUT_VARIABLES

Specifies the parameters' values of the Kmeans algorithm. Check the list of parameters here.

JSON format

Usage: It should be connected with Train_Model and Predict_Model.

More information about the source of this task can be found here.
Mean_Shift

Task Overview: Mean shift is a non-parametric feature-space analysis technique for locating the maxima of a density function.

Task Variables:

Table 52. Mean_Shift_Task variables

Variable name

Description

Type

TASK_ENABLED

If False, the task will be ignored, it will not be executed.

Boolean (default=True)

INPUT_VARIABLES

Specifies the parameters' values of the Mean Shift algorithm. Check the list of parameters here.

JSON format

Usage: It should be connected with Train_Model and Predict_Model.

More information about the source of this task can be found here.

12.2.10. ML Ensemble Learning

AdaBoost

Task Overview: AdaBoost combines weak classifier algorithm into a single strong classifier.

Task Variables:

Table 53. AdaBoost_Task variables

Variable name

Description

Type

TASK_ENABLED

If False, the task will be ignored, it will not be executed.

Boolean (default=True)

INPUT_VARIABLES

Specifies the parameters' values of the AdaBoost algorithm. Check the list of parameters here.

JSON format

TYPE

Enter the type of algorithm. There are two possible: classification or regression.

List [Classification or Regression]

Usage: It should be connected with Train_Model and Predict_Model.

More information about the source of this task can be found here.
CatBoost

Task Overview: CatBoost is a gradient boosting which helps to reduce overfitting. It can be used to solve both classification and regression challenge.

Task Variables:

Table 54. CatBoost_Task variables

Variable name

Description

Type

TASK_ENABLED

If False, the task will be ignored, it will not be executed.

Boolean (default=True)

INPUT_VARIABLES

Specifies the parameters' values of the CatBoost algorithm. Check the list of parameters here.

JSON format

TYPE

Enter the type of algorithm. There are two possible: classification or regression.

List [Classification or Regression]

Usage: It should be connected with Train_Model and Predict_Model.

More information about the source of this task can be found here.
Gradient_Boosting

Task Overview: Gradient Boosting is an algorithm for regression and classification problems. It produces a prediction model in the form of an ensemble of weak prediction models. Task Variables:

Table 55. Gradient_Boosting_Task variables

Variable name

Description

Type

TASK_ENABLED

If False, the task will be ignored, it will not be executed.

Boolean (default=True)

INPUT_VARIABLES

Specifies the parameters' values of the Gradient Boosting algorithm. Check the list of parameters here.

JSON format

TYPE

Enter the type of algorithm. There are two possible: classification or regression.

List [Classification or Regression]

Usage: It should be connected with Train_Model and Predict_Model.

More information about the source of this task can be found here.
Random_Forest

Task Overview: Random Forest is an algorithm for regression, classification and other tasks that operates by constructing a multitude of decision trees at training time. Task Variables:

Table 56. Random_Forest_Task variables

Variable name

Description

Type

TASK_ENABLED

If False, the task will be ignored, it will not be executed.

Boolean (default=True)

INPUT_VARIABLES

Specifies the parameters' values of the Random Forest algorithm. Check the list of parameters here.

JSON format

TYPE

Enter the type of algorithm. There are two possible: classification or regression.

List [Classification or Regression]

Usage: It should be connected with Train_Model and Predict_Model.

More information about the source of this task can be found here.
XGBoost

Task Overview: XGBoost is an implementation of gradient boosted decision trees designed for speed and performance.

Task Variables:

Table 57. XGBoost_Task variables

Variable name

Description

Type

TASK_ENABLED

If False, the task will be ignored, it will not be executed.

Boolean (default=True)

INPUT_VARIABLES

Specifies the parameters' values of the XGBoost algorithm. Check the list of parameters here.

JSON format

TYPE

Enter the type of algorithm. There are two possible: classification or regression.

List [Classification or Regression]

Usage: It should be connected with Train_Model and Predict_Model.

More information about the source of this task can be found here.

12.2.11. Train

Train_Model

Task Overview: Train a model using a classification, a regression or an anomaly algorithm.

Table 58. Train_Model_Task variables

Variable name

Description

Type

TASK_ENABLED

If False, the task will be ignored, it will not be executed.

Boolean (default=True)

LABEL_COLUMN

Enter the column label name.

String

USE_NVIDIA_RAPIDS

Enable NVIDIA RAPIDS support.

Boolean (default=False)

  1. More information about the source of the ML Classification can be found here.

  2. More information about the source of the ML Regression can be found here.

  3. More information about the source of the ML Anomaly Detection can be found here.

12.2.12. Predict

Predict_Model

Task Overview: Generate predictions using a trained model.

Table 59. Predict_Model_Task variables

Variable name

Description

Type

TASK_ENABLED

If False, the task will be ignored, it will not be executed.

Boolean (default=True)

LABEL_COLUMN

Enter the column label name.

String

USE_NVIDIA_RAPIDS

Enable NVIDIA RAPIDS support.

Boolean (default=False)

Usage: It should be used after the task Train_Model.

12.2.13. ML Explainability

Model_Explainability

Task Overview: Explain ML models globally on all data, or locally on a specific data points using the SHAP and eli5 Python libraries. You can see more details at: https://www.kaggle.com/learn/machine-learning-explainability

Table 60. Model_Explainability_Task variables

Variable name

Description

Type

TASK_ENABLED

If False, the task will be ignored, it will not be executed.

Boolean (default=True)

LABEL_COLUMN

Enter the column label name.

String

FEATURE_PARTIAL_PLOTS

Partial Dependence Plots show how a feature affects predictions.

String [e.g., distance_circularity, max_length_aspect_ratio, etc].

FEATURE_PARTIAL2D_PLOTS

2D Partial Dependence Plots show predictions for any combination of two features.

String [e.g, distance_circularity, max_length_aspect_ratio].

SHAP_ROW_SHOW

Enter the row of data to show. The SHAP (https://github.com/slundberg/shap) values interpret the impact of having a certain value for a given feature in comparison to the prediction we’d make if that feature took some baseline value. Feature values causing increased predictions are in pink and Feature values decreasing the prediction are in blue. The SHAP_ROW_SHOW The row of data to show

Integer

Usage: It should be connected with Train_Model.

12.3. Deep Learning Bucket

The deep-learning bucket contains diverse generic deep learning tasks that enable you to easily compose workflows for predictive models learning and testing. This bucket can be easily customized according to your needs. It offers different options, you can customize it by adding new tasks or update the existing tasks.

  1. All deep learning tasks were implemented using PyTorch library.

  2. It is recommended to use an enabled-GPU machine to run the deep learning tasks.

12.3.1. Input and Output

Import_Image_Dataset

Task Overview: Load and return an image dataset. There are some simple rules for organizing your files and folders.

  1. Image Classification Dataset: Each class must have its own folder which should contain its related images. The Figure below shows how your folders and files should be organized.

200
You can use RGB images in JPG or PNG formats.
You can find an example of the organization of the folders at: https://s3.eu-west-2.amazonaws.com/activeeon-public/datasets/ants_vs_bees.zip
  1. Image Segmentation Dataset: Two folders are required: the first folder should contain the RGB images in JPG format and another folder should contain its corresponding annotations in PASCAL VOC format. RGB images and annotations should be organized as follows:

150
You can use RGB images in JPG format (Images folder) and the groundtruth annotations (Classes folder) in the PNG format using Pascal VOC pattern.
You can find an example of the organization of the folders at: https://s3.eu-west-2.amazonaws.com/activeeon-public/datasets/oxford.zip
  1. Object Detection Dataset: Two folders are demanded: the first folder should contain the RGB images in JPG format and another folder should contain its corresponding anotations in XML format using PASCAL VOC format or TXT format using COCO format (http://cocodataset.org/#home). The RGB images and annotations should be organized as follows:

150
You can use RGB images in JPG format (Images folder) and the annotations (Classes folder) in the XML format using Pascal VOC or COCO pattern.
In these links, you can find an example of the organization of the folders using Pascal_VOC Dataset and COCO Dataset.

Task Variables:

Table 61. Import_Image_Dataset_Task variables

Variable name

Description

Type

GPU_NODES_ONLY

If True, the tasks will be executed on GPU nodes.

Boolean (default=True)

DATA_URL

URL pointing to the zip folder containing the needed data.

String

TRAIN_SPLIT

Must be a float within the range (0.0, 1.0), not including the values 0.0 and 1.0.

Float (default=1)

VAL_SPLIT

Must be a float within the range (0.0, 1.0), not including the values 0.0 and 1.0.

Float (default=0.1)

TEST_SPLIT

Must be a float within the range (0.0, 1.0), not including the values 0.0 and 1.0.

Float (default=0.3)

DATASET_TYPE

Enter the type of your dataset. There are two possible types: classification or segmentation

List [Classification, Detection or Segmentation]

Download_Model

Task Overview: Download a trained model by a deep learning algorithm.

Task Variables:

Table 62. Import_Model_Task variables

Variable name

Description

Type

GPU_NODES_ONLY

If True, the tasks will be executed on GPU nodes.

Boolean (default=True)

MODEL_TYPE

Choose the type of your model. There are two possible types: PyTorch or ONNX.

List [PyTorch or ONNX]

Not all deep networks support the ONNX model yet. You can download ONNX model of the following networks: AlexNet, DenseNet-161, ResNet-18, VGG-16 and YOLO.
Import_Model

Task Overview: Import a trained model by a deep learning algorithm.

Task Variables:

Table 63. Import_Model_Task variables

Variable name

Description

Type

GPU_NODES_ONLY

If True, the tasks will be executed on GPU nodes.

Boolean (default=True)

MODEL_URL

URL pointing to the zip folder containing the needed model.

String

Import_Text_Dataset

Task Overview: Import data from external sources. Each unique label must have its own folder which should contain its related text file. If your data is unlabeled, use the name 'unlabeled' for the folder containing your text file.

Task Variables:

Table 64. Import_Text_Dataset_Task variables

Variable name

Description

Type

GPU_NODES_ONLY

If True, the tasks will be executed on GPU nodes.

Boolean (default=True)

DATASET_URL

URL pointing to the zip folder containing the needed data.

String

TRAIN_SPLIT

Must be a float within the range (0.0, 1.0), not including the values 0.0 and 1.0.

Float (default=1)

TEST_SPLIT

Must be a float within the range (0.0, 1.0), not including the values 0.0 and 1.0.

Float (default=0.3)

VAL_SPLIT

Must be a float within the range (0.0, 1.0), not including the values 0.0 and 1.0.

Float (default=0.1)

TOY_MODE

Use a subset of the data to train the model fastly.

Boolean (default=True)

TOKENIZER

Transform the text into tokens. Different options are available (str.split,moses,spacy,revtok,subword)

List (default=str.split)

SENTENCE_SEPARATOR

Split the text into separated paragraphs, separated lines, separated words. Choose your own separator.

String (default=\r)

CHARSET

Encode to be used to read the text.

String (default='utf-8')

IS_LABELED_DATA

True if data is labeled.

Boolean (default=True)

Torchtext were used to preprocess and load the text input. More information about this library can be found here.
Preview_Results

Task Overview: Preview the results of the predictions generated by the trained model.

Task Variables:

Table 65. Preview_Results_Task variables

Variable name

Description

Type

GPU_NODES_ONLY

If True, the tasks will be executed on GPU nodes.

Boolean (default=True)

OUTPUT_FILE

Converts the prediction results to HTML or CSV file.

List (default='HTML')

Export_Images

Task Overview: Download a zip file of your results.

Table 66. Export_Images_Task variables

Variable name

Description

Type

GPU_NODES_ONLY

If True, the tasks will be executed on GPU nodes.

Boolean (default=True)

Search_Image_Dataset

Task Overview: Search image from Bing or DuckDuckGo navigator and return an image dataset.

Task Variables:

Table 67. Search_Image_Dataset_Task variables

Variable name

Description

Type

GPU_NODES_ONLY

If True, the tasks will be executed on GPU nodes.

Boolean (default=True)

DATA_FOLDER

Specifies the path where the data should be downloaded.

String

SEARCH_TERM

Enters a keyword to query into search engine.

String

QUERY_SIZE

Maximum number of search results for a single query (maximum of 34 per request for Bing navigator).

List [Bing, DuckDuckGo] default=DuckDuckGo

IMG_SIZE

Inserts (width, height) of the images as a tuple with 2 elements.

Integer (default=(200, 200))

SEARCH_ENGINE

Defines a source engine to query and download images.

String

Usage: It should be connected with Import_Image_Dataset.

Torchtext were used to preprocess and load the text input. More information about this library can be found here.

12.3.2. Image Classification

AlexNet

Task Overview: AlexNet is the name of a Convolutional Neural Network (CNN), originally written with CUDA to run with GPU support, which competed in the ImageNet Large Scale Visual Recognition Challenge in 2012.

Usage: It should be connected to Train_Image_Classification_Model.

Table 68. AlexNet_Task variables

Variable name

Description

Type

GPU_NODES_ONLY

If True, the tasks will be executed on GPU nodes.

Boolean (default=True)

USE_PRETRAINED_MODEL

Parameter to use a pre-trained model for training. If True, the pre-trained model with the corresponding number of layers is loaded and used for training. Otherwise, the network is trained from scratch.

Boolean (default=True)

PyTorch were used to build the model architecture based on AlexNet.
DenseNet-161

Task Overview: Densely Connected Convolutional Network (DenseNet) is a network architecture where each layer is directly connected to every other layer in a feed-forward fashion (within each dense block).

Usage: It should be connected to Train_Image_Classification_Model.

PyTorch were used to build the model architecture based on DenseNet-161.
Table 69. DenseNet-161_Task variables

Variable name

Description

Type

GPU_NODES_ONLY

If True, the tasks will be executed on GPU nodes.

Boolean (default=True)

USE_PRETRAINED_MODEL

Parameter to use a pre-trained model for training. If True, the pre-trained model with the corresponding number of layers is loaded and used for training. Otherwise, the network is trained from scratch.

Boolean (default=True)

ResNet-18

Task Overview: Deep Residual Networks (ResNet-18) is a deep convolutional neural network, trained on 1.28 million ImageNet training images, coming from 1000 classes.

Usage: It should be connected to Train_Image_Classification_Model.

PyTorch were used to build the model architecture based on ResNet-18.
Table 70. ResNet-161_Task variables

Variable name

Description

Type

GPU_NODES_ONLY

If True, the tasks will be executed on GPU nodes.

Boolean (default=True)

USE_PRETRAINED_MODEL

Parameter to use a pre-trained model for training. If True, the pre-trained model with the corresponding number of layers is loaded and used for training. Otherwise, the network is trained from scratch.

Boolean (default=True)

VGG-16

Task Overview: The VGG-16 is an image classification convolutional neural network.

Usage: It should be connected to Train_Image_Classification_Model.

PyTorch were used to build the model architecture based on VGG-16.
Table 71. VGG-16_Task variables

Variable name

Description

Type

GPU_NODES_ONLY

If True, the tasks will be executed on GPU nodes.

Boolean (default=True)

USE_PRETRAINED_MODEL

Parameter to use a pre-trained model for training. If True, the pre-trained model with the corresponding number of layers is loaded and used for training. Otherwise, the network is trained from scratch.

Boolean (default=True)

12.3.3. Image Segmentation

FCN

Task Overview: The FCN16 combines layers of the feature hierarchy and refines the spatial precision of the output.

Usage: It should be connected to Train_Image_Segmentation_Model.

PyTorch were used to build the model architecture based on FCN.
Table 72. FCN_Task variables

Variable name

Description

Type

GPU_NODES_ONLY

If True, the tasks will be executed on GPU nodes.

Boolean (default=True)

IM_SIZE

Insert (width, height) of the images as a tuple with 2 elements.

Integer (default=(64, 64))

NUM_CLASSES

Number of classes.

Integer (default=5)

SegNet

Task Overview: is a deep convolutional encoder-decoder architecture for robust semantic pixel-wise labelling.

Usage: It should be connected to Train_Image_Segmentation_Model.

PyTorch were used to build the model architecture based on SegNet.
Table 73. SegNet_Task variables

Variable name

Description

Type

GPU_NODES_ONLY

If True, the tasks will be executed on GPU nodes.

Boolean (default=True)

IM_SIZE

Insert (width, height) of the images as a tuple with 2 elements.

Integer (default=(64, 64))

NUM_CLASSES

Number of classes.

Integer (default=3)

UNet

Task Overview: consists of a contracting path to capture context and a symmetric expanding path that enables precise localization.

Usage: It should be connected to Train_Image_Segmentation_Model.

PyTorch were used to build the model architecture based on UNet.
Table 74. UNet_Task variables

Variable name

Description

Type

GPU_NODES_ONLY

If True, the tasks will be executed on GPU nodes.

Boolean (default=True)

IM_SIZE

Insert (width, height) of the images as a tuple with 2 elements.

Integer (default=(64, 64))

NUM_CLASSES

Number of classes.

Integer (default=3)

12.3.4. Image Object Detection

SSD

Task Overview: produces a fixed-size collection of bounding boxes and scores for the presence of object class instances in those boxes, followed by a non-maximum suppression step to produce the final detections. For more details click on this link

Usage: It should be connected to Train_Image_Object_Detection_Model.

PyTorch were used to build the model architecture based on SSD.
Table 75. SSD_Task variables

Variable name

Description

Type

GPU_NODES_ONLY

If True, the tasks will be executed on GPU nodes.

Boolean (default=True)

START_ITERATION

Initial iteration.

Integer (default=0)

MAX_ITERATION

Maximum iteration.

Integer (default=5)

LR_STEPS

Learning steps update for SGD (Stochastic Gradient Descent).

Integer (default=5)

LR_FACTOR

Learning rate update for SGD.

Float (default= 1e-3) Range in [0, 1].

GAMMA

Gamma update for SGD.

Float (default=0.1) Range in [0, 1].

MIN_SIZES

Minimum object size for detection by specifying numerical values or reference areas on screen. Objects smaller than that are ignored.

Integer (default= [30, 60, 111, 162, 213, 264])

MAX_SIZES

Maximum object size for detection by specifying numerical values or reference areas on screen. Objects larger than that are ignored.

Integer (default= [60, 111, 162, 213, 264, 315])

LEARNING_RATE

Initial learning rate.

Float (default= 1e-8) Range in [0, 1].

MOMENTUM

Momentum value for optimization.

Float (default=0.9) Range in [0, 1].

WEIGHT_DECAY

Weight decay for SGD

Float (default= 5e-4) Range in [0, 1].

IMG_SIZE

Insert (width, height) of the images as a tuple with 2 elements.

Integer (default=(300, 300))

NUM_CLASSES

Number of classes.

Integer (default=21)

LABEL_PATH

The URL of the file containing the class names of the dataset.

String (default=(https://s3.eu-west-2.amazonaws.com/activeeon-public/datasets/voc.names))

USE_PRETRAINED_MODEL

Parameter to use pre-trained model for training. If True, the pre-trained model with the corresponding number of layers is loaded and used for training. Otherwise, the network is trained from scratch.

Boolean (default=True)

The default parameters of the SSD network were set for the PASCAL VOC dataset (http://host.robots.ox.ac.uk/pascal/VOC/voc2012/). If you’d like to use another dataset, you probably need to change the default parameters.
YOLO

Task Overview: You only look once (YOLO) is a single neural network to predict bounding boxes and class probabilities. For more details click on this link

Usage: It should be connected to Train_Image_Object_Detection_Model.

PyTorch were used to build the model architecture based on YOLO.
Table 76. YOLO_Task variables

Variable name

Description

Type

GPU_NODES_ONLY

If True, the tasks will be executed on GPU nodes.

Boolean (default=True)

LEARNING_RATE

Initial learning rate

Float (default= 0.0005) Range in [0, 1].

MOMENTUM

Momentum value for optimization.

Float (default=0.9) Range in [0, 1].

WEIGHT_DECAY

Weight decay for SGD

Float (default= 5e-4) Range in [0, 1].

IMG_SIZE

Insert (width, height) of the images as a tuple with 2 elements.

Integer (default=(414, 416))

NUM_CLASSES

Number of classes.

Integer (default=81)

CONF_THRESHOLD

This parameter shows how certain it is that the predicted bounding box actually encloses some object. This score doesn’t say anything about what kind of object is in the box, just if the shape of the box is any good.

Float (default=0.5) Range in [0, 1].

NMS_THRESHOLD

This parameter will select only the most accurate (highest probability) one of the boxes.

Float (default=0.45) Range in [0, 1].

LABEL_PATH

The URL of the file containing the class names of the dataset.

String (default=(https://s3.eu-west-2.amazonaws.com/activeeon-public/datasets/coco.names))

USE_PRETRAINED_MODEL

Parameter to use pre-trained model for training. If True, the pre-trained model with the corresponding number of layers is loaded and used for training. Otherwise, the network is trained from scratch.

Boolean (default=True)

The default parameters of the YOLO network were set for the COCO dataset (http://cocodataset.org/#home). If you’d like to use another dataset, you probably need to change the default parameters.

12.3.5. Text Classification

GRU

Task Overview: Gated recurrent units (GRUs) are a gating mechanism in recurrent neural networks.

Task Variables:

Table 77. GRU_Task variables

Variable name

Description

Type

GPU_NODES_ONLY

If True, the tasks will be executed on GPU nodes.

Boolean (default=True)

EMBEDDING_DIM

The dimension of the vectors that will be used to map words in some languages.

Integer (default=50)

HIDDEN_DIM

Hidden dimension of the neural network.

Integer (default=40)

DROPOUT

Percentage of the neurons that will be ignored during the training.

Float (default=0.5)

Usage: It should be connected to Train_Text_Classification_Model.

PyTorch were used to build the model architecture based on GRU.
LSTM

Task Overview: Long short-term memory (LSTM) units (or blocks) are a building unit for layers of a recurrent neural network (RNN).

Task Variables:

Table 78. LSTM_Task variables

Variable name

Description

Type

GPU_NODES_ONLY

If True, the tasks will be executed on GPU nodes.

Boolean (default=True)

EMBEDDING_DIM

The dimension of the vectors that will be used to map words in some languages.

Integer (default=50)

HIDDEN_DIM

Hidden dimension of the neural network.

Integer (default=40)

DROPOUT

Percentage of the neurons that will be ignored during the training.

Float (default=0.5)

HUsage: It should be connected to Train_Text_Classification_Model.

PyTorch were used to build the model architecture based on LSTM.
RNN

Task Overview: A recurrent neural network (RNN) is a class of artificial neural network where connections between units form a directed graph along a sequence.

Task Variables:

Table 79. RNN_Task variables

Variable name

Description

Type

GPU_NODES_ONLY

If True, the tasks will be executed on GPU nodes.

Boolean (default=True)

EMBEDDING_DIM

The dimension of the vectors that will be used to map words in some languages.

Integer (default=50)

HIDDEN_DIM

Hidden dimension of the neural network.

Integer (default=40)

DROPOUT

Percentage of the neurons that will be ignored during the training.

Float (default=0.5)

Usage: It should be connected to Train_Text_Classification_Model.

PyTorch were used to build the model architecture based on RNN.

12.3.6. Train Model

Train_Image_Classification_Model

Task Overview: Train a model using a Convolutional Neural Network (CNN) algorithm.

Task Variables:

Table 80. Train_Image_Classification_Model variables

Variable name

Description

Type

GPU_NODES_ONLY

If True, the tasks will be executed on GPU nodes.

Boolean (default=True)

NUM_EPOCHS

Number of times all of the training vectors are used once to update the weights.

Integer (default=1)

BATCH_SIZE

Batch size to be used.

Integer (default=4)

NUM_WORKERS

Number of subprocesses to use for data loading. 0 means that the data will be loaded in the main process.

Integer (default=2)

SHUFFLE

Set to True to have the data reshuffled at every epoch.

Boolean (default=True)se for data loading. 0 means that the data will be loaded in the main process.

Usage: Could be connected to Predict_Image_Classification_Model and Download_Model.

Train_Text_Classification_Model

Task Overview: A recurrent neural network (RNN) is a class of artificial neural network where connections between units form a directed graph along a sequence.

Task Variables:

Table 81. Train_Text_Classification_Model variables

Variable name

Description

Type

GPU_NODES_ONLY

If True, the tasks will be executed on GPU nodes.

Boolean (default=True)

LEARNING_RATE

Determines how quickly or how slowly you want to update the parameters.

Float (default=0.001)

OPTIMIZER

Choose the optimization algorithm that would help you to minimize the Loss function. Different options are available (42B, 840B, twitter.27B,6B).

List (default=Adam)

LOSS_FUNCTION

Choose the function that will be used to compute the loss. Different options are available (Adam,RMS, SGD, Adagrad, Adadelta).

List (default=NLLLoss)

EPOCHS

Number of times all of the training vectors are used once to update the weights.

Integer (default=10)

TRAINABLE

True if you want to update the embedding vectors during the training process.

Boolean (default=False)

GLOVE

Choose the glove vectors that need to be used for words embedding. Different options are available (42B, 840B, twitter.27B,6B)

List (default=6B)

USE_GPU

True if you need to execute the training task in a GPU node.

Boolean (default=True)

Usage: Could be connected to Predict_Text_Classification_Model and Download_Model.

Train_Image_Segmentation_Model

Task Overview: Train a model using an image segmentation algorithm.

Task Variables:

Table 82. Train_Image_Segmentation_Model variables

Variable name

Description

Type

GPU_NODES_ONLY

If True, the tasks will be executed on GPU nodes.

Boolean (default=True)

NUM_EPOCHS

Number of times all of the training vectors are used once to update the weights.

Integer (default=1)

BATCH_SIZE

Batch size to be used.

Integer (default=1)

NUM_WORKERS

Number of subprocesses to use for data loading. 0 means that the data will be loaded in the main process.

Integer (default=1)

SHUFFLE

Set to True to have the data reshuffled at every epoch.

Boolean (default=True)se for data loading. 0 means that the data will be loaded in the main process.

Usage: Could be connected to Predict_Image_Segmentation_Model and Download_Model.

Train_Image_Object_Detection_Model

Task Overview: Train a model using an object detection algorithm.

Task Variables:

Table 83. Train_Image_Object_Detection_Model variables

Variable name

Description

Type

GPU_NODES_ONLY

If True, the tasks will be executed on GPU nodes.

Boolean (default=True)

NUM_EPOCHS

Number of times all of the training vectors are used once to update the weights.

Integer (default=1)

BATCH_SIZE

Batch size to be used.

Integer (default=1)

NUM_WORKERS

Number of subprocesses to use for data loading. 0 means that the data will be loaded in the main process.

Integer (default=1)

12.3.7. Predict

Predict_Image_Classification_Model

Task Overview: Generate predictions using a trained model.

Table 84. Predict_Image_Classification_Model variables

Variable name

Description

Type

GPU_NODES_ONLY

If True, the tasks will be executed on GPU nodes.

Boolean (default=True)

BATCH_SIZE

Batch size to be used.

Integer (default=4)

NUM_WORKERS

Number of subprocesses to use for data loading. 0 means that the data will be loaded in the main process.

Integer (default=2)

SHUFFLE

Set to True to have the data reshuffled at every epoch.

Boolean (default=True)se for data loading. 0 means that the data will be loaded in the main process.

Usage: It should be used after the tasks Train_Image_Classification_Model or Download_Model.

Predict_Text_Classification_Model

Task Overview: Generate predictions using a trained model.

Table 85. Predict_Text_Model variables

Variable name

Description

Type

GPU_NODES_ONLY

If True, the tasks will be executed on GPU nodes.

Boolean (default=True)

LOSS_FUNCTION

Choose the function that will be used to compute the loss. Different options are available (Adam,RMS, SGD, Adagrad, Adadelta).

List (default=NLLLoss)

Usage: It should be used after the tasks Train_Text_Classification_Model or Download_Model.

Predict_Image_Segmentation_Model

Task Overview: Generate predictions using a trained segmentation model.

Table 86. Predict_Image_Segmentation_Model variables

Variable name

Description

Type

GPU_NODES_ONLY

If True, the tasks will be executed on GPU nodes.

Boolean (default=True)

BATCH_SIZE

Batch size to be used.

Integer (default=4)

NUM_WORKERS

Number of subprocesses to use for data loading. 0 means that the data will be loaded in the main process.

Integer (default=2)

SHUFFLE

Set to True to have the data reshuffled at every epoch.

Boolean (default=True)se for data loading. 0 means that the data will be loaded in the main process.

Usage: It should be used after the tasks Train_Image_Classification_Model or Download_Model.

Predict_Image_Object_Detection_Model

Task Overview: Generate predictions using a trained object detection model.

Table 87. Predict_Image_Object_Detection_Model Task variables

Variable name

Description

Type

GPU_NODES_ONLY

If True, the tasks will be executed on GPU nodes.

Boolean (default=True)

BATCH_SIZE

Batch size to be used.

Integer (default=1)

NUM_WORKERS

Number of subprocesses to use for data loading. 0 means that the data will be loaded in the main process.

Integer (default=1)

SHUFFLE

Set to True to have the data reshuffled at every epoch.

Boolean (default=True)se for data loading. 0 means that the data will be loaded in the main process.

Usage: It should be used after the task Predict_Image_Object_Detection_Model or Download_Model.

Model_Explainability

Task Overview: Explain a Deep learning Model using GradientExplainer.

Table 88. Model_Explainability Task variables

Variable name

Description

Type

GPU_NODES_ONLY

If True, the tasks will be executed on GPU nodes.

Boolean (default=True)

IMG_SAMPLES

Number of samples on which to explain the model’s output.

Integer (default=2)

IMG_LIST

Choose some images to explain.

List (default=1, 4, 6, 12)

FEATURE_LAYER

Choose a layer to explain.

String (default=features[7] for a VGG16 model). For example, you can use features[0] for AlexNet, layer1[0].conv1 for ResNet, etc.

RANKED_OUTPUTS

Explain many of the top model outputs determined by output rank order.

Integer (default=4).

Usage: It should be used after the the task Train_Image_Classification_Model.

Shap uses GradientExplainer to explain a deep learning model. More information about this library can be found here or on GitHub repository here.
This task requires too much memory. You may receive an error message if you don’t have enough memory (RAM).

12.4. Data Visualization Bucket

The data-visualization catalog integrates generic tasks that can be easily used to broadcast visualizations of the analytic results provided by AI tasks. It offers a large set of plots that can be organized programmatically or through the UI. These plots are used to create dashboards for both live and real-time data, inspect results of experiments, or debug experimental code. The data-visualization catalog provides a fast, easy and practical way to execute different workflows generating these diverse visualizations that are automatically cached by the TensorBoard and Visdom Server. However, other visualization libraries can be integrated as well.

12.4.1. Visdom

It provides a large set of plots that can be organized programmatically or through the UI. These plots can be used to create dashboards for both live and real-time data, inspect results of experiments, or debug experimental code.

Visdom_Service_Start

Task Overview: Bind or/and Start Visdom server.

Task Variables:

Table 89. Visdom_Service_Start_Task variables

Variable name

Description

Type

SERVICE_ID

The id of the Visdom service.

String (default="Visdom")

INSTANCE_NAME

The instance name of the server to be used to broadcast the visualization.

String (default="visdom-server")

PROXIFIED

It takes by default the value of VISDOM_PROXYFIED workflow variable.

String (default="$VISDOM_PROXYFIED") (default=empty)

ENGINE

Container engine.

String (default="$CONTAINER_PLATFORM")

NATIVE_SCHEDULER

Name of the Native Scheduler node source to use when the workflow tasks must be deployed inside a cluster such as SLURM, LSF, etc.

String (default=empty)

NATIVE_SCHEDULER_PARAMS

Parameters given to the native scheduler (SLURM, LSF, etc) while requesting a ProActive node used to deploy the workflow tasks.

String (default=empty)

If two workflows use the same service instance names, then, their generated plots will be created on the same service instance.
Visdom_Service_Actions

Task Overview: Manage the life-cycle of Visdom PSA service. It allows to trigger three possible actions: Pause_Visdom, Resume_Visdom and Finish_Visdom.

Task Variables:

Table 90. Visdom_Service_Actions_Task variables

Variable name

Description

Type

INSTANCE_ID

The service instance ID.

String (default=Empty)

INSTANCE_NAME

The instance nameof the server to be used to broadcast the visualization.

String

ACTION

The action that will be processed regarding the service status.

List [Pause_Visdom, Resume_Visdom and Finish_Visdom] (default="Finish_Visdom")

Visdom_Visualize_Results

Task Overview: Plot the different results obtained by a predictive model using Visdom

Task Variables:

Variable name

Description

Type

TASK_ENABLED

If False, the task will be ignored, it will not be executed.

Boolean (default=True)

TARGETED_CLASS

The targeted class that you need to track

URL

String

VISDOM_ENDPOINT

The visdom endpoint to be used.

Usage: This task has to be connected to Visdom_Service_Start. The Visdom server should be up in order to be able to broadcast visualizations.

Visdom_Plots

Task Overview: return numerous examples of plots covered by Visdom.

Task Variables:

Variable name

Description

Type

VISDOM_ENDPOINT

The visdom endpoint to be used.

URL

12.4.2. Visdom Workflows

The following workflows present some examples using Visdom service to visualize the results obtained while training and testing some predictive models.

Visdom_Plot_Example: returns numerous examples of plots covered by Visdom.

Visdom_Real_time_Digit_Classification: shows an example of realtime plotting using the Visdom server for training a convolutional neural network (CNN) for MNIST digit classification.

Check_Visdom_Support: checks if the user wants (or not) to start the Visdom service.

A demo video of these workflows is available in ActiveEon Youtube Channel.

12.4.3. Tensorboard

It provides the visualization and tooling needed for machine learning experimentation such as tracking, and visualizing metrics such as loss and accuracy, visualizing the model graph (ops and layers), viewing histograms of weights, biases, or other tensors as they change over time, projecting embeddings to a lower dimensional space, displaying images, text, and audio data and others.

Tensorboard_Service_Start

Task Overview: Start the TensorBoard server as a service.

Task Variables:

Table 91. Tensorboard_Service_Start variables

Variable name

Description

Type

SERVICE_ID

The id of the TensorBoard service.

String (default="Tensorboard")

INSTANCE_NAME

The instance name of the server to be used to broadcast the visualization.

String

MOUNT_LOG_PATH

Specifies the path where Tensorboard logs are created and stored on the host.

String (default=/shared/$TENSORBOARD_HOST_LOG_PATH)

ENGINE

Container engine.

String (default="$CONTAINER_PLATFORM")

PROXIFIED

It takes by default the value of TENSORBOARD_PROXYFIED workflow variable.

String (default="$TENSORBOARD_PROXYFIED") (default=empty)

NATIVE_SCHEDULER

Name of the Native Scheduler node source to use when the workflow tasks must be deployed inside a cluster such as SLURM, LSF, etc.

String (default=empty)

NATIVE_SCHEDULER_PARAMS

Parameters given to the native scheduler (SLURM, LSF, etc) while requesting a ProActive node used to deploy the workflow tasks.

String (default=empty)

CONTAINER_ROOTLESS_ENABLED

If True, the user will be able to run the workflow in a rootless mode.

(default=False)

Tensorboard_Service_Actions

Task Overview: Manage the life-cycle of TensorBoard PSA service. It allows to trigger three possible actions: Pause_Tensorboard, Resume_Tensorboard and Finish_Tensorboard.

Task Variables:

Table 92. Tensorboard_Service_Actions_Task variables

Variable name

Description

Type

INSTANCE_ID

The service instance ID.

String (default=Empty)

INSTANCE_NAME

The instance name of the server to be used to broadcast the visualization.

String

ACTION

The action that will be processed regarding the service status.

List [Pause_Tensorboard, Resume_Tensorboard and Finish_Tensorboard] (default="Finish_Tensorboard")

12.4.4. Tensorboard Workflows

The following workflows present some examples using TensorBoard service to visualize the results obtained while training and testing some predictive models.

Tensorboard_Realtime_CIFAR10_Training: shows an example of real-time graph using TensorBoard for training a CNN using CIFAR10 database.

Tensorboard_Plots_Example: shows an example exposing the different plots available in TensorBoard.

Check_Tensorboard_Support: checks if the user wants (or not) to start the TensorBoard service.

12.5. Satellite Imagery Bucket

The satellite-imagery bucket contains some tasks that enable you to search, download and retrieve the metadata of Sentinel satellite images from the PEPS website and Copernicus Open Access Hub.

12.5.1. Fetch_Images_From_Satellite_Platforms

It allows to download the metadata and images from the Copernicus and PEPS platforms or both simultaneously.

Fetch Satellite Images

Task Variables:

Table 93. Fetch_Images_From_Satellite_Platforms variables

Variable name

Description

Type

SEARCH_ENGINE

Defines an engine to search and download satellite images.

List [Peps, Copernicus, All] (default=Copernicus)

OUTPUT_PATH

Specifies the path where the data should be downloaded.

String

Please click here to create a new user account from Peps website.
Please click here to create a new user account from Copernicus website.

12.5.2. Fetch_Satellite_Images_From_PEPS

Task Overview: Load and return a PEPS dataset including a metadata folder with metadata files and images folder containing satellite images.

Task Variables:

Table 94. Fetch_Satellite_Images_From_PEPS variables

Variable name

Description

Type

LOCATION

Defines a town name.

String (default=Indonesia)

PLATFORM_NAME

Specifies an instrument on a Sentinel satellite.

List [S1, S2, S2ST, S3] (default=S2)

PRODUCT_TYPE

Limits the search to a Sentinel product type.

List [GRD, SLC, OCN (for S1) or S2MSI1C S2MSI2A S2MSI2Ap (for S2)] (default=S2MSI1C)

SENSOR_MODE

Specifies the search to a Sentinel sensor mode.

List [EW, IW , SM, WV (for S1) or INS-NOBS, INS-RAW (for S3)] (default=INS-NOBS)

START_DATE

Determines a start date of the query in the format YYYYMMDD.

String

END_DATE

Define an end date of the query in the format YYYYMMDD.

String

TILE

Limits the search to a tile number.

String

LATITUDE

Determines the search to a latitude in decimal degrees.

Float

LONGITUDE

Limits the search to a longitude in decimal degrees.

Float

OUTPUT_PATH

Specifies the path where the data should be downloaded.

String

Please add third party credentials (USER_NAME_PEPS and USER_PASS_PEPS) in the Scheduling & Orchestration interface → Manage Third-Party Credentials to connect to PEPS.
More information about the source of this task can be found here.

12.5.3. Fetch_Satellite_Images_From_Copernicus

Task Overview: Load and return a Copernicus dataset including a metadata folder with metadata files and images folder containing satellite images according to the resolution & image band selected by user.

Task Variables:

Table 95. Fetch_Satellite_Images_From_Copernicus variables

Variable name

Description

Type

PLATFORM_NAME

Specifies an instrument on a Sentinel satellite.

String [Sentinel-1, Sentinel-2, Sentinel-3, Sentinel-4, Sentinel-5, Sentinel-5, Precursor, Sentinel-6](default=Sentinel-2)

FOOTPRINT

Defines a geojson file with footprints of the query result.

String

PRODUCT_TYPE

Limits the search to a Sentinel product type.

List [GRD, SLC, OCN (for S1) or S2MSI1C S2MSI2A S2MSI2Ap (for S2)] (default=S2MSI1C)

START_DATE

Determines a start date of the query in the format YYYYMMDD.

String

END_DATE

Defines an end date of the query in the format YYYYMMDD.

String

USE_START_AND_END_DATE

If True, it uses the date defined in the START_DATE and START_DATE fields, otherwise it downloads all scenes that were published in the last 24 hours.

Boolean (default=True)

SPATIAL_RESOLUTION

Defines granule dimensions for each resolution band.

List [10m, 20m, 60m] (default=10m)

IMAGE_BAND

Determines from 13 spectral bands spanning from the Visible and Near Infra-Red (VNIR) to the Short Wave Infra-Red (SWIR).

List [All, B01, B02, B03, B04, B05, B06, B07, B08, B8A, B09, B10, B11, B12, TCI] (default=All)

OUTPUT_PATH

Specifies the path where the data should be downloaded.

String

Please add third party credentials (USER_NAME_COP and USER_PASS_COP) in the Scheduling & Orchestration interface → Manage Third-Party Credentials to connect to Copernicus.
More information about the source of this task can be found here.

Activeeon SAS, © 2007-2019. All Rights Reserved.

For more information, please contact contact@activeeon.com.