Block Configuration

This page describes common block properties, settings, and functions. Detailed information on functions and usage of specific blocks is found on their respective pages.

Configuration Dialog

After being placed in the workflow, a block is usually configured for a specific task. Naturally, different blocks have a variety of different settings which are not detailed here.


To open the block’s configuration, double-click the block after it is placed in the workflow. The configuration window contains 4 tabs 1:

  • Configuration: the block-specific configuration. The contents of this tab depend on the type of the block you configure and are described on the block’s documentation page in (click the help button 2 to open this page).
  • Options: allows to view and set block’s options, and to add options to workflow parameters (see section Options).
  • Ports: allows to view input and output ports, their data types, set up port monitoring, and add ports to workflow parameters (see Ports).
  • Sandbox: sets the location of the block’s working directory (see Sandbox).

Many blocks allow to map some values from configuration to their inputs and outputs. One of the simplest examples is Const, the block that allows you to add named constants; each constant added automatically creates an output port with the same name, so when the workflow starts, this port outputs the value you have set for the constant. Other typical example are CAD and CAE integration blocks, such as SolidWorks; after a document file is loaded in this block, you can select document variables that have to appear as block’s inputs and outputs.

Common Settings

This section describes settings and properties that are common across all blocks.


Options are an essential part of the block configuration; the Options tab often contains advanced settings not available on the Configuration tab.


To change an option, double-click its value 1. Non-default values are shown in bold 2.

On this tab you can also add any option to the list of workflow parameters 3. It makes the option available in the Parameters pane in Run, allowing to change its value quickly without opening the block’s configuration. Note that values specified in Run override those set in the block’s configuration.

While the layout of this tab is the same for all blocks, available options depend on the type of the block. Detailed option descriptions are found on block documentation pages.


Each block has named inputs and outputs called ports. In pSeven, all ports are one-way only, either input or output (bidirectional ports can be emulated by input-output port pairs when needed).


The Ports tab shows current ports, their names 1 and types 2. Note that certain changes in block’s configuration can change its ports (for example, when adding variables).

In some cases a block requires an input to some port, but this value is a constant. To avoid adding a block with constants, you can assign a value 3 directly to a port. For input ports, these values are accepted only if there is no link connected to the port. Values assigned to output ports work differently: some blocks can use these values as output defaults in case of error (see Error Handling), some others have more specific uses for them — for example, in the PythonScript block a value assigned to a port becomes the initial value of the script variable, which is associated with that port.

Like options, ports can also be added to workflow parameters 4. You can assign values to the ports in the Parameters pane in Run. Note that values specified in Run override those set in the block’s configuration, and neither of them is used if there is a link connected to the port (that is, the link has top priority if it exists).

Finally, any port can be monitored 5 meaning that all data sent or received through this port is captured by pSeven and stored in the project database for further analysis. Monitored ports are shown in the Monitoring pane in Run.

Signal Ports

All blocks have two special ports: do (input) and done (output) which are intended for explicit block synchronization.

The do port is used to give a start signal to a block. If this port is not connected, the block will start as soon as it receives all required data. However if you create a link connected to this port, the block will wait until it do port receives some input. The do port accepts data of any type, so any variable can be used as a signal. The received value does not matter.

The done port always emits a signal when the block has finished execution. The signal is a Boolean value which is True is the execution finished successfully and False if there was an error, thus done can also be used as a status port.


A sandbox is the current working directory for the block at workflow run-time. For example, this directory stores files needed during block execution — whenever a block needs to write a temporary file to disk, it writes to the sandbox.

By default, the sandbox is a temporary directory created in the system directory for temporary files. The default sandbox exists only while it is needed, so each block decides when to create and delete the sandbox by itself. You can change this behavior, as well as the location of the sandbox, on the Sandbox tab.


The location may be set relative to project directory (useful for portable projects) or by an absolute path.

Behavior determines when to clear the sandbox: the cleanup may be done automatically — either each time the block executes, or only when the workflow finishes — or manually, meaning that there is no automatic cleanup, and the block never deletes its sandbox.

If the sandbox has to be cleared between block start-ups, yet there are some files that must always be found in sandbox, you can also set a sandbox prototype. It is a directory which contents are copied to sandbox when it is created or re-created. The prototype can also be used simply to initialize the sandbox with all required files.

Finally, two or more blocks can be assigned the same sandbox. In this case, all of them have equal rights to access sandbox files, but the sandbox may be cleared only when all blocks allow this. For example, such configuration can be used to exchange files between blocks, if for some reason these files cannot be sent through ports.

Block Icons

Blocks in pSeven have specific icons so that you can easily identify them in the workflow or find them on the Block library pane. The icons on the Block library pane are always default, but in the workflow you can set a custom icon for the following blocks:

  • Composite,
  • Program,
  • PythonScript, and
  • Text.

Their common feature is that these blocks serve as wrappers for third-party tools, a group of blocks or even another workflow and thus may require special identification.

To set a custom icon:

  • Select a block in the workflow.
  • Use the Set icon… ‣ Set icon… command from the edit toolbar menu to open the file selection dialog.
  • In the Set icon… dialog, select an image file to use.

To reset the icon to default:

  • Select a block in the workflow.
  • Use the Set icon… ‣ Set icon… ‣ Default command from the edit toolbar menu.

Default block icons are also stored in the Block icons directory in the pSeven workspace (see section Installation for its location).

Advanced Settings

This section describes advanced configuration options that are available only in a few blocks.


Data caching allows to avoid redundant calculations by remembering the input and output values of the block. When a cached block receives an input, it looks through the cached input values. If the received input is found in cache (cache hit), the output values are read from the cache and output to the workflow. If the input is not found (cache miss), the block performs calculations, outputs the results and updates the cache.


To use the cache, select “Enable cache” in the block configuration dialog. The file name is optional:

  • If the file name is not specified, the block will use a memory cache which exists only while the workflow runs and is cleared when the workflow finishes. In this case, cached values are not available after running the workflow.
  • If you specify a file name and path, the block will store cached values in this file. The file is persistent, so in this case cached values will be available for analysis after running the workflow.

In case you want to reset a cache file, you can clear it from the block configuration dialog. Note that clearing the cache deletes all cached data.

Caching is currently supported only by the Composite block. Another block can be cached by nesting it into a Composite with enabled cache. This works if:

  • The nested block does not have optional inputs — that is, the block always requires data to all input ports in order to start.
  • The nested block does not receive or output values of List, Dict, File, or Blob types. These data types cannot be cached.

Blocks with optional inputs cannot be cached because the Composite block itself does not support optional inputs. Values of uncacheable types will cause an error and stop the workflow.

Note also that since a workflow itself is an Composite block, you can configure caching on the workflow level by enabling it in the root block’s configuration.

See also

Composite block — Cache
More details on cache configuration in Composite blocks.
Caching tutorial
Provides an example of cache usage in the Composite block.


Environment settings allow to change environment variables for the process started by the block. These changes apply only at the run-time and only to this process — they do no affect the system environment or other blocks. If the block supports defining environment variables, its Configuration tab contains a nested tab named Environment.


You can add new environment variables or modify existing ones. Values of existing variables can be used in new definitions. For example, to append a directory to system PATH:

  • Create a new variable named PATH.
  • Set its value to ${PATH};C:\path\to\directory (Windows) or ${PATH}:/path/to/directory (Linux).

Note that the syntax for names of variables is ${VARIABLE} for both Windows and Linux. The Windows system syntax (%VARIABLE%) should not be used.

Environment settings are supported in:

  • Program — set environment variables for the program or shell script executed by the block (in case of remote execution, also supports changing remote environment variables).
  • PythonScript — set environment variables for the embedded Python script.

Error Handling

In case a block encounters an error when running, it can perform certain actions as specified in its configuration. Error handling by the block is controlled using the Error handling behavior option that has 3 possible values:

  • “stop workflow”: the block raises an error and the workflow is stopped immediately. This is the default for all blocks. It is also the only possible behavior for blocks that do not support error handling.
  • “output signal only”: the block suppresses the error (does not interrupt the workflow) but outputs False to the done port (see Signal Ports). The signal can then be processed in order to handle the error. Other ports do not output any data.
  • “output defaults and signal”: the same as above, but in addition to the signal, the block also outputs values assigned to ports (see section Ports). In this case, the assigned values can be understood as default output in case of error.

Note that setting the error handling behavior to “output defaults and signal” requires assigning values to all output ports of the block — otherwise it will not pass validation and the workflow will not start.

Error handling is most useful for the blocks that launch external programs: if the program execution results in an error, handling this error in the block allows the workflow to continue normally, possibly taking some predefined actions such as selecting an alternative processing branch.

Blocks that support the Error handling behavior option are:

  • Integration type blocks: ANSYSWorkbench, Creo, FMI model, FloEFD, Kompas3D, NX, STAR-CCM+ (beta), and SolidWorks. These blocks can output defaults in case when the program finishes with an error — for example, fails to rebuild a model or run simulation.
  • Core algorithmic blocks: Design space exploration, ApproxBuilder, DFBuilder, DRBuilder. These blocks can output default values or files in case of internal algorithm failure.
  • Approximation model: can output defaults when it fails to evaluate the model, read model properties, or when another error occurs.
  • Excel: can output default values if it fails to recalculate the Excel document or read output cells.
  • Text: can output default values of variables if it fails to parse or generate a file.
  • Program: can output empty files (instead of stopping) in case when the program it launches has finished with an error, or another error occurs (as set in the block’s configuration).
  • PythonScript: can output default values of variables which were not initialized in the embedded script.
  • Composite can output default values in case if any of the nested blocks finishes with an error. Note that Composite handles only errors raised by the blocks, but not errors that appear when data is sent from one port to another with an incompatible data type.

See also

Conditions and Error Handling
The tutorial that provides an example of handling possible errors during workflow execution and shows using the Error handling behavior option.

Run-time File Configuration

Most blocks that process files during the workflow run-time — load them from disk on start, receive or send files through ports — use the Configure file dialog for the file setup.


Compared to the simple file selection dialog, the Configure file dialog provides several advanced settings. For example, you can add a port which will receive the path to your file, write additional data to the file before it is processed by the block, and so on. These settings are described in detail in the File block documentation.


Some blocks contain a random component which make them produce different results after each run. Such non-regular behavior is controlled by a random number generator. But often for convenience purposes, it may be necessary to make calculation results more reproducible. This can be achieved with the help of Deterministic option. Its values are as follows:

  • “disabled”: the block outputs different results after each run;
  • “block run”: the block outputs the same result each time, irrespective of the number of its runs as part of the workflow;
  • “workflow run”: the block outputs the same sequence of results after each new workflow run.

When the option is enabled (the values are “block run” or “workflow run”), the user can specify the initial state of the random generator by setting the seed, an integer that will be passed as parameter to initialize the generator. Fixed seed allows getting the same set of random numbers after each run.

Blocks that support the Deterministic option are: Design space exploration, IVE (experimental), Uncertainty quantification, DoE (legacy), Random, ApproxBuilder, DFBuilder.

Manual Stop

Certain blocks in pSeven support the stop function, meaning that you can manually interrupt block’s execution in a running workflow. The behavior of a stopped block may be different, depending on its configuration and the type of interrupt support it implements. Some blocks support the output of intermediate results, which allows the workflow to continue normally; others can only raise an error when stopped. By default this error stops the workflow, but the block can be configured with error handling which allows the workflow to continue even in this case.

The stop function is available on the Run screen. To stop a block, hover it with your mouse cursor and click the stop icon that appears in the top left corner. A dialog will appear asking you for the action to perform when stopping the block.

If the block supports the output of intermediate results, the stop icon is colored white.


In this case the Stop block dialog has 3 available actions.

  • Stop: try to output intermediate results (soft stop). For example, if the block controls a loop, and some iterations of this loop have already finished, the block can output results of these iterations. There are two possible cases here:
    1. Intermediate results are available. In this case, the workflow continues normally, processing the intermediate results output by the block.
    2. Intermediate results are not available. In this case the block raises an error, and the error is processed according to the error handling behavior configured for the block. If the behavior is to output defaults or signal, the workflow will continue (though it can be stopped by the next block if, for example, it is unable to process these defaults). If the behavior is to stop the workflow, the workflow will be stopped immediately (see section Error Handling for more details).
  • Terminate: do not try to output intermediate results, always stop the block (hard stop). The block always raises an error, which is then processed in the same way as described above. So, depending on the block’s error handling behavior, terminating a block may still allow the workflow to continue.
  • Cancel: do not interrupt the block, continue running the workflow.

If the block does not support the output of intermediate results, the stop icon is colored red.


In this case, the soft stop action is not available in the dialog.


Blocks that do not support the intermediate results output can be stopped with an error only. Again, this error is processed according to the block’s error handling behavior, and depending on it, the workflow may continue after you terminate the block.

The stop dialog also contains a special option to update data caches (see Cache). This option is available only if the stopped block is contained into a block with enabled caching.

  • When “Cache values output by the stopped block” is enabled, the results output by the block on stop (and corresponding input values) will be added to the cache. This is primarily intended to cache partial results for the blocks that support this feature. Note that updating the cache on stop may also be unwanted — for example, when terminating the block that outputs default values in case of error (default values probably should not be saved to the cache).
  • When “Cache values output by the stopped block” is disabled, the cache will not be updated. This is useful in the case noted above (output values indicate an error and should not be cached).

The manual stop function is supported by the following blocks:

  • ApproxBuilder, Design space exploration, Optimizer (legacy), Map, and For support both the stop and terminate actions.
  • FMI model, NX, Program, STAR-CCM+ (beta), and Composite support the terminate action only.