From fb012786c3b701001c54c246cd744b3e249b83fc Mon Sep 17 00:00:00 2001 From: Joakim Hove Date: Fri, 11 Feb 2022 11:31:31 +0100 Subject: [PATCH] Address final review comments in pyaction.tex and actionx.tex --- docs/tm/udq_actionx/actionx.tex | 6 ++++-- docs/tm/udq_actionx/pyaction.tex | 19 ++++++++++--------- 2 files changed, 14 insertions(+), 11 deletions(-) diff --git a/docs/tm/udq_actionx/actionx.tex b/docs/tm/udq_actionx/actionx.tex index 205aa44df..d75671794 100644 --- a/docs/tm/udq_actionx/actionx.tex +++ b/docs/tm/udq_actionx/actionx.tex @@ -210,7 +210,9 @@ processed content of the \inlinecode{Schedule} class is managed in vector of \inlinecode{ScheduleState} instances, where one \inlinecode{ScheduleState} represents the complete dynamic input state at a particular report step. The processed \kw{SCHEDULE} code is created with the method -\inlinecode{Schedule::iterateScheduleSection()}. +\begin{code} + Schedule::iterateScheduleSection(). +\end{code} When \inlinecode{Schedule::iterateScheduleSection(report\_step)} is called it starts by clearing the vector of \inlinecode{ScheduleState} instances from @@ -233,7 +235,7 @@ unconditionally referenced in the deck we get a challenge at the first pass through the \kw{SCHEDULE} section. In the example below a new well \kw{W1} is defined with the \kw{WELSPECS} keyword when the action \inlinecode{NEW\_WELL} evaluates to true. At 1.st of January 2025 the well \kw{W1} is opened with the -\kw{WCONPROD} keyword. The enginer making this model assumes that the +\kw{WCONPROD} keyword. The engineer making this model assumes that the \inlinecode{NEW\_WELL} action will evaluate to true sometime before 1.st of January 2025, and thereby ensure that the well is fully defined when it is eventually opened with \kw{WCONPROD}: diff --git a/docs/tm/udq_actionx/pyaction.tex b/docs/tm/udq_actionx/pyaction.tex index 0a37a5845..79084b685 100644 --- a/docs/tm/udq_actionx/pyaction.tex +++ b/docs/tm/udq_actionx/pyaction.tex @@ -117,7 +117,7 @@ arguments are: \ref{pyaction_actionx}). \item[\inlinecode{report\_step}:] This is an integer for the report step we are currently working on. Observe that the \pyaction{} is called for every - simulator timestep, i.e. it will typically be called multiple time with + simulator timestep, i.e. it will typically be called multiple times with the same value for the $\mathrm{report\_step}$ argument. \item[\inlinecode{summary\_state}:] An instance of the \inlinecode{Opm::SummaryState} class, this is where the current summary @@ -151,14 +151,14 @@ arguments are: \subsection{Holding state} The \pyaction{} keywords will often be invoked multiple times, a Python dictionary \inlinecode{state} has been injected in the module - that dictionary -can be used to maintain state between invocations. Let ut assume we want to +can be used to maintain state between invocations. Let us assume we want to detect when the field oil production starts curving down - i.e. when $\partial^2_{t} \mathrm{FOPR} < 0$, in order to calculate that we need to keep track of the timesteps and the $\mathrm{FOPR}$ as function of time - this is one possible implementation: \begin{code} def diff(pair1, pair2): - return (pair1[0] - pair2[0], pair1[1] - pair12[1]) + return (pair1[0] - pair2[0], pair1[1] - pair2[1]) def fopr_diff2(summary_state): fopr = summary_state.get('FOPR') @@ -201,10 +201,11 @@ function calls like \end{code} to close a well and set the oil rate of another well. Unfortunately it proved very complex to get good semantics for combining such runtime changes with the -keyword based model for \kw{SCHEDULE} section, so the current recommendation is -actually to apply the keywords from \kw{ACTIONX} from the Python module when a -change to the \kw{SCHEDULE} section is desired\footnote{Yes, from a programmers -point of view this is a very unsatisfactory solution, but it seems to work. +keyword based model for \kw{SCHEDULE} section. The current recommendation is to +apply changes to the \kw{SCHEDULE} section using callbacks to \kw{ACTIONX} +keywords from Python code, this is illustrated in the example +below\footnote{From a programmers point of view the solution seems very +unsatisfactory, but it works and it plays nicely with the \kw{ACTIONX} behavior. If/when the underlying \inlinecode{Schedule} implementation changes there is nothing per se in the \pyaction{} design which inhibits use of a better \inlinecode{Schedule} api in the future.}. @@ -361,7 +362,7 @@ UDQ ... ... -- Need to define a well list with all the production wells. --- This is to ensur that the WCONPROD keyword is only applied +-- This is to ensure that the WCONPROD keyword is only applied -- to producers. WLIST 'PROD' P1 P2 P3 .../ @@ -388,7 +389,7 @@ def run(ecl_state, schedule, report_step, summary_state, actionx_callback): \section{Security implications of \pyaction{}} \label{pyaction_security} The \pyaction{} keyword allows for execution of arbitrary user supplied Python -code, with the priveliges of the user actually running \flow{}. If you have a +code, with the priviliges of the user actually running \flow{}. If you have a setup where \flow{} runs with a different user account than the person submitting the simulation you should be \emph{very careful} about enabling the embedded Python functionality and the \pyaction{} keyword. As a scary example