More work ....

docs/tm/udq_actionx/actionx.tex

@@ -5,22 +5,41 @@ The \actionx{} keyword is the most direct way to \emph{program} in the deck. The
 \actionx{} functionality consist of the \actionx{} keyword itself, with some
 metadata and a condition and then a list of keywords which are injected into
 Schedule section at the point in time where the condition evaluates to true.
-
-\begin{deck}
-ACTIONX
-INJECTION 10 0 /
-WBHP P1 < 200.0 /
-/
-
-WELOPEN
-  'WI1' 'OPEN' 5* /
-/
-
-ENDACTIO
-\end{deck}
 The \actionx{} statement is evaluated at the end of every timestep, and if it
 evaluates to true the new keywords should take effect immediately.
 
+\section{Structure of the \actionx{} keyword}
+The \actionx{} keyword itself consist of multiple records. The first record is
+metadata with the name of action, the number of times the action can be
+triggered and the minimum time elapsed before an action is eligible for a second
+run.
+
+The subsequent records are \emph{conditions}, all the conditions are of the same
+form
+\begin{code}
+  lhs condition rhs
+\end{code}
+if there are more conditions they must be joined with a trailing \kw{AND} or
+\kw{OR}, conditions can be grouped with paranthesis. The quantatites in an
+\actionx{} expression must be ``quite simple'', for more advanced expressions
+the natural way is to first define a \udq{} and then use the \udq{symbol} in the
+\actionx{}, this is illustrated in section \ref{uda}.
+
+
+
+
+\begin{deck}
+ACTIONX
+  INJECTION 10 0 /
+  WBHP P1 < 200.0 /
+  /
+
+  WELOPEN
+  'WI1' 'OPEN' 5* /
+  /
+
+  ENDACTIO
+\end{deck}
 
 
 
@@ -192,6 +211,14 @@ append the \actionx{} keywords in the right \inlinecode{ScheduleBlock} instance
 and then rerun the \inlinecode{Schedule::iterateScheduleSection} from the
 correct report step.
 
+\subsection*{\actionx{} input}
+While parsing the \kw{SCHEDULE} section the \actionx{} keywords are somewhat
+special cased - the keywords are not internalized but rather tucked away for
+future injection. The keywords in the \actionx{} are parsed and stored in a
+class \inlinecode{Action::ActionX} and all of these instances are in a vector
+\inlinecode{Action::Actions}.
+
+
 \section{Interaction with the simulator}
 
 \begin{enumerate}

docs/tm/udq_actionx/udq.tex

@@ -393,6 +393,7 @@ two sets, only well OP1 would have a defined value in this case.
 
 
 \section{Used as a control: UDA}
+\label{uda}
 Probably one of the most important uses of the \udq{} functionality is the
 ability to use a \udq{} as control in e.g. the \kw{WCONINJE} keyword. In the
 example below we calculate the produced liquid volume from a group of wells and
@@ -520,11 +521,14 @@ The \inlinecode{SummaryState} class is not part of the \udq{} implementation,
 but it is a very important class for the \udq{} functionality. At the end of
 every timestep the simulator will call the method \inlinecode{evalSummary} which
 will call into opm-common and evaluate all summary variables and store them in a
-\inlinecode{SummaryState} instance. The \inlinecode{SummaryState} class manages
-a set of maps with well, group and field variables, when evaluating e.g. the
-\kw{WOPR} the results will be stored in a two level map first indexed with
-keyword \kw{WOPR} and then with well name. Afterwards the \udq{} layer can fetch
-values with \inlinecode{SummaryState::get\_well\_var()}. The values in the
+\inlinecode{SummaryState} instance\footnote{Observe that during initialization
+the \udq{} expressions are inspected, and we make sure that all summary
+variables needed to evaulate \udq{} expressions are evaluated in the Summary
+evaluation.}. The \inlinecode{SummaryState} class manages a set of maps with
+well, group and field variables, when evaluating e.g. the \kw{WOPR} the results
+will be stored in a two level map first indexed with keyword \kw{WOPR} and then
+with well name. Afterwards the \udq{} layer can fetch values with
+\inlinecode{SummaryState::get\_well\_var()}. The values in the
 \inlinecode{SummaryState} have been converted to output units, this is important
 for the \kw{UDA} evaluation.