Workflow execution features

In pSeven Enterprise, workflow execution is driven by data flow. The order in which workflow blocks are executed is determined by the block data dependencies. Blocks are launched as data arrives at their inputs. Certain loop controls are also provided based on data flow (see Driver ports).

During workflow execution, each block starts operating only if all its data dependencies are met. For example, a composite block only starts its workflow if there is data on each of its input ports. Setting up and linking the inputs inside a composite block allows you to control the start of its workflow execution.

Iterative computations

An efficient way of organizing iterative computations with different datasets is to use batch mode on an input port of the composite block. For this, the port is switched to batch mode and an array of datasets for computations is fed to it. The block performs computations on each dataset, and different datasets can be processed concurrently in a parallel computing fashion. For each input dataset, the computation result is presented as an element in the array of output results.

Composite blocks also provide a hierarchical structure of the workflow, allowing it to perform the same sequence of computations multiple times with different input datasets. To do this, you can use a composite block as the body of a loop, in which the loop driver block feeds a new dataset for computations into the composite block at each iteration. Furthermore, enclosing a loop in a composite block that is the body of another loop enables nested loops to be implemented.

You can also implement a nested loop using a sequence of driver ports in such a way that the nested loop is driven by the body of the outer loop:

Within each iteration of the outer loop, as many iterations of the nested loop are performed as necessary to complete the nested loop. A new iteration of the outer loop starts only after the nested loop finishes.

This loop structure makes it easier to pass static parameters into the loop. To do this, link inputs of the loop body with outputs of some block outside the loop. The values passed in this way to the body of the loop remain unchanged during the execution of the loop.

In the above example, the parameter values related to the current iteration of the outer loop are passed into the body of the nested loop. These values are independent of the nested loop and remain unchanged until the nested loop ends. The same is true for parameter values that are passed from outside to the body of the outer loop: the values are reused at each iteration of the outer loop.

Working directory management

Each block has a working directory that can be used to store files. These can be files containing data for computations, as well as files created during a workflow run. Some blocks may have a separate working directory, other blocks may have a common working directory. Since the entire workflow is organized as a composite block, it also has its own working directory.

Workflow run directory

The workflow directory holds workflow run resources. These resources are files and folders you can see on the Files tab in the Explorer pane when you navigate to the workflow directory. During a workflow run, the workflow engine copies resources to the respective run directory. For each workflow run, a new run directory is created.

Since the workflow directory is the parent container for the run resources, it serves as the prototype for the workflow run directory. More precisely, the run directory prototype is the workflow directory from which files and folders that are not used as run resources are excluded. The workflow engine creates the run directory by copying its prototype.

You can exclude individual files or entire folders from the run directory prototype. Such files and folders are not copied to the workflow run directory, and they have their names grayed out on the Files tab. To exclude/include files and folders from the run directory prototype, you can use Run file rules commands from the menu in the Explorer pane, or plus/minus buttons that appear when you hover over the name of the file or folder on the Files tab.

The folder structure of the run directory prototype that you can view on the Files tab depends upon the working directory setting for the Composite blocks in the given workflow:

• The prototype does not have a separate folder for the working directory of the Composite block - the parent working directory setting. For example, if the Composite block with this setting is at the very top level of the workflow, its working directory is the workflow run directory. This settup is suitable for simple workflows.

  To place any files in the Composite block's working directory in this case, upload them to the workflow directory root on the Files tab. At the beginning of the workflow execution, those files will be copied to the root of the workflow run directory.

• The prototype contains a separate folder for the working directory of the Composite block - the single working directory setting. For example, if the Composite block with this setting is at the very top level of the workflow, its working directory is assigned the following name by default: 🏠.{block-name}, where {block-name} stands for the name of the Composite block and 🏠 denotes the workflow root. This setup is suitable for most cases where the Composite block is intended to run in batch mode.

  To place any files in the Composite block's working directory with this setting, upload them to the folder that represents the block's working directory on the Files tab. At the beginning of the workflow execution, those files will be copied to the block's working directory in the workflow run directory.

• The prototype contains a separate folder for the working directory of the Composite block with the folder name suffix of [####] - the indexed working directory setting. For example, if the Composite block with this setting is at the very top level of the workflow, then, on the Files tab, its working directory is assigned the following name by default: 🏠.{block-name} [####], where {block-name} stands for the name of the Composite block and 🏠 denotes the workflow root. At each iteration of the block in batch mode, a separate working directory is created, with the directory name containing the iteration number. This settup is suitable when you need to save files separately for each iteration.

  To place any files in the Composite block's working directory with this setting, upload them to the folder that represents the block's working directory on the Files tab. When starting each iteration of this block in batch mode, those files will be copied to the block interaion working directory in the workflow run directory.

Block working directories

The working directories of the blocks are located in the run directory of the workflow. The hierarchy of folders representing the working directories of blocks matches the hierarchy of blocks in the workflow:

• The block can be a child of the workflow, i.e. it is included in the workflow directly, not as part of any Composite block. In this case, the working directory of the block is either the same as the run directory of the workflow, or is a certain folder in the workflow run directory root.
• The block can be a child of some Composite block, i.e. it is directly included in that Composite block. In this case, the working directory of the block is either the same as the working directory of the enclosing Composite block, or is a certain folder in the root of the working directory of that Composite block.

In either case, the run directory of the workflow or the working directory of the respective Composite block is the parent for the child block's working directory.

Composite blocks have a number of working directory settings. Depending on which setting is selected, the working directory of the Composite block is:

• The parent directory (parent setting)
• A single folder in the parent directory root (the single setting)
• A separate folder for each block iteration in the parent directory root (the indexed setting)

The parent block's working directory serves as the working directory for all of its non-composite child blocks. If a non-composite block is directly included in the workflow, the workflow run directory serves as the working directory for that block.

In the run directory prototype, a hierarchy of folders is created in accordance with the hierarchy of blocks and working directory settings, you can view it on the Files tab when the workflow directory is open in the Explorer pane. This hierarchy enables you to upload files to the working directories of the respective blocks. For example, the 🏠.Model folder represents the working directory of a Composite block named Model with the single working directory setting. Files uploaded to the 🏠.Model folder in the workflow directory will be copied to the Model block's working directory at the beginning of each workflow run.

File management

Workflow blocks can read and write files in their working directories, using files to exchange data. File-based data exchange is, in particular, necessary for integration with task-specific programs such as CAD/CAE systems. Thus, CAD integration blocks usually work with files representing geometric models or their assemblies.

During the execution of the workflow, its blocks normally create files in their working directories and can read files that other blocks create. Working directories are saved after the workflow completes, providing access to the computation history. The files created during the workflow execution are also saved in the working directories and can be accessed for further analysis.

Accounting for iterations

Composite blocks that perform iterative computations can create and store working directories separately for each iteration. This feature enables one to track the input and output files at each iteration for a deeper analysis of the computations performed. By using a separate working directory at each iteration, a natural correspondence is established between the input and output files and other data for each cycle of block computations.

Consider a Сomposite block that operates in batch mode. Such a block can concurrently process multiple elements of the input array in an arbitrary order, with the end-to-end processing of each element being a single iteration. The block performs as many iterations as there are elements in the input array.

Depending upon the configuration, a Composite block may have a separate working directory at each iteration. For uniqueness, the working directory name contains the iteration number. In this way, files created and used at each iteration are saved in a separate directory and remain available after the workflow run is completed.

A similar way of organizing working directories is also possible when using a Composite block as the body of a loop:

To store files at each iteration of the loop, a separate working directory can be created, and the entire set of working directories for all iterations will be available after the workflow run is completed:

Placing files in indexed working directories

Working directories of the workflow blocks are created by copying the respective prototype directories from the workflow directory. Thus, all files marked for copying from the prototype directory are automatically included in the working directory. Each file placed in the prototype directory and marked for copying can be found in the corresponding working directory during the workflow run.

This feature specifically makes it possible to place the same input files in the working directory for each iteration. Thus, as applied to the above example, such files should be uploaded to the working directory prototype for the Composite block, located in the workflow directory:

If you need to have a certain file in the working directory to perform the computation, upload it to the working directory prototype when configuring the workflow. The file loaded in this way will always be available in the working directory during the workflow run.