Skip to main content
Version: FCP 25.11

Task Templates

Task templates are standardized job configurations provided by FCP. They package key settings such as command-line arguments, runtime environment variables, and compute resource specifications into reusable templates, presented through a visual UI. This significantly reduces the learning curve for HPC workloads and helps users submit jobs efficiently.

Permissions​

For details, see Permissions.

Field Descriptions​

When creating or editing a task template, configure:

  • Name: Unique identifier for the template.
  • Icon (optional): Visual identifier. Supports PNG/JPG/SVG/WEBP files up to 5 MB. Recommended size: 72 px x 72 px square for best display.
  • Video (optional): Link an operation demo.
  • Manual (optional): Link detailed documentation.
  • Tags (optional): Add one or more classification tags for later filtering. Tags are used when creating tasks to associate and filter templates.
  • Description (optional): Detailed usage notes, scenarios, and cautions.
  • Definition: The core execution logic of the template, including commands, scripts, and input/output definitions. See Task template syntax.

How to Use​

1. Create a task template​

Prerequisites:

  • You have the system permission Create job template.
  • If you plan to associate clusters, you have Use permission for the target clusters.

Steps:

  1. Go to Task Template management and click Create template.
  2. Fill in fields according to Field Descriptions.
  3. In Definition, describe the task execution logic using the template syntax.
  4. (Optional) Configure Associated clusters.
  5. Save the template.

2. Manage and use templates​

  • Template list: Shows all templates with icon, name, tags, and description.
  • Search and filter:
    • Keyword search: Search by template name or tag name.
    • Tag filter: Click a tag to filter templates associated with it.
  • Template actions:
    • Details: Click the template name to view full configuration.
    • Edit: Modify template configuration.
    • Delete: Remove the template from the system.
  • Access control: Administrators can grant template permissions to specific users/groups with Read (view/use) and Update (modify) permissions.

Associate Clusters​

Associating templates with clusters can restrict which resources users can select when submitting tasks from a template.

  • Default: Newly created templates are not associated with any cluster.
  • How to associate:
    • In the template edit or details page, open Associated clusters.
    • Unassociated cluster list: Shows all clusters eligible for association. Clusters in states such as Releasing/Released/Error are filtered out automatically. Supports searching by cluster status and cluster name.
    • Associated cluster list: Shows clusters already associated with the template.
    • You can move clusters from the unassociated list to the associated list, or remove them.
  • Impact on task submission:
    1. No associated clusters: When a user creates a task from the template and selects Existing cluster, they can see all clusters they have permission to use.
    2. Associated clusters configured: When a user selects Existing cluster, they can see only clusters in the associated list that are in Running/Updating state. If the user has no access to any of these clusters, the list is empty.

Tag Management​

Tags classify task templates and help with filtering and organization.

  • Core features:
    • Create/Edit tags: Define tag name, icon, and description (same icon requirements as template icons).
    • Tag list: Centralized management and shows how many templates are associated with each tag.
    • Search and delete: Search tags and delete single or multiple tags.
  • Usage: Tags are mainly used in Create task. Users can filter templates by tags when selecting a template.

Task Template Syntax​

Note: This syntax is for the scheduler-oriented task mode (Direct tasks) only.

parameters: # Parameter list (one or more)
  - name: param1 # name pattern: [a-zA-Z0-9_]
    display: Display name # Name shown in UI
    description: Description # Used to generate help docs
    type: Type # INT | FLOAT | PATH | ENUM | STRING | BOOL | PATH_ARRAY | STRING_ARRAY | ENUM_SCRIPT (case-insensitive, must use underscore)
    required: bool # Whether required; default false
    usage: Usage # SCRIPT | SCHEDULER, default SCRIPT
    schedPrefix: Prefix # If usage is SCHEDULER, the parameter value is appended after this prefix
    value: string # Default value, e.g. '0', '0.3', 'true', 'abc', '/abc/def'
                  # For PATH_ARRAY/STRING_ARRAY, separate values by ',', e.g. '/abc/def,/ghi/jkl'
                  # Note: For PATH/PATH_ARRAY values, always use relative paths and do not end with '/'
    option:
      # Use the browser native fetch API for remote calls.
      # For fetch usage, see: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API
      # The platform injects built-in headers automatically:
      # Authorization: Bearer <token>
      # X-Current-ClusterId: <clusterId>
      # X-Current-PartitionId: <partitionId>
      # X-Current-JobId: <jobId>
      fetch:
        url: https://example.com # Request URL
        method: GET # GET | POST
        headers: # Additional custom headers
          key1: value1
          key2: value2
        # response is expected to be JSON, schema:
        # [
        #   {"id": "1", "display": "Option 1"},
        #   {"id": "2", "display": "Option 2"}
        # ]
      values: # Static options (for ENUM)
        - id: value1
          display: Description # Display name
      path: # For PATH / PATH_ARRAY types: file filter
        pattern: Filter # File name filter; empty means no filter
        directory: bool # true | false, whether directory
      float:
        min: Min # optional
        max: Max # optional
      int:
        min: Min # optional
        max: Max # optional
      string:
        pattern: regex # Regex pattern for validation
  # The following section describes restrict.resourceCheck.
  # It is used to check idle resources in the selected cluster partition, and provides two variables:
  # 1) partition: idle resource data for the selected partition
  # {
  #  clusterId?: number; // cluster id
  #  name?: string; // cluster name
  #  partitionId?: number; // partition id
  #  partitionName?: string; // partition name
  #  idleCpu?: number;   // idle CPU
  #  allocCpu?: number;  // allocated CPU
  #  totalCpu?: number;  // total CPU
  #  idleMemory?: number;  // idle memory
  #  allocMemory?: number; // allocated memory
  #  totalMemory?: number; // total memory
  #  runningComputeCount?: number; // running compute node count
  #  idleComputeCount?: number; // idle compute node count
  # }
  #
  # 2) data: user input values for parameters defined above (for dynamic comparisons)
  # Example:
  # [
  #   {
  #      "name": "count","value": {"float": 3 },
  #      "def": {
  #        "name": "count",
  #        "display": "Loop count",
  #        "description": "Loop count",
  #        "type": "FLOAT",
  #        "required": true,
  #        "option": {
  #          "float": { "min": "1", "max": "3" }
  #        }
  #      }
  #   },
  #   {"name": "filepath","value": {"path": "/job-1.cwl" },"def": ... },
  #   {"name": "filepath_array","value": {"paths": ["/zy4523","/zy56"]},"def": ... },
  #   {"name": "String","value": { "string": "asdas"},"def": ... },
  #   {"name": "stringarray","value": {"strings": [ "adas"]},"def": ... },
  #   {"name": "Bool","value": {"bool": true},"def": ... },
  #   {"name": "int","value": {"int": 3},"def": ... }
  # ]
  # IMPORTANT:
  # When comparing user input values (data) with partition resources (partition), units may differ.
  # Example: scheduler memory defaults to MiB/MB, but idleMemory is in GiB/GB.
  # Convert units before comparison as needed, for example:
  # if (num2 > partition.idleMemory)  ->  if ((num2 / 1000) > partition.idleMemory)
  #
  # Return a string to show a warning. Return null/empty to show no warning.
restrict:
  resourceCheck: |-
    let num1 = data.filter(item => item.name === 'count')[0].value.float;
    let num2 = data.filter(item => item.name === 'int')[0].value.int;
    if (partition.idleCpu < num1) {
        return 'Insufficient idle CPU for this submission. The task will be queued after it is created.';
    }
    if (partition.idleMemory < num2) {
       return 'Insufficient idle memory for this submission. The task will be queued after it is created.';
    }
    return null
nameExpression: |-  # Used to set a dynamic task name
  console.log(formData, key, value) # If you are unsure about the data, print it and adjust the code accordingly. Remove comments in actual use.
  setName(value);
  # More examples are provided in `nameExpression examples` below.
outputs: # Output files to display
  - path: xxx/xxx/output.file # File name filter; empty means no filter
    type: Type # TEXT | IMAGE | VIDEO | AUDIO | FILE
script: |-
    #!/bin/bash
    # Script content
    echo {{ param1 }} # Reference parameter param1

We provide a set of task template examples for common engineering simulation software. You can use them as references or start from them directly:

nameExpression examples​

Example configuration:

parameters:
    - name: stringInput
      display: String test
      description: Description for String test
      type: sTrinG # case-insensitive
      required: true

    - name: stringArrayInput
      display: StringArray test
      description: Description for StringArray test
      type: STRING_ARRAY
      required: true

    - name: pathInput
      display: PATH input test
      description: Description for PATH input test
      type: PATH
      required: true
      option:
        path:
          directory: false

    - name: pathArrayInput
      display: Required memory
      description: Memory value input
      type: PATH_ARRAY
      required: true
      option:
        path:
          directory: false

nameExpression:
  console.log(formData, key, value); # If you are unsure about the data, print it and adjust the code accordingly. Remove comments in actual use.
  setName(value);
outputs:
    - name: output
      description: Output
      path: output
      type: text
script: |-
    #!/bin/bash
    {{ stringput }}

In this YAML example, the formData structure looks like:​

{
  "jobName":"atxttxt",
  "stringput":"aaaa",
  "stringArrayInput":[
    "bbbb",
    "cccc"
  ],
  "pathInput":[
    {
      "type":"FILE",
      "size":166,
      "name":"atxt.txt",
      "path":"/atxt.txt",
      "parent_path":"/",
      "mime":"text/plain; charset=utf-8",
      "last_modified_time":1739432273501,
      "storage_id":-1
    }
  ],
  "pathArrayInput":[
    {
      "type":"FILE",
      "size":166,
      "name":"atxt.txt",
      "path":"/atxt.txt",
      "parent_path":"/",
      "mime":"text/plain; charset=utf-8",
      "last_modified_time":1739432273501,
      "storage_id":-1
    },
    {
      "type":"FILE",
      "size":9,
      "name":"a.txt",
      "path":"/a.txt",
      "parent_path":"/",
      "mime":"text/plain; charset=utf-8",
      "last_modified_time":1739347355456,
      "storage_id":-1
    }
  ]
}

In this YAML example, key and value behave as follows​

key and value refer to the form field whose value changes each time an input changes (in this example: stringInput, stringArrayInput, pathInput, pathArrayInput).

  • When stringInput changes: key is stringInput, value is a string /aaaa.
  • When stringArrayInput changes: key is stringArrayInput, value is an array ['bbbb', 'cccc'].
  • When pathInput changes: key is pathInput, value is a string /atxt.txt.
  • When pathArrayInput changes: key is pathArrayInput, value is an array ['/atxt.txt', '/a.txt'].

Notes​

  • Values in formData may differ from values you get via formData[key], and also differ from value returned by different control types (PATH, STRING, PATH_ARRAY, STRING_ARRAY). Compare the printed output above to understand the structure.
  • In real usage, pay attention to the data structure. If behavior does not match your expectations, check the data carefully and debug the code.