\title{\bf{\huge{
DRAFT *** DRAFT *** DRAFT \\
Users Manual for \\
BRL-CAD Graphics Editor \\
MGED
}}}
\author{
Keith A. Applin \\
Michael J. Muuss \\
Robert J. Reschly \\
{\em US Army Ballistic Research Laboratory} \\
{\em Aberdeen Proving Ground, MD} \\
\and
Alan Collier \\
{\em US Army Foreign Science and Technology Center} \\
{\em Charlottesville, VA} \\
\and
Mike Gigante \\
Ian Overend \\
{\em The Royal Melbourne Institute of Technology} \\
{\em Australia}
}

\date{6-October-1988}

\maketitle

\tableofcontents
\listoffigures

% ---------------------------------------------------------------------------

\chapter{INTRODUCTION}

Computer graphics is one of the fastest growing fields
in the computer industry.
Computer graphics has applications in many diverse areas, from electronic
games to medicine; from cartoons to the space industry.  Just
what is interactive computer graphics and why is it so versatile?
Human visual perception is quite keen and communicating with a
computer is generally faster and easier
with images, rather than with
numbers. Furthermore, by
having the computer continuously updating a display,
the display itself becomes the communications medium.
The user converses with the computer through the display using
devices such as light pens,
mice, data tablets, buttons, and
knobs.  The response of the computer is immediately reflected
on the display,
providing a fast communication channel between person and machine.
This technology is called interactive computer graphics.

As the Army's lead laboratory for vulnerability technology, the
Ballistic Research Laboratory (BRL) constantly performs
analyses for a wide variety of military systems.
Three dimensional computer models of the
physical characteristics of these systems
are vital to these studies.
Since the mid-1960's, BRL has used a solid modeling technique
called Combinatorial Solid Geometry (CSG or COMGEOM)
for representing these models.
The COMGEOM technique uses
Boolean logic operations to combine basic geometric
shapes or primitives to produce complex three-dimensional objects.
The COMGEOM geometric models are processed by
the Geometric Information
For Targets (GIFT)
\cite{gift1,gift2}
and LIBRT
\cite{solid-models}
for use in follow-on engineering analysis.

Geometric models are large collections
of numerical data which have traditionally
been created and edited manually, and analyzed in a batch environment.
The production and modification of geometric models has been a slow,
labor-intensive
process.
In 1980, BRL initiated an effort to improve the response
time of the geometric modeling process by applying interactive
computer graphics techniques.
As a result of this work, BRL
developed the Multi-device Graphics EDitor (MGED),
an interactive editor for solid models
based on the COMGEOM technique.
Using MGED, a designer can build, view, and modify model descriptions
interactively by manipulating the graphical representation,
receiving immediate visual feedback on a graphics display.
MGED replaces the manual method for the production
and modification of geometric models.

Before MGED was built,
existing packages were evaluated with respect to
their utility for the geometric modeling process.
Quite an exhaustive search of commercially available systems
was conducted and none were found which met
the BRL requirements.
A study was initiated to examine the feasibility of producing
the required capability in-house;
a preliminary version of MGED which
quite convincingly demonstrated the
feasibility of such an undertaking \cite{interactive-construction}.
It was then decided to develop MGED into a full production code.
Production MGED code has been used since January 1982 to
build models interactively at BRL.

This report is intended to serve as  a user manual
for the MGED program.
The process of viewing and editing a description using MGED
is covered in detail.  The internal data structure is also covered, as
it is an important part in the overall design.
All the commands will be discussed and a command summary table presented.
Also, a section will be devoted to the hardware interfaces for each
major class of workstations which MGED supports.

\section{Philosophy}

The role of CAD models at BRL differs somewhat from
that of CAD models being built in the automobile and aerospace industries,
resulting in some different design choices
being made in the BRL-CAD software.
Because BRL's main use for these models is to conduct detailed
performance and survivability analyses of large complex vehicles,
it is required that the model of an entire vehicle be completely contained
in a single database suitable for interrogation by the application codes.
This places especially heavy demands on the database software.
At the same time, these analysis codes require less detail
than would be required if NC machining were the primary goal.

At BRL, there are only a small number of primary designers responsible
for the design of a vehicle, and for the construction of the corresponding
solid model.  Together they decide upon and construct the
overall structure of the model,
then they perform the work of building substructures in parallel,
constantly combining intermediate results into the full model database.
Because of the need to produce rapid prototypes (often creating a full design
within a few weeks), there is no time for a separate integration stage;
subsystem integration must be an ongoing part of the design process.

Once an initial vehicle design is completed, there is usually the
need for exploring many alternatives.  Typically, between three and twelve
variations of each design need to be produced, analyzed, and optimized
before recommendations for the final design can be made.
Also, there is a constantly changing definition of performance;
new developments may necessitate rapidly re-evaluating
all the designs of the past several years for trouble spots.

The user interface is designed to be powerful and ``expert friendly'' rather
than foolproof for a novice to use.
However, it only takes about two days for new users to start doing useful
design work with MGED.
True proficiency comes with a few months practice.

Finally, it is vitally important that the software offer the same capabilities
and user interface across a wide variety of display and processor hardware.
Government procurement regulations make single-vendor solutions difficult.
The best way to combat this is with highly portable software.

\section{Displays Supported}

It is important for a CAD system to have a certain degree of independence
from any single display device in order to provide longevity of the
software and freedom from a single equipment supplier.
The MGED editor supports serial use of multiple displays by way of
an object-oriented programmatic
interface between the editor proper and the display-specific code.
All display-specific code for each type of hardware is isolated
in a separate {\em display manager} module.
High performance of the display manager was an important design goal.
Existing graphics libraries
were considered, but no well established standard existed with the necessary
performance and 3-dimensional constructs.
By having the display manager modules incorporated as a direct part of
the MGED editor, the high rates of display update necessary to deliver
true interactive response are possible, even when using CPUs of modest power.

An arbitrary number of
display managers may be included in a copy of MGED, allowing the user
to rapidly and conveniently move his editing session from display to display.
This is useful for switching between several displays, each of
which may have unique benefits:  one might have color capability,
and another might have depth cueing.
The {\bf release} command closes out MGED's use of the current
display, and does an implicit attach to the ``null'' display manager.
This can be useful to allow another user to briefly examine an image
on the same display hardware without having to lose the state of
the MGED editing session.  The {\bf attach} command is used to
attach to a new display via its appropriate display manager routines.
If another display is already attached, it is released first.
The null display manager also allows the MGED editor to be run from a normal
alphanumeric terminal with no graphic display at all.  This can be useful
when the only tasks at hand involve viewing or changing
database structures, or entering or adjusting geometry parameters
in numerical form.

Creation of a new display manager module in the ``{\bf C}'' language
\cite{c-prog-lang}
generally takes an experienced
programmer from one to three days.
The uniform interface to the display manager provides two levels
of interactive support.
The first level of display support includes
the Tektronix 4014, 4016, and compatible displays,
including the Teletype 5620 bit-mapped displays.
However, while storage-tube style display devices allow MGED to
deliver the correct functionality, they lack the
rate of screen refresh needed for productive interaction.
The second level of support, including real-time interaction,
is provided by
the Vector General 3300 displays,
the Megatek 7250 and 7255 displays,
the Raster Technologies Model One/180 display,
the Evans and Sutherland PS300 displays
with either serial, parallel, or Ethernet attachment,
the Sun workstations,
and the Silicon Graphics IRIS workstation family.

\section{Portability}

Today, the half-life of computer technology is
approximately two to three years.
To realize proper longevity of the modeling software, it needs to be written
in a portable language to allow the software to be moved readily from
processor to processor without requiring the modeling software or users
to change.
Then, when it is desirable to
take advantage of the constantly increasing
processor capabilities and similarly increasing memory capacity by replacing
the installed hardware base, there are a minimum of ancillary costs.
Also, it may be desirable to connect together processors from a variety
of vendors, with the workload judiciously allocated to
the types of hardware that best support the requirements of each particular
application program.
This distribution of processing when coupled with the fact that
users are spread out over multiple locations makes networking a vital
ingredient as well.

BRL's strategy for achieving this high level of portability was to target
all the software for the UNIX operating system,
\cite{unix-ts-sys},
with all the software written in the ``{\bf C}''
programming language \cite{c-prog-lang}.
The entire BRL-CAD Package, including the MGED editor
is currently running on all UNIX machines at BRL,
under several versions of the UNIX operating system, including
Berkeley 4.3 BSD UNIX, Berkeley 4.2 BSD UNIX, and AT\&T System V UNIX.

The list of manufacturers and models of CPUs that support the UNIX
operating system \cite{modern-tools-hi-res}
is much too lengthy to include here.  However, BRL
has experience using this software on
DEC VAX 11/750, 11/780, 11/785 processors,
Gould PN6000 and PN9000 processors,
Alliant FX/8 and FX/80 processors (including systems with eight CPUs),
Silicon Graphics IRIS 2400, 2400 Turbo, 3030, 4-D, and 4-D/GT workstations,
the Cray X-MP, the Cray-2,
and the ill-fated Denelcor HEP H-1000 parallel supercomputer.

\section{Object-Oriented Design}

The central editor code has four sets of object-oriented interfaces
to various subsystems, including database access, geometry processing,
display management, and command parser/human interface.
In each case, a common interface has been defined for the set of
functions that implement the subsystem;
multiple instances of these function sets can exist.
The routines in each instance of a subsystem are completely independent
of all the routines in other functions sets, making it easy to add new
instances of the subsystem.  A new type of primitive geometry,
a new display manager, a new database interface, or a new command
processor can each be added simply by writing all the routines
to implement a new subsystem.
This approach greatly simplifies software maintenance, and allows
different groups to have responsibility for the
creation and enhancement of features within each of the subsystems.

\chapter{THE COMBINATORIAL GEOMETRY METHODOLOGY}

\section{Background}

Since the MGED system is presently based on the COMGEOM solid modeling
technique, a brief overview of the COMGEOM technique is required
to effectively use MGED.
For more detailed information on the COMGEOM technique see
\cite{gift1,gift2}.

\begin{figure}[tb]
\begin{tabular}{l l}
Symbol & Name \\
\\
ARS	& Arbitrary Triangular Surfaced Polyhedron \\
ARB	& Arbitrary Convex Polyhedron \\
ELLG	& General Ellipsoid \\
POLY	& Polygonal Faceted Solid \\
SPL	& Non-Uniform Rational B-Spline (NURB) \\
TGC	& Truncated General Cone \\
TOR	& Torus \\
HALF	& Half Space (Plane)
\end{tabular}
\caption{Basic Solid Types \label{list-of-basic-solids} }
\end{figure}
\begin{figure}[tb]
\begin{tabular}{l l}
Symbol & Name \\
\\
RPP	& Rectangular Parallelepiped \\
BOX	& Box \\
RAW	& Right Angle Wedge \\
SPH	& Sphere \\
RCC	& Right Circular Cylinder \\
REC	& Right Elliptical Cylinder \\
TRC	& Truncated Right Cylinder \\
TEC	& Truncated Elliptical Cylinder \\
\end{tabular}
\caption{Special-Case Solid Types \label{list-of-special-case-solids} }
\end{figure}
The COMGEOM technique utilizes two basic entities - a solid and a region.
A solid is defined as one of fifteen basic geometric shapes or
primitives.  Figure \ref{list-of-basic-solids} lists the
basic solid types, and Figure \ref{list-of-special-case-solids}
lists special cases of the basic solid types for which support exists.
The individual parameters of each solid define the solid's
location, size, and orientation.  A region is a combination of
one or more solids and is defined as the volume occupied
by the resulting combination of solids.
Solids are combined into regions using any of three logic
operations: union (OR), intersection (+), or difference (-).
The union of two solids is defined as the volume in either
of the solids.
The difference of two solids is defined as the volume of the first
solid minus the volume of the second solid.
The intersection of two solids is defined as the volume
common to both solids.
%%% XXX Figure 1 presents a graphical representation of these operations.

Any number of solids may be combined to produce a region.
As far as the COMGEOM technique is concerned, only a region can
represent an actual component of the model.
Regions are homogeneous;  they are composed of a single material.
Each region represents a single object in the model;
the solids are only building blocks which are combined to
define the {\em shape} of the regions.
Since regions represent the components of the model, they
are further identified by code numbers.
These code numbers either identify the region as
a model component (nonzero item code)
or as air (nonzero air code).
Any volume not defined as a region is assumed to be ``universal air'' and
is given an air code of ``01''.
If it is necessary to distinguish between universal ``01'' air and any
other kind of air, then that volume must be defined as a region
and given an air code other than ``01''.
Normally, regions cannot occupy the same volume (overlap),
but regions identified with
air codes can overlap with any region identified as a component
(i.e. one that has a nonzero item code).
Regions identified with different air codes, however, can not overlap.

\section{Directed Acyclic Graph and Database Details}

One of the critical aspects of a graphics software package
is its internal data structure.
Since geometric models often result
in very large volumes of data being generated,
the importance of the data structure here is emphasized.
Thus it is felt that a brief introduction to the
organization of the MGED database is
important for all users.

The database is stored as a single,
binary, direct-access
UNIX file for efficiency and cohesion,
with fixed length records called database {\em granules}.
Each object occupies one or more granules of storage.
The user sees and manipulates the directed acyclic graphs
like UNIX paths (e.g., car/chassis/door),
but in a global namespace.
There can be many independent or semi-independent
directed acyclic graphs within the same database,
each defining different models.
The figure also makes heavy use of the {\em instancing} capability.
As mentioned earlier, the
{\em leaves} of the graph are the primitive solids.

Commands exist to import sub-trees from other databases and libraries,
and to export sub-trees to other databases.
Also, converters exist to dump databases in printable form for
non-binary interchange.

\section{Model Building Philosophy}

The power of a full directed acyclic graph structure for representing
the organization of the database gives a designer a great deal of
flexibility in structuring a model.
In order to prevent chaos, most designers at BRL choose to
design the overall structure of their model in a top-down manner,
selecting meaningful names for the major structures and sub-structures
within the model.
Actual construction of the details of the
model generally proceeds in a bottom-up
manner, where each sub-system is fabricated from component primitives.

The first sub-systems to be constructed are the chassis and skin of the
vehicle, after which a set of analyses are run to validate the geometry,
checking for unintentional gaps in the skin or for solids which overlap.
The second stage of model construction is to build the features of the
main compartments of the vehicle.  If necessary for the analysis
codes that will be used, the different types of air compartments within
the model also need to be described.
The final stage of model construction is to build the internal
objects to the desired level of detail.
This might include modeling engines, transmissions, radios,
people, seats, etc.
In this stage of modeling, the experienced designer will draw heavily on the
parts-bin of model components and on pieces extracted from earlier
models, modifying those existing structures to meet his particular
requirements.

Throughout the model building process it is important for the model builder
to choose part names carefully, as the MGED database currently has a
global name space, with individual node names limited to 16 characters.
In addition, BRL has defined conventions for naming the elements in the
top three levels of database structure,
allowing people to
easily navigate within models prepared at
different times by different designers.
This naming convention
facilitates the integration of design changes into existing models.

\chapter{THE BASIC EDITING PROCESS}

\section{Interaction Forms}

Textual and numeric interaction with the MGED editor is the most
precise editing paradigm because it allows exact
manipulation of known configurations.
This works well when the user is designing the model
from an existing drawing, or when all dimensions are known (or are computable)
in advance.

The use of a
tablet or mouse, knob-box or dial-box, buttons, and a joystick
are all simultaneously supported by MGED for analog inputs.
Direct graphic interaction via a ``point-push-pull'' editing paradigm
tends to be better for
prototyping, developing arbitrary geometry, and fitting
together poorly specified configurations.
Having both types of interaction capability available at all times
allows the user to select the style of interaction that best
meets his immediate requirements.

\section{The Faceplate}

\begin{figure}
\centering \includegraphics{faceplate.ps}
\caption{The MGED Editor Faceplate.}
\label{faceplate}
\end{figure}

\begin{figure}
\centering \includegraphics{buttonmenu.ps}
\caption{The Pop-Up Button Menu.}
\label{buttonmenu}
\end{figure}

When the MGED program has a display device attached, it
displays a border around the region of the screen being used
along with some ancillary status information.  Together, this
information is termed the editor ``faceplate''.
See Figure \ref{faceplate}.
In the upper left corner of the display is a small enclosed area
which is used to display the current editor state;
this is discussed further in the Editor States section, below.

Underneath the state display is a zone in which three ``pop-up'' menus
may appear.
The top menu is termed the ``button menu,'' as it
contains menu items which duplicate many of the functions assigned to
the button box.
Having these frequently used
functions available on a pop-up menu
can greatly decrease the number of times that the user needs to remove
his hand from the pointing device (either mouse or tablet puck)
to reach for the buttons.
An example of the faceplate and first level menu is shown in
Figure \ref{buttonmenu}.
The second menu is used primarily for the various editing states,
at which time it contains all the editing operations which are generic
across all objects (scaling, rotation, and translation).
The third menu contains selections for object-specific editing operations.
The choices on these menus are detailed below.

It is important to note that while some display hardware that MGED runs on
has inherent support for pop-up menus included, MGED does not
presently take advantage of that support, preferring to depend
on the portable menu system within MGED instead.
It is not clear whether the slight increase in functionality that might
accrue from using display-specific menu capabilities would offset the
slight nuisance of a non-uniform user interface.

Running across the entire bottom of the faceplate is a thin rectangular
display area which holds two lines of text.
The first line always contains a numeric display of the model-space
coordinates of the center of the view and the current size of
the viewing cube, both in the currently selected editing units.
The first line also contains the current rotation rates.
The second line has several uses, depending on editor mode.
Normally it displays the formal name of the database that is being
edited, but in various editing states this second line will instead
contain certain path selection information.
When the angle/distance cursor function is activated, the second
line will be used to display the current settings of the cursor.

It is important to mention that while the database records all
data in terms of the fixed base unit of millimeters, all numeric interaction between
the user and the editor are in terms of user-selected display [or local] units.
The user may select from millimeters, centimeters, meters, inches, and
feet, and the currently active display units are noted in the first
display line.

The concept of the ``viewing cube'' is an important one.
Objects drawn on the screen are clipped in X, Y, and Z, to the size
indicated on the first status line.
This feature allows extraneous wireframes which are positioned within view
in X and Y, but quite far away in the Z direction to not be seen,
keeping the display free from irrelevant objects when zooming in.
Some display managers can selectively enable and disable Z axis clipping
as a viewing aid.

\section{The Screen Coordinate System}

\begin{figure}
\centering \includegraphics{coord-axes.ps}
\caption{The Screen Coordinate System.}
\label{coord-axes}
\end{figure}

The MGED editor uses the standard right-handed
screen coordinate system,
as shown in Figure \ref{coord-axes}.
The Z axis is perpendicular to the screen and the positive Z direction is
out of the screen.  The directions of positive (+) and negative (-) axis
rotations are also indicated.  For these rotations, the ``Right
Hand Rule'' applies:  Point the thumb of the right hand along the direction
of +X axis and the other fingers will describe the sense of positive
rotation.

\section{Changing the View}

At any time in an editing session, the user may add one or more
subtrees to the active model space.  If the viewing cube is
suitably positioned, the newly added subtrees are drawn on the display.
(The ``reset'' function can always be activated to get the entire active
model space into view).
The normal mode of operation is for users to work with wireframe
displays of the unevaluated primitive solids.  These wireframes can be
created from the database very rapidly.
\begin{figure}
\centering \includegraphics{crod.ps}
\caption{An Engine Connecting Rod.}
\label{crod}
\end{figure}

\begin{figure}
\centering \includegraphics{crod-close.ps}
\caption{Close-Up Connecting Rod, Showing Z-clipping.}
\label{crod-close}
\end{figure}

On demand, the user can request the calculation of
approximate boundary wireframes that account for
all of the boolean operations specified along the arcs of the
directed acyclic graph in the database.
This is a somewhat time consuming process, so it is not used
by default, but it is quite reasonable to use whenever the
design has reached a plateau.
Note that these boundary wireframes are not stored in the database,
and are generally used as a visualization aid for the designer.
Figure \ref{crod} shows an engine connecting rod.
On the left side is the wireframe of the unevaluated primitives
that the part is modeled with, and on the right side is the approximate
boundary wireframe that results from evaluating the boolean expressions.

Also, at any time the user can cause any part of the active model space
to be dropped from view.
This is most useful when joining two complicated subsystems
together;  the first would be called up into the active model space,
manipulated until ready, and then the second subsystem would also be
called up as well.  When any necessary adjustments had been made,
perhaps to eliminate overlaps or to change positioning tolerances,
one of the subassemblies could be dropped from view,
and editing could proceed.

The position, size, and orientation of the viewing cube can be
arbitrarily changed during an editing session.
The simplest way to change the view is by selecting one of nine
built in preset views, which can be accomplished by a simple keyboard
command, or by way of a button press or first level menu selection.
The view can be rotated and translated to any arbitrary position.
The user is given the ability to execute a {\bf save view} button/menu
function that attaches the current view to a {\bf restore view} button/menu
function.

The rate of rotation around each of the X, Y, and Z axes
can be selected by knob, joystick, or keyboard command.
Because the rotation is specified as a rate, the view
will continue to rotate about the view center until the rotation
rate is returned to zero.
(A future version of MGED will permit selection of rate or value
operation of the knobs).
Similarly, the zoom rate (in or out) can be set by keyboard
command or by rotating a control dial.
Also, displays with three or more mouse buttons have binary (2x) zoom
functions assigned to two of the buttons.
Finally, it is possible to set a slew rate to translate the view
center along any axis in the current viewing space, selectable
either by keyboard command or control dial.
In VIEW state, the main mouse button translates the
view center;  the button is defined to cause the indicated point to become
the center of the view.

The assignment of zoom and slew functions to the mouse buttons tends to
make wandering around in a large model very straightforward.
The user uses the binary zoom-out button to get an overall view, then
moves the new area for inspection to the center of the view and uses
the binary zoom-in button to obtain a ``close up'' view.
Figure \ref{crod-close}
shows such a close up view of the engine connecting rod.
Notice how the wireframe is clipped in the Z viewing direction
to fit within the viewing cube.

\section{Model Navigation}

In order to assist the user in creating and manipulating a complicated
hierarchical model structure, there is a whole family of editor commands
for examining and searching the database.
In addition, on all keyboard commands, UNIX-style regular-expression
pattern matching, such as ``*axle*'' or ``wheel[abcd]'', can be used.
The simplest editor command ({\bf t}) prints a table of contents, or directory,
of the node names used in the model.  If no parameters are specified,
all names in the model are printed,
otherwise only those specified are printed.
The names of solids are printed unadorned, while the names of combination
(non-terminal) nodes are printed with a slash (``/'') appended to them.

If the user is interested in obtaining detailed information about the
contents of a node, the list ({\bf l}) command will provide it.
For combination (non-terminal) nodes, the information about all departing
arcs is printed, including the names of the nodes referenced, the boolean
expressions being used, and an indication of any translations and rotations
being applied.
For leaf nodes, the primitive solid-specific ``describe yourself''
function is invoked, which provides a formatted display of the parameters
of that solid.

The {\bf tops} command is used to find the names of all nodes which are
not referenced by any non-terminal nodes;  such nodes are either
unattached leaf nodes, or tree tops.
To help visualize the tree structure of the database,
the {\bf tree} command exists to
print an approximate representation of the database subtree below the
named nodes.
The {\bf find} command can be used to find the names of all non-terminal
nodes which reference the indicated node name(s).  This can be very helpful
when trying to decide how to modify an existing model.
A related command ({\bf paths}) finds the full tree path specifications
which contain a specified graph fragment, such as ``car/axle/wheel''.
In addition to these commands, several more commands exist
to support specialized types of searching through the model database.

\section{Editor States}

The MGED editor operates in one of six states.
Either of the two PICK states can be entered by button press,
menu selection, or keyboard command.  The selection of the desired
object can be made either by using {\em illuminate mode}, or by
keyboard entry of the name of the object.

Illuminate mode is arranged such that if there are {\bf n} objects visible on
the screen, then the screen is divided into {\bf n} horizontal bands.
By moving the cursor (via mouse or tablet) up and down through these bands,
the user will cause each solid in turn to be highlighted on the screen,
with the solid's name displayed in the faceplate.
The center mouse button is pressed when the desired solid is located, causing
a transition to the next state (Object Path, or Solid Edit).

Illuminate mode offers significant advantages over more conventional pointing
methods when the desired object lies in a densely populated region of the
screen.  In such cases, pointing methods have a high chance of making an
incorrect selection.
However, in sparsely populated regions of the screen, a pointing paradigm
would be more convenient, and future versions of MGED will support this.

\section{Model Units}

All databases start with an ``ident'' record which contains
a title string that identifies the model, the
current local units (e.g., mm, cm or inches) of the model,
and a database version identification number.
As noted, all numerical information
in the database is stored in the fixed base
unit of millimeters,
and all work (input and output) is done in a user-selected local unit.
The user can change his local unit at any time
by using the {\bf units} command.
This way of handling units was selected to free the user from worrying
about units conversion when components are drawn from the ``parts bin''.