\chapter{Features} \label{ch:features}
See Chapter~\ref{ch:configuration} for information on how to
enable/disable and use the features described in this chapter.

\section{Operator Abstraction} \label{sec:operator_abstraction}
The operations performed by JEGA are broken up both conceptually and
in actual software design such that each is performed by a specific
class of operator.  The operators are invoked in some order until
some stopping and/or convergence criteria has been met.  Each of the
operations can be performed by any number of available operator
specializations. For example, the initialization of a population can
be performed by any of the available "Initializers".
Chapter~\ref{ch:configuration} details the different specializations
available for each operator type. The current operator categories
are shown in the list below in no particular order.  The description
accompanying each is not intended to imply in any way exactly how
these operations are carried out, only their desired result or
intent.

\begin{itemize}

\item \textbf{Main Loops} - Define the progression or order of operations of
the algorithm as well as perform any relevant intermediate actions.

\item \textbf{Initializers} - Create the initial population of candidate
solutions.

\item \textbf{Mutators} - Add random variation to a group of candidate
solutions for the purposes of design space exploration.

\item \textbf{Crossers} - Mate existing candidate solutions together to
create new candidate solutions for the purposes of exploitation of
observed good solutions.

\item \textbf{Convergers} - Determine when the algorithm should stop and
return its current result.

\item \textbf{Evaluators} - Perform the evaluation of response functions
including objectives and constraints with respect to a supplied set
of design variable values.

\item \textbf{Fitness Assessors} - Assess the fitness of evaluated candidate solutions with respect to one another.

\item \textbf{Selectors} - Choose a subset of all current candidate solutions
to become the next population.

\item \textbf{Niche Pressure Applicators} - Encourage
differentiation amongst the candidate solutions for the purposes of
exploration.  Also referred to simply as ``Nichers''.

\item \textbf{Post Processors} - Perform whatever operations are desired on
the final set of reported solutions prior to their return from the
algorithm.

\end{itemize}

This design allows a great deal of flexibility in the way JEGA
behaves.  It also allows for easy incorporation of new techniques
for performing the various operations.

\section{Running Multiple Algorithms} \label{sec:multiple_algs}
JEGA is the project that houses the various genetic algorithms
available.  It is not entirely abstract in that there is some code
that is external to the algorithms themselves.  This code is
primarily embodied by the front end sub-project.  Using this front
end code, multiple GA's can be created and used to solve multiple
problems within a single application.

\section{Thread Safety} \label{sec:thread_safety}

JEGA can be configured at compile time to be thread aware.  In this
way, multiple instances of the JEGA algorithms can be safely run
simultaneously from different threads within a program.  See
Chapter~\ref{ch:configuration} for information on how to configure
for this feature at compile time.

\section{Logging} \label{sec:logging}
JEGA reports information to users via a logging capability.  It can
be configured to log to the console, text files, or both (see
Section~\ref{sec:compile_logging_config} for more information).

No matter what else is happening, if file logging is enabled, JEGA
will create and write some information to a ``global'' log file.
This is where messages generated by non-algorithmic components are
written.

JEGA can be used in a number of ways and multiple algorithms may be
run in a given program.  If multiple algorithms are to be run, each
algorithm can be configured to log to a separate file or each can
log to the ``global'' log file or any combination.

Every message has a similar format as shown below.

\begin{center}
$<day> <time> <year>: <level>- <issuer>: <message>$
\end{center}

An example would then be:

\begin{center}
Fri Sep 01 08:59:29 2006: quiet- JEGA Front End: Random seed = 12345
\end{center}

JEGA will not overwrite previous logs.  If a file exists with the
name supplied to JEGA, JEGA will open the existing file and begin
appending log entries into it.  For this reason, it is important to
archive or discard old log files when appropriate.

\section{Portability and Interoperability} \label{sec:interop}

The core of JEGA is written in ANSI C++ without the use of any vendor
specific or third party libraries.  All source code required to make
and use JEGA as a library is included with the distribution.  It is
regularly tested on a number of platforms including multiple Unix and
Linux flavors as well as on Windows (both natively and using cygwin).
For building JEGA on the *nix platforms, an autoconf harness is included
in the distribution.  For building natively on windows, Visual Studio
projects for each of VS .NET 2003, 2005, and 2008 are provided.

To create a JEGA executable from code requires use of boost libraries.

For Windows users, JEGA is also distributed with a Managed front
end.  This is a separate (small) body of code that will operate JEGA
from a project that uses the Microsoft managed extensions for C++.
Using this body of code, it is possible to use JEGA directly from
within any of the .NET languages using common language runtime
support.  JEGA is also distributed with a Visual Basic front end
that takes advantage of this capability.  Other front ends are
planned for the future including those for the other .NET languages
as well as one for JAVA (non-Microsoft specific).
