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 with data for computations, as well as files created during workflow execution. 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 working directory

When creating a workflow, a prototype of its run directory is created. This is the Files folder of the workflow. During a workflow run, the workflow engine copies the contents of the Files folder to the respective run directory. For each workflow run, a new run directory is created.

The structure of the Files folder depends upon the working directory setting for the given workflow:

• No separate subfolder for the workflow working directory - the parent working directory setting. The workflow working directory is the same as the run directory. This setting is suitable for simple workflows.

  To place any files in the workflow working directory in this case, upload them to the root of the Files folder. At the beginning of the workflow execution, these files will be copied to the root of the workflow run directory.

• The folder with a subfolder named 🏠 by default - the single working directory setting. The workflow working directory is the 🏠 folder located in the run directory root. This setting is suitable for most workflows, except when the entire workflow is used in batch mode.

  To place any files in the working directory, upload them to the 🏠 subfolder of the Files folder. At the beginning of the workflow execution, these files will be copied to the 🏠 folder in the workflow run directory.

• Folder with a subfolder named 🏠 [####] - the indexed working directory setting. At each iteration of the workflow in batch mode, a separate working directory is created in the run directory root, with the directory name containing the iteration number. This setting is suitable when you need to save files separately for each iteration.

  To place any files in the working directory, upload them to the 🏠 [####] subfolder of the Files folder. At the beginning of each iteration of workflow, these files will be copied to the working directory of this iteration.

Block working directories

The working directories of the blocks are contained in the working 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 working directory of the workflow, or is a folder in the workflow working 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 folder in the root of the working directory of this composite block.

In both cases, the working directory of the workflow or that of the respective composite block is the parent for the working directory of the child block.

Composite blocks have the same working directory settings as the workflow itself. Depending upon the setting selected, the working directory of the composite block is one of the following:

• The parent directory (the 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. For example, if a non-composite block is directly included in the workflow, the workflow working directory serves as the working directory for that block.

In the Files folder, a hierarchy of subfolders is created in accordance with the hierarchy of blocks and working directory settings. This allows you to upload files to the working directories of the respective blocks. For example, the 🏠/Composite folder hierarchy represents the working directory of a composite block named Composite with the single setting selected for both this block and the workflow. Files uploaded to the 🏠/Composite subfolder in the Files folder will be copied to the working directory of the Composite block.

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 composite block that operates in batch mode. Such a block is capable of concurrent processing of different 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. Thus, 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, whereas 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 and its blocks are created by copying the respective prototype directories from the workflow configuration. Thus, all files from the prototype directory are automatically included in the working directory. Any file placed in the prototype directory can be found in the corresponding working directory during the workflow execution.

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

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 execution.