Troubleshooting Simulation Performance with the Diagnostics Tool

Simulation cases can easily grow in complexity as we improve the fidelity of the case or add more unit operations to the overall model. This can have an impact on the performance of the case particularly if we have many recycles and controllers. The Symmetry process software platform offers many alternatives to speed up simulation cases, but we are faced with the challenge that we must first identify the sections of the model that are causing the speed bottlenecks, and this may not always be a simple task.

This article describes the use of the Diagnostics tool to troubleshoot the performance of simulation models created in the Symmetry platform. For this example, we will use a Claus plant with trim air control (Figure 1) based on the simulation case TrimAirThreestage.vsym which is included in the default installation of Symmetry 2018. 

The Diagnostics tool can be found in the window of the Main Flowsheet and it contains information related to the case such as memory consumption, unit operation count, and performance.


Figure 1. Claus plant used for Diagnostics tool example

The first step for this exercise is to open the Diagnostics tab. You can use the flowsheet icon from the Visio toolbar and select the corresponding tab as shown in Figure 2.


Figure 2. Default view of Diagnostics tab

 The default view contains a Main frame with generic information such as the total count of unit operations, convergence status, memory usage, and the time it took for the last solve pass. This Main frame also contains a variety of options to enable different types of timers. In this case, we will check the “Unit Op Timers Active” option to enable the timers for the unit operations. This will automatically enable the “Internal Timers” as well. The next step is to resolve the case to get the first set of results and then we can inspect the timers (shown in Figure 3).


Figure 3. Diagnostics tab after enabling timers and resolving

The Frame labeled “Performance per Unit Operation” displays a summary of the total time it took for each unit operation. The column “Timer Op” contains the name of the unit operation (or its internal object) as a hyperlink to open its Window. The column “Timer By Op” includes the total time it took to solve the unit operation as many times as it solved. This number of solve passes is shown in the column “Timer Hit Count”. For example, the Bed-3.itnRxn took 2.73 seconds to solve 3 times. By default, timers will keep accumulating as we keep resolving the simulation case. The Main frame contains options to reset the timers or to configure the timers to get reset after every solve pass.

There are two other frames called “Internal Performance” and “Performance per Type”. The first frame includes a summary of the time spent in generic types of actions such as flash calculations. The second frame below accumulates the time spent by type of unit operation. In Figure 4 we can see that the PH flash accounts for a considerable portion of the solution time. This is expected for most simulations. The high time spent in the dew point flash is not as common but is necessary for this model because we are monitoring the dew point approach in the sulfur converter beds to avoid dropping a liquid phase which could in turn damage the catalyst. 


Figure 4. Internal Performance timers

It is worth mentioning that enabling the timers for the unit operations also enabled two new variables in the Main frame called “Show Op Status” and “Log Solve Pass”. The first variable will include the status message of every unit operation in the performance summary frame. The other variable is an advanced feature that logs the order in which every unit operation is being solved. Care should be taken when using this feature because the log file will keep growing and the performance of the case will be degraded.


 Figure 5. Include unit operation Status to the timers

 IMPORTANT: Timers in the Diagnostics tab are not to be taken as accurate timers. The overhead of tracking time and refreshing the user interface may impact the actual time. Timers are meant to be used as a qualitative guide when comparing among unit operations, the same applies to counters. Sometimes the counter may indicate a number that is higher than we may expect because a unit operation may have solved partially one time if not all the information was available in the first solve pass (e.g. only solved for delta pressure). Also, keep in mind that refreshing the Diagnostics tab during recycle iterations may incur in overhead that will impact the results.

We can now start troubleshooting the case from the Diagnostics tab. For this example, Bed-3 (the third converter) is taking a lot longer to solve than the other unit operations. We can then click on the link to open this unit operation and see in that the number of segments is set to 30 which is an unusually high value (default is 5). This is likely the cause of the slow solve time because it will require 31 dew point calculations to calculate the dew point margin. Upon inspection of the dew point margin profile plot in Figure 7, we can conclude that the profile is almost linear and the dew point margin is likely to always appear at the outlet of the converter, therefore, it should be safe to reduce the number of segments to 5 or even lower. 


Figure 6. Converter Bed-3 is set to 30 segments


 Figure 7. Dew point margin in Bed-3

After we change the number of segments to 5, reset the timers, and resolve the case we will see that the solve time for Bed-3 is reduced to a comparable value to the other converters as shown in Figure 8. 


Figure 8. Performance per unit operation after reducing the number of segments in Bed-3

We could then proceed to make step changes in the feed and evaluate the performance of the flowsheet while controllers iterate. For a case like this, we may find that the tolerance in the dew point margin controllers is too tight (0.01 C) and we could relax it by 10 or even 100. The diagnostics tab may also help understand the performance of the order of solution of controllers. For example, for this plant, it was concluded that the dew point margin controller of Bed-2 should be solved before that of Bed-3 but there are other simulations in which users may want to solve the controllers simultaneously.

This article described the main features of the Diagnostics tool in the Symmetry platform for a steady state simulation and how we can use it to troubleshoot the performance of a case. It is worth mentioning that this tool is also available in the dynamics engine but the features and variables are adapted for the functionality of a transient engine. 

Please contact us if you have any questions or feedback.

Raul Cota, Ph.D., P. Eng.

To Top