Many fields of science and engineering use numerical simulation to solve coupled partial differential equations, so there is no shortage of software to address that need. A wide variety of programs can be found in diverse working environments, from “do-it-yourself” function libraries to extensive “leave-the-driving-to-us” graphical user interfaces.
Most of those programs are specialized for a specific scientific field, such as fluid dynamics, mechanics, thermal analysis, or RF design. However, a select few are classified as "multiphysics solvers." Such programs attempt to bridge the gaps between the specialties by simplifying the process of coupling differential equations to produce cross-disciplinary models.
One of the more ambitious of these tools is Comsol Multiphysics. With its broad internal array of intuitive tools for drawing, meshing, material specification, finite-element analysis, post-processing, and graphical display, it has become one of the favorites of the multiphysics community.
The software is organized into a basic multiphysics core package and more than 25 add-on modules addressing the specific couplings, boundary conditions, and equations useful in individual scientific and engineering disciplines. It is a rare user that does not take advantage of one or more of these modules, though in principle the core package would be sufficient to carry out individual field capabilities with the application of sufficient personal ingenuity and labor.
The fifth version
In its latest V5.0 release, Comsol Multiphysics has also introduced something new to the modeling enterprise: the application builder, and its counterpart, the application server. The application builder allows the modeler to sweep away the detail-oriented tools that were used to produce a model and to fashion a more approachable application—an app—that is intuitive and easy to use.
The app may have a simple mouse-driven interface constructed with an assortment of buttons, lists, menus, graphics, and text to make its operation straightforward. It may be launched from within the Comsol Multiphysics program. But, importantly, it may also be lifted entirely from that feature-rich environment with the help of the Comsol application server. In the latter case, the app may be run as a stand-alone application, or as a web resource within a conventional browser.
The application builder itself is now an integral part of the Comsol Multiphysics modeling software, while the application server is offered separately at a small fraction of the cost of a corresponding Comsol Multiphysics floating network license with the same add-on modules (about 10% on a per-concurrent-user basis). With that in mind, the application server should be a very attractive method of providing colleagues or clients with a model that they may use independently without competing for the resources of the more expensive model-building tools.
Two questions present themselves: How will modelers use this new capability? How difficult is it to use? I can only speculate about the first question. Certainly, the apps will be attractive for users who shy away from models due to uneasiness or unfamiliarity with the full modeling environment of Comsol Multiphysics. But there are other scenarios as well. With the application builder, modeling results may be presented in the form of live, real-time examples rather than static summaries in charts and graphs. Equally, models may be constructed for use in lectures or demonstrations, provided that they run relatively quickly. Commercial users may offer models of their product’s performance, to be used in the place of data sheets or may produce licensable models as products in their own right.
In brief, the application builder is a new line of communication between the professional modeling expertise of the model builder, and the science and engineering expertise of model users.
How to build an app
I do not need to speculate about the complexity of creating an app, as it is easy enough to give it a try. I began with a functioning Comsol Multiphysics model that I wanted to turn into an app. It is possible to simply use one of the models from the example library that comes with the product, but instead I chose to use a simple three-dimensional model of the current flow and heating of a multi-pixel thick-film thermal print head such as might be used in a FAX machine and depicted in figure 1. Voltage may be applied to selected electrodes of the print head to heat corresponding portions of a resistive film, and the purpose of the model is to discover the final temperature distribution in the film.
Figure 1. The idealized print head used by the author in testing Comsol's application builder. CREDIT: William Vetterling
To implement the model as an app most quickly, I used a tool called the application wizard. The wizard starts with a Comsol model, and assembles lists of elements from it that are suitable for use as inputs and outputs, modeling operations, and graphics. It then allowed me to select from these lists the subset of properties that I want to incorporate into my app.
In this particular case, I might select as inputs the number of electrodes and their width; as operations, a command that constructs the geometry, and another that executes the model; as graphics, a graph showing the object, and another showing a 3D surface plot of the temperature. The detailed modeling choices relating to mesh construction, solver parameters, tolerances and material properties may be left hidden to the user-interface.
Figure 2. A screen shot of the app I built using the application wizard. CREDIT: William Vetterling
Having made these selections, I pressed "continue," and the result was a working app that has input or display boxes for the input/output data, pushbuttons for the actions, and display panels for the graphics. The app components, or widgets, are displayed on a canvas, and can be dragged with the mouse to suitable locations for an attractive interface. A handy "Test application" button allows me to launch the new app and test its features from within the design environment. Figure 2 shows a screenshot of the app I built from my model using the application wizard.
Full power ahead
The application wizard is quick and produces a user-friendly version of a model in just a few minutes, but it doesn’t exercise the full power of the application builder. If I want to build something a bit more impressive, an array of tools can help assemble more fully-featured apps.
For that purpose, the application builder has two sub-tools. The first is the form editor, which primarily generates the page layouts that comprise an app. Form editor offers a much wider selection of widgets and users specify sequences of actions associated with each of them.
The second sub-tool is the method editor, which is essentially a Java programming and debugging environment that allows users to combine the Comsol interface with Java programs and libraries in order to generate apps that break out of the wizard's “inputs/operations/outputs” regimen.
Form editor offers the usual complement of graphical user-interface widgets (such as buttons, check boxes, combo boxes, radio buttons, text boxes, sliders, and tables). It also offers a few that are especially useful for a modeling application, including a progress bar, a message log, an equation widget displaying formatted LaTeX equations, and a results table.
Forms may be grouped into a form collection, which may then be designated as the main form, to be shown whenever the app is initiated. The members of the collection may appear on the main form as selectable tabs, as items in a table, or as panes within a single window. In addition, the main form may be outfitted with pull-down menus or a toolbar-style menu.
The method editor also has capabilities related to modeling. As a Java programming environment it can, of course, implement Java code, classes, and libraries from any source. However, it can also interact with the Comsol model tree and the Comsol API (Application Programming Interface) in a number of useful ways. (The Comsol model tree is an outline of the operations carried out by the Comsol model, and represents a complete and detailed description of the model underlying the app.)
For example, there is a recording feature that allows users to turn on the recorder, carry out some operations in the model tree (such as creating a graph, or specifying a mesh), and then turn off the recorder to find the Java-equivalent code added to your Java method. Additionally, the package provides three tools known as model data access, model code and model expression.
Model data access allows users to inspect the model tree, select from the hundreds (or even thousands) of parameters that define the model, and make selections available for reading or altering their values. Model code allows users to select a node in the model tree and generate code corresponding to that node, or to change the model settings of that node. Model expression presents a list of all the expressions used as input or output arguments in the model. It also lists the built-in functions, operators and physical constants available in the model and generates the correct syntax for addressing them. Together, these tools make it unnecessary to delve into the Comsol Multiphysics Programming Reference Manual that fully documents the API.
Further embellishments
After attending a two-hour seminar on the basics of application builder, and reading the 200-page Introduction to Application Builder, I spent a day embellishing the wizard-generated app described above. The result was the app shown in figure 3. It has a toolbar at the top and has divided the tasks of geometry definition, model execution, and display of results into separate pages. The first form of the collection allows specification of the print head pixel count and dimensions, and then draws the print head. Unlike the simpler app, it not only constructs the geometry, but also resizes it to fit in the graphics window.
Figure 3. Apps built using application wizard can be embellished later with forms and other enhancements. CREDIT: William Vetterling
The second page of the app, which is shown in figure 3, has two functions. Clicking the selection box in the lower right produces a drawing of the geometry in the graphics window. This is a live drawing, and a mouse-click on any of the electrode boundaries results in the application or removal of a voltage on that boundary. Clicking on the Compute button carries out the meshing and solving operations and changes the graphics window to a false color representation of the simulated surface temperatures. During the solution, a progress-bar appears in the lower right to track progress.
On completion, the model sounds a chime and prepares several pages with further results. One page provides a 1D cut through the 2D surface temperature data to show the temperature profile through the centers of the pixels. Two others normalize the temperature data and apply the typical response curve of an indium antimonide detector, to simulate the image and profile as reported by the IR microscope. The three graphs were produced with a Java method that is initiated at the completion of the simulation, and the automatic code generation facilities of the method editor were used to discover the proper syntax for scaling, graphing and resizing the model results for presentation.
This is the distillation of my few hours with the application builder. Creating an easy-to-use interface is not an onerous task, and there is satisfaction, even for a skilled model builder, in seeing the clutter removed before setting about using a model productively. Technically speaking, it has been possible to add simplified user-interfaces like this to Comsol models in the past, considering that Comsol Multiphysics has for some time been able to export its models as Java or Matlab code containing calls to the Comsol API. Both Java and Matlab have facilities for GUI development. However, examples of such interfaces are not abundant, presumably because of the chore of mastering both the API and the GUI toolboxes.
Moreover, an application produced in this way still relies on the use of a Comsol Multiphysics installation to run, and so in most instances cannot be easily shared. The major contribution of the new tools is to integrate the development into a single tool, to simplify greatly the interaction with the API, and to provide a standalone server that is separate from the more expensive model-development tools. This change promises to make the user-interface a more natural and commonplace part of the model development process, and to engage a much wider audience in the use and appreciation of multiphysics models.
Bill Vetterling is a research fellow and manager of the image science laboratory at Zink Imaging in Billerica, Massachusetts.
