The main driving force behind designing the MATLAB® Toolbox was to make a modular solution that both supports our existing users, versed in our usual scripting language, and our new users, that would like to build models in the simplest possible way. We partitioned the usual simulation workflow into model building (GeneralSim and sister classes), job setup and execution (Job class) and post-processing (PostProcess) stages (as shown in Fig. 1) and abstracted away any processing and model setup verification steps not directly required to be accessed by users.
Figure 1. The MATLAB® classes that comprise the OnScale MATLAB® Toolbox and their relationship
Each of these classes contain properties and methods that can be accessed by the user to achieve the desired simulation model structure. For the duality of simplicity and specificity, most member functions are implemented in two ways, including a more automated approach for ease of use, while maintaining the opportunity for fine-tuning simulations to your specific needs.
Let us look at the classes in more detail!
GeneralSim class
The simulation classes are a family of classes (GeneralSim and RFSim currently, more to come) inherited from a generic simulation base class (BaseSim). To maintain a lightweight solution, the common elements within the various simulations are included in the base simulation class, and the additional specific properties and methods are included in the specific classes on top of that.
These classes are responsible for model building (either from CAD or primitives), material assignment, boundary condition setup, excitation, mesh, and runtime selection. Runtime plots and data exports can be set up as well.
To support existing workflows, users can use existing material files, and/or create new materials to be added from within MATLAB®. Boundary conditions can be defined between interfaces of parts, specific CAD or primitive surfaces, or the whole domain boundary. Mesh options include a rectilinear structured mesh for fast execution or general connectivity meshes for very accurate feature resolution, or a mixture of both. As in all cases, at least a part of the mesh is a rectilinear structured mesh, keypoint selection is of utmost importance for accurate results. Keypoints are locations in the model where mesh nodes are enforced. It is possible via the Toolbox to automatically select planar surfaces to be included in the list of keypoints, significantly reducing the burden on the user.
Various views of the model structure, such as the geometry, keypoints, glued surfaces (for hybrid meshes), slice planes (for 2D slice models of 3D structures) are possible, ensuring that the properly set up model is submitted for execution.
Finally, excitation function and execution length are selected.
Before the generation of a solver input file, the selected properties, features, and model setup are cross-checked to minimize the probability of simulation failures.
Job class
Once an input file is generated (or an older one manually written can be used as well) it can be assigned to a Job object for local execution or submission to the cloud. Solver precision (single or double), memory requirement, number of compute cores are specified as well to adjust the resource use for the computational need. For large, multi-million DoF models, partitioning of the problem is usually recommended across many compute nodes, these MPI options are accessed via the Job class too.
Although material or CAD files are automatically added as dependent files for submission, these can be manually adjusted as well, should you require supporting files along with an existing input deck.
The Job class allows the user to carry out parametric studies. Sweep parameters can be selected, and input distributions assigned to these. Execution of the individual simulations within a single job is automatically handled by our cloud infrastructure.
Finally, enquiring the status of a job and individual simulations within the job is possible via the Job class and once available, data can be downloaded.
The Account class supports the Job class and stores user credentials.
PostProcess class
Our main target with the post-processing class was to provide a solution where the user can process data even from multiple simulations without loops and do it in a way that pre-processing, such as windowing, Fourier transforms or interpolation is in the most straightforward fashion. Time and frequency domain plots, calculation of key performance indicators (KPIs, such as min, max, argmin, argmax, bandwidth, etc) are possible, and various access functions aid the user to process data even further.
Enjoy working with our toolbox and don’t hesitate to let us know what features you most want next!
