\documentclass[12pt]{beamer}
\input{BEAMERoptions.tex}

% ----- Packages and libraries ----- %
\usepackage[T1]{fontenc} 				% cut/paste and search with "_"
\usepackage[english]{babel}
\usepackage{graphics}
\usepackage{verbatim}
\usepackage{times}
\usepackage{graphicx}
\usepackage{epsfig}
\usepackage{subfigure}
\usepackage{amssymb}
\usepackage{amsmath, amsfonts}
\usepackage{amsthm}
\usepackage{color}
\usepackage{alltt}
\usepackage{anyfontsize}
\usepackage{tikz}
   \usetikzlibrary{shapes, arrows, shadows}

\newcommand{\Frametitle}[1]{\frametitle{\includegraphics[width=0.25in]{esp_logo.png}
      \hspace{0.05in} #1}}

\newcommand{\FrameTitle}[1]{\frametitle{\includegraphics[width=0.3in]{caps_logo.png}
      \hspace{0.05in} #1}}

\setbeamertemplate{navigation symbols}{}
\setbeamertemplate{caption}[numbered]

%============================
% command to repeate a ~ n-times
%============================
\newcount\myloopcounter

\newcommand{\spaces}[1][10]{%
  \myloopcounter0% initialize the loop counter
  \loop\ifnum\myloopcounter < #1 % Test if the loop counter is < #1
  ~%
  \advance\myloopcounter by 1 %
  \repeat % start again
}
%============================

% ----- Presentation information ----- %
\title[AIM Programming -- Overview]{
\includegraphics[width=1.0in]{caps_logo.png}\\
Computational Aircraft Prototype Syntheses\\
AIM Programming -- Overview\\[0.02in]
For {\tt ESP} Rev 1.28}

\author[Haimes]{
Bob Haimes \\
  {\footnotesize \textcolor{blue}{bob@geocentrictech.com}~~or~~\textcolor{blue}{haimes@mit.edu} \\[-0.03in]
    Geocentric Technologies LLC}
}

\date[July 2025]{}

% ----- Document follows ----- %

\begin{document}

\begin{frame}
  \titlepage
\end{frame}

\begin{frame}
  \Frametitle{Stewardship}
  
{  \center
  {\bf Geocentric Technologies, LLC} will be taking over the
  stewardship of {\tt EPS} (and {\tt CAPS}) from {\bf MIT}
  
  }
  
  \vspace{0.1in}
  This is a reflection of software transitioning from an academic {\it research} project to {\it mature
  commercial} products with support.\\[0.05in]
   Note that the software will remain under an {\it Open Source} license and hence continue to be freely available.
 
   \vspace{0.15in}
 \footnotesize
  This entails (post {\tt ESP} Rev 1.28) the following:
  \begin{itemize}
  \item Change of hosting website to: {\tt http://geocentrictech.com/ESP}
  \item Opening up a portal so that external sources can contribute plugins
  \item Moving most of the current AIMs to that portal, this will strongly effect how {\tt CAPS} is distributed
  \end{itemize}
  
%  \vspace{0.01in}
  \center {\bf This transition is initially funded by an Air Force SBIR}
  \end{frame}
  
   \begin{frame}
  \FrameTitle{Stewardship}
  
Requirements for contributed AIMs \& Mesh Writers:
 \footnotesize
  \begin{itemize}
  \item A directory with the top-level name of the contribution, for example:\\
  name{\bf AIM} or name{\bf Writer}
  \item The source, Makefile and NMakefile (as will be seen in the upcoming sessions)
  \item A Windows {\it def} file
  \item An optional {\it example} subdirectory -- contains illuminating plugin executions\\
  that are driven by CSM and Python scripts, as well as supporting files for the execution
  \item A {\it test} subdirectory\\
  Unit and regression tests  to support continuous integration and acceptance\\
  Executed by issuing ``make test'' (or ``nmake -f NMakefile test'') at the top-level
  \item A {\it docs} subdirectory -- the contents of which is still under discussion
  \end{itemize}
  
  \vspace{0.075in}
  There will be methods for users to grab plugins from the portal, but the details of this have not been finalized.
  
  \end{frame}
  
 \begin{frame}
  \Frametitle{Stewardship -- Software Testing}

\vspace{-0.05in}
\begin{block}{The {\tt CAPS} API and AIMs}
\begin{itemize}
\item This is MUCH harder than most software testing because the full execution depends on third-party
software, which may change and is out of our control
\item How do you test the results of surface and volume mesh generation as well as (and in conjunction with) solver execution?
\begin{itemize}
\item Mesh counts depend on the geometry and floating point predicates!
\item Solver integrated quantities can hide issues!
\item Is this the responsibility of {\tt CAPS}?
\end{itemize}
\item AIMs will now require testing and will not be accepted without
\item This should be done in Python in one of two ways:
\begin{enumerate}
\item Use Python's testing framework (see {\tt exercises/session06}) %-- or-- 
\item By Python script(s) that contain {\it asserts} (see  {\tt exercises/session07})
\end{enumerate}
\vspace{-0.025in}
\footnotesize Note: both sessions use the same AIM.
\end{itemize}

\end{block}

\end{frame}


 \begin{frame}
  \FrameTitle{{\tt CAPS} in Design}
 
 \vspace{-0.05in}
  \begin{block}{{\tt CAPS} Execution}

\vspace{0.025in}
The Design workflow may require a long running and complex process involving a mix of multi-fidelity and
multidisciplinary analyses:

\begin{itemize}
\item May need to manage the complexity
\item Get to some point and ask {\it what if} questions
\item Store away (checkpoint) the state of the Design at various times
\end{itemize}

\vspace{0.075in}
{\tt CAPS} Design execution breaks the process into {\it phases}
\begin{itemize}
\item One {\it phase} is a ``stepping stone'' to the next
\item Allows for ``branching'' from a completed {\it phase} to
  multiple new {\it phases} (like repositories --- but with no merging)
\item Each {\it phase} is typically driven by a different {\tt CAPS} app or pyCAPS script
\item Can robustly get from {\it phase} to {\it phase}
\end{itemize}

  \end{block}
  
\end{frame}

\begin{frame}
  \FrameTitle{{\tt CAPS} in Design}
 
 \vspace{-0.05in}
  \begin{block}{{\tt CAPS} {\it phases}}

\vspace{0.025in}
In most cases:
\begin{itemize}
\item The first {\it phase} builds the objects
\item The subsequent {\it phases} discover or use the existing objects
\end{itemize}

\vspace{0.035in}
At all times the current object state is mirrored on disk:
\begin{itemize}
\item Uses directory structure to mimic the object hierarchy
\item Writes objects when updated in binary (which are usually small)
\end{itemize}

\vspace{0.035in}
In addition, {\tt CAPS} API function's output are {\it journaled} to disk

\vspace{0.035in}
End result:
\begin{itemize}
\item Execution can be paused, interrupted or encounter an error and continue later
\item AIM post-Analysis is re-executed during continuation when last invocation is
reached to reestablish any internal storage
\end{itemize}

  \end{block}
  
\end{frame}

 
\begin{frame}
  \FrameTitle{{\tt CAPS} in Design}
 
 \vspace{-0.075in} 
  \begin{block}{{\tt CAPS} Execution Modes}
  \vspace{0.025in}
 {\tt CAPS} has 4 modes for starting a session:
  {\small
  \begin{itemize}
  \vspace{-0.09in}
  \item Scratch --
  This is for development (and not production). It will remove any existing data in the {\it Scratch} directory of the Problem's path
  \vspace{-0.09in}
  \item Initial --
 This {\it phase} is %internally given the name {\it Initial} and it is
  started by a call to {\tt caps\_open} that points to a nonexistent
  {\it phase} subdirectory. The initialization can either be from a
  geometry file or an {\tt OpenCSM} or {\tt EGADS} Model.
   \vspace{-0.09in}
  \item Continuation* -- This occurs when {\tt CAPS} has not finished a {\it phase} either do to an interruption or not reaching {\tt caps\_close} (that can mark the {\it phase} complete). In this case the {\tt CAPS} application or pyCAPS script can be run from the beginning, but reading results from the {\it journal} is used
  to quickly get to the position where the {\it phase} terminated.
   \vspace{-0.09in}
  \item Starting from a completed {\it phase}
  \end{itemize}
  \vspace{-0.075in}
  * works best when most of the computation is controlled by {\tt CAPS}\\[-0.05in]
  ~~~must be same {\tt ESP} rev \& architecture (due to the chaotic nature of meshing)
  }
  \end{block}
  
  \end{frame}
  
 \begin{frame}
  \FrameTitle{{\tt CAPS} in Design}
 
 \vspace{-0.085in} 
  \begin{block}{{\tt CAPS} Directory Structure}
  \vspace{0.025in}
 {\footnotesize
  At the top specified directory level you will find {\it phase} subdirectories\\[0.05in]
  
  In each {\it phase} subdirectory you may see:
  \begin{itemize}
  \scriptsize
  \vspace{-0.05in}
  \item capsRestart.cpc -- a CSM saved state file -- or --\\
    capsRestart.egads -- an {\tt EGADS} file (for nonparametric runs)
    \vspace{-0.05in}
    \item capsRestart -- subdirectory that contains the {\tt CAPS} restart data
    \vspace{-0.05in}
  \item capsClosed -- the {\it phase} has been closed
   ({\tt caps\_close} has been called to mark completion)
     \vspace{-0.05in}
  \item capsLock -- an indication that another application is executing in this subdirectory
       \vspace{-0.05in}
  \item AIMnames -- subdirectories each related to an AIM instance in the running {\tt CAPS} Problem/Phase
  \end{itemize}

 \vspace{-0.075in}  
 Notes:
\begin{itemize}
 \scriptsize
  \vspace{-0.05in}
\item {\it Scratch} phase (no name specified) is not as protected as the others
  \vspace{-0.05in}
\item {\tt CAPS} Problem directory or individual {\it phase} subdirectories can be copied and used elsewhere
\end{itemize}

\vspace{-0.12in}
\scriptsize
   \center
\begin{tikzpicture}
        \draw (0.0,0.8) node {Problem Directory};
        	\draw[o-,semithick] (0,0.5) -- ( 3,0.5);
	\draw[semithick]     (0,0.5) -- (-3,0.5);
	\draw[semithick]     (-2,0.1) -- (-2,0.5);
	\draw[semithick]     (-2.1,0.0) --  (-3.5,0.0);
	\draw[o-,semithick] (-2.1,0.0) --  (-0.5,0.0);
        \draw[semithick]     ( 2,0.1) -- ( 2,0.5);
	\draw[semithick]     ( 2.1,0.0) --  ( 3.5,0.0);
	\draw[o-,semithick] ( 2.1,0.0) --  ( 0.5,0.0);
	\draw (4.25,0.0) node {Phases};

        \draw[semithick]     (-0.75,0.0) -- (-0.75,-0.3);
        \draw[semithick]     (-1.5,0.0) -- (-1.5,-0.3);
         \draw[semithick]    (-2.5,0.0) -- (-2.5,-0.3);
         \draw[semithick]    (-3.25,0.0) -- (-3.25,-0.3);
         
        \draw[semithick]     ( 0.75,0.0) -- ( 0.75,-0.3);
        \draw[semithick]     ( 1.5,0.0) -- ( 1.5,-0.3);
         \draw[semithick]    ( 2.5,0.0) -- ( 2.5,-0.3);
         \draw[semithick]    ( 3.25,0.0) -- ( 3.25,-0.3);
         
         \draw[semithick]     (-0.75,-0.6) -- (-0.75,-0.8);
         \draw[semithick]    (-1.5,-0.6) -- (-1.5,-0.8);
         \draw[semithick]    (-2.5,-0.6) -- (-2.5,-0.8);
         \draw[semithick]    (-3.25,-0.6) -- (-3.25,-0.8);  
         
         \tiny
         \draw (-3.25,-0.45) node {AIM1};
         \draw (-2.5,-0.45) node {AIM2};
          \draw (-1.5,-0.45) node {...};
         \draw (-0.75,-0.45) node {capsRestart};

\end{tikzpicture}

  }
  
  \end{block}
  
  \end{frame}

\begin{frame}
  \Frametitle{{\tt CAPS} Infrastructure in {\tt ESP}}

  % procedure that is part of CAPS
  \tikzstyle{iproc} = [rectangle,
                       draw,
                       fill=blue!15,
                       thick,
                       inner sep=0pt,
                       minimum width=15mm,
                       minimum height=15mm,
                       align=center]
 \tikzstyle{oproc} = [rectangle,
                       draw,
                       fill=blue!40,
                       thick,
                       inner sep=0pt,
                       minimum width=15mm,
                       minimum height=10mm,
                       align=center]
  % procedure that is external to CAPS
  \tikzstyle{eproc} = [rectangle,
                       draw,
                       fill=orange!20,
                       thick,
                       inner sep=0pt,
                       minimum width=15mm,
                       minimum height=15mm,
                       align=center]
  % file or database
  \tikzstyle{disc}  = [cylinder,
                       shape border rotate=90,
                       aspect=0.25,
                       draw,
                       fill=green!20,
                       thick,
                       inner sep=0pt,
                       minimum width=15mm,
                       minimum height=15mm,
                       align=center]
  % link between procedures and discs
  \tikzstyle{link}  = [<->,
                       very thick]

  \begin{center}
    \begin{tikzpicture}[font=\scriptsize\sf]
      % picture elements
      \node[oproc,  minimum height=12mm] (ESP)  at (0.43,6.80) {~~~~~ESP~~~~~ \\ UI};
      \node[iproc,  minimum height=12mm] (pyCaps)  at (0.43,5.15) {~~~~pyCAPS~~~~};
      \node[eproc, minimum height=40mm] (framework) at (0.43,2.05) {User \\ \\ -------- \\ \\ MDO \\ ~~Framework~~
                                                                                                               \vspace{0.04in} \\ \tiny \em MSTC Engr \\ \tiny OpenMDAO \\ \tiny \em ~ModelCenter~ \\ \tiny \em ~ModeFRONTIER~ };
      \node[eproc, double copy shadow]  (tools)     at (2.75,0.85) {Analysis \\ tools};
      \node[iproc, minimum height=45mm] (executive) at (2.75,4.35) {Computa- \\ tional \\ Aircraft \\ Prototype \\ Syntheses \\ (CAPS) \\ API};
      \node[disc]                       (probDB)    at (4.75,3.3) {Problem \\ Database};
%   \node[iproc]                      (analysis)  at (4.75,4.35) {Analysis \\ Subsystem};
      \node[oproc, minimum height=28mm]  (geometry)  at (4.75,6.1) {Geometry \\ Subsystem \\ --- \\ OpenCSM \vspace{0.01in} \\ EGADS};
      \node[oproc,]                     (lite) at (10.0,2.0)  {EGADSlite};
      \node[disc,  double copy shadow]  (analIO)    at (6.75,1.25) {Analysis \\ I/O Files};
      \node[iproc, double copy shadow]  (AIM)       at (6.75,4.35) {Analysis \\ Interface \\ Module \\ (AIM)};
      \node[iproc, double copy shadow]  (meshW) at (8.85,4.35) {Mesh \\ Writers};
      \node[disc]                       (geomDB)    at (6.75,6.65) {Geometry \\ Database};

      % links (arrows)
      \draw[link,dotted] (ESP)  to (pyCaps);
      \draw[link,dotted] (1.20,6.95)  to (4.0,6.95);
      \draw[link,dotted] (1.30,0.85)  to (tools);
%   \draw[link,dotted] (framework)  to (tools);
      \draw[link,dotted] (1.30,3.375)  to (2.0,3.375);
%   \draw[link,dotted] (framework)  to (executive);
      \draw[link]         (1.28,5.05) to (2.0, 5.05);
      \draw[link,dotted]        (pyCaps)      to (framework);
      \draw[link]        (3.5,1.2)      to (analIO);
      \draw[link]        (executive)  to (probDB);
%   \draw[link]        (3.50,4.375)  to (analysis);
%   \draw[link]        (executive)  to (analysis);
      \draw[link]        (executive)  to (geometry);
%   \draw[link]        (probDB)     to (analysis);
%   \draw[link]        (analysis)   to (geometry);
%   \draw[link]        (analysis)   to (AIM);
      \draw[link]        (executive) to (AIM);
      \draw[link]        (geometry) to (AIM);
      \draw[link]        (analIO)      to (AIM);
      \draw[link]        (meshW)    to (AIM);
      \draw[<-,very thick]  (AIM) to (6.0,2.4);
      \draw[<-,very thick]  (3.5,1.45) to (6.0,2.4);
      \draw[link]        (geometry)   to (geomDB);
      \draw[<-,very thick, dotted] (5.5,5.75) to (10.0, 5.75);
      \draw[->,very thick, dotted] (10.0, 5.75) to (lite);
      \draw[<-,very thick, dotted] (lite) to (10.0, 0.35);
      \draw[->,very thick, dotted] (10.0, 0.35) to (3.5,0.35);
    \end{tikzpicture}
  \end{center}
  \end{frame}

\begin{frame}
  \FrameTitle{{\tt CAPS} Objects}

  \begin{block}{Object-based Not {\it Object Orientated}}
  \begin{itemize}
  \item Like \textcolor{blue}{ego}s in {\tt EGADS}
\item Pointer to a C structure -- allows for a function-based API
\item Treated as {\it blind pointers} (i.e., not meant to be dereferenced)\\
Header info is used to determine how to dereference the {\it pointer}
\item API C Functions
\begin{itemize}
\item Returns an {\textcolor{magenta}{int}} error code or {\tt CAPS\_SUCCESS}
\item Usually have one (or more) input Objects
\item Can have an output Object (usually at the end of the argument list)
\end{itemize}
\item Can interface with multiple compiled languages\\
pyCAPS sits on-top of the C API
\end{itemize}
  \end{block}

  \vspace{0.1in}
  See \$ESP\_ROOT/doc/CAPSapi.pdf

\end{frame}

\begin{frame}[fragile]
  \FrameTitle{{\tt CAPS} Objects}
  
 {\scriptsize
\begin{verbatim}
/*
 * defines the owning information
 */
typedef struct {
  int      index;            /* intent phrase index -- -1 no intent */
  char     *pname;           /* the process name -- NULL from Problem */
  char     *pID;             /* the process ID   -- NULL from Problem */
  char     *user;            /* the user name    -- NULL from Problem */
  short    datetime[6];      /* the date/time stamp */
  CAPSLONG sNum;             /* the CAPS sequence number */
} capsOwn;
\end{verbatim}
}

  \end{frame}

\begin{frame}[fragile]
  \FrameTitle{{\tt CAPS} Objects}
 
 \vspace{-0.075in}
 {\scriptsize
\begin{verbatim}
/*
 * defines the CAPS object
 */
typedef struct capsObject {
  int     magicnumber;          /* must be set to validate the object */
  int     type;                 /* object type */
  int     subtype;              /* object subtype */
  int     delMark;              /* delete mark */
  char    *name;                /* object name */
  egAttrs *attrs;               /* object attributes */
  void    *blind;               /* blind pointer to object data */
  void    *flist;               /* freeable list */
  int     nHistory;             /* number of history entries */
  capsOwn *history;             /* the object's history */
  capsOwn last;                 /* last to modify the object */
  struct  capsObject *parent;
} capsObject;

typedef struct capsObject* capsObj;
\end{verbatim}
}

\footnotesize
Note: this is only for reference. AIM programming is outside of the {\tt CAPS} Object handling. {\tt blind} is a pointer to 
a {\tt CAPS} data structure where AIM programming does have access.

  \end{frame}

\begin{frame}
  \FrameTitle{{\tt CAPS} Objects}

    \begin{block}{Problem Object}
\footnotesize
The Problem is the top-level {\it container} for a single mission. It maintains a single set of interrelated geometric models, analyses to be executed, connectivity and data associated with the run(s), which can be both multi-fidelity and multidisciplinary.  There can be multiple Problems in a single execution of {\tt CAPS} and each Problem is designed to be {\it thread safe} allowing for multi-threading of {\tt CAPS} at the highest level.
\end{block}

    \begin{block}{Value Object}
\footnotesize
A Value Object is the fundamental {\it data} container that is used within {\tt CAPS}. It can represent {\it inputs} to the Analysis and Geometry subsystems and {\it outputs} from both. Also Value Objects can refer to {\it mission} parameters that are stored at the top-level of the {\tt CAPS} database. The values contained in any {\it input} alue Object can be {\it linked} to another Value (or {\it DataSet}) Object of the same {\it shape}. Attributes are also cast to temporary ({\it User}) Value Objects.
\end{block}

\end{frame}

\begin{frame}
  \FrameTitle{{\tt CAPS} Objects}

  \begin{block}{Analysis Object}
\footnotesize
The Analysis Object refers to an instance of running an analysis code. It holds the {\it input} and {\it output} Value Objects for the instance and a directory path in which to execute the code (though no explicit execution is initiated). Multiple various analyses can be utilized and multiple instances of the same analysis can be handled under the same Problem.
\end{block}

  \begin{block}{Bound Object}
\footnotesize
A Bound is a logical grouping of BRep Objects that all represent the same entity in an engineering sense (such as the ``outer surface of the wing'').  A Bound may include BRep entities from multiple Bodies; this enables the passing of information from one Body (for example, the aero OML) to another (the structures Body).\\[0.075in]
Dimensionally:
\begin{itemize}
\vspace{-0.05in}
\item 1D -- Collection of Edges
\vspace{-0.05in}
\item 2D -- Collection of Faces
%\vspace{-0.05in}
%\item 3D -- At the Body level
\end{itemize}
\end{block}

\end{frame}

\begin{frame}
  \FrameTitle{{\tt CAPS} Objects}

\begin{block}{VertexSet Object}
\footnotesize
A VertexSet is a {\it connected} or {\it unconnected} group of locations at which discrete information is defined.  Each {\it connected} VertexSet is associated with one Bound and a single {\it Analysis}. A VertexSet can contain more than one DataSet. A {\it connected} VertexSet can refer to 2 differing sets of locations. This occurs when the solver stores it's data at different locations than the vertices that define the discrete geometry (i.e. cell centered or non-isoparametric FEM discretizations). In these cases the solution data is provided in a different manner than the geometric.
\end{block}

\begin{block}{DataSet Object}
\footnotesize
A DataSet is a set of engineering data associated with a VertexSet. The rank of a DataSet is the (user/pre)-defined number of dependent values associated with each vertex; for example, scalar data (such as {\it pressure}) will have rank of one and vector data (such as {\it displacement}) will have a rank of three.  Values in the DataSet can either be deposited there by an application or can be computed (via evaluations, data transfers or sensitivity calculations).
\end{block}

\end{frame}

\begin{frame}
  \FrameTitle{{\tt CAPS} Objects}

  \begin{center}
   \def\arraystretch{1.15}
  \begin{tabular}{| l | l | l |}
    \hline
   \bf Object & \bf SubTypes & \bf Parent Object \\
    \hline
        \hline
    capsProblem     & Parametric, Static   &  \\
        \hline
    ~capsValue         &  GeometryIn, GeometryOut, & capsProblem, \\[-0.02in]
                              &  Parameter, User   &   capsValue                     \\
                                  \hline
    ~capsAnalysis     &              & capsProblem \\
        \hline
    ~~~capsValue         &    AnalysisIn, AnalysisOut,  & capsAnalysis \\[-0.02in]
                               &         AnalysisDynO         &  \\
                                   \hline
    ~capsBound       &               & capsProblem \\
        \hline
    ~~~capsVertexSet    & Connected, Unconnected & capsBound\\
        \hline
    ~~~~~capsDataSet     & FieldOut, FieldIn, User, & capsVertexSet\\[-0.02in]
                              & GeomSens, TessSens, Builtin &        \\

    \hline
  \end{tabular}

  \vspace{0.05in}
  Body Objects are {\tt EGADS} Objects (egos)\\[0.05in]
  \small
  See {\tt \$ESP\_ROOT/include/capsTypes.h} for the complete {\it defines}
\end{center}

\end{frame}

\begin{frame}
  \FrameTitle{{\tt CAPS} Body Filtering}

    Filtering the active CSM Bodies occurs at two different stages: once in the {\tt CAPS} framework, and once in the AIMs.
    The filtering in the {\tt CAPS} framework creates sub-groups of Bodies from the CSM stack that
    are passed to the specified AIM. Each AIM instance is then responsible for
    selecting the appropriate Bodies from the list it has received.\\
    \vspace{1em}
    The filtering is performed by using two Body attributes:\\
    ``capsAIM'' and ``capsIntent''.

%  \vspace{0.15in}
%  \begin{block}{Filtering within AIM Code}
%  \footnotesize
%  Each AIM can adopt it's own filtering scheme for down-selecting how to use each Body it receives.
%  The ``capsIntent'' string is accessible to the AIM, but it is for information only.
%  \end{block}

\end{frame}

\begin{frame}
  \FrameTitle{{\tt CAPS} Body Filtering}

  \vspace{-0.5em}
  \begin{block}{CSM AIM targeting: ``capsAIM''}
  \footnotesize
  The CSM script generates Bodies which are designed to be used by specific AIMs. The AIMs that the Body is
  designed for is communicated to the {\tt CAPS} framework via the ``capsAIM'' string attribute. This is a
  semicolon-separated string with the list of AIM names. Thus, the CSM author can give a clear indication to which AIMs should
  use the Body. For example, a body designed for a CFD calculation could have:\\
 \vspace{1em}
  ATTRIBUTE capsAIM \$su2AIM;fun3dAIM;cart3dAIM
  \end{block}

\vspace{-0.05in}
  \begin{block}{{\tt CAPS} AIM Instantiation: ``capsIntent''}
  \footnotesize
  The ``capsIntent'' Body attribute is used when an AIM uses different Body types for different analyses.  The attribute ``capsIntent'' is a semicolon-separated list of keywords. 
   An argument to {\tt caps\_makeAnalysis} accepts a semicolon-separated list of keywords when an AIM is instantiated
  in {\tt CAPS}/pyCAPS. Bodies from the ``capsAIM'' selection with a matching string attribute ``capsIntent'' are
  passed to the AIM instance. If the string
  to {\tt caps\_makeAnalysis} is \textcolor{magenta}{NULL}, all Bodies with a ``capsAIM'' attribute that matches the AIM name are given to the AIM instance.
  \end{block}

\end{frame}

\begin{frame}
  \FrameTitle{Analysis Interface Module -- Intro 1/4}

  \begin{itemize}
  \item Hides all of the individual Analysis details (and peculiarities)
  \begin{itemize}
  \item Individual plugin functions {\it translate} from the Analysis' perspective back and forth to {\tt CAPS}
  \item Provides a direct connection to BRep geometry and attribution through {\tt EGADS}
  \end{itemize}
  \item Outside the {\tt CAPS} Object infrastructure
    \begin{itemize}
    \item Use of C structures
    \item AIM Utility library (with the {\it context} embedded in {\tt aimInfo})
     \end{itemize}
  \end{itemize}

 \vspace{0.075in}
 \footnotesize
Notes due to changes at Rev 1.19:
 \scriptsize
 \begin{enumerate}
 \item When an AIM function is invoked it is in the correct directory (as part of the Problem file structure). 
 \item There is no longer an explicit AIM parent/child relationship. This is accomplished via {\it linking} AnalysisOut Values of the {\it parent} to AnalysisIn Values of the {\it child}.
\item During restart only ``Post'' is executed at the last use of the AIM instance.
\item AIM specific storage is no longer indexed by the instance and is held internally.
%\item \textcolor{red}{Any non-NULL {\tt capsErrs} return for an {\tt icode} of {\tt CAPS\_SUCCESS} will generate a History entity in
% the Analysis Object with the comments in the Error Structure.}
 \end{enumerate}

\end{frame}

\begin{frame}
  \FrameTitle{Analysis Interface Module -- Intro 2/4}

\begin{block}{Large Mesh IO}
\footnotesize
The meshing AIMs used to hold onto the grid information in memory
and pass a pointer on to the CFD AIMs that write out a mesh file during solver
preAnalysis. %This is not the best use of resources and limits the ability
%for {\tt CAPS} to perform its overall mission.
\\[0.1in]

In order to have the meshing AIM know what kind of file the
downstream solver AIM requires, there needs to be information ``passed''
from the  solver AIM to the meshing AIM. This is accomplished through
the linkage itself. An AIM utility function has been added that
returns the info for linked (solver) AIMs to aid in knowing what files to write
in aimPostAnalysis. After the files have been written from PostAnalysis, the mesh memory needs to
be freed up.\\[0.1in]

The mesh writer is specified by using the Value structure member: {\tt meshWriter}. This is filled
in the link target (solver) AnalysisIn Value Object, which will allow for
the upstream (meshing) AIM to have knowledge about how the mesh is to be written. The
string contains the name of the so/DLL to be loaded for the writing. The meshing
AIM accesses this information via the AIM utility function {\tt aim\_writeMeshes}. See Session13.
\end{block}

\end{frame}

\begin{frame}
  \FrameTitle{Analysis Interface Module -- Intro 3/4}

\begin{block}{Analysis Dynamic Value Objects}
\footnotesize
There are circumstances where you may not know {\it a priori} all of the AnalysisOut values of interest. In
this case an AIM can generate outputs that have not been registered at initialization -- AnalysisDynO Values.
\begin{itemize}
\item These are transient Objects and cannot be used in {\it linking}
\item After successful AIM preAnalysis invocation, all existing Analysis Dynamic
   Output Objects that are stored in the instance are deleted (and those
   associated mirrored restart files)
\item AIM postAnalysis is the only place where Analysis Dynamic Output Objects
   can be created (see {\tt aim\_makeDynamicOutput})
\item They should not be created (i.e., they will already exist) if the \textcolor{espred}{restart}
   flag is set
\item After successful postAnalysis (and not at restart), the created Dynamic
   Output Objects are given the serial number of postAnalysis (and are
   written for restart)
\item If postAnalysis errors, any created Dynamic Output Objects are deleted
\end{itemize}
\end{block}

\end{frame}

\begin{frame}
  \FrameTitle{Analysis Interface Module -- Intro 4/4}

  \begin{itemize}
   \item An AIM plugin is required for each Analysis code at:
  \begin{itemize}
  \item a specific {\it intent}
  \item a specific {\it mode}  (i.e., where the inputs may be different)
  \end{itemize}
    \item AIMs can ``talk'' to each other
    \begin{itemize}
      \item AIM outputs of one AIM instance can be linked to inputs of another AIM instance
      \item Communication can be accomplished via pointers
    \end{itemize}
    \item Dynamically loaded at runtime -- extendibility and extensibility
    \begin{description}
      \item[Windows] Dynamically Loaded Libraries ({\tt name.dll})
      \item[LINUX] Shared Objects ({\tt name.so})
      \item[MAC] {\it Bundles}, {\tt CAPS} uses the {\tt so} file extension
    \end{description}
    \item Plugin names must be unique -- loaded by the name
    \vspace{0.2in}
    \item $\dagger$ indicates memory handled by {\tt CAPS} in the AIM descriptions\\
    i.e., {\tt CAPS} will free these memory blocks when necessary
  \end{itemize}
\end{frame}

\begin{frame}
  \FrameTitle{AIM Entry Points}
  
 {\scriptsize
 Registration~~~(Session07):
 \begin{itemize}
 \item aimInitialize
 \item aimInputs
 \item aimOutputs
 \item aimCleanup
 \end{itemize}
 
Analysis Execution~~~(Session07):
 \begin{itemize}
 \item aimUpdateState
 \item aimPreAnalysis
 \item aimExecute -- optional
 \item aimPostAnalysis
 \item aimCalcOutput
 \end{itemize}
 
 Data Transfers -- all optional~~~(Session12):
  \begin{itemize}
  \item aimDiscr
  \item aimFreeDiscrPtr
  \item aimLocateElement
  \item aimTransfer
  \item aimInterpolation \& aimInterpolateBar
  \item aimIntegration \& aimIntegrateBar
  \end{itemize}
 }
  
\end{frame}  

\begin{frame}
  \FrameTitle{AIM Function Sequencing}

\begin{block}{Analysis Execution Calling Sequences}
\footnotesize
AIM function execution happen automatically and are driven by what is requested and the {\it clean/dirty} state of the associated {\tt CAPS} Objects 
\begin{itemize}
\item {\tt aimUpdateState} is always called before {\tt aimDiscr}, {\tt aimPreAnalysis} or {\tt aimPostAnalysis}
\item {\tt aimDiscr} may be called before or after {\tt aimPreAnalysis} or {\tt aimPostAnalysis}
\item {\tt aimPreAnalysis} is always called before {\tt aimExecute} or {\tt aimPostAnalysis} (unless
doing a restart/continuation)
\item {\tt aimPostAnalysis} is called right after {\tt aimUpdateState} when {\tt CAPS} is restarting (the {\it restart} argument is set), or if {\tt aimPostAnalysis} is the first live function with continuation. See note on next page.
\end{itemize}
Only {\tt aimPreAnalysis} and/or {\tt aimPostAnalysis} (not at restart) should write to the Analysis directory.
\end{block}

\end{frame}

\begin{frame}
  \FrameTitle{AIM Function Sequencing}

\begin{block}{A Note on Continuation and Journalling}

\begin{itemize}
\item The internal state for each AIM instance must be able to be recovered by the AIM
\item This means that the structure pointed by {\tt instStore} (described in the next session)
needs to be refilled during the invocation of {\tt aimPostAnalysis} with the \textcolor{espred}{restart} flag
\item This may require the AIM to write this data every time it is modified. This file should reside in
the AIM's {\it path} and given a unique filename
\item On restart this file should be read either in {\tt aimUpdateState} or {\tt aimPostAnalysis}
\end{itemize}
\end{block}

\end{frame}
  
  \begin{frame}[fragile]
  \FrameTitle{AIM Makefile -- MAC/Linux}
  
{\tiny
\begin{verbatim}
#
ifndef ESP_ROOT
$(error ESP_ROOT must be set -- Please fix the environment...)
endif
ifndef ESP_ARCH
$(error ESP_ARCH must be set -- Please fix the environment...)
endif
#
IDIR  = $(ESP_ROOT)/include
include $(IDIR)/$(ESP_ARCH)
LDIR  = $(ESP_ROOT)/lib

$(LDIR)/myAIM.so:	myAIM.o $(LDIR)/libaimUtil.a
        $(CC) $(SOFLGS) -o $(LDIR)/myAIM.so myAIM.o \
                -L$(LDIR) -laimUtil -locsm -legads -ludunits2 -ldl -lm

myAIM.o:	myAIM.c $(IDIR)/aimUtil.h $(IDIR)/capsTypes.h
        $(CC) -c $(COPTS) $(DEFINE) -I$(IDIR) myAIM.c

run:	$(LDIR)/myAIM.so
        python session01.py

clean:
        -rm myAIM.o 

cleanall:	clean
        -rm $(LDIR)/myAIM.so
	
\end{verbatim}
} 
\vspace{-0.1in}
\footnotesize {\tt $\%$ make}~~~~-or- \\[-0.05in]
 {\tt $\%$ make run}
\end{frame}

 \begin{frame}[fragile]
  \FrameTitle{AIM NMakefile -- Windows}
  
{\tiny
\begin{verbatim}
#
!IFNDEF ESP_ROOT
!ERROR ESP_ROOT must be set -- Please fix the environment...
!ENDIF
#
IDIR = $(ESP_ROOT)\include
!include $(IDIR)\$(ESP_ARCH).$(MSVC)
LDIR = $(ESP_ROOT)\lib

$(LDIR)\myAIM.dll:	myAIM.def myAIM.obj
        -del $(LDIR)\myAIM.dll $(LDIR)\myAIM.lib $(LDIR)\myAIM.exp
        link /out:$(LDIR)\myAIM.dll /dll /def:myAIM.def myAIM.obj \
                /LIBPATH:$(LDIR) aimUtil.lib ocsm.lib egads.lib udunits2.lib
        $(MCOMP) /manifest $(LDIR)\myAIM.dll.manifest \
                /outputresource:$(LDIR)\myAIM.dll;2

myAIM.obj:	myAIM.c $(IDIR)\aimUtil.h $(IDIR)\capsTypes.h
        cl /c $(COPTS) $(DEFINE) /I$(IDIR) myAIM.c

run:	$(LDIR)\myAIM.dll
        python session01.py

clean:
        -del myAIM.obj

cleanall:	clean
        -del $(LDIR)\myAIM.dll $(LDIR)\myAIM.lib $(LDIR)\myAIM.exp

\end{verbatim}
} 
\vspace{-0.1in}
\footnotesize {\tt $>$ nmake -f NMakefile}~~~~-or- \\[-0.05in]
{\tt $>$ nmake -f NMakefile run}
\end{frame}

\begin{frame}
\FrameTitle{The upcoming AIM development sessions}

\begin{itemize}
\item We will be incrementally building up functionality in two simple AIMs: {\tt myAIM.c} \& {\tt theAIM.c}
\item Most all of the AIMs in the {\tt ESP} distribution can be used as examples/templates, but note:
\begin{itemize}
\item Many of these have a dependency on a library of utility functions that has not been documented
\item Even if documented, the number of functions is overwhelming and would be difficult to include here
\item Also the desire is now to have isolated AIMs that can stand-alone and have few dependancies 
\end{itemize}
\item Nearly all sessions have one or more exercises that (hopefully) illuminate the additions to the AIM from the last session, and
do some development
\item It would be great is you are considering building an AIM and can find some of the {\it exercise} time to work on that!
\end{itemize}
\end{frame}

\begin{frame}
\FrameTitle{Notes on {\tt myAIM.c}}

The goal is to provide a template for AIM development, but this AIM is/will be self-contained and does not actually execute anything.
\begin{itemize}
\item {\tt aimPreAnalysis} examines the inputs available but does not open and write an analysis input file.
\item {\tt aimExecute} does nothing (except indicate that the non-existent analysis has run).
\item {\tt aimPostAnalysis} also does not open and read an analysis output file, parse it, and fill in the AnalysisOut and AnalysisDynO outputs.
\item Python scripts, which differ in each session, attempt to display the results of the added functionality.
\item Because the same AIM name is used for most of these sessions, it is a good idea to end/start the session with~~ {\tt make cleanall} (or~~ {\tt nmake -f nmakefile cleanall})
\end{itemize}
\end{frame}

\begin{frame}
\FrameTitle{Notes on {\tt theAIM.c}}

This AIM is also a template but actually runs a simple analysis.
\begin{itemize}
\item {\tt aimPreAnalysis} examines the inputs available and writes an analysis input file.
\item {\tt aimExecute} sets up a command-line that gets passed to a shell to execute the analysis.
\item {\tt aimPostAnalysis} reads the analysis output file and stores away the results to make them available through calls to {\tt aimCalcOutput}.
\item Because the same AIM name is used for most of these sessions, it is a good idea to end/start the session with~~ {\tt make cleanall} (or~~ {\tt nmake -f nmakefile cleanall})
\end{itemize}
\end{frame}


\begin{frame}
\FrameTitle{Exercises}
  
In {\it exercises/session06}:
\begin{itemize}
\item Load {\tt case.csm} into {\it serveESP}
\begin{itemize}
 \item Examine the geometry we will be using in these sessions
\item Note the attributes placed on Faces
\end{itemize}
\item Examine the Python test script {\tt session06.py}
\item Build the AIM (in this case {\tt myAIM})
\item Execute the script
\begin{itemize}
 \item {\tt make run}  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- or -- 
\item {\tt python session06.py} ~~~~~~~~ -- or -- 
\item {\tt serveESP session06.py}
\end{itemize}
\item Note the {\it test} directory and execute the tests via~~ {\tt make test}
\item For C++ programmers:
\begin{itemize}
\item Examine the difference between {\tt myAIM.c} and {\tt myAIM.cpp}
\item Build with:~ {\footnotesize {\tt make -f cpp.make}}~~ --or-- ~~{\footnotesize {\tt nmake -f cpp.mak}}
\item Use variants of these Makefiles for your exercises
\end{itemize}
\end{itemize}
  
 \end{frame}


\end{document}

