A software architecture is a set of concepts, methods, rules and standards used to organize a software system and make things work together. Developing an architecture for design involves making decisions about what constitutes design and what view of the design process the system will adopt. Abstracting the architecture into the right set of domains is critical to achieving flexibility within and consistency between domains.

We have chosen to view the design process from the standpoint of what we believe to be the “reality” in electromagnetics research: individual or small group R&D “projects”. This implies the need for multiple design tools (many of which are legacy codes) applied to different aspects of and/or regions of a single “device” which may be simple or a complex amalgam of elements. In this approach, to be effective, design tools must be driven by a single geometry. In addition, common user interface methods for the various tools are highly desirable. These considerations have to be coupled with the need, inherent in R&D, for flexibility and extensibility of tools without requiring the user to become an expert programmer.

The Field Marshal simulation environment addresses these issues in the following way. The simulation process is broken roughly into the domains shown below. These domains group typical user activities in the simulation process and provide logical transition points for connection to legacy tools. Within each of these domains, there are “components” that implement Field Marshal methods. This “abstraction” permits FM to provide a reasonably consistent interface to the user across a wide range of simulation tools.

• Parameter Entry

• Geometry Entry

• Parameter-Geometry Connection

• Parameter and Geometry Translation

• Data Management

• Graphics and Visualization

There are two keys to making this abstraction work, the Generic Variable Template (GVT) and the CutBox. The GVT is a formatted text file that “describes” a tool from the standpoint of its input parameters and approach to geometry. The GVT is used to drive the FM Common User Interface and connect parameters to geometry. Although initial creation of a GVT should be done by someone intimately familiar with the tool, there is considerable flexibility here in the overall level of connection between the tool and the FM environment. Equally important, there is ample opportunity to specialize the tool interface for specific tasks. All of this can be accomplished without altering the tool in any way.

Each tool within the FM environment will have an associated text file, e.g. <toolname>.GVT, describing its input requirements. For specific projects the user is free to edit a copy of a tool’s GVT to make the tool more specific and more efficient for that project. Some of the information contained in the GVT is listed below.

• Visible variable names (for user, long & provides cues)

• Internal variable names (tool)

• Global (project) database names

• Visible units (for user)

• Internal units (tool)

• Data type in tool (i.e. real, integer, character, etc.)

• Input required or optional (Y/N or T/F option)

• Default value

• Upper/lower limits

• Read from project global data (Y/N or T/F option)

• Write to project global data (Y/N or T/F option)

• CUI display directives

  • Group membership (i.e. which index card)

  • Display type (i.e. toggle, button, box, slide, etc.)

  • Show/Hide variable (in the CUI)

  • Dependencies (i.e. only display when certain option(s) selected)

• Output translation directives

  • Output group

  • Output type

    • Legacy (formatted, list directed, namelist, etc.)

    • Wrapped

    • Numarray

The second key element, the CutBox, provides the link between geometry, tools and parameters. A CutBox is simply a “tagged” rectangular region in a project’s geometry. The user specifies the region as a CutBox and then links that region with a specific tool and set of parameters. When a CutBox is “activated” a sub-geometry is created by “trimming” the geometry outside the CutBox rectangular region. The associated tool GVT is then loaded into the Common User Interface for parameter entry. This enables multiple tools to be applied to the same geometry without interference. It also permits the same tool to be applied to different regions of a geometry without input parameters “colliding”.

When a tool is attached to a CutBox in a specific project, a tool folder is created within a CutBox folder. A copy of the generic variable template associated with that tool is copied into the new tool folder along with other tool files. This GVT copy may be specialized by the user for that specific project.

There are various other issues that are handled at the environment level. For example, on startup of the FM environment, the user is presented with a project management dialog window. This allows the user to enter a specific project, duplicate a project, delete a project or create an archive of a project. When a project is created, a folder (directory) with the project name is created in a user-selected location. The project’s name, location and other data are entered into a project database kept in the Field Marshal directory. In the new project folder, empty global project data and geometry files are created along with other “housekeeping” files and folders.