\subsubsection{Sequential Files}
The programmer supplies the sequential code for each class as necessary. The
files should be named in the form of class name with appropriate file extension.
The header file is not really an ANSI C header file. Instead, it is the
sequential portion of the class's declaration. Charisma will generate the class 
declaration from the orchestration code, and incorporate the sequential portion
in the final header file. For example, if a molecular dynamics simulation has
the following classes (as declared in the orchestration code):

\begin{SaveVerbatim}{foodecl}
    class MDMain : MainChare;
    class Cell : ChareArray3D;
    class CellPair : ChareArray6D;
\end{SaveVerbatim}
\smallfbox{\BUseVerbatim{foodecl}}

The user is supposed to prepare the following sequential files for the classes:
MDMain.h, MDMain.C, Cell.h, Cell.C, CellPair.h and CellPair.C, unless a class
does not need sequential declaration and/or definition code. Please refer to the
example in the Appendix. 

For each class, a member function ``void initialize(void)'' can be defined and
the generated constructor will automatically call it. This saves the trouble of 
explicitly call initialization code for each array object. 

\subsubsection{Producing and Consuming Functions}
The C/C++ source code is nothing different than ordinary sequential source code,
except for the producing/consuming part. For consumed parameters, a function
treat them just like normal parameters passed in. To handle produced parameters, 
the sequential code needs to do two special things. First, the function should 
have extra parameter for output parameters. The parameter type is keyword \code{outport},
and the parameter name is the same as appeared in the orchestration code. Second,
in the body of the function, the keyword \code{produce} is used to connect the 
orchestration parameter and the local variables whose value will be sent out, in 
a format of a function call, as follows.

\begin{SaveVerbatim}{foodecl}
    produce(produced_parameter, local_variable[, size_of_array]);
\end{SaveVerbatim}
\smallfbox{\BUseVerbatim{foodecl}}

When the parameter represents a data array, we need the additional
\code{size\_of\_array} to specify the size of the data array. 

The dimensionality of an orchestration parameter is divided into two parts: 
its dimension in the orchestration code, which is implied by the dimensionality
of the object arrays the parameter is associated, and the local dimensionality,
which is declared in the declaration section. The orchestration dimension is not
explicitly declared anywhere, but it is derived from the object arrays. For 
instance, in the 1D Jacobi worker example, ``lb'' and ``rb'' has the same 
orchestration dimensionality of workers, namely 1D of size [16]. The local
dimensionality is used when the parameter is associated with local variables 
in sequential code. Since ``lb'' and ``rb'' are declared to have the local
type and dimension of ``double [512]'', the producing statement should connect
it with a local variable of ``double [512]''.

\begin{SaveVerbatim}{foodecl}
    void JacobiWorker::produceBorders(outport lb, outport rb){
      . . .
      produce(lb,localLB,512);
      produce(rb,localRB,512);
    }
\end{SaveVerbatim}
\smallfbox{\BUseVerbatim{foodecl}}

Special cases of the produced/consumed parameters involve scatter/gather
operations. In scatter operation, since an additional dimension is implied in
the produced parameter, we the \code{local\_variable} should have additional
dimension equal to the dimension over which the scatter is performed. Similarly,
the input parameter in gather operation will have an additional dimension the
same size of the dimension of the gather operation.

For reduction, one additional parameter of type char[] is added to specify the
reduction operation. Built-in reduction operations are ``+'' (sum), ``*'' (product),
``$<$'' (minimum), ``$>$'' (maximum) for basic data types. For instance the 
following statements takes the sum of all local value of \code{result} and 
for output in \code{sum}.

\begin{SaveVerbatim}{foodecl}
    reduce(sum, result, ``+'');
\end{SaveVerbatim}
\smallfbox{\BUseVerbatim{foodecl}}

If the data type is a user-defined class, then you might use the function or
operator defined to do the reduction. For example, assume we have a class
called ``Force'', and we have an ``add'' function (or a ``+'' operator) defined.

\begin{SaveVerbatim}{foodecl}
    Force& Force::add(const Force& f);
\end{SaveVerbatim}
\smallfbox{\BUseVerbatim{foodecl}}

In the reduction to sum all the local forces, we can use

\begin{SaveVerbatim}{foodecl}
    reduce(sumForces, localForce, "add");
\end{SaveVerbatim}
\smallfbox{\BUseVerbatim{foodecl}}

\subsubsection{Miscellaneous Issues}
In sequential code, the user can access the object's index by a keyword 
``thisIndex''. The index of 1-D to 6-D object arrays are:

\begin{SaveVerbatim}{foodecl}
  1D: thisIndex
  2D: thisIndex.{x,y}
  3D: thisIndex.{x,y,z}
  4D: thisIndex.{w,x,y,z}
  5D: thisIndex.{v,w,x,y,z}
  6D: thisIndex.{x1,y1,z1,x2,y2,z2}
\end{SaveVerbatim}
\smallfbox{\BUseVerbatim{foodecl}}

