Designing Easy To Use Simulation and Technical Software
Keywords: FEATool, multiphysics, computer simulation, software
architecture, software design, finite element analysis, FEM
The last two decades have seen an exponential growth in the use and development of numerical models for simulation of physical phenomena such as fluid flows, heat transfer, and structural stresses. Algorithms and software codes have grown in numbers and capabilities as the computational power of computers has increased.
Today, an industrial engineer can literally have both the computational capacity, and software to realize very complex simulations at their fingertips. Unfortunately it is often still as difficult to grasp and understand many software codes today as it was decades ago. In order to be able to trust and use the results from these software codes in applications involving our health and safety, such as the design of medical equipment, vehicles, and buildings, it would be more desirable if the codes would be open source, easier to use, understand, and validate.
Computer simulation software typically come in two distinct flavors. One the one hand commercial software packages which are designed by and for experts, and thus are very complex and complicated to use even with graphical user interfaces (GUIs). On the other academic codes which, no matter how computationally brilliant, require a significant commitment in time and effort to even set up, compile, and get running.
Some alternatives are presented here, borrowing on concepts from FEATool Multiphysics [1], a simulation Matlab and Octave Finite Element (FEM) simulation toolbox which has specifically been designed to be as easy to use as possible, both with respect to GUI and command line usage, as well as user customizability and extensibility.
The inspiration for the design concept comes from several sources but the main implementation models it aspires to follow are Sketchpad [2], Smalltalk [3] and, Emacs [4], where it is easy for a non-expert end user to inspect, customize, and modify every aspect of the software.
The overall goal of the FEATool design is then that is should be so easy to use that ideally no documentation is necessary. Both the GUI and command line interface (CLI) should be easily discoverable for all but the most advanced features. The starting point for designing the software suite can thus be summarized with following design criteria
- Be as easy to use as possible
- Be flexible, customizable, and extensible
- Have sufficient performance
with extensible meaning to allow for user extensions and modifications.
Programming Language
With usability in mind and with the goal of giving as many users as possible a chance to themselves both understand and also to modify the open source code it is natural to choose an interpreted non-compiled language with an easy syntax. In this case the choice was made in favor of the Matlab m-script language. The benefits aside from the non-compiled nature are easy syntax, good array and matrix handling, built-in support for graphics, visualization, and GUI functionality. Moreover, GNU Octave which is freely available and is currently fully compatible with Matlab, even with full GUI support.
Implementation Philosophy
It goes without saying that good standard programming practices should be followed with emphasis on making the code base modular and as simple as possible (geometry and grid generation modules should for example be able to work fine just by themselves, both on the command line and with a GUI). A natural mix of object oriented and procedural concepts will be necessary to keep the performance acceptable due to the language interpreter.
To connect the command line and graphical user interface objects a Smalltalk model is used. This means that if for example a point or edge is moved on a geometry or grid object in the GUI, then the underlying handle object will be modified accordingly. And in reverse a change on the command line will instantly update the GUI. In this way it will be very intuitive to work both with the command line and also the GUI.
Command Line Usage
This is an example of the current minimum FEATool syntax for defining and solving a Poisson equation on a circle on the command line
fea.geom.objects = { gobj_circle( [0 0], 1, ‘C1’ ) }
fea.sdim = { ‘x’ ‘y’ }
fea.grid = gridgen( fea.geom, ‘hmax’, 0.1 )fea.phys.poi.dvar = {‘u’}
fea.phys.poi.sfun = {‘sflag1’}
fea.phys.poi.eqn.seqn = ‘-( ux_x + uy_y ) = 1’
fea.phys.poi.eqn.coef = {}
fea.phys.poi.bdr.sel = 1
fea.phys.poi.bdr.coef{5} = {1}
fea.phys.poi.bdr.coef{7} = {0}fea = parsephys( fea )
fea = parseprob( fea )
fea.sol.u = solvestat( fea )
postplot( fea, ‘surfexpr’, ‘u’ )
Although it is only 14 lines of code, and much more compact and understandable than most other simulation software, it is still not as user friendly and discoverable as it could be.
Therefore, a new syntax and data structure is proposed for even more convenience on the command line. The involved data structures are hidden in persistent memory to allow very simple function call syntax, and together with logical function naming conventions, this enables users to easily find and remember descriptive commands such as
add_circle( [0 0], 1, ‘C1’ )
generate_grid( 0.1 )
add_equation( ‘-( ux_x + uy_y ) = 1’ )
add_boundary_condition( ‘u = 0’ )
solve_system( 1 )
plot_expression( ‘u’ )Also note that the syntax for specifying equations and boundary conditions is very close to how it is written on paper. Moreover, to get help and information about a function or command it should be sufficient to simply type the command without any in or output arguments (which in addition to the help text can also print the current state of the problem definition, such as currently defined equations and coefficients). This help system together with tab completion and good function naming conventions makes commands both easily discoverable, and also easy to get the syntax.
Graphical User Interface
Today a GUI is a necessity for making software easier to use. In the case of FEATool the aim is not to clutter the GUI with advanced features and non-relevant selections, but limit the visible choices to the current task, and optionally allow the user to select more advanced options through extended menus.
Three GUI `layers` are suggested, the first showing simply the physics modes and materials chosen (for example fluid dynamics with water). The second layer opens up the equation parser so that the user can edit the underlying partial differential equations, or even enter their own custom systems of equations. The final layer opens up very advanced options for expert users such as choice of finite element shape functions, and solver tuning parameters.
Moreover, the GUI is designed around the command line user functions. In this way for every command that is given in the GUI there is also corresponding CLI command, and thus the whole modeling process can be recorded and saved as a script file. This simulation model script file can later be modified, played back, and also be used to learn the scripting language from.
Extensibility
Modeled mostly after the Emacs editor, extensibility here means that the software should be designed so that it should be possible for the end user to go in and change or even completely substitute subroutines and functions.
The GUI should also allow for easy modification by allowing users to control which function calls are made when calling for example grid generation, solvers, or postprocessing subroutines.
High Performance Computing
As can be surmised, the goal of FEATool is not to be the fastest or first Exaflop scale code. This would not be possible with the choices made to favor usability. However, the solution here will be to allow interfacing with external software. The users will themselves be able to write small functions, callable from both the command line and GUI, that transfers grid and problem specification to an external tool, and reads in the results after simulations have been finished. In this way it is sufficient to aim for `good enough` performance in the internal solver, leaving large scale simulations to external specialized solvers.
References
[1] An Easy to Use Octave and Matlab Multiphysics FEM Finite Element Analysis Toolbox, Precise Simulation Limited, Hong Kong, 2013–2017.
[2] I. E. Sutherland. Sketchpad: A Man-Machine Graphical Communication System, Garland Publishers, New York, 1980.
[3] A. Kay, D. Ingalls, A. Goldberg. Smalltalk-80 The Language, Addison Wesley, 1989.
[4] R. Stallman. EMACS: The Extensible, Customizable, Self-Documenting, Display Editor, MIT AI Lab, AI Memo 519a, 1981.
