Starting in 1976, Defence Research Establishment Atlantic (DREA) began to develop a finite element code called MAVART, which is an acronym for Model for the Analysis of the Vibrations And Radiation of Transducers. The main purpose of MAVART is to analyze the performance of piezoelectric underwater acoustic transducers, like hydrophones and sonar projectors. The first version of the code had an axisymmetric capability only but it played an important role in DREA's development of a number of sonar projectors over the last 20 years, including the free flooding ring, ringshell, resonant pipe and barrel stave projector (BSP). The BSP violates the symmetry assumption such that a fully 3D model is needed to predict its performance, and this led to development of MAVART3D, over the period 1991-96.During the 1980's DREA developed model generation tools for MAVART, written in Fortran for mainframes and Tektronix graphics terminals. These tools could not readily be extended to 3D. The solution adopted was to lease a commercial off the shelf modeller, PATRAN , which ran on Silicon Graphics workstations. Translators had to be written to interface PATRAN with MAVART. While PATRAN met our requirements, it tied us to a limited range of expensive computer platforms, just when it was becoming apparent that MAVART could run effectively on the increasingly powerful personal computers. There was no low cost (even if that meant reduced capability) way to use PATRAN, i.e., you couldn't use it on a PC or laptop, it was high-end workstation or nothing. While this had little impact on DREA's in-house work, it inhibited transferring MAVART3D to industry, where modest computing resources are the norm. This provided the incentive to develop an affordable modeller for MAVART3D, because without it, the code would probably never leave the lab. After reviewing the features of a number of modellers a wish list for the bare essentials was drawn up.
Parametric modelling quickly rose to the top of the list. Parametric modelling means that the part dimensions, finite element meshing instructions, boundary conditions, etc., can be specified by parameters in a file of commands, the file can be processed by a command interpreter and new models built by the computer with minimal user intervention. Modellers that are purely mouse-driven, or WYSIWYG (what you see is what you get) in style, are fine for making a single model of a given design. However they are next to useless when a new design is being optimized and numerous modifications are required. With a WYSIWYG modeller, to make a change of shape you often have to go back to the beginning and start clicking again. A hybrid approach is used by some modellers where the model can be built with mouse clicks, but in the background user input is converted into commands which are logged in a session file. This file is all that is needed to be stored, since the complete model can be generated from it, and it is usually tiny in size compared to the finite element model. With some computer operating systems, a shell script can instruct the modeller to process a session file into a finite element model, do the translation, finite element analysis, postprocessing, and return a perfomance measure that can guide the next edit of the session file. A high-end system like Pro/ENGINEER  can do all this from within the application.
After getting comfortable working with session files one realizes that interactivity is not essential during the process of creating simple models, such as are needed for sonar transducer design. Working from a hand-drawn sketch with occasional plotting of the preliminary stages of the model can be quite efficent. Truly interactive graphics, with live rotations and animations are most useful when debugging the model, and showing off results to the boss or clients.
With these considerations, the wish list for a 3D modeller became:
1. parametric modelling
2. command language driven - with GUI to be added later if affordable
3. graphic capable, but real-time not essential
4. complex variables built-in
5. portable - should run on anything - MAC, PC, UNIX, ALPHA...
6. all data files ASCII text only, e-mailable
7. easy to maintain and modify
8. uses standard file types (e.g., Postscript) for graphics.
With these goals established, the next step was to identify a suitable software development environment. After our first look at it in one of Nancy Blachman's courses, Mathematica  was the obvious choice. The biggest unknown was whether the number crunching performance would suffice and the only way to check this was to prototype. Mathematica is a great prototyper, but how far beyond prototyping can it be driven? Finite element modelling is definitely getting into the realm of serious number crunching, and therefore an interesting test of Mathematica's capabilities. Our prototype finite element modelling package has the working title ModelMaker.
The design of the package is described in Section 2. In particular, Section 2.1 introduces points, and developes the database used to store them. This same database structure is used for all the other entities: curves, surfaces, solids, node types, element types, nodes, elements and materials, that are presented in subsequent parts of Section 2. Examples which illustrate possible applications are shown in Section 3. Comments on the way ahead for ModelMaker and conclusions are given in Sections 4 and 5.