The topic of this discussion is as above, sharing my views on this issue. The choice of development tools, or rather the choice of technical route, is theoretically the primary aspect that needs to be clarified.
The scope of discussion is: development of motor simulation or electric drive system simulation toolchains.
When deciding which development tool to choose, one can first ask the following questions:
Question 1: What is the ultimate goal of the toolchain development? Is it an automation tool for single physical field simulation processes or a system design optimization tool for multi-component and multi-physical field?
If it is the former, pyaedt is a good toolkit, and the official version of pyaedt v1.0 should be released soon. The simplicity of the code has significantly improved compared to ironpython, and the official website also has detailed technical documentation; if it is the latter, especially considering the joint simulation of motor and electric control, whether there are sufficiently good alternatives in the Python ecosystem compared to Simulink, and whether it aligns with the research and development habits of most organizations and industry practices needs careful consideration.
Question 2: How much resources (people + materials + time) are available for toolchain development? Is the use of Matlab licensed or restricted for commercial use?
Encouragement is given to develop from 0 to 1, breaking free from the Matlab ecosystem. If developing industrial software comparable to optislang for professional PIDO (Process Integrated Design Optimization), and considering commercial use, C++ may be more suitable. Of course, choosing this path requires considerable resources, which cannot be borne by 2-3 people or individual developers. If there are only a few developers, and commercial use is not considered, and the organization does not have Matlab licensing restrictions, the only issue to consider is the cost of Matlab licensing. Although Python is free, there is a saying to remember: free is often the most expensive! During the secondary development process, the availability and convenience of support documentation and technical support for various libraries (such as access to external networks for research and development organizations) can greatly reduce the development experience, after all, we are all engineering students, not just coders.
Question 3: What is the essence of the toolchain?
The toolchain encapsulates the simulation process and the methodology for simulation design optimization. Its essence is a tool that combines “process automation + evolutionary algorithms/machine learning + expert knowledge,” aimed at: improving efficiency + inspiring innovation + empowering system simulation. In the case of the motor electromagnetic simulation optimization toolchain, it will involve: Design of Experiments (DOE) + evolutionary algorithms + machine learning + app development + driver script development. Matlab can handle all of the above in one go and is sufficiently user-friendly. Therefore, the development of the toolchain should not focus on code showmanship, but rather on quickly transforming the methodology of motor design or simulation into code, promoting the widespread application of expert knowledge within the research and development organization, rather than spending too much time on programming skills, languages, and learning to use various libraries.
Based on the above, I will briefly explain my reasons for choosing Matlab for development:
① As per Question 1, the ultimate goal is to create a toolchain for electric drive systems.
② As an individual developer, I am not considering commercial use for now; commercial users can purchase Matlab licenses themselves, or later mixed programming can be done, and the migration cost is not as high as imagined. For PIDO-type tools, the computational load is not large, and there are no frequent data input/output operations, so there is basically no issue with running efficiency not meeting engineering needs. The real time-consuming part lies in the finite element solver, which is not something the toolchain itself needs to solve.
③ Historical reasons. I am more accustomed to using Matlab; when I started secondary development, the pyaedt library was not yet available. From my current development experience, in terms of the motor simulation toolchain, the scripts driving Maxwell account for less than 1/4 of the total code volume of the toolchain, and the workload for refactoring and optimization in this part is small, with simple code construction. The largest code volume is in: a. reusable functional sub-modules oriented to demand; b. building and restructuring the computational architecture (considering multi-desktop parallelism, computational anomaly detection, and breakpoint continuation, etc.); c. UI interface interaction design. The essence of the toolchain is actually similar to that of a product manager, addressing the real bottlenecks in electromagnetic design simulation and creating an easy-to-use and effective tool.
As for the core pain points currently existing in motor simulation design, stay tuned for the next breakdown.