\documentclass[12pt]{article}
\usepackage{verbatim}
\usepackage{amssymb,amsmath}
\usepackage{amsthm}
\usepackage{graphicx}
\usepackage{epsfig}
\begin{comment}
\setlength{\textwidth}{6.50in}
\setlength{\oddsidemargin}{0in}
\setlength{\evensidemargin}{0in}
\setlength{\textheight}{8.5in}
\setlength{\topmargin}{-.25in}
\end{comment}
%\newtheorem{theorem}{Theorem}
\newtheorem{corollary}{Corollary}[section]
\newtheorem{lemma}[corollary]{Lemma}
\newtheorem{proposition}[corollary]{Proposition}
\newtheorem{theorem}[corollary]{Theorem}
%\newtheorem{conjecture}[corollary]{Conjecture}
\newcommand{\Prob} {{\bf P}}
\newcommand{\Z}{{\mathbb Z}}
\newcommand{\E}{{\bf E}}
\newcommand{\Es}{{\rm Es}}
\newcommand{\Cp}{{\rm cap}}
\newcommand{\R}{{\mathbb{R}}}
\newcommand{\C}{{\mathbb C}}
\newcommand{\rad}{{\rm rad}}
\newcommand{\hdim}{{\rm dim}_h}
\newcommand{\bound}{\partial_O}
\newcommand{\dist}{{\rm dist}}
\newcommand{\x}{{\bf x}}
\newcommand{\y}{{\bf y}}
\newcommand{\sphere}{{\cal S}}
\newcommand{\Var}{{\rm Var}}
\newcommand{\Q}{{\bf Q}}
\newcommand{\add}{+}
\newcommand{\bdim}{{\rm dim}_b}
\newcommand{\lf}{\lfloor}
\newcommand{\rf}{\rfloor}

\newcommand{\be}{\begin{equation}}
\newcommand{\ee}{\end{equation}}
\newcommand{\bea}{\begin{eqnarray}}
\newcommand{\eea}{\end{eqnarray}}
\newcommand{\beann}{\begin{eqnarray*}}
\newcommand{\eeann}{\end{eqnarray*}}

\def\reff#1{(\ref{#1})}

\def \dHalf  {{\cal H}}
\def \dhulls {{\cal A}}
\def \dhcap {{\rm dhcap}}
\def \Im {{\rm Im}}
\def \Re {{\rm Re}}
\def \p {\partial}
\def \edges {{\cal E}}
\def \Half {{\mathbb H}}
\def \reals {{\mathbb R}}
\def \interior {\rm int}
\def \LEW{LEW}
\def \sledim{\hat d}
\def \Disk {{\mathbb D}}
\def \Square {{\cal S}}
\def \diam {{\rm diam}}
\def \state {{\cal X}}
\def \eset {\emptyset}

\def \saws {{\cal R}}
\def \paths {{\cal K}}
\def \loop {{\cal L}}
\def \um  {{\bar m}}
\def \soup {{\cal C}}
\def \tree {{\cal T}}
\def \sgn {{\rm sgn}}
\def \looper {{\cal J}}
\def \strip{{\cal S}}

\def \scaleexp{{\rho}}

\def \energy {{\cal E}}
\def \hcap {{\rm hcap}}
\def \rect{{\cal R}}
\def \distsub {{\Upsilon}}
\def \distsubtwo {{\Theta}}

\def \dyad {{\cal D}}

\def \F {{\mathcal F}}

\def \walk {{\mathcal W}}
\def \hwalk {{\mathcal H}}
\def \bridge{{\mathcal B}}
\def \ibridge{{\mathcal I}}

\def \acat {{\oplus}}
\def \bcat {{\otimes}}

\def \Define {\noindent {\bf Definition.} }
\def  \Pf  {\noindent {\bf Proof.} }
\def \freemass {{\cal C}}
\newenvironment{remark}[1][Remark]{\begin{trivlist}
\item[\hskip \labelsep {\bfseries #1}]}{\end{trivlist}}
\newenvironment{definition}[1][Definition]{\begin{trivlist}
\item[\hskip \labelsep {\bfseries #1}]}{\end{trivlist}}
\newenvironment{example}[1][Example]{\begin{trivlist}
\item[\hskip \labelsep {\bfseries #1}]}{\end{trivlist}}
\newenvironment{conjecture}[1][Conjecture]{\begin{trivlist}
\item[\hskip \labelsep {\bfseries #1}]}{\end{trivlist}}

\begin{document}

\section{SLE partition functions}

For a domain $D$ and points $z,w$ on its boundary, we let
$H_D(z,w)$ denote the total mass of the SAW's in $D$ from $z$ to $w$.
This is a rather vague definition. Our goal is to argue that it
should be conformally covariant in the following sense. If $\Phi$ is
a conformal map on $D$, then
\bea
H_D (z,w)  =
[\Phi_A^\prime(z) \Phi_A^\prime(w)]^{5/8}
H_{\Phi(D)}(\Phi(z),\Phi(w))
\label{eqzz}
\eea
This formula should not be taken too literally. In particular, there
are lattice effects to be taken into account.

Let
\beann
Z(0,n) = \sum_{\omega:0 \rightarrow n, \omega \subset \Half} \beta^{|\omega|}
\eeann
The sum is over all self-avoiding walks that start at $(0,0)$, end
at $(n,0)$  and stay in the upper half plane except for their endpoints.
We assume that there is an exponent $\scaleexp$ such that
the limit
\beann
c=\lim_{n \rightarrow \infty} Z(0,n) n^\rho
\eeann
exists. Now let $x >0$. Let $[nx]$ denote the integer closest to $x$.
We have
\beann
\lim_{n \rightarrow \infty} Z(0,[nx]) n^\scaleexp =
\lim_{n \rightarrow \infty}  Z(0,[nx]) [nx]^\scaleexp
{n^\scaleexp \over [nx]^\scaleexp}
= {c \over x^\scaleexp}
\eeann
This shows that
\bea
H_\Half(0,x) = \frac{1}{x^\scaleexp} \, H_\Half(0,1)
\label{scaling}
\eea

Let $A \subset \Half$ be such that $\Half \setminus A$ is a simply connected
domain which is bounded away from $0$. The scaling limit of the
self-avoiding walk is conjectured to be $SLE_{8/3}$, a
chordal restriction measure.
The probability that a SAW $\gamma$ in $\Half$ from $0$ to $\infty$ does not
enter $A$ is given by
\beann
P(\gamma \cap A = \emptyset) = [\phi_A^\prime(0)]^{5/8}
\eeann
where $\phi_A$ is a conformal map from $\Half \setminus A$ to $\Half$
which sends $\infty$ to itself and has derivative $1$ at $\infty$.
(This means $\phi(z) \asymp z$ as $z \rightarrow \infty$.)
If we assume that the scaling limit of the probability mesasure
for the SAW between two points is conformally invariant,
then we can find the probability that a SAW in $\Half$ from $0$ to a
real $x$ hits $A$. Denote this probability by
$P_{\Half,0,x}(\gamma \cap A =\emptyset)$.
Let $\psi_x$ be a Moibius transformation of
$\Half$ to itself which fixes $0$ and sends $x$ to $\infty$.
Then
\beann
P_{\Half,0,x}(\gamma \cap A =\emptyset)=  [\phi_{\psi_x(A)}^\prime(0)]^{5/8}
\eeann
We can express this probability as a ratio of partition functions
\beann
P_{\Half,0,x}(\gamma \cap A =\emptyset) = {H_{\Half \setminus A} (0,x)
\over H_\Half(0,x) }
\eeann
So we have the following transformation result for partition functions
\beann
H_{\Half \setminus A} (0,x)  = [\phi_{\psi_x(A)}^\prime(0)]^{5/8} H_\Half(0,x)
\eeann

Recall that $\phi_{\psi_x(A)}$ is a conformal map that takes
$\Half \setminus \psi_x(A)$ to $\Half$ and fixes $0$ and $\infty$.
Letting
\beann
\phi_{x,A}= \psi_x^{-1} \circ \phi_{\psi_x(A)} \circ \psi_x,
\eeann
$\phi_{x,A}$ maps $\Half \setminus A$ to $\Half$ and fixes $0$
and $x$.
Since $\psi_x(0)=0$, $\phi_{\psi_x(A)}(0)=0$, and
$(\psi_x^{-1})^\prime(0)=1/\psi_x^\prime(0)$,
we have that
\beann
\phi_{x,A}^\prime(0) = \phi_{\psi(A)}^\prime(0)
\eeann
So we have
\bea
H_{\Half \setminus A} (0,x)  = [\phi_{x,A}^\prime(0)]^{5/8} H_\Half(0,x)
\label{trans}
\eea
Of course there is more that one conformal map of $\Half \setminus A$
to $\Half$ that fixes $0$ and $x$. The particular map we defined has
$\phi_{x,A}^\prime(x)=1$.
A general conformal map $\Phi_{x,A}$ of $\Half \setminus A$
to $\Half$ that fixes $0$ and $x$ can be written as
$\Phi_{x,A} = \chi \circ \phi_{x,A}$
where $\chi$ is a Moibius transformation of $\Half$ to itself that
fixes $0$ and $x$.
Such transformations are given by
\beann
\chi(z) = {z \over c(z-x)+1}
\eeann
where $c \in \reals$.
A short computation shows $\chi^\prime(0) \chi^\prime(x)=1$.
Since
\beann
\Phi_{x,A}^\prime(0) &=& \chi^\prime(0) \phi_{x,A}^\prime(0) \\
\Phi_{x,A}^\prime(x) &=& \chi^\prime(x) \phi_{x,A}^\prime(x) = \chi^\prime(x)
\eeann
we find
\beann
\phi_{x,A}^\prime(0) = \Phi_{x,A}^\prime(0)  \Phi_{x,A}^\prime(x)
\eeann
So \reff{trans} can be written as
\bea
H_{\Half \setminus A} (0,x)  =
[\Phi_{x,A}^\prime(0) \Phi_{x,A}^\prime(x)]^{5/8} H_\Half(0,x)
\label{eqaa}
\eea
where $\Phi_{x,A}$ is any conformal map of $\Half \setminus A$ to $\Half$
which fixes $0$ and $x$.

Now let $\Phi_A$ be a conformal map that maps $\Half \setminus A$
onto $\Half$ and fixes $0$ but not $x$. Let $\lambda=\Phi_A(x)/x$.
Then $\Phi_{x,A} = \lambda^{-1} \Phi_A$ fixes $x$, and so \reff{eqaa}
implies
\beann
H_{\Half \setminus A} (0,x)  =
[\Phi_A^\prime(0) \Phi_A^\prime(x)]^{5/8} \lambda^{-5/4} H_\Half(0,x)
\label{eqbb}
\eeann
Using \reff{scaling} we can rewrite this as
\bea
H_{\Half \setminus A} (0,x)  =
[\Phi_A^\prime(0) \Phi_A^\prime(x)]^{5/8} \lambda^{\rho-5/4}
H_\Half(0,\Phi_A(x))
\eea

Until now we have been assuming the conformal map $\Phi_A$ fixes $0$.
By adding a real constant to the map we can relax this constraint.
Since $H_\Half(x,y) = H_\Half(y-x)$, we conclude that for any
conformal map of $\Half \setminus A$ to $\Half$,
\bea
H_{\Half \setminus A} (0,x)  =
[\Phi_A^\prime(0) \Phi_A^\prime(x)]^{5/8} \lambda^{\rho-5/4}
H_\Half(\Phi_A(0),\Phi_A(x))
\eea
If $\rho=5/4$ this estabilishes \reff{eqzz} for a limited
class of domains.

\end{document}
\end


\chapter{TUTORIALS ON EDITING SOLIDS}

The Solid Editing state of MGED is used to modify the fundamental
parameters of an individual solid.
Each solid must be modified individually.

\section{Solid Edit: A Six-Sided Polyhedron}

\begin{figure}
\centering \includegraphics{es8-top.ps}
\caption{Top View of ARB8.}
\label{es8-top}
\end{figure}

This section illustrates the use of commands while in
SOL EDIT state to alter the
shape of a polyhedron with six sides and 8 faces (ARB8).

\noindent{\tt
\$ {\em mged es.g} \\
BRL-CAD Release 3.0 Graphics Editor (MGED) Compilation 82 \\
    Thu Sep 22 08:08:39 EDT 1988 \\
    mike@video.brl:/cad/.mged.4d2 \\
 \\
es.g: No such file or directory \\
Create new database (y|n)[n]? {\em y} \\
attach (nu|tek|tek4109|ps|plot|sgi)[nu]? {\em sgi} \\
ATTACHING sgi (SGI 4d) \\
Untitled MGED Database (units=mm) \\
mged> {\em in arb8 rpp -1 1 -1 1 -1 1} \\
mged> {\em size 10} \\
mged>
}

Figure \ref{es8-top}
is a top view of the six-sided polyhedron.
The Z-axis perpendicular to the viewing screen.
Next, the view is rotated so that all sides can be seen.

\noindent{\tt
mged> {\em Twist ROTY knob clockwise and restore} \\
mged> {\em Twist ROTX knob counter-clockwise and restore} \\
mged>
}

\begin{figure}
\centering \includegraphics{es8-rot.ps}
\caption{A Rotated View of the ARB8.}
\label{es8-rot}
\end{figure}
Figure \ref{es8-rot} shows a better perspective of the solid.

The next step in this tutorial is to transfer to the solid edit state.
This can be accomplished in two ways:  either by going through
the SOL PICK state (``illuminate mode'') or by direct transfer via
keyboard command.
Using illuminate mode is better when the name of the solid to be
edited may not be known, while the keyboard command is generally
preferred when the name of the solid is known.

\noindent{\tt
mged> {\em Select the ``Solid Illum'' entry in the button menu} \\
mged> {\em Move the mouse out of the menu area} \\
mged> {\em Click the mouse to enter SOL EDIT state} \\
mged>
}

To perform a direct transfer from the viewing state to the solid edit state
using a keyboard command, enter:

\noindent{\tt
mged> {\em sed arb8} \\
mged>
}

\begin{figure}
\centering \includegraphics{es8-sed.ps}
\caption{An ARB8 in Solid Edit State.}
\label{es8-sed}
\end{figure}

Figure \ref{es8-sed} corresponds to the view on the display.
The ARB8 MENU is unique to the ARB primitive,
and lists operations that can only be performed on an ARB solid.
The items in the ARB8 MENU are
selected by using the mouse.
Each of the other types of solids have a
similar unique menu.
When one of these items is selected, the top level ARB8 MENU disappears,
to be replaced with the indicated subordinate menu.
The top-level menu reappears when either
the ``edit menu'' item in the SOLID EDIT menu is selected,
or the ``RETURN'' item in the subordinate menu is selected.

The  SOLID EDIT  menu applies to all
solids when in the SOL EDIT state.
The items in the  SOLID EDIT  menu are selected
by either using the mouse or by depressing the appropriate button on the
button box.
When any of the SOLID EDIT menu items are selected
(e.g., ``Rotate'', ``Translate'', ``Scale''), the solid-specific menu
disappears.
Th top-level solid-specific menu reappears when
the ``edit menu'' item in the SOLID EDIT menu is selected.

The {\em p [params]} command is used to
make precise changes, where the numeric value of the parameter being
edited is know.
Values for all parameters in the ARB8
and SOLID EDIT menus can be specified by using the {\em p} command,
or by pointing and clicking with the mouse.

\begin{figure}
\centering \includegraphics{es8-tr0.ps}
\caption{Translating ARB8 Point 1 to the Origin.}
\label{es8-tr0}
\end{figure}

\subsection{Translate Operation}

\noindent{\tt
mged> {\em Select the ``Translate'' entry in the solid edit menu} \\
mged> {\em p 0 0 0} \\
mged>
}

Point 1 of the primitive is moved to point 0 0 0,
as shown in Figure \ref{es8-tr0}.

The translate solid operation is selected
by either picking ``Translate'' on the solid edit menu
with the mouse, by depressing the solid edit button on the button box,
or by entering the {\em press sed} command.
Parameters to the translate solid operation
are of the form {\em p a b c}
where {\em a}, {\em b}, and {\em c} are the new coordinates
of point 1 in the solid.
The other points are transferred to keep the same position
relative to point 1.
The general form of the new coordinates for point is

\begin{center}
\begin{verbatim}
x ' = x + a - x
y ' = y + b - y
Z ' = Z + c - Z
\end{verbatim}
\end{center}

The command

\noindent{\tt
mged> {\em p 1 -1 -1} \\
mged>
}

can be used to restore the primitive to the original position.

\subsection{Rotate Operation}

\begin{figure}
\centering \includegraphics{es8-xrot.ps}
\caption{Solid Edit Rotation of 45 Degrees about X.}
\label{es8-xrot}
\end{figure}

The rotate operation is initiated by either selecting Rotate on the menu
screen with the mouse,
by depressing the Solid Rotate button on the button box,
or by entering the {\em press srot} command on the keyboard.

\noindent{\tt
mged> {\em Select the ``Rotate'' entry in the solid edit menu} \\
mged> {\em p 45 0 0} \\
mged>
}

The parameter {\em p} command is used to make precise rotation changes.
The
command is entered in the form {\em p a b c} where
{\em a}, {\em b}, and {\em c} are the angles
(in degrees) of rotation about the x, y, and z axes respectively.  Point 1,
the vertex, remains fixed, and the solid is rotated about this point.  A
positive angle of rotation is counter-clockwise when viewed in the positive
direction along an axis.

The order of rotation is not commutative.
Rotation takes place about the
Z axis, Y axis, and X axis in that order.
Figure \ref{es8-xrot} shows the rotation of 45 degrees about the X axis.

%The following is the formula for moving point (x,y,z) through angles
%(a, b, c) to point (x', y', z')
%\begin{verbatim}
%[X'] [cos b cos c                     -cos b sin c        sin b        ][X]
%[Y']=[sin a sin b cos c +cos a sin b   cos a cos c -sin a sin b sin c -sin a cos b ][Y]
%[Z'] [sin a sin c -cos a sin b cos c   cos a sin b sin c + sin a cos c cos a cos b ][Z]
%\end{verbatim}

The values entered after the p are absolute - the rotations are applied to
the primitive as it existed when solid rotation was first selected.  Thus
entering {\em p 0 0 0} will undo any rotations
performed since solid rotation was begun.

\begin{figure}
\centering \includegraphics{es8-yrot.ps}
\caption{Solid Edit Rotation of 45 Degrees about Y.}
\label{es8-yrot}
\end{figure}

\begin{figure}
\centering \includegraphics{es8-zrot.ps}
\caption{Solid Edit Rotation of 45 Degrees about Z.}
\label{es8-zrot}
\end{figure}

\noindent{\tt
mged> {\em p 0 45 0} \\
mged>
}

Figure \ref{es8-yrot} displays the solid
after it has been rotated about the Y axis.

\noindent{\tt
mged> {\em p 0 0 45} \\
mged>
}

Figure \ref{es8-zrot} displays the solid
after it has been rotated about the Z axis.

\noindent{\tt
mged> {\em p 0 0 0} \\
mged>
}

This restores the original orientation of the solid.

\subsection{Scale Operation}

\begin{figure}
\centering \includegraphics{es8-scale.ps}
\caption{ARB8 Scale Increased by 2X.}
\label{es8-scale}
\end{figure}

\noindent{\tt
mged> {\em Select the ``Scale'' entry in the solid edit menu} \\
mged> {\em p 2} \\
mged>
}

Figure \ref{es8-scale} corresponds to the view that is shown on the display.
The scale operation may be initiated by either selecting
the Scale entry  on the menu with the mouse,
by depressing the Solid Scale button,
or by entering {\em press sscale} on the keyboard.
The parameter command {\em p n} is
used to enter a precise scale factors, where {\em n} is
the scale factor.
The coordinates of point 1 remain the same.  The distances
from point 1 to the other points are multiplied by the scale value {\em n}.
The general equations for the transformation from point p to p' are

\begin{verbatim}
    x'[i] = x[i] + n (x[i] - x[1] )
    y'[i] = y[i] + n (y[i] - y[1] )   i != 1
    z'[i] = z[i] + n (z[i] - z[1] )
\end{verbatim}

The size of the primitive may be changed by depressing the mouse at
different positions.  When the mouse is clicked, the
edited primitive is scaled about point 1 (the key point)
by an amount proportional
to the distance the mouse is from the center of the screen.  If the mouse
is above the center of the screen, the edited primitive will become larger.
If the
mouse is below the center, the primitive will become smaller.

The value of {\em n} entered is applied to the primitive as it existed when the
solid scale state was entered.

Entering {\em p 1} will return the primitive
to the size it had when the solid scale operation first started.

\noindent{\tt
mged> {\em p 1} \\
mged>
}

\begin{figure}
\centering \includegraphics{es8-edge1.ps}
\caption{ARB8 Edge 15 Moved Through (9, -2, -2).}
\label{es8-edge1}
\end{figure}

\begin{figure}
\centering \includegraphics{es8-edge2.ps}
\caption{ARB8 Edge 12 Moved Through (2, 5, -2).}
\label{es8-edge2}
\end{figure}

\begin{figure}
\centering \includegraphics{es8-edge3.ps}
\caption{ARB8 Edge 14 Moved Through (2, -2, 7).}
\label{es8-edge3}
\end{figure}

\subsection{Moving Edges}

The move edge command permits the moving of a line or edge so that the
line passes through the selected point.

\noindent{\tt
mged> {\em Select the ``edit menu'' entry in the solid edit menu} \\
mged> {\em Select the ``move edges'' entry in the ARB menu} \\
mged> {\em Select the ``move edge 15'' entry in the ARB8 edges menu} \\
mged> {\em p 9 -2 -2} \\
mged>
}

The edge 15 is moved so that it passes through the point (9, -2, -2).  The
coordinates of the new points 1 and 5 are the intersection of the new edge
with the planes 234 and 678.  Since both the old edge and new edge 15 are
parallel to the X axis,
the X coordinate of the point given by the {\em p} command
has no meaning.  The X coordinates for points 1 and 5 are not changed.
See Figure \ref{es8-edge1}.

\noindent{\tt
mged> {\em p 9 -1 -1} \\
mged>
}

This restores the original shape.
The choice of ``9'' for the X coordinate was arbitrary.

\noindent{\tt
mged> {\em Select the ``move edge 12'' entry in the ARB8 edges menu} \\
mged> {\em p 2 5 -2} \\
mged>
}

The edge 12 is parallel to the Y axis.  This command moves the points 1
and 2 so that their X and Z coordinates are 2 and -2.
See Figure \ref{es8-edge2}.
The Y coordinates are not changed.

To restore the view, enter:

\noindent{\tt
mged> {\em p 1 5 -1} \\
mged>
}

The choice of ``5'' for the Y coordinate was arbitrary.

\noindent{\tt
mged> {\em Select the ``move edge 14'' entry in the ARB8 edges menu} \\
mged> {\em p 2 -2 7} \\
mged>
}

The edge 14 is parallel to the Z axis.
This command moves the points 1
and 4 so that their X and Y coordinates are 2 and -2.
See Figure \ref{es8-edge3}.
The Z coordinates are not changed.

\noindent{\tt
mged> {\em p 1 -1 7} \\
mged>
}

This restores the original shape.
The choice of ``7'' for the Z coordinate was arbitrary.

\subsection{Extrude Command}

\begin{figure}
\centering \includegraphics{es8-ex1.ps}
\caption{ARB8 Rear Face Extruded 5 Units in -Z.}
\label{es8-ex1}
\end{figure}

\begin{figure}
\centering \includegraphics{es8-ex2.ps}
\caption{ARB8 Rear Face Extruded 3 Units in +Z.}
\label{es8-ex2}
\end{figure}

The extrude command is used to move the opposite surface a distance from
the specified surface or plate.
This command can only be used when an ARB solid is in
solid edit state.

\noindent{\tt
mged> {\em extrude 1265 5} \\
mged>
}

In Figure \ref{es8-ex1},
the plane opposite surface whose points are 1, 2, 6, and 5
is moved to a distance of 5 in the positive Z direction from plane 1265.  Note
that the points were selected counter-clockwise when viewed in the positive
direction along the Z axis.

\noindent{\tt
mged> {\em extrude 1562 3} \\
mged>
}

In Figure \ref{es8-ex2},
the plane opposite surface 1562 is moved to a distance of 3
in the negative Z direction from 1562.  Note that the points were selected
clockwise when viewed in the positive direction along the Z axis.

\noindent{\tt
mged> {\em extrude 1265 2} \\
mged>
}

This restores the original shape of this solid.

To return control to the VIEWING state, select the ``REJECT Edit''
item on the button menu, press the ``reject'' button on the button box,
or enter the command {\em press reject} on the keyboard.
Then, enter

\noindent{\tt
mged> {\em d arb8} \\
mged>
}

to drop the ARB8 from view.

\section{Solid Edit:  A Five-Sided Polyhedron}

\begin{figure}
\centering \includegraphics{es5-top.ps}
\caption{Top View of an ARB5.}
\label{es5-top}
\end{figure}

\begin{figure}
\centering \includegraphics{es5-rot.ps}
\caption{A Rotated View of the ARB5.}
\label{es5-rot}
\end{figure}

\begin{figure}
\centering \includegraphics{es5-sed.ps}
\caption{The ARB5 in Solid Edit State.}
\label{es5-sed}
\end{figure}

This tutorial illustrates the application of the SOL EDIT state to the ARB5
solid.
In this tutorial, the view is modified by using the rotation
knobs so that all sides can be seen.

\noindent{\tt
mged> {\em size 6} \\
mged> {\em in arb5 arb5} \\
Enter X, Y, Z for point 1: {\em 0 0 0} \\
Enter X, Y, Z for point 2: {\em 0 0 1} \\
Enter X, Y, Z for point 3: {\em 0 1 1} \\
Enter X, Y, Z for point 4: {\em 0 1 0} \\
Enter X, Y, Z for point 5: {\em -1 .5 .5} \\
mged>
}

Figure \ref{es5-top} is the display of arb5
in the VIEWING state that is seen when
the solid is first created.
In this view, the Z axis is perpendicular to the viewing screen.

\noindent{\tt
mged> {\em Twist ROTY knob clockwise and restore} \\
mged> {\em Twist ROTX knob counter-clockwise and restore} \\
mged>
}

These actions generate a view shown in Figure \ref{es5-rot}
that shows all sides.

\noindent{\tt
mged> {\em Select the ``Solid Illum'' entry in the button menu} \\
mged> {\em Move the mouse out of the menu area} \\
mged> {\em Click the mouse to enter SOL EDIT state} \\
mged>
}

These actions will place MGED in the SOL EDIT state
as shown in Figure \ref{es5-sed}.

\subsection{Translate Operation}

\begin{figure}
\centering \includegraphics{es5-tr.ps}
\caption{Translating an ARB5.}
\label{es5-tr}
\end{figure}

\noindent{\tt
mged> {\em Select the ``Translate'' entry in the solid edit menu} \\
mged> {\em p -1 -1 1} \\
mged>
}

This command cause point 1 to be moved to coordinates (-1, -1, 1) and the
other points are moved so that they keep the same relative position to point
1.  See Figure \ref{es5-tr}.

Enter this command to restore the solid to its original location:

\noindent{\tt
mged> {\em p 0 0 0} \\
mged>
}

\subsection{Rotate Operation}

\begin{figure}
\centering \includegraphics{es5-xrot.ps}
\caption{ARB5 Solid Edit Rotation about X.}
\label{es5-xrot}
\end{figure}

\noindent{\tt
mged> {\em Select the ``Rotate'' entry in the solid edit menu} \\
mged> {\em p 45 0 0} \\
mged>
}

Figure \ref{es5-xrot} shows a rotation of 45 degrees
about an axis parallel to the X axis.
The rotate command is entered in the form {\em p a b c}
where {\em a}, {\em b}, and {\em c} are the angles
(in degrees) of rotation about the x, y, and z axes and intersect at point 1.
All rotation takes place about point 1.

\noindent{\tt
mged> {\em p 0 0 0} \\
mged>
}

This restores the original orientation of the solid.

\subsection{Scale Operation}

\begin{figure}
\centering \includegraphics{es5-scale.ps}
\caption{ARB5 Scale Increased by 2X.}
\label{es5-scale}
\end{figure}

\noindent{\tt
mged> {\em Select the ``Scale'' entry in the solid edit menu} \\
mged> {\em p 2} \\
mged>
}

Figure \ref{es5-scale} shows the change in the primitive.
Point 1 remains the same
and the distances of the other points from point 1 is multiplied by 2.

Entering {\em p 1} will return the primitive
to the size it had when the solid scale operation first started.

\noindent{\tt
mged> {\em p 1} \\
mged>
}

\subsection{Move Edge Command}

\begin{figure}
\centering \includegraphics{es5-edge1.ps}
\caption{ARB5 Edge 14 Moved Through (1, 1, 1).}
\label{es5-edge1}
\end{figure}

\begin{figure}
\centering \includegraphics{es5-edge2.ps}
\caption{ARB5 Point 5 Moved to (-1.5, 1, 1).}
\label{es5-edge2}
\end{figure}

\begin{figure}
\centering \includegraphics{es5-edge3.ps}
\caption{ARB5 Edge 45 Moved Through (-1.5 1 1).}
\label{es5-edge3}
\end{figure}

\begin{figure}
\centering \includegraphics{es5-edge4.ps}
\caption{ARB5 Edge 12 Moved Through (2, 1, 2).}
\label{es5-edge4}
\end{figure}

\noindent{\tt
mged> {\em Select the ``edit menu'' entry in the solid edit menu} \\
mged> {\em Select the ``move edges'' entry in the ARB menu} \\
mged> {\em Select the ``move edge 14'' entry in the ARB8 edges menu} \\
mged> {\em p 1 1 1} \\
mged>
}

The edge 14 is moved so that it moves through the point (1, 1, 1).
Note that this point is the mid-point between points 1 and 4.
See Figure \ref{es5-edge1}.

\noindent{\tt
mged> {\em p 0 2 0} \\
mged>
}

This restores the original shape.

\noindent{\tt
mged> {\em Select the ``move point 5'' entry in the ARB5 edges menu} \\
mged> {\em p -1.5 1 1} \\
mged>
}

The point 5 is moved to location -1.5, 1, 1.  See Figure \ref{es5-edge2}.

\noindent{\tt
mged> {\em p -1 .5 .5} \\
mged>
}

will restore the original shape.

\noindent{\tt
mged> {\em Select the ``move edge 45'' entry in the ARB5 edges menu} \\
mged> {\em p -1.5 1 1} \\
mged>
}

In Figure \ref{es5-edge3}, the edge 45 is moved
so that it passes through the point (-1.5, 1, 1).
Note that this point lies between the points 4 and 5.

\noindent{\tt
mged> {\em p -1 .5 .5} \\
mged>
}

This restores the original shape.

\noindent{\tt
mged> {\em Select the ``move edge 12'' entry in the ARB5 edges menu} \\
mged> {\em p 2 1 2} \\
mged>
}

In Figure \ref{es5-edge4},
the edge 12 is moved so that it passes through the point (2, 1, 2).
Note that the coordinates correspond to point 2.

The movement of the edges may yield unpredictable results when the edges
are not parallel to one of the axes.

To return control to the VIEWING state, select the ``REJECT Edit''
item on the button menu, press the ``reject'' button on the button box,
or enter the command {\em press reject} on the keyboard.
Then, enter

\noindent{\tt
mged> {\em d arb5} \\
mged>
}

to drop the ARB5 from view.

\section{Solid Edit: Alter a Cylinder}

\begin{figure}
\centering \includegraphics{esc-top.ps}
\caption{Top View of a Cylinder.}
\label{esc-top}
\end{figure}

\begin{figure}
\centering \includegraphics{esc-rot.ps}
\caption{A Rotated View of the Cylinder.}
\label{esc-rot}
\end{figure}

\begin{figure}
\centering \includegraphics{esc-sed.ps}
\caption{A Cylinder in Solid Edit State.}
\label{esc-sed}
\end{figure}

This tutorial illustrates the application of the SOL EDIT state to
cylinder solids.

\noindent{\tt
mged> {\em size 12} \\
mged> {\em in cyl rcc} \\
Enter X, Y, Z of vertex: {\em 0 0 0} \\
Enter X, Y, Z of height (H) vector: {\em 2 0 0} \\
Enter radius: {\em 1}
mged>
}

Figure \ref{esc-top} is the display of the cylinder solid
when viewed from the top.
Since the
Z axis is perpendicular to the viewing screen, a view of all sides cannot be
seen.

\noindent{\tt
mged> {\em Twist ROTY knob clockwise and restore} \\
mged> {\em Twist ROTX knob counter-clockwise and restore} \\
mged>
}

These actions generate a view, Figure \ref{esc-rot}, that shows all sides.

\noindent{\tt
mged> {\em Select the ``Solid Illum'' entry in the button menu} \\
mged> {\em Move the mouse out of the menu area} \\
mged> {\em Click the mouse to enter SOL EDIT state} \\
mged>
}

Figure \ref{esc-sed} is the view that displays the menu
for the SOL EDIT state.
The
point V is at the origin (0,0,0) in this example and is in the middle of the
circle that contains points A and B.  H is the point of the center of the
circle that contains points C and D.  The coordinates of H are the coordinates
of the vector from V to H and represent the relative position of H to V.  Mag
is the magnitude of these vectors and is represented by the formula
\begin{center}
\begin{verbatim}
Mag = sqrt( x + y + z )
\end{verbatim}
\end{center}

``H dir cos'' are the direction cosines of the vector H which
is perpendicular to plane of the points A, B, and V.  The coordinates of A
are the coordinates of the vector from V through A.  Mag is the magnitude of
the vectors from V to A.  The coordinates of B are the coordinates of the
vectors from V through B.  Mag is the magnitude of the vector from V to B.
The values for c and d are the magnitudes of the vectors from the tip of
vector H to the points C
and D respectively.
``A x B dir cos'' represents the direction cosines of the
vector ``A x B''.

\subsection{Translate Operation}

\begin{figure}
\centering \includegraphics{esc-tr.ps}
\caption{Translating Cylinder Vertex to (1, 1, 1).}
\label{esc-tr}
\end{figure}

\noindent{\tt
mged> {\em Select the ``Translate'' entry in the solid edit menu} \\
mged> {\em p 1 1 1} \\
mged>
}

The location of the vertex point V is moved to (1, 1, 1).
The locations of the other
points relative to V remains the same.  See Figure \ref{esc-tr}.

Move the mouse anywhere on the screen (outside the menu area), and click.
Notice
that the cylinder is moved so that V is placed at this location, and the
coordinates of the other points remain the same relative to V.

\noindent{\tt
mged> {\em p 0 0 0} \\
mged>
}

This restores the solid to the original location.

\subsection{Rotate Operation}

\begin{figure}
\centering \includegraphics{esc-xrot.ps}
\caption{Solid Edit Rotation of 45 Degrees about X.}
\label{esc-xrot}
\end{figure}

\begin{figure}
\centering \includegraphics{esc-yrot.ps}
\caption{Solid Edit Rotation of 45 Degrees about Y.}
\label{esc-yrot}
\end{figure}

\begin{figure}
\centering \includegraphics{esc-zrot.ps}
\caption{Solid Edit Rotation of 45 Degrees about Z.}
\label{esc-zrot}
\end{figure}

\noindent{\tt
mged> {\em Select the ``Rotate'' entry in the solid edit menu} \\
mged> {\em p 45 0 0} \\
mged>
}

When viewing in the positive X direction, the cylinder is rotated counter-
clockwise 45 degrees about an axis through point V parallel to the x axis.
See Figure \ref{esc-xrot}.

\noindent{\tt
mged> {\em p 0 45 0} \\
mged>
}

When viewing in the positive Y direction, the cylinder is rotated counter-
clockwise 45 degrees about an axis through point V parallel to the Y axis.
See Figure \ref{esc-yrot}.

\noindent{\tt
mged> {\em p 0 0 45} \\
mged>
}

When viewing in the positive Z direction, the cylinder is rotated counter-
clockwise 45 degrees about an axis through point V parallel to the Z axis.
See Figure \ref{esc-zrot}.

The command

\noindent{\tt
mged> {\em p 0 0 0} \\
mged>
}

will restore the cylinder to the original orientation.

\subsection{Scale Operation}

\begin{figure}
\centering \includegraphics{esc-scale.ps}
\caption{Cylinder Scale Increased by 1.5X.}
\label{esc-scale}
\end{figure}

\noindent{\tt
mged> {\em Select the ``Scale'' entry in the solid edit menu} \\
mged> {\em p 1.5} \\
mged>
}

The point V remains fixed, the distance H between the two end-plate ellipses
is multiplied by 1.5.
See Figure \ref{esc-scale}.

The command

\noindent{\tt
mged> {\em p 1} \\
mged>
}

restores the original scale.

\subsection{Scale H Command}

\begin{figure}
\centering \includegraphics{esc-sh.ps}
\caption{Cylinder Scale H Vector.}
\label{esc-sh}
\end{figure}

\noindent{\tt
mged> {\em Select the ``edit menu'' entry in the solid edit menu} \\
mged> {\em Select the ``scale H'' entry in the TGC menu} \\
mged> {\em p 1} \\
mged>
}

The magnitude of the vector H is reduced from 2 to 1.
See Figure \ref{esc-sh}.  The command

\noindent{\tt
mged> {\em p 2} \\
mged>
}

will restore the original shape.

\subsection{Scale A Command}

\begin{figure}
\centering \includegraphics{esc-sa.ps}
\caption{Cylinder Scale A Vector.}
\label{esc-sa}
\end{figure}

\noindent{\tt
mged> {\em Select the ``scale A'' entry in the TGC menu} \\
mged> {\em p 2} \\
mged>
}

The magnitude of the vector through point A is increased to 2, i.e.,
the length of the axis of the ellipse through point A is set equal to p.
See Figure \ref{esc-sa}.  The command

\noindent{\tt
mged> {\em p 1} \\
mged>
}

will restore the original shape.

\subsection{Scale B Command}

\begin{figure}
\centering \includegraphics{esc-sb.ps}
\caption{Cylinder Scale B Vector.}
\label{esc-sb}
\end{figure}

\noindent{\tt
mged> {\em Select the ``scale B'' entry in the TGC menu} \\
mged> {\em p 2} \\
mged>
}

The magnitude of the vector through point B is increased to 2, i.e.,
the length of the axis of the ellipse through point B is set equal to p.
See Figure \ref{esc-sb}.  The command

\noindent{\tt
mged> {\em p 1} \\
mged>
}

will restore the original shape.

\subsection{Scale C Command}

\begin{figure}
\centering \includegraphics{esc-sc.ps}
\caption{Cylinder Scale C Vector.}
\label{esc-sc}
\end{figure}

\noindent{\tt
mged> {\em Select the ``scale C'' entry in the TGC menu} \\
mged> {\em p 2} \\
mged>
}

The magnitude of the vector through point c is increased to the value of
p.  The length of the axis of the ellipse through point c is set equal to the
value of p.  See Figure \ref{esc-sc}.  The command

\noindent{\tt
mged> {\em p 1} \\
mged>
}

will restore the original shape.

\subsection{Scale D Command}

\begin{figure}
\centering \includegraphics{esc-sd.ps}
\caption{Cylinder Scale D Vector.}
\label{esc-sd}
\end{figure}

\noindent{\tt
mged> {\em Select the ``scale D'' entry in the TGC menu} \\
mged> {\em p 2} \\
mged>
}

The magnitude of the vector through point D is changed to the value of p.
The length of the axis of the ellipse through point D is set equal to the
value of p.  See Figure \ref{esc-sd}.  The command

\noindent{\tt
mged> {\em p 1} \\
mged>
}

will restore the original shape.

The scale H, A, B, C, and D commands provide for setting the magnitude
equal to the value entered by the {\em p} command.
The solid edit {\bf scale} operation provides
for multiplying {\bf all} the vectors by the value
entered by the {\em p} command.

\subsection{Move End H Command}

\begin{figure}
\centering \includegraphics{esc-mh.ps}
\caption{Cylinder Move End of H.}
\label{esc-mh}
\end{figure}

\noindent{\tt
mged> {\em Select the ``move end H'' entry in the TGC menu} \\
mged> {\em p 3} \\
mged>
}

The length of the vector H is changed to the value of p.
See Figure \ref{esc-mh}.  The command

\noindent{\tt
mged> {\em p 2} \\
mged>
}

will restore the original shape.

\subsection{Move End H (rt) Command}

\begin{figure}
\centering \includegraphics{esc-mhrt.ps}
\caption{Cylinder Move End of H \& Rotate.}
\label{esc-mhrt}
\end{figure}

\noindent{\tt
mged> {\em Select the ``move end H(rt)'' entry in the TGC menu} \\
mged> {\em p 3} \\
mged>
}

This command is similar to the ``move end H'' command except the vector
through point A is rotated so its direction is in the -Y direction.
See Figure \ref{esc-mhrt}.  The command

\noindent{\tt
mged> {\em p 2} \\
mged>
}

will restore the original shape, but not the original orientation.

To return control to the VIEWING state, select the ``REJECT Edit''
item on the button menu, press the ``reject'' button on the button box,
or enter the command {\em press reject} on the keyboard.
Then, enter

\noindent{\tt
mged> {\em d cyl} \\
mged>
}

to drop the cylinder from view.

\section{Solid Edit: Alter Ellipsoid}

\begin{figure}
\centering \includegraphics{ese-top.ps}
\caption{Top View of an Ellipsoid.}
\label{ese-top}
\end{figure}

\begin{figure}
\centering \includegraphics{ese-sed.ps}
\caption{An Ellipsoid in Solid Edit State.}
\label{ese-sed}
\end{figure}

This tutorial illustrates the application of the SOL EDIT state to the
ellipsoid primitive.

\noindent{\tt
mged> press reset
mged> {\em size 6} \\
mged> {\em in ell ellg} \\
Enter X, Y, Z of vertex: {\em 0 0 0} \\
Enter X, Y, Z of vector A: {\em 1 0 0} \\
Enter X, Y, Z of vector B: {\em 0 .3536 -0.3536} \\
Enter X, Y, Z of vector C: {\em 0 .3536  0.3536} \\
mged>
}

Figure \ref{ese-top} is the display of the primitive in the viewing state.
Since the
Z axis is perpendicular to the viewing screen, a view of all sides cannot be
seen.

\noindent{\tt
mged> {\em Twist ROTY knob clockwise and restore} \\
mged> {\em Twist ROTX knob counter-clockwise and restore} \\
mged>
}

These actions generate a view that shows all sides.

\noindent{\tt
mged> {\em Select the ``Solid Illum'' entry in the button menu} \\
mged> {\em Move the mouse out of the menu area} \\
mged> {\em Click the mouse to enter SOL EDIT state} \\
mged>
}

The display will be changed from the VIEWING MODE through the SOL PICK to
the SOL EDIT state.  Figure \ref{ese-sed} is the view that is displayed.

The coordinates of the points A, B, C, are given by the product of the
magnitude of the vector and the cosine of X, Y, and Z direction cosines.  In
the display, the coordinates are:

\begin{center}
\begin{verbatim}
A = (1, 0, 0)
B = (0, 0.3536, -0.3536)
C = (0, 0.3536,  0.3536)
\end{verbatim}
\end{center}
or
\begin{center}
\begin{verbatim}
A = ( 1* cos  0,  1* cos 90,   1* cos 90 )
B = (.5* cos 90, .5* cos 45, -.5* cos 45 )
C = (.5* cos 90, .5* cos 45,  .5* cos 45 )
\end{verbatim}
\end{center}

\subsection{Translate Operation}

\begin{figure}
\centering \includegraphics{ese-tr.ps}
\caption{Translating Ellipsoid to (-1, 1, 1).}
\label{ese-tr}
\end{figure}

\noindent{\tt
mged> {\em Select the ``Translate'' entry in the solid edit menu} \\
mged> {\em p -1 1 1} \\
mged>
}

The key point V is moved to (-1, 1, 1) and the ellipsoid maintains its
relative position to V.  See Figure \ref{ese-tr}.

While in the SOL EDIT state, the solid may be translated by
using the mouse.  These changes are not numerically exact, but they can be
useful to visually position a solid with respect to other solids.
Move the mouse to a position outside the menu area on the screen.
Click the mouse.
The center point (V) of the ellipsoid will be translated to that point.
Note that only the value of the coordinates of V are changed.
The command

\noindent{\tt
mged> {\em p 0 0 0} \\
mged>
}

will restore the original position.

\subsection{Rotate Operation}

\begin{figure}
\centering \includegraphics{ese-xrot.ps}
\caption{Solid Edit Rotation of 45 Degrees about X.}
\label{ese-xrot}
\end{figure}

\begin{figure}
\centering \includegraphics{ese-yrot.ps}
\caption{Solid Edit Rotation of 45 Degrees about Y.}
\label{ese-yrot}
\end{figure}

\begin{figure}
\centering \includegraphics{ese-zrot.ps}
\caption{Solid Edit Rotation of 45 Degrees about Z.}
\label{ese-zrot}
\end{figure}

The rotate operation is initiated by either selecting Rotate on the menu
screen with the mouse,
by depressing the Solid Rotate button on the button box,
or by entering the {\em press srot} command on the keyboard.

\noindent{\tt
mged> {\em Select the ``Rotate'' entry in the solid edit menu} \\
mged> {\em p 45 0 0} \\
mged>
}

Figure \ref{ese-xrot} shows the rotation of the ellipsoid about its X axis.
The angle of rotation is counter-clockwise when viewed in the positive X
direction.  The direction cosines of vectors VB and VC are changed by 45 .

\noindent{\tt
mged> {\em Select the ``Rotate'' entry in the solid edit menu} \\
mged> {\em p 0 45 0} \\
mged>
}

Figure \ref{ese-yrot} shows the rotation of the ellipsoid about its Y axis.
The angle
of rotation is counter-clockwise when viewed in the positive Y direction.  The
rotation is made from the original view, and the restoration of the view is
not necessary.

\noindent{\tt
mged> {\em Select the ``Rotate'' entry in the solid edit menu} \\
mged> {\em p 0 0 45} \\
mged>
}

Figure \ref{ese-zrot} shows the rotation of the ellipsoid about its Z axis.
The axis
of rotation is counter-clockwise when viewed in the positive Z direction.
The command

\noindent{\tt
mged> {\em p 0 0 0} \\
mged>
}

restores the original orientation of the solid.

\subsection{Scale Operation}

\begin{figure}
\centering \includegraphics{ese-scale.ps}
\caption{Ellipsoid Scale Decreased.}
\label{ese-scale}
\end{figure}

\noindent{\tt
mged> {\em Select the ``Scale'' entry in the solid edit menu} \\
mged> {\em p .5} \\
mged>
}

Point V is not changed,
but the distance from V to the surface of the ellipsoid is multiplied by 0.5,
because the magnitude of the vectors are multiplied by the value of 0.5.
See Figure \ref{ese-scale}.

Move the mouse to a position outside the menu area and above the X axis,
and click the mouse.
Notice that the size of the ellipsoid has grown, i.e.,
the magnitude of the vectors have increased.
Move the mouse to a position below the X axis, and click the mouse.
Notice that the size of the ellipsoid has increased.

The command

\noindent{\tt
mged> {\em p 1} \\
mged>
}

will restore the original scale.

NOTE:
The use
of the scale operation from the Solid Edit menu
will result in the values of all the vectors being
multiplied by the value of the scale.
Use of the scale operaton from the Ellipsoid menu
with a particular vector A, B, or C changes the
magnitude of that vector to the value of the scale.

\subsection{Scale A Command}

\begin{figure}
\centering \includegraphics{ese-sa.ps}
\caption{Ellipsoid Scale A Vector.}
\label{ese-sa}
\end{figure}

\noindent{\tt
mged> {\em Select the ``edit menu'' entry in the solid edit menu} \\
mged> {\em Select the ``scale A'' entry in the ellipsoid menu} \\
mged> {\em p 1.5} \\
mged>
}

The magnitude of the vector to point A is set equal to the value of p
(e.g. 1.5).
The components of the vector are (1.5, 0, 0) since the vector was
parallel to the X axis.  See Figure \ref{ese-sa}.  The command

\noindent{\tt
mged> {\em Select the ``scale A'' entry in the TGC menu} \\
mged> {\em p 1} \\
mged>
}

will restore the original shape.

\subsection{Scale B Command}

\begin{figure}
\centering \includegraphics{ese-sb.ps}
\caption{Ellipsoid Scale B Vector.}
\label{ese-sb}
\end{figure}

\noindent{\tt
mged> {\em Select the ``scale B'' entry in the Ellipsoid menu} \\
mged> {\em p 1.5} \\
mged>
}

The magnitude of the vector to point B is set equal to the value of p
(e.g. 1.5).
The coordinates of the vector are the product of p and the
direction cosines of B.  See Figure \ref{ese-sb}.  The command

\noindent{\tt
mged> {\em p 0.5} \\
mged>
}

will restore the original shape.

\subsection{Scale C Command}

\begin{figure}
\centering \includegraphics{ese-sc.ps}
\caption{Ellipsoid Scale C Vector.}
\label{ese-sc}
\end{figure}

\noindent{\tt
mged> {\em Select the ``scale C'' entry in the Ellipsoid menu} \\
mged> {\em p 1.5} \\
mged>
}

The magnitude of the vector to point C is set equal to the value of p
(i.e., 1.5).
The coordinates of the vector are the product of p and the
direction cosines of C.  See Figure \ref{ese-sc}.  The command

\noindent{\tt
mged> {\em p 0.5} \\
mged>
}

will restore the original shape.

To return control to the VIEWING state, select the ``REJECT Edit''
item on the button menu, press the ``reject'' button on the button box,
or enter the command {\em press reject} on the keyboard.
Then, enter

\noindent{\tt
mged> {\em d ell} \\
mged>
}

to drop the ellipsoid from view.

\section{Solid Edit: Alter Torus}

\begin{figure}
\centering \includegraphics{est-top.ps}
\caption{Top View of a Torus.}
\label{est-top}
\end{figure}

\begin{figure}
\centering \includegraphics{est-sed.ps}
\caption{The Torus in Solid Edit State.}
\label{est-sed}
\end{figure}

This tutorial illustrates the application of the SOL EDIT state to the
torus solid.

\noindent{\tt
mged> {\em size 6} \\
mged> {\em in tor tor} \\
Enter X, Y, Z of vertex: {\em 0 0 0} \\
Enter X, Y, Z of normal vector: {\em 0 1 0} \\
Enter radius 1: {\em 1} \\
Enter radius 2: {\em 0.2} \\
mged>
}

Figure \ref{est-top} is the display of the torus solid in viewing state.
Since the
Z-axis is perpendicular to the viewing screen, a view of all sides cannot be
seen.

\noindent{\tt
mged> {\em Twist ROTY knob clockwise and restore} \\
mged> {\em Twist ROTX knob counter-clockwise and restore} \\
mged>
}

These actions generate a view of the torus that shows all sides,
as shown in Figure \ref{est-sed}.

\noindent{\tt
mged> {\em Select the ``Solid Illum'' entry in the button menu} \\
mged> {\em Move the mouse out of the menu area} \\
mged> {\em Click the mouse to enter SOL EDIT state} \\
mged>
}

The torus is a ring whose cross-section is a circle.  The distance from
the vertex to the center of the cross-section is r1 and r2 is the radius of
the circular cross section.

Let the points I and O be the intersection of the line x=-z and the torus.
Then,
\begin{center}
\begin{verbatim}
I = (-(r2-r1) cos 45, 0, (r2-r1) cos 45 )
O = (-(r2+r1) cos 45, 0, (r2+r1) cos 45 )
\end{verbatim}
\end{center}

\subsection{Translate Operation}

\begin{figure}
\centering \includegraphics{est-tr.ps}
\caption{Translating a Torus.}
\label{est-tr}
\end{figure}

\noindent{\tt
mged> {\em Select the ``Translate'' entry in the solid edit menu} \\
mged> {\em p -.5 -1 .5} \\
mged>
}

The vertex V of the torus is moved to (-.5, -1, .5).
See figure \ref{est-tr}.  The
coordinates of the other points remain the same, relative to the vertex.
The command

\noindent{\tt
mged> {\em p 0 0 0} \\
mged>
}

will restore the original position.

\subsection{Rotate Operation}

\begin{figure}
\centering \includegraphics{est-xrot.ps}
\caption{Torus Solid Edit Rotation about X.}
\label{est-xrot}
\end{figure}

\begin{figure}
\centering \includegraphics{est-yrot.ps}
\caption{Torus Solid Edit Rotation about Y.}
\label{est-yrot}
\end{figure}

\begin{figure}
\centering \includegraphics{est-zrot.ps}
\caption{Torus Solid Edit Rotation about Z.}
\label{est-zrot}
\end{figure}

\noindent{\tt
mged> {\em Select the ``Rotate'' entry in the solid edit menu} \\
mged> {\em p 45 0 0} \\
mged>
}

The torus is rotated 45 degrees counter-clockwise about the positive X axis.
The
coordinates of the points I and H are transformed using the following matrix:
\begin{verbatim}
    [x'] [1   0      0   ] [x]
    [y']=[0  .7071 -.7071] [y]
    [z'] [0  .7071  .7071] [z]
\end{verbatim}
See Figure \ref{est-xrot}.

\noindent{\tt
mged> {\em p 0 45 0} \\
mged>
}

The torus is rotated 45 degrees counter-clockwise about the positive Y axis.
See Figure \ref{est-yrot}.

\noindent{\tt
mged> {\em p 0 0 45} \\
mged>
}

The torus is rotated 45 degrees counter-clockwise about the positive Z axis.
See Figure \ref{est-zrot}.
The original orientation is restored by entering

\noindent{\tt
mged> {\em p 0 0 0} \\
mged>
}

\subsection{Scale Operation}

\begin{figure}
\centering \includegraphics{est-scale.ps}
\caption{Torus Scale Increased.}
\label{est-scale}
\end{figure}

\noindent{\tt
mged> {\em Select the ``Scale'' entry in the solid edit menu} \\
mged> {\em p 1.5} \\
mged>
}

The vertex remains the same and all distances from the vertex are
multiplied by 1.5, the value entered with p.  See Figure \ref{est-scale}.
To return to the original scale, enter

\noindent{\tt
mged> {\em p 1} \\
mged>
}

\subsection{Scale Radius 1 Command}

\begin{figure}
\centering \includegraphics{est-sr1.ps}
\caption{Scale Torus Radius 1.}
\label{est-sr1}
\end{figure}

\noindent{\tt
mged> {\em Select the ``edit menu'' entry in the solid edit menu} \\
mged> {\em Select the ``scale radius 1'' entry in the TORUS menu} \\
mged> {\em p 1.5} \\
mged>
}

The distance from the vertex to the center of the cross-section of the
ring is set equal to the values given with {\em p}, e.g., 1.5.
See Figure \ref{est-sr1}.
The original scale can be restored with

\noindent{\tt
mged> {\em p 1} \\
mged>
}

\subsection{Scale Radius 2 Command}

\begin{figure}
\centering \includegraphics{est-sr2.ps}
\caption{Scale Torus Radius 2.}
\label{est-sr2}
\end{figure}

\noindent{\tt
mged> {\em Select the ``edit menu'' entry in the solid edit menu} \\
mged> {\em Select the ``scale radius 2'' entry in the TORUS menu} \\
mged> {\em p 0.5} \\
mged>
}

The distance from the center of the cross-section of the ring is set equal
to the value given with {\em p}, e.g. 0.5.
This value must remain less than the value for r1.
See Figure \ref{est-sr2}.
The command

\noindent{\tt
mged> {\em p 0.2} \\
mged>
}

will restore the original shape.

To return control to the VIEWING state, select the ``REJECT Edit''
item on the button menu, press the ``reject'' button on the button box,
or enter the command {\em press reject} on the keyboard.
Then, enter

\noindent{\tt
mged> {\em d tor} \\
mged>
}

to drop the torus from view.


\documentclass{article}

\usepackage{amsmath,amssymb,amsthm,graphicx}
\usepackage{fullpage}
\usepackage{caption,subcaption}
\newtheorem{prob}{Problem}
\newtheorem{theorem}{Theorem}[section]
\newtheorem{lemma}{Lemma}[section]

\newenvironment{problem}
{
\renewcommand{\labelenumi}{(\alph{enumi})}
\renewcommand{\labelenumii}{\roman{enumii}.}
\begin{prob}
}
{
\end{prob}
 }
 \newcommand{\N}{\mathbb{N}}
 \newcommand{\Z}{\mathbb{Z}}
 \newcommand{\Q}{\mathbb{Q}}
 \newcommand{\R}{\mathbb{R}}
 \newcommand{\C}{\mathbb{C}}
 \newcommand{\bM}{\begin{bmatrix}}
 \newcommand{\eM}{\end{bmatrix}}
 \newcommand{\Ni}{\N\cup\{\infty\}}
  \newcommand{\rmD}[1]{\mathrm{d}#1}
\newcommand{\floor}[1]{\lfloor #1 \rfloor}
\title{Optimal Path Planning for Robotic Arms in Household Assistance}
\author{Vikram Sunder and Zachary Greenberg}

\begin{document}

\maketitle

\section{Abstract}
We investigated and implemented motion planning algorithms for a robotic arm. The algorithm computes a shortest path in a given metric space.  To find the optimal path, we considered various metrics on a graph in Configuration Space. For example we considered the Euclidean distance in work space, energy needed to transition between states, and the energy required to hold an object in the gripper. Currently we have a small mobile robot with a five degrees of freedom arm. The overall objective is for the robot to help with small household tasks. We simulated the motion of the arm in Matlab to evaluate the various paths.

\section{Introduction}
One of the main problems with bringing robots into the home is the cost of hight precision parts. Currently the cost of quality robotic arms is far beyond the price range of the average household. While they might be more accessible in the future, we want to experiment with a lower cost robotic arm currently available. The trade off here is decreased power and precession. Our robot has a small 5 degree of freedom arm, that we hope to use to pick up plates/cups or open doors. However, to maximize the set of objects we can manipulate and the duration of time that we can carry out interactions we need minimize the length of individual interactions and the energy required to carry them out.  The longer our arm takes to manipulate an object the more power it will consume from its highly limited power source.  Likewise the more torque required from the servos will translate to increased current draw and minimize the weight of the objects we can manipulate.  As such we must optimize our trajectories to meet these goals.

\section{The Robot}
Our robot uses Willow Garage's Turtlebot as a base. On top of this we have attached a PhantomX Reactor robotic arm. This arm has 5 degrees of freedom. It can rotate about the base to select a particular plane of motion.  There are then three degrees of freedom in this particular plane.  The last degree of freedom is a wrist joint. \ref{fig:DHparam} for the Denavit-Hartenberg parameters for the robot. \\
\begin{figure}[hb]
\centering
\begin{tabular}{|r|c|c|c|c|}
\hline
&$\alpha$ & a & d & $\theta$\\
\hline
\hline
1& $\frac{\pi}{2}$ & 0 & 26.5 & $\theta_0$\\
\hline
2& 0 & 150 & 0 & $\frac{\pi}{2}+\theta_1$\\
\hline
3& 0 & 150 & 0 & $\theta_2$\\
\hline
4& $\frac{\pi}{2}$& 0 & 0 & $\frac{\pi}{2}+\theta_3$\\
\hline
5& 0& 0& 116.525 & $\theta_4$\\
\hline
\end{tabular}
\caption{Denavit Hartenberg Paramaters}
\label{fig:DHparam}
\end{figure} \\
For path planning there are a few convenient things about the forward kinematics for this robot. The first is that the final angle, $\theta_4$ doesn't affect the final position of the robot. Therefore when searching configuration space, any algorithm doesn't need to search changes in $\theta_4$. Similarly $\theta_0$ only affects what plane the robot needs to be in. In a configuration space only constrained by angle limits, it is a simple computation to figure out what plane the goal point is in. Then $\theta_0$ can be calculated to point the arm in that plane. Thus we only have to search the space defined by $\theta_1,\theta_2,\theta_3$. This cuts the search space from a five dimensional space to a three dimensional space. It also solves one workspace variable, which leaves only $x,z,\alpha$ where $\alpha$ is the pitch of the end effector.
\section{Path Planning}
Instead of computing the inverse kinematics for the arm, we decided to search the configuration space using a shortest path algorithm and use the forward kinematics to stop. From above we saw that only 3 angles had to be searched over. From there we discretized the space by placing nodes at even intervals along all three dimensions. Let a tick be the length of the intervals in radians. Then we connected any two nodes that differed by one tick in some coordinate. This created a graph to search over. Currently we are using a tick size of $\frac{\pi}{100}$ radians, but eventually a tick will correspond to the precision of the servos. This tick size gave us enough precision to find smooth paths, without making the graph too big.\\
We considered several search algorithms for the graph and eventually settled on $A^*$. We looked into $D*$, but since we chose not to consider any moving obstacles, we did not have to recompute the paths as we searched. This meant that the added complexity of $D*$ wasn't helpful. $D*$ also isn't any faster then $A*$ to find the initial path. The other search algorithm we considered was RRT. RRT is fast, but does guarantee an optimal path. The advantage of RRT is its ability to search high-dimensional non-convex spaces.  Given the number of degrees of freedom available to us this is not advantageous or necessary. Once we optimized our $A^*$ code for speed, it was fast enough to search the entire space. This combined with the simplicity of $A^*$ made it the best choice.\\
The next thing that we needed to do was find a consistent and admissible heuristic. The simplest metric we could use was the Euclidean distance in the work space between the nodes. The standard heuristic for this space is the euclidean distance to the target. When we changed the metric, we wanted an easy way to determine a heuristic. So for every new metric we added the cost to the euclidean distance. Let $c(v,w)$ be the added cost function. Let $d(v,w)$ be the euclidean distance between the nodes. So the weight of an edge $(u,v)$ is $c(v,w)+d(v,w)$. Then let $h(v)$ be the distance from $v$ to the target, $g$. So for an edge $(u,v)$ we have:
\begin{align*}
h(v) =& d(v,g)\\
\leq& d(v,w) + d(w,g) & \text{[triangle inequality]}\\
\leq& d(v,w) + c(v,w) + d(w,g) & [c(v,w)>0]\\
\leq& w(\{u,v\}) +h(g)
\end{align*}
So as long as our additional cost is always positive, the standard distance heuristic is always consistent.

\section{Metrics }
\subsection{Euclidean Work Space}
The first metric we tried was looking at the euclidean distance in the work space. So if $FK$ was the function that maps angles to work space, the cost between nodes $u$ and $v$ is $d_{e}(FK(u),FK(v))$. In path planning in addition to specifying a position we might want to specify an orientation of the arm. For this arm the orientation we care about is the sum of $\theta_1,\theta_2,\theta_3$, which we will call $\alpha$.
So we will add to the distance between nodes $|\Delta\alpha|$ and add $|\alpha- \alpha_{target}|$ to the heuristic. Everything is still consistent so $A^*$ still works. This gives two different metrics, the basic distance, which considers orientation, and the no-alpha metric, which does not. See Figure {fig:basicPaths} to see the difference in the paths found for each metric.\\
\begin{figure}[htb]
\centering
\begin{subfigure}[b]{0.5\textwidth}
\centering
\includegraphics[scale=.5]{PathPics/Basic_Path.jpg}
\caption{Orientation Path}
\end{subfigure}%
~
\begin{subfigure}[b]{0.5\textwidth}
\centering
\includegraphics[scale=.5]{PathPics/NoAlpha_Path.jpg}
\caption{No Orientation Path}
\end{subfigure}

\caption{Euclidean Distance Paths}
\label{fig:basicPaths}
\end{figure}\\

\subsection{State Maintenance Method 1}

	From here, so long as we add positive weights to the existing costs of edges in our graph our heuristic will remain consistent and admissible.  Power is a major constraint for our robot. The amount of force the arm can output is highly limited, as is the amount of power available to the robot to carry out its various actions and functions.  As such we want to make all our motions as energy efficient as possible.  To do this we used the fact that the torque output of every actuator correlates to its energy consumption.  Therefore we will attempt to minimize the sum of the total torque of each state on a given path.  Let J be the Jacobian of the forward kinematic map of our robotic arm.  The Jacobian transpose will provide us with a linear map from forces applied by the arm to the output torques of the individual joints.  Thus we can calculate the torques required to generate a force at the end effector to counteract the force of gravity on object we are manipulating.   The cost of the edge between two configuration states $u$ and $v$ is as follows:

\[	d(u,v) =  \left\|(FK(u)-FK(v))\right\|^2 + \left\|J^T_v\bM 0 \\ 0 \\ mg \eM\right\|^2\]
Figure \ref{fig:EnergyPaths1} shows the different paths obtained by considering this energy.
\begin{figure}[htb]
\centering
\begin{subfigure}[b]{0.5\textwidth}
\centering
\includegraphics[scale=.3]{PathPics/Wrench_Path.jpg}
\caption{Orientation Path}
\end{subfigure}%
~
\begin{subfigure}[b]{0.5\textwidth}
\centering
\includegraphics[scale=.3]{PathPics/Wrench_NoAlpha_Path.jpg}
\caption{No Orientation Path}
\end{subfigure}

\caption{Paths When Considering Energy To Hold Up an Object}
\label{fig:EnergyPaths1}
\end{figure}\\
\subsection{State Maintenance Method 2}

	One of the issues with this is that it does not take into account the transition from one state to the next.  To do this we use the ratio of the torque at the new state to the torque at the old state.  This causes a transition to a state that requires more torque to have a higher cost and a transition to a lower state have lower cost.  Our cost function here where u is the initial state and v is the next state is as follows:

	 \[	d(u,v) =  \left\|(FK(u)-FK(v))\right\|^2 + \frac{\left\|J^T_v\bM 0 \\ 0 \\ mg \eM\right\|^2}{\left\|J^T_u\bM 0 \\ 0 \\ mg \eM\right\|^2}\]

Figure \ref{fig:EnergyPaths2} compares taking the ratio of these torques to the original formulation, of looking at the torque needed to hold the next state. You can see that the ratio of torques resulted in a shorter, smoother path to the goal.\\
\begin{figure}[htb]
\centering
\begin{subfigure}[b]{0.5\textwidth}
\centering
\includegraphics[scale=.3]{PathPics/Wrench_Path.jpg}
\caption{Path When Only Considering The Next State}
\end{subfigure}%
~
\begin{subfigure}[b]{0.5\textwidth}
\centering
\includegraphics[scale=.3]{PathPics/Wrench_Ratio_Path.jpg}
\caption{Path for Ratio of Torques}
\end{subfigure}

\caption{Paths When Considering Energy To Hold Up an Object}
\label{fig:EnergyPaths2}
\end{figure}\\

\subsection{Kinetic Energy}
The final set of metrics we considered take into account the kinetic energy needed to move from state to state. To simplify this problem we assume the arm is massless except for a mass in the end effector. \\
Once again the Jacobian $J$, comes in handy as a map from from angular velocity to linear velocity. Let $\dot{\theta}$ be the difference in angles between the states $(u,v)$ divided by a time-step $h$. Then the linear kinetic energy of the object the arm is carrying is:
 \[E_{linear} = \frac{1}{2}m \|J_u\dot{\theta}\|^2\]. \\
For angular kinetic energy we approximated the actual value. We assumed that each angle contributes equally to angular kinetic energy and rotates about the same point. This is a significant simplification, but it saves on computation time and complexity. In order to calculate the actual rotation energy, we would need to compute the locations of each joint, not just the end effector in the search, which is at least three times slower. With this approximation our angular kinetic energy is:
\[E_{angular} = \frac{1}{2}m \left\|\frac{\Delta\theta_1+\Delta\theta_2+\Delta\theta_3)}{h}\right\|^2\]
The final metric we considered was the total kinetic energy between points, which is the sum of the previous two metrics.\\
Figure \ref{fig:KineticPaths} shows the paths for these three metrics. In this path you can see that the total kinetic energy path is identical to the linear kinetic energy path. This is most likely due to the level of approximation in our angular kinetic energy calculations.\\
\begin{figure}[htb]
\centering
\begin{subfigure}[b]{0.33\textwidth}
\centering
\includegraphics[scale=.33]{PathPics/Energy_Linear_Path.jpg}
\caption{Linear Kinetic Engery Path}
\end{subfigure}%
~
\begin{subfigure}[b]{0.33\textwidth}
\centering
\includegraphics[scale=.33]{PathPics/Energy_Angular_Path.jpg}
\caption{Angular Kinetic Energy Path}
\end{subfigure}%
~
\begin{subfigure}[b]{0.33\textwidth}
\centering
\includegraphics[scale=.33]{PathPics/Energy_Kinetic_Path.jpg}
\caption{Total Kinetic Energy Path}
\end{subfigure}

\caption{Paths When Considering Kinetic Energy}
\label{fig:EnergyPaths2}
\end{figure}\\
\section{Conclusion}
Overall the smoothest path we found was paths that accounted for the total/linear kinetic energy. In this case we specified position and orientation and still found a smooth path to the goal. Using just Euclidean distance if we don't care about orientation the algorithm finds a smooth path. But when trying to find a path with orientation as well it moves into position and then struggles to change orientation without moving too far away from the target. By considering the energies the algorithm can find paths that change orientation on the way even if takes more distance. \\
In practice specifying orientation of the arm will be important. In order to pick up objects, the arm must grip them in a specific way and then place them the right way up. If the path planning can't specify an angle it won't be able to do this. Therefore either including kinetic energy or the cost of holding a position is important for getting smooth paths. Which of these two methods to use depends on the weight of the object you are holding and how long it will stay at each state.
\section{Future Work}
In the future there are several other metrics to consider. One thing to do is to remove the approximations on angular kinetic energy to get a better optimization. Another metric to consider would be the combination of the Kinetic Energy with the cost to hold up an object. These two costs would need to be scaled appropriately to determine which was more important. In general we can continue to work on developing a more accurate physics model of the arm to accurately determine the cost of individual motions. \\
Another way to improve the smoothness of the paths found is to make the tick size smaller. This increases the size of the grid, but lets the robot check more paths. Unfortunately the complexity of the problem is cubic in the grid size, so even small increases in size quickly become too expensive to compute. This is especially true, if the cost of each edge is doing a lot of complicated forward kinematics for each joint and energy calculations.\\
Outside of our simulation, the robot will need to navigate in a house to perform tasks. So it will need to plan a path to move before, it plans a path for the arm. Choosing where to move is another optimization problem in and of itself. There is a shell in the workspace of the arm, where it is more maneuverable and can reach more orientations. Ideally a complete path planning algorithm would move the robot so that the target is in that zone. Alternatively we can relax the constraints on arm position and use the addition of the mobile base to enhance possible manipulations\\
Finally this algorithm needs to move beyond simulation and on to an actual robot. In practice it might be apparent that certain paths are less prone to drifting and accumulating error. This would provided a decisive case for one metric over the other.
\end{document}


\section{Progress}
	During past weeks, we've built a proof-of-concept ASR system based on
	MFCC feature and GMM for modeling spearker with fine-tuned parameters.

	A brief performance summary:
	\begin{itemize}
		\item $10s\sim15s$ training corpus per person.
		\item $2s\sim5s$ test corpus per person.
		\item We adopted GMM with $32$ Gaussians.
		\item Accuracy on 5 speakers is about 93 percent
		\item Accuracy on 10 speakers is about 90 percent
	\end{itemize}

	It turns out that, our method worked well when the condition that the number of
	speakers is limited to 5 or less is met. But as we employed the new dataset
	which provided by teacher this week, which contains 102 speaker, comprised
	of 60 females and 42 males, in three speaking conditions: reading,
	spontaneous and whisper, the challenge we are facing is beyond our expectation.

	Although we fulfilled the plan we aforementioned in opening report, the overall
	performance is still unsatisfying.
	The main reason that MFCC + GMM approach suffers from new corpus is that,
	using solely MFCC limits the model we can use to generative models,
	which in turns brings computation inefficiency to feature extraction, model
	training and testing.


\paragraph{}
The several algorithms that are being used warrant having some high-level pseudocode written in order to better explain their operation in the programming, those that where omitted are either highly implementation specific or basic equations.

\setcounter{algorithm}{1}

\begin{algorithm}[H]
\caption{Calculation of All Forces}
\begin{algorithmic}[1]
\FOR{$Body_A \leftarrow 1$ \TO Bodies}
  \FOR{$Body_B \leftarrow (Body_A-1)$ \TO Bodies}
    \IF{$Body_B \neq Body_A$}
      \STATE $Matrix_F[Body_A][Body_B] \leftarrow calculateForce(Body_A, Body_B, x)$
      \STATE $Matrix_F[Body_B][Body_A] \leftarrow calculateForce(Body_A, Body_B, y)$
    \ENDIF
  \ENDFOR
\ENDFOR
\end{algorithmic}
\end{algorithm}

\begin{algorithm}[H]
\caption{Summation of All Forces}
\begin{algorithmic}[1]
\FOR{$Body_A \leftarrow 1$ \TO Bodies}
  \FOR{$Body_B \leftarrow 1$ \TO Bodies}
    \IF{$Body_B \neq Body_A$}
      \IF{$Body_B < BodyA$}
        \STATE $Body[xAccess]_F~-\leftarrow Matrix_F[Body_B][Body_A]$
        \STATE $Body[yAccess]_F~+\leftarrow Matrix_F[Body_A][Body_B]$
      \ELSE
        \STATE $Body[xAccess]_F~+\leftarrow Matrix_F[Body_A][Body_B]$
        \STATE $Body[yAccess]_F~-\leftarrow Matrix_F[Body_B][Body_A]$
      \ENDIF
    \ENDIF
  \ENDFOR
\ENDFOR
\end{algorithmic}
\end{algorithm}

\begin{algorithm}[H]
\caption{Integration of New Position}
\begin{algorithmic}[1]
\IF{$ScenarioChange$}
  \STATE $CalculateForceMatrix()$
  \STATE $SumAllForcesToBodies()$
  \STATE
  \FOR{$bC \leftarrow 1$ \TO $Bodies$}
    \STATE \COMMENT{Acceleration}
    \STATE $Body[bC]_{ax} \leftarrow Body[bC]_{Fx}/Body[bC]_{m})$
    \STATE $Body[bC]_{ay} \leftarrow Body[bC]_{Fy}/Body[bC]_{m})$
  \ENDFOR
  \STATE
  \STATE $ScenarioChange \leftarrow false$
\ENDIF
\STATE
\FOR{$bC \leftarrow 1$ \TO $Bodies$}
  \STATE \COMMENT{Half-Velocity}
  \STATE $Body[bC]_{vx} ~+\leftarrow 0.5(Body[bC]_{ax}\times\Delta{t})$
  \STATE $Body[bC]_{vy} ~+\leftarrow 0.5(Body[bC]_{ay}\times\Delta{t})$
  \STATE \COMMENT{Position}
  \STATE $Body[bC]_{rx} ~+\leftarrow Body[bC]_{vx}\times\Delta{t}$
  \STATE $Body[bC]_{ry} ~+\leftarrow Body[bC]_{vy}\times\Delta{t}$
\ENDFOR
\STATE
\STATE $CheckCollisions()$
\STATE
\STATE $CalculateForceMatrix()$
\STATE $SumAllForcesToBodies()$
\STATE
\FOR{$bC \leftarrow 1$ \TO $Bodies$}
  \STATE \COMMENT{Acceleration}
  \STATE $Body[bC]_{ax} \leftarrow Body[bC]_{Fx}/Body[bC]_{m})$
  \STATE $Body[bC]_{ay} \leftarrow Body[bC]_{Fy}/Body[bC]_{m})$
  \STATE \COMMENT{Half-Velocity}
  \STATE $Body[bC]_{vx} ~+\leftarrow 0.5(Body[bC]_{ax}\times\Delta{t})$
  \STATE $Body[bC]_{vy} ~+\leftarrow 0.5(Body[bC]_{ay}\times\Delta{t})$
\ENDFOR
\end{algorithmic}
\end{algorithm}

\begin{algorithm}[H]
\caption{Collision Detection and Simulation}
\begin{algorithmic}[1]
\FOR{$bC_A \leftarrow 1$ \TO $Bodies$}
  \FOR{$bC_B \leftarrow (bC_A-1)$ \TO $Bodies$}
    \IF{$bC_B \neq bC_A$}
      \STATE $Distance \leftarrow calculateDistance(bC_A, bC_B)$
      \IF{$Distance < (Body[bC_A]_r+Body[bC_B]_r)$)}
        \STATE $p_{x} \leftarrow ((Body[bC_A]_m \cdot Body[bC_A]_{vx}) + (Body[bC_B]_m \cdot Body[bC_B]_{vx}))$
        \STATE $p_{y} \leftarrow ((Body[bC_A]_m \cdot Body[bC_A]_{vy}) + (Body[bC_B]_m \cdot Body[bC_B]_{vy}))$
        \STATE
        \STATE $Body[bC_A]_m \leftarrow (Body[bC_A]_m+Body[bC_B]_m)$
        \STATE $Body[bC_A]_{vx} \leftarrow (p_{x}/Body[bC_A]_m)$
        \STATE $Body[bC_A]_{vy} \leftarrow (p_{y}/Body[bC_A]_m)$
        \STATE
        \STATE $DeleteBody(bC_B)$
      \ENDIF
    \ENDIF
  \ENDFOR
\ENDFOR
\end{algorithmic}
\end{algorithm}


% !TeX root = ./documentation.tex

\chapter{Implementation}
\label{ch:implementation}
As mentioned before in the chapter \ref{ch:tecBasics} we will be using Node.js with Parcel as a module bundler. This way we can use Node.js modules and build an HTML page that does not require a Node.js server running in the background, making it portable and executable without any prerequisites except for a browser. The implementation in JavaScript will be an object oriented approach using the class syntax introduced in ECMAScript 2015, which will make it more pleasing for the eye and less confusing \cite{MozillaDevelopers2019}.

Since the Davis-Putnam algorithm can have tasks with a high computational effort, we decided to use separate threads to compute and animate. So we can display all the changes to the problem as it is being satisfied and prevent the GUI from freezing on long lasting computations. As previously explained in chapter \ref{sec:tecWorker} this is possible with a so-called worker in JavaScript. It is important to mention here, that because the worker and main script communicate with each other via messages, we need to make sure that while computing no unwanted messages are send. Such messages could be multiple computing request being send almost simultaneously to the worker, because the worker will buffer send messages and respond to them after finishing all previous tasks. This could lead to problems if for example during a long lasting computation task additional computations are requested, then no other requests could be handled before all those computation tasks have been finished nor could those be interrupted. Our approach here will be to tell the main script when a computational task started and ended. This way certain UI elements can be locked while the worker computes and unlocked when the worker finishes the given task.

Next we need to take a look at the mathematical part of the script. Because JavaScript uses references when comparing objects, we will use Immutable.js as discussed in chapter \ref{sec:tecImmutable} to counter this problem when working with sets. Since we will have a set of clauses for the algorithm to satisfy with those clauses being sets of literals, we would need to implement a deep compare ourselves if we were to use native JavaScript. Now that we know that Immutable.js will solve the set comparison problem, the literals still need to be implemented somehow. We decided to use simple strings for the literals with the restriction of the first character not being allowed to be an ``!'', as we will use that character to indicate that the literal is negated. The choice to use strings is based on the same reason for using Immutable.js for the sets. Immutable.js has immutable structures that are compared by value, but for other objects Immutable.js compares them just like native JavaScript by their object references. This means if we were to use custom classes for literals we would need to implement a deep compare anyway, but strings on the other hand are compared by length and character order by default. Resulting in less effort when implementing the mathematical part of the algorithm \cite{MozillaDevelopers2019a}, \cite{MozillaDevelopers2019b}, \cite{ImmutableDevelopers2019}.
% Equal operator https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Comparison_Operators#Equality_operators
% Object is https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/is
% Immutable is https://immutable-js.github.io/immutable-js/docs/#/is

So for example the formula $(\; p\; \lor\; \neg q\; )\; \land\; (\; s\; \lor\; r\; )$ would be implemented as the following Listing \ref{code:setOfClauses} with \texttt{Set} being the Set class of Immutable.js and not the native JavaScript one.

\begin{listing}[H]
\begin{minted}{javascript}
// (p or not q) and (s or r) as a set of clauses in JavaScript
let set_of_clauses = new Set(new Set('p', '!q'), new Set('s', 'r'));
\end{minted}
    \caption{Example for a set of clauses in JavaScript}
    \label{code:setOfClauses}
\end{listing}

Now that it is clear how a set of clauses will be implemented in JavaScript and the decision to use two threads has been made, we can start getting into the classes and their tasks.

\section{Util Object}
\label{sec:impUtil}
Because some functions like negating a literal will be used in multiple parts of the script, we will use an object to host these functions. This object will be called the Util Object. By doing so it can be imported when those functions are needed and prevent redundant code, making it easy to maintain or change.

It contains the function to negate a literal and functions for formatting sets and literals to HTML strings. It can be expanded further in future, but for now these will do.
Because we are using strings for literals we can negate them by adding a ``!'' and applying a simple RegEx operation afterwards as shown in the following Listing \ref{code:negateLiteral}.

\begin{listing}[H]
\begin{minted}{javascript}
Util.negateLiteral = (literal) => return ('!' + literal).replace(/^!!/, '');
Util.negateLiteral('p');  // result: !p
Util.negateLiteral('!p'); // result: p
\end{minted}
    \caption{Example for negating a literal in JavaScript}
    \label{code:negateLiteral}
\end{listing}

Formatting sets and literals to HTML, using the span element and adding classes to it, will allow us to color code them in the GUI. This will make it easier for the user to interpret the visuals of the animation.

\section{Implementing the Algorithm of Davis-Putnam}
\label{sec:impDavisPutnam}
The original \textit{Davis-Putnam algorithm} is recursive and so are most of its implementations. If you were to calculate everything till you find a possible solution or the response that the given problem can not be satisfied, then a recursive implementation is not an issue. For our purposes, which is the visualization of the algorithm as it solves the given problem step by step, we prefer to use an iterative implementation. If we use a recursive implementation we would need to calculate everything upfront, which is not the case for a iterative implementation. These can be paused at any point and because of that we can calculate the step when we need it to be calculated. This means only the creation of the problem that will be satisfied by the algorithm will affect the initial loading time.

One of the challenges here is the double recursive call of the algorithm and splitting it into single unit cuts per iteration for the micro steps. The basic idea will be a class that holds the current state of the problem with a step function that does either a macro or micro step further satisfying the problem till it is satisfied or not satisfiable. One macro step will include all micro steps till the algorithm guesses the next literal, with micro steps being single unit cuts. To be able to do this the class also needs to know what has been done previously to continue from that point. With that in mind the following points will be able to describe the state of the algorithm, so that it can continue from where it stopped.

\begin{enumerate}
    \item The set of clauses describing the current state of the problem
    \item The literals it has guessed previously
    \item The unit clauses it has already used for unit propagation
    \item The unit clause or literal that is currently in use for unit cuts
\end{enumerate}

The last point is important for the micro steps, because we need to do all possible unit cuts before using the next unit clause. Because it is possible to represent the state of the algorithm, we can also use this to simulate the double recursive call. By pushing the current state with the negation of the guessed literal to the stack and adding the guessed literal to the current state for further satisfaction, we can pop a state from the stack to continue from that point if the current state is not satisfiable.

Because we will use an iterative implementation, we need to think about everything that needs to be done in one step of the iteration. Since we will have macro and micro steps, we will use two loops one for the macro steps and one for the micro steps, so that one macro step will execute all micro steps that it includes. Lets say we have a function step that receives a number of steps $n$ so that it will do $n$ micro or macro steps on the state. Then we need to reduce the step count when a guessed literal $L$ has been added to the state, in case of macro steps, or a unit cut has been calculated, for micro steps. The function step would look like the pseudo code of Listing \ref{code:stepDavisPutnam}. Doing all micro steps at the start of a macro step results in checking if it is satisfied. If it is not satisfiable, it is followed by a backtrack and the guessing of a new literal.

\begin{listing}[h!]
    \textit{/* do step(s) on a state that contains a set of clauses $S$ */}\\
    \textbf{function} step( number of steps $n$ ) \textbf{return}\\
        \hspace*{0.5cm} \textbf{repeat} \textit{/* macro step loop */}\\
            \hspace*{1.0cm} \textbf{repeat} \textit{/* micro step loop for subsume and unit cuts */}\\
                \hspace*{1.5cm} \textit{/* select a new literal and subsume till unit cuts can be done with said literal */}\\
                \hspace*{1.5cm} \textbf{repeat}\\
                    \hspace*{2cm} choose a unit clause $U$ that has not been used yet\\
                    \hspace*{2cm} add $U$ to used unit clauses of the state\\
                    \hspace*{2cm} choose and remember literal $L$ from $U$\\
                    \hspace*{2cm} \textit{/* unit subsumption */}\\
                    \hspace*{2cm} delete from $S$ every clause containing $L$\\
                \hspace*{1.5cm} \textbf{until} all unit clauses have been used or clauses in $S$ contain $\bar{L}$\\
                \hspace*{1.5cm} \textit{/* check if cuts can be done before trying to do a unit cut */}\\
                \hspace*{1.5cm} \textbf{if} clauses in $S$ contain $\bar{L}$ \textbf{then}\\
                    \hspace*{1.5cm} \textit{/* single unit resolution */}\\
                    \hspace*{2cm} choose one of the smallest clauses $C$ that contains $\bar{L}$\\
                    \hspace*{2cm} delete $\bar{L}$ from $C$\\
                    \hspace*{2cm} \textbf{if} it is a micro step \textbf{then}\\
                        \hspace*{2.5cm} $n \texttt{-=} 1$\\
                    \hspace*{2cm} \textbf{fi}\\
                \hspace*{1.5cm} \textbf{fi}\\
            \hspace*{1.0cm} \textbf{until} all unit clauses have been used or $n = 0$\\
            \hspace*{1.0cm} \textit{/* check if satisfied */}\\
            \hspace*{1.0cm} \textbf{if} $S$ contains only unit clauses \textbf{then}\\
                \hspace*{1.5cm} \textit{/* is satisfied */}\\
                \hspace*{1.5cm} \textbf{continue}\\
            \hspace*{1.0cm} \textbf{else if} $n = 0$ \textbf{then}\\
                \hspace*{1.5cm} \textbf{continue}\\
            \hspace*{1.0cm} \textbf{fi}\\
            \hspace*{1.0cm} $n \texttt{-=} 1$\\
            \hspace*{1.0cm} \textit{/* check if current state is not satisfiable */}\\
            \hspace*{1.0cm} \textbf{if} a clause becomes $\{\}$ in $S$ \textbf{then}\\
                \hspace*{1.5cm} \textbf{if} stack is empty \textbf{then}\\
                    \hspace*{2cm} \textit{/* is not satisfiable */}\\
                    \hspace*{2cm} set $S = \{\;\{\}\;\}$\\
                    \hspace*{2cm} \textbf{continue}\\
                \hspace*{1.5cm} \textbf{fi}\\
                \hspace*{1.5cm} pop state from the stack\\
                \hspace*{1.5cm} \textbf{continue}\\
            \hspace*{1.0cm} \textbf{fi}\\
            \hspace*{1.0cm} choose and remember a literal $L$ occurring in $S$\\
            \hspace*{1.0cm} push state with literal $\bar{L}$ to the stack\\
            \hspace*{1.0cm} add literal $L$ to the current state\\
        \hspace*{0.5cm} \textbf{until} no further steps can be done or $n = 0$\\
        \hspace*{0.5cm} \textbf{return}\\
    \textbf{end function}\\
    \caption{Iterative step for \textit{Davis-Putnam algorithm}}
    \label{code:stepDavisPutnam}
\end{listing}

\subsection{Davis-Putnam Class}
\label{sub:impDavisPutnam}
As previously explained we need a stack of states to provide an iterative implementation of the \textit{Davis-Putnam algorithm}. For this purpose we create a Davis-Putnam class. Its primary features are that it contains a state, a stack of states and a function to execute a macro or micro step on the state. Because the algorithm is supposed to be animated we have to pass the operations on the set of clauses and the unit clauses of the set of clauses to represent the state. This can be done with event listeners, that are called on the important operations of the algorithm. Since there are a number of events we decided to use a class that contains functions to be called when those events happen. These events are as follows:

\begin{enumerate}
    \item set of clauses satisfied
    \item set of clauses not satisfiable
    \item backtrack
    \item choose a literal
    \item subsume
    \item unit cut
\end{enumerate}

Each of those events calls will receive the important information needed to describe the operation and state of the set of clauses. They all receive the literals of the unit clauses, so we can represent the state at those points. The first three do not need any additional information, but the later do. When a literal is chosen said literal will also be handed to the function for the event. The function for subsume will receive all removed clauses and the function for unit cut receives the used literal and the clause before and after the operation. This way all operations during one step can affect the animation.

Since the animation is for educational purposes, it is also important to be able to replicate the results. Therefor we will be using Seedrandom.js as mentioned in chapter \ref{sec:tecSeed} at this point. When choosing a random element in this class we will use our own random number generator that we initialize with a seed. This way each seed has its unique repeatable calculation. It is important to mention here that this is also only possible because of the way the Set class from Immutable.js works. ``When iterating a Set, the entries will be (value, value) pairs. Iteration order of a Set is undefined, however is stable. Multiple iterations of the same Set will iterate in the same order \cite{ImmutableDevelopers2019a}.'' % Immutable.js Set https://immutable-js.github.io/immutable-js/docs/#/Set

\subsection{Davis-Putnam Consumer Class}
\label{sub:impDavisPutnamConsumer}
This class is for handling the events of the Davis-Putnam class. It contains the following functions:

\begin{enumerate}
    \item onSatisfied
    \item onNotSatisfiable
    \item onBacktrack
    \item onChoose
    \item onSubsume
    \item onUnitCut
\end{enumerate}

Those functions are basically placeholders, since the class is supposed to be extended by a subclass. The subclass should alter these functions to their needs. Other than that this class has no further purpose.

\subsection{Davis-Putnam Worker Class}
\label{sub:impDavisPutnamWorker}
As said before we will have a worker for the calculations. This class initializes a worker for the main script to do all the calculations. It extends the Davis-Putnam Consumer from the previous chapter \ref{sub:impDavisPutnamConsumer}. It will create its own Davis-Putnam instance and add itself as a consumer, so that all events from said instance will call the functions of this class. When these functions are called the worker will send messages to the main script with all the information. In addition to those messages it will also tell the main script when it starts or stops calculating, because of the potential problem named previously in chapter \ref{ch:implementation}. These will be all outgoing messages. As for the incoming messages from the main script, we will accept requests for a new set of clauses, a seed for the Davis-Putnam class, switching between micro and macro steps, and to calculate the next step.

Because the worker and main script communicate via messages only, there is only one listener for all those events. To be able to distinguish between the different requests we will define a default message structure as shown in the following Listing \ref{code:workerMessage}.

\begin{listing}[h!]
\begin{minted}{javascript}
// message example
let message = {
    'cmd': command_name,
    'options': {
        'option_1': value_1,
        'option_2': value_2
    }
}
\end{minted}
    \caption{Worker message example}
    \label{code:workerMessage}
\end{listing}

The ``cmd'' value will indicate what kind of request it is and the ``options'' object will contain all the information needed to fulfill that request. This way the listener can be implemented with a simple switch-case to handle the requests as shown in the following Listing \ref{code:workerListener}.

\begin{listing}[h!]
\begin{minted}{javascript}
// listen to events
self.addEventListener('message', event => {
    let cmd = event.data.cmd;
    let options = event.data.options;

    // handle commands
    switch(cmd) {
        case 'seed':
            // handle seed change
            break;
        case 'clauses':
            // handle clauses change
            break;
        case 'micro':
            // handle micro/macro change
            break;
        case 'step':
            // handle step
            break;
        default:
            // undefined command
    }
});
\end{minted}
    \caption{Event listener of the Davis-Putnam Worker class}
    \label{code:workerListener}
\end{listing}

With the components of the calculation thread finished, we are only missing those of the animation thread.

\section{Implementing the N-Qeens Problem}
\label{sec:impQueens}
To be able to solve a problem with the \textit{Davis-Putnam algorithm}, a propositional formula needs to be defined in JavaScript. Therefore we will create a function to return for a given number $n$ a set of clauses that express the \textit{N-Queens Problem} for said $n$. The queens will be represented by a literal of the form ``row,col'' and the negated literal will mean that no queen can be placed there. Lets say for example we have $\texttt{row} := 3 \land \texttt{col} := 4$ then the literal for the queen would be as follows ``3,4'' and the negation would be ``!3,4''. This makes it easy to transform the string back into coordinates for the chessboard.

\subsection{Queens Clauses Function}
\label{sub:impQueensClauses}
This function returns a set of clauses for the \textit{N-Queens Problem}, so that for a given $n$ the problem will be to place $n$ queens on a $n \times n$ board. To create this set of clauses the following functions are used to help:

\paragraph{atMostOne}
Returns a set of clauses that allows only one of the given literals to be true, for a given set of literals.

\paragraph{atMostOneInRow}
Returns a set of clauses where only one of the row can be true, for a given $n$ and $row$.

\paragraph{oneInColumn}
Returns a set of clauses where at least one in the column is true, for a given $n$ and $column$.

\paragraph{atMostOneInUpperDiagonal}
Returns a set of clauses where only one in the upper diagonal can be true, for a given $n$ and helper variable $k$.

\paragraph{atMostOneInLowerDiagonal}
Returns a set of clauses where only one in the lower diagonal can be true, for a given $n$ and helper variable $k$.

\subsection{Chessboard Class}
\label{sub:impChessboard}
To visualize the \textit{N-Queens Problem}, we will use Two.js as mentioned before in chapter \ref{sec:tecTwo}. The Chessboard class will receive a number $n$ and create a visual representation of a $n \times n$ chessboard. Since the state of the set of clauses will be represented by the literals of the unit clauses, we will need two different indicators per tile of the board. We decided to represent the queen by a green dot and a negative literal by a red cross.

The chessboard will have four layers the first being the board itself, the second for the $n \times n$ tiles of the board, the third for the queens and the last for the crosses. This way we can initialize the board with all needed Two.js objects and add or remove them from their specific layers. To only add or remove changes between two states, the chessboard will remember the state to be able to compare it with the new state. This will result in a smoother animation and less visual changes.

As for scaling of the chessboard, we will scale the Two.js scene to fit the parent HTML container with a listener that gets called when the window resizes.

\section{Implementing User Interaction}
\label{sec:impUI}
Now that we have the \textit{Davis-Putnam algorithm} and \textit{N-Queens Problem} set up in JavaScript, we need to enable the user to interact with it. In chapter \ref{ch:conception} we talked about the design. Said design will be used as a reference for the GUI of the animation. Therefor we need an HTML, CSS and JavaScript file for the webpage.

As for the interaction of the User with the animation, we will enable the user to do the following:

\begin{enumerate}
    \item change the seed for the Davis-Putnam class,
    \item change the number $n$ for the \textit{N-Queens Problem} affecting also the visualization,
    \item toggle between micro and macro steps,
    \item request the next step to be animated,
    \item request to automatically animate all steps until requested to stop or no further steps can be done,
    \item reset the whole animation to run it again from the start,
    \item display previous calculated states of the shown steps.
\end{enumerate}

For all points except the last one we got corresponding elements for interaction incorporated into the design. To enable the user to display previous states, we decided to make the elements of the calculation history clickable.

\subsection{HTML Document}
\label{sub:impHTML}
The HTML file contains all important elements needed for the GUI with their unique ids to access them via JavaScript. No additional GUI elements will be added with JavaScript except for populating the calculation log. For changing GUI elements, we will be using the ``checkbox hack''. This way we do not need to change the style of the GUI with JavaScript and additional listeners, focusing the JavaScript part only on the interaction with the worker and visual representation by the chessboard \cite{Coyier2012}.
% checkbox hack https://css-tricks.com/the-checkbox-hack/

\subsection{CSS Document}
\label{sub:impCSS}
For the layout we decided to use a grid based design, to be able to make it somewhat responsive. We added only one break-point for the smallest size we want the GUI to have, so that the chessboard has an acceptable minimal size. For larger screens it will scale up accordingly.

\subsection{Frame Class}
\label{sub:impFrame}
To initialize the animation and all its needed components, we created a Frame class. This class contains all the functions for the user interaction, the worker for the calculations and the chessboard object for visualization. It creates all the listeners for the UI elements and handles the communication with the worker. To synchronize the animation with the worker the user interface elements that should not be triggered will be disabled during the calculation process of the worker and enabled at the end of said calculation. This way we prevent unwanted behavior of the worker. Whenever the worker sends a message containing an important step of the calculation a new entry will be created for the calculation history. New entries will be added before the previous entries, so that the top entry is the latest and the bottom one the first calculation step.

Each of the named possible user interactions receives their own listener, that handles the requested task. On top of those we need one more for the messages of the worker, because we will have a two way communication. This listener is very similar to the one for the worker as previously shown in Listing \ref{code:workerListener}, only that it will handle all outgoing messages of the worker.

\section{Result}
\label{sub:impResult}
The result of the implementation can be viewed and interacted with at \href{https://koenloogman.github.io/Animation-Of-N-Queens-Problem-In-JavaScript/}{GitHub Pages of koenloogman (https://koenloogman.github.io/Animation-Of-N-Queens-Problem-In-JavaScript/)}. The animation is optimized for the latest version of Google Chrome or Firefox and maybe works on other browsers as well, but we recommend said two browsers for the best experience. If interested in the full source code, it can be seen at \href{https://github.com/koenloogman/Animation-Of-N-Queens-Problem-In-JavaScript}{GitHub of koenloogman (https://github.com/koenloogman/Animation-Of-N-Queens-Problem-In-JavaScript)}.