Modern general-purpose CAE simulation software has a high degree of integration, especially since many commercial software no longer support the export of computational results. This creates some limitations for using result data in third-party software. For example, users may wish to export result data or perform special processing on the results, such as coupling computation. The general-purpose CAE simulation software WELSIM provides a results export feature, allowing users to quickly and conveniently obtain result files.
Currently, there are two ways to export results: exporting all historical results or exporting the results at the current time step.
Exporting All-Time History Results
For transient analysis, the results will contain data from multiple time steps. Users can export the results from all time steps at once. Supported formats include binary PVD and ASCII PVD. For detailed information about the PVD format, you can refer to the article “ParaView Data (pvd) file format and writing”.
To achieve this, find the “Export All Results” command in the right-click context menu of the solution node and click it.
After selecting “Export All Results,” a dialog box will prompt you to enter a file name. Here you can choose to export in ASCII or binary format.
Afterward, you will be able to find the exported result files at the target path. As shown below, the entry file for the results set is called WelSim_Results.pvd. It can be directly read by open-source post-processing software, such as ParaView. Each folder corresponds to the result data at a specific time step.
Exporting Current Time Step Results
Sometimes, users only need the result data at a certain time step, like the final step result of a steady-state analysis. In order to do this, you can click the corresponding results object, set the “Set Number,” and select “Export Result” from the right-click context menu to export the results at the current time step. Supported file formats include VTU, PVTU, classic VTK, Tecplot, and text. The exported result file will contain all types of results at the current time step.
After selecting “Export Result,” you will be prompted to enter a file name where you can choose the export format.
In this example, the PVTU format was chosen for export. Users can open this file in ParaView or VisIt software to engage in post-processing work in these third-party software.
WELSIM provides mainstream result file formats. For time-based transient analysis results, you can export the entire time history in PVD format. For steady-state results, you can export in VTU, PVTU, VTK, or Tecplot formats.
All exported files contain the mesh data of nodes and elements.
With the continuance of new updated versions, WELSIM will support more types of result files.
WELSIM and the author are not affiliated with ParaView, VTK, and TecPlot. ParaView, VTK, and TecPlot are used only as a nominative reference to the open-source projects and software developed and released by these teams or institutions.
The general-purpose engineering simulation software WELSIM has released its latest 2024R2 (internal version 2.9). Compared to its previous releases, the 2024R2 version contains many new features and enhancements, which can better support various types of engineering simulation analysis.
Added support for CalculiX
The new 2024R2 version adds a pre-processing module for the CalculiX solver, allowing users to quickly generate input scripts required for CalculiX computation, or directly call CalculiX for solving through WELSIM.
Currently, 60 commands are supported, which accounts for 42% of all CalculiX commands. All of which are core commands, capable of common analysis needs.
Added support for Elmer FEM
The new version adds pre-processing support for Elmer FEM, allowing users to quickly generate input scripts required for Elmer FEM calculations. Upon successful export, a solver input script named elmer_welsim.sif will be generated, along with a mesh dataset consisting of four files named mesh.header, mesh.nodes, mesh.elements, and mesh.boundary.
Users can also directly call Elmer FEM for calculations through WELSIM. Currently supported Elmer equations include: Coil Solver, Fluidic Force, Free Surface Reduced, Heat Equation, MagnetoDynamics, Mesh Update, Navier-Stokes, Poisson BEM, Save Line, Save Scalars, Static Electrical Solver, Static Current Solver, Stress Analysis, Stream Solver, etc.
WELSIM introduced a new Additional Solver object to support users in adding various Elmer solver settings.
Enhancements
To conclude, the 2024R2 version has new features and improvements, such as adding a search function to the solver output window, and supporting the import and export of csv format files for the table window. WELSIM has added a specific gas constant material property. Furthermore, the free material editing software MatEditor has added the feature to export material data in CalculiX and Elmer FEM formats.
The automatic testing system has become more user-friendly and contains more tests. WELSIM has created support for reading and saving of test group files *.wstb, and support for the deletion of selected test cases. WELSIM now also provides system-level operations, such as deleting local files and confirming specified files. In the new 2024R2 version, more than 200 test cases can be found and utilized.
WELSIM and the author are not affiliated with CalculiX and Elmer FEM. CalculiX and Elmer FEM is used only as a nominative reference to the open-source project and software developed and released by these teams or institutions.
QtTesting is an open-source testing framework with a friendly license, similar to BSD3, and can be used for commercial products. It has been applied in practical instances for large-scale software such as VTK, ParaView, Slider3D, and WELSIM, proving to be an effective and user-friendly testing framework. As long as the software utilizes QT as its GUI framework, QtTesting can be used as the foundational component for the testing system. The source code of QtTesting can be directly downloaded from https://gitlab.kitware.com/paraview/qttesting or https://github.com/Kitware/QtTesting.
QtTesting is officially endorsed for UI testing. Although, in practical use, it not only can test GUI, but also can test any other functionalities of a product through the properties provided by the GUI, such as the accuracy of calculation results. Many of the numerical results in WELSIM can be validated through the functionality of QtTesting.
QtTesting Framework
The Testing Module of QtTesting consists of two major modules: Translator and Player. Both modules establish connections with widgets in the QT framework to interact with the GUI framework. The translator captures events or signals of the widgets, while the player controls the widgets by traversing all active widgets to obtain the current object of the widget.
Test Translator
The translator module provides users with a fast way to create test files, essentially acting as a macro command for mouse, keyboard, and widget controls. When users perform certain low-level Qt actions such as “mouse movement,” “button press,” “button release,” etc., the generated signals will be captured and converted into higher-level events that can be serialized and played, such as “button activation.” The pqWidgetEventTranslator class and its derived classes play an important role in QtTesting. The derived classes of pqWidgetEventTranslator need to implement the translateEvent() method to handle Qt events and convert signals into high-level events consisting of two strings: a command and a command parameter (which may be empty). Finally, the high-level events are passed to their output container by emitting the recordEvent() signal once or multiple times. This is saved to an XML file, completing the recording of a macro command.
During program execution, pqEventTranslator receives every Qt event that occurs in the entire application runtime and sequentially passes Qt events to each pqWidgetEventTranslator instance. The high-level events emitted by pqEventTranslator can be captured by corresponding observers. Observers either serialize and print the high-level events, or save them. Currently, QtTesting includes two observers, pqEventObserverStdout and pqEventObserverXML, which serialize high-level events to standard screen output and XML files, respectively. Developers can also create their own observers to implement custom functions, such as serializing events to log files or Python scripts.
The translator module can also record check events, such as verifying a property. During the check, an overlay will be drawn on the widget where the mouse hovers. A green overlay indicates that the widget can be checked; if the overlay is red, it indicates otherwise. When clicking on the widget for checking, a check event will be recorded, and a related QString value will be output. This feature is a crucial part when verifying numerical results in WELSIM automated testing.
Running Tests
The essence of running automated tests is to play back recorded macro commands. In the QtTesting framework, pqEventSource provides an abstract interface for objects that provide a stream of “high-level events.” pqXMLEventSource inherits from pqEventSource and implements specific functionality. It is capable of reading XML files generated by pqEventObserverXML.
pqEventPlayer maintains a set of pqWidgetEventPlayer objects responsible for converting high-level events into low-level events. pqEventDispatcher retrieves events from pqEventSource and passes them to an instance of pqEventPlayer for execution. During runtime, each high-level event is encoded into three strings (object pointer, command, and parameters). Those are passed to pqEventPlayer::playEvent(). pqEventPlayer decodes the pointer address and uses it to locate the corresponding widget. Then, pqEventPlayer passes the high-level event and widget to each pqWidgetEventPlayer until one emits a signal indicating the event has been handled.
Creating New Translators and Players
A new translator must at least reimplement the translateEvent(QObject object, QEvent event, int eventType, bool& error) method. First, it must check if the object is of the correct class. Then, it should handle the case of pqEventTypes::ACTION_EVENT, saving the command and related parameters. Sometimes it should also be able to handle pqEventTypes::CHECK_EVENT.
Similarly, a new player should at least reimplement the playEvent(QObject* object, const QString& command, const QString& arguments, int eventType, bool& error) method. First, it should handle pqEventTypes::ACTION_EVENT, converting the read command and parameters into Qt commands, returning true for events it can handle. For checking commands, it should be able to handle the pqEventTypes::CHECK_EVENT event type. Using the provided command and parameters to check the current value of the Qt object, it should set the error variable to false in case of different values, but it should return true for all handled check events, even failed ones.
Sometimes translator and player classes will correspond one-to-one. Developers can refer to pqLineEditEventTranslator and pqLineEditEventPlayer for simple examples, and pqAbstractItemViewEventTranslatorBase/pqAbstractItemViewEventPlayerBase for advanced examples.
Running Tests
The source code of QtTesting is easy to compile, provided with a CMake program, which allows quick compilation into a static or dynamic library. Since this testing module is called in only a few places in the product, compilation into a static library is appropriate.
QtTesting has been successfully applied in software such as VTK, ParaView, but no test cases are available publicly. Fortunately, the general-purpose engineering simulation software WELSIM not only uses QtTesting as the GUI testing framework, but also open-sourced all test cases. Users can download WELSIM and the test cases to experience automated testing based on QtTesting.
WELSIM’s automated testing user interface is based on the interface of QtTesting, with additional features, such as:
1. Support for reading *.wstb files, which contain a set of *.xml files, allowing for easier reading of multiple test cases at once.
2. Saving failed test cases to *.wstb files. Users do not need to manually select test cases for saving.
3. Adding a right-click context menu for selecting or deselecting test cases.
Developers can also add other functionalities as needed.
Conclusion
QtTesting is a free testing system for Qt GUI frameworks. It not only provides the core functions for capturing QT events and signals, but also offers a user-friendly interface, making it friendly for both developers and end-users. QtTesting can assist software developers with quickly establishing testing systems. Its built-in functionality for capturing and controlling widgets can meet the testing needs of most products, and it is easy to adapt. Developers can add new testing modules based on the widgets of their own products.
We have successfully applied QtTesting to the automated testing of the simulation software WELSIM, achieving great results. The content discussed in this article can be applied not only to CAE simulation software, but also to any graphical software built using the QT framework.
WelSim and the author are not affiliated with Qt or QtTesting. There is no direct relationship between WelSim, the author, and the Qt or QtTesting development teams or organizations. The reference to Qt and QtTesting here is solely for technical blog articles and software usage reference.
