Using the Subprocess operator to stop operator execution order from changing

When editing a large process containing a lot of branches where calculations are done for use later, the operator execution order can go wrong causing the process to fail.

For example, the following shows a relatively complex process with the operator execution order overlaid.

The operators in steps 23 to 25 are calculating a macro that is used in step 13. Clearly, the order is wrong and the process is broken and this can just happen as a result of editing the process. Luckily, this is easy to fix by using the "bring operator to front" operation but I use a trick with the "Subprocess" operator.

The following shows this.

The "Subprocess" operator at what is now step 11 fixes everything. The example set output from step 10 is not required but joining it to step 11 forces it to be executed before all the other steps that might use the macros it is calculating.

Inside the "Subprocess" operator the first input is simply copied directly to the output. The second input is not connected to anything. The following shows this.

As a bonus feature, it is also possible to use this operator to untangle and "neaten up" complex workflows as shown below in a hypothetical example.

The first input is connected to the fifth output, the second to the fourth and so on. There are no restrictions on the type of data flowing through the "Subprocess" operator so this is easy to implement with any type of connection.