Version Compatibility

pSeven keeps backward compatibility for projects, except a few version-specific issues described below. Project compatibility means that a project created in older version can be opened with a newer version of pSeven and will not lose its data or settings. When you open an older project for the first time, it will be automatically updated to use the new version format (this is called a project upgrade and can also be done manually without opening a project, from the File ‣ Upgrade Project menu). Please note that there is no forward compatibility support: a project created in a newer version of pSeven can not be opened with an older one. It also means that an upgraded project is no longer compatible with its original (older) version of pSeven.

It is always recommended to create backup copies of your projects before an upgrade, especially if you are not very familiar with maintaining projects from different versions or are unsure about the consequences of the upgrade.

pSeven 6.9

  • This release includes pSeven Core 6.9 which applied significant changes to the computational budget allocation and selection policies in various optimization algorithms that are used in the Optimizer block. Due to these changes, in most optimization problems that include computationally expensive functions the solving path has changed as compared to the previous versions of pSeven and pSeven Core. This has lead to difference in optimization results which can be observed when comparing results from pSeven 6.9 and earlier versions. This difference is not an error and should not raise any issues, since in expensive problem context the optimal solution can always be established only approximately so direct comparison is never reliable.

    This change does not introduce any compatibility issues with the workflows created in previous pSeven versions. However, you may want to review the Optimizer block configuration in tasks involving global optimization — that is, surrogate based optimization (problems that include expensive functions, see Hint Reference) or problems where a non-default GTOpt/GlobalPhaseIntensity value was used. In both these cases, a certain adjustment of GTOpt/GlobalPhaseIntensity may be needed; for more details on selecting the value to use, see section Local and Global Methods.

  • pSeven 6.9 changes the syntax of references to existing environment variables in block’s environment settings (see section Environment in Block Configuration). Previously it used names of variables beginning with @ (@VARIABLE) — for example, to append a directory to system PATH:


    Since 6.9, the syntax is ${VARIABLE}, for example:


    This change causes an issue if you run a workflow from previous versions that contains a Program or PythonScript block with environment settings using the old syntax. To resolve the issue, you will have to manually update configuration of such blocks. Note that the ${VARIABLE} syntax is used both in Windows and Linux versions of pSeven; the Windows system syntax (%VARIABLE%) should not be used.

pSeven 6.6

  • Prior to 6.6, the algorithm to solve robust optimization problems implemented in the Optimizer block effectively ignored the linearity type setting for objectives and constraints in robust optimization problems, thus losing the opportunity to speed up evaluations of such functions. Version 6.6 improves robust optimization algorithms, in particular allowing to specify linear or quadratic functions in robust optimization problems. The algorithm now does not ignore function type but assumes that functions specified as linear or quadratic do not depend on any stochastic variable (which is correct by definition). However, Optimizer currently does not check your problem formulation in this case. This can lead to unexpected behavior if you define a function that does depend on a stochastic variable, and at the same time you specify it to be linear or quadratic using the hint.

    Note that such problem formulation is incorrect and should be avoided for general reasons. In previous versions it was not an issue because function type was simply ignored in robust optimization problems.

    It is recommended to recheck configuration of Optimizer blocks in workflows from previous versions of pSeven if:

    • the workflow solved an optimization problem with stochastic variables, and
    • linearity type was set to linear or quadratic for some objective or constraint.

    In this case, you should verify that linear and quadratic problem functions do not actually depend on a random (stochastic) variable.

  • pSeven 6.6 discontinues the support for the old version of the PythonScript block that was available only in pSeven 2.0 and below. Workflows containing the old block version can be opened but will require certein updates done manually in order to return them to working state. For details, see section Old Versions on the PythonScript block page.

pSeven 6.3

  • In prior versions all constraints in results output by the Optimizer block were sorted in order of adding them to the problem. This became inconvenient if there are both general and chance constraints in robust optimization, since they are listed on different tabs and there is actually no way to recover in what order they have been added. Due to this, since 6.3 all chance constraints will be sorted after general constraints in optimization results, as described in section Robust Problem Solution on the Optimizer block page.

    This change does not break block-level compatibility (for example, ports and data types are not changed), though it can lead to certain data compatibility issues due to the changed order of columns. It is recommended to revise workflows that solve a robust optimization problem with chance constraints, if they somehow process the constraints data from the Optimizer solution.

    This change can possibly affect a workflow only if:

    • the workflow includes an Optimizer block, and
    • Optimizer solves a robust optimization problem, and
    • this problem has one or more chance constraints.

pSeven 6.0 RC 1

  • pSeven 6.0 RC 1 adds the support for changing values of document variables with assigned units of measurement in the SolidWorks block. A consequence of this update is that the block no longer converts output values to document measurement units for variables that were assigned their own units of measurement — thus block’s output in pSeven 6.0 RC 1 and above may be different from earlier versions.

    For example, consider a document where length units are meters and there is a variable specified in millimeters (x = 5mm). The block reads this value from document and outputs it to a port.

    • In earlier versions the output value is 0.005 (meters, value of variable converted to document units).
    • In pSeven 6.0 RC 1 and above the output values is 5 (millimeters, units of measurement are kept).

pSeven 5.0

  • This release includes several changes in options controlling the behavior of certain randomized algorithms used in approximation (ApproxBuilder and DFBuilder blocks).

    Prior to pSeven 5.0 there were several options controlling the behavior of randomized algorithms in certain ApproxBuilder techniques, namely GTApprox/HDAInitialization, GTApprox/HDARandomSeed, and GTApprox/SGPSeedValue. To simplify the options structure, these options were removed and replaced with two common options: GTApprox/Deterministic that switches between the deterministic and non-deterministic modes and GTApprox/Seed that sets the fixed seed used in the deterministic mode (if it is on). Also, GTApprox/Seed does not have a special value to generate a random seed (as it was for GTApprox/HDARandomSeed and GTApprox/SGPSeedValue) — this function is now entirely controlled by GTApprox/Deterministic.

    This change can affect compatibility due to option name changes, but default technique behavior and available controls remain the same.

    By default, model training in previous versions was deterministic; this behavior is kept as default (GTApprox/Deterministic is on by default). To change HDA, HDAGP and SGP initialization, you can now do one of the following:

    • Keep GTApprox/Deterministic on but change GTApprox/Seed (new deterministic initialization).
    • Switch GTApprox/Deterministic off. In this case GTApprox/Seed is ignored. This is random initialization, the same as setting GTApprox/HDAInitialization to "Random" or using special GTApprox/HDARandomSeed and GTApprox/SGPSeedValue values in previous versions.

    Similar changes were done in internal validation (cross validation) options in ApproxBuilder and DFBuilder to keep their names and behavior in line with the described above:

    • GTApprox/IVRandomSeed is renamed to GTApprox/IVSeed and simply sets the seed used if GTApprox/IVDeterministic is on. Default behavior is deterministic, the same as in previous versions.
    • GTDF/IVRandomSeed is renamed to GTDF/IVSeed and sets the seed used if GTDF/IVDeterministic is on. Default behavior is deterministic, the same as in previous versions.

    Also, to help reproduce the results obtained in a non-deterministic mode, the seeds generated for training and cross validation are now added to model info.

pSeven 4.0

  • pSeven 4.0 changes the listening port of the local license server that provides licenses to pSeven running in the standalone mode (that is, using a local license file). Previous versions used default FlexNet Publisher port 27000, which in many cases lead to port conflicts with other software using the FlexNet licensing system. pSeven 4.0 uses port 27042 to avoid this typical conflict. However, if a license file from an older version is found on the host where pSeven is installed, the local license server may cease to start because of different port numbers in the old and new license files.

    This issue is identified by the following message in pSeven logs:

    ERROR: license files have conflicting port numbers
    Please edit the license files so the port numbers on the SERVER line are identical.


    pSeven logs are found under the pSeven settings directory (%USERPROFILE%\.p7\ in Windows, ~/.p7/ in Linux). In Windows, you can also use a menu shortcut to open this directory: Start ‣ All Programs ‣ pSeven ‣ pSeven Logs.

    The recommended solution is to uninstall older versions of pSeven and switch to using pSeven 4.0. Note that the pSeven uninstaller does not remove user files and settings, so old license files can be left in the pSeven settings directory. These files have to be removed manually.

    pSeven settings directory is %USERPROFILE%\.p7\ in Windows and ~/.p7/ in Linux. You can also open this directory with a system menu shortcut (for example, in Windows: Start ‣ pSeven ‣ License Management ‣ Open License File Location).

    If needed, it is possible to keep both pSeven 4.0 and an older version installed and functional, but solution depends on how pSeven was installed, the number of users, and other details. You can contact for help with this configuration.

  • This release changes behavior of output file ports of the Program block. Previously, if the block’s script failed and did not generate some file that would be output to a port, this port did not output anything. Since pSeven 4.0, in this case an empty file is output instead.

    Old workflows assuming there is no output from Program in case of script failure are likely to behave not as expected when run in 4.0. It is recommended to review settings of blocks which parse Program output files. If you need to ignore empty files from Program, you can also use a Condition block with a condition based on script exit status.

  • pSeven 4.0 introduced certain changes in generating parameter names in the SolidWorks and Kompas3D blocks when document parameters are added to block parameters (mapped to ports). When upgrading a project from version 3.4 or older to 4.0, this can result in block configuration being broken if in the original document there is a parameter which name contains one of the following characters: < > : " \ | ? *. In 4.0 these characters are prohibited in document parameter names and will be replaced; as a result, the associations between block parameters and document parameters will be lost, and the block will not be able to start.

    This situation is fixed in pSeven 4.1 and above by allowing all characters in block parameter names, so if a project is upgraded from 3.4 or older to 4.1 or newer, it will continue to work normally. However, if the project was first upgraded from 3.4 or older to 4.0, and then from 4.0 to 4.1 or newer, the broken block configuration is not fixed automatically, and the project will continue to be unusable.

    Due to this, it is recommended to skip version 4.0 if you require the support for parameter names such as “Part/Subpart” (or containing other characters from < > : " \ | ? *) and upgrade to 4.1 directly.

    If you are upgrading to 4.1 or newer, it is recommended to restore a backup of the project from version 3.4 and upgrade it to the current version, skipping version 4.0. If this is not possible, you can manually edit block parameters after upgrading the project to the current version to make block parameter names the same as document parameter names. Another option is to remove all block parameters and re-add them, allowing pSeven to generate correct block parameter names automatically.

pSeven 3.0

  • This release changes the rule of processing Composite block’s input ports: now all inputs are required to start the block. Earlier, the Composite block could start as soon as there was an input for at least one of the nested blocks. Old workflows exploiting this behavior will possibly freeze if run in 3.0 Final, because of Composite blocks waiting for all inputs, and have to be redesigned to avoid this.

    This change was required by the new feature of loading an existing workflow into a Composite block. Old behavior is in fact against the idea of the Composite block as an integral workflow component, thus the change makes the workflow model more consistent and will benefit in creating re-usable workflow components as custom Composite blocks.

PSE 1.8.3

  • The 1.8.3 release changes the project database scheme (project.p7pdb file format). This change is a result of an update which makes the database more efficient, reducing its size and memory usage when journaling large data (see the 1.8.3 changelog). Unfortunately, the new format is not compatible with old database files, and due to this the database contents will be lost when upgrading older projects to 1.8.3.

    In practice this results in emptying the saved journals when a project from version 1.8.2 or older is upgraded to 1.8.3 or newer versions. Other project settings remain intact. Workflows in the upgraded project are fully functional, workflow design and configurations are not affected. Workflows may be re-run after the upgrade to restore the journal data, since journaling settings are saved in the workflow run configuration.

    Before upgrading to 1.8.3, it is recommended to backup your projects and to export the report data (tables) to CSV files.