% $Id$

%\subsection{Design and Implementation Notes}

\begin{enumerate}

\item Some methods which have a Field interface are actually 
implemented at the underlying Grid or Array level; they
are inherited by the Field class.  This allows the user
API (Application Programming Interface) to present functions at
the level which is most consistent to the application without
restricting where inside the ESMF the actual implementation
is done.

\item The Field class is implemented in Fortran, and as such is
defined inside the framework by a Field derived type and a set of 
subprograms (functions and subroutines) which operate on that derived type.  
The Field class itself is very thin; it is a container class which
groups a Grid and an Array object together.

\item Fields follow the framework-wide convention of the
{\it unison} creation and operation rule: All PETs which are
part of the currently executing VM must create the
same Fields at the same point in their execution.  Since an early
user request was that global object creation not impose the overhead of
a barrier or synchronization point, Field creation does no inter-PET
communication.  For this to work, each PET must query the total number
of PETs in this VM, and which local PET number it is.  It can then
compute which DE(s) are part of the local decomposition, and any
global information can be computed in unison by all PETs independently
of the others.  In this way the overhead of communication is avoided,
at the cost of more difficulty in diagnosing program bugs which result
from not all PETs executing the same create calls.

\item Related to the item above, the user request to not impose
inter-PET communication at object creation time means that requirement
FLD 1.5.1, that all Fields will have unique names, and if not specified, 
the framework will generate a unique name for it, is difficult or
impossible to support.  A part of this requirement has been implemented;
a unique object counter is maintained in the Base object class, and if
a name is not given at create time a name such as "Field003" is generated
which is guaranteed to not be repeated by the framework.   However, it
is impossible to error check that the user has not replicated a name,
and it is possible under certain conditions that if not all PETs have
created the same number of objects, that the counters on different PETs
may not stay synchronized.   This remains an open issue.

\end{enumerate}
