MOPED2

doc/user_manual/src/HERON_user_manual.tex

@@ -166,7 +166,7 @@
 \date{}
 \SANDnum{INL/EXT-20-58976, GDE-939}
 \SANDprintDate{\today}
-\SANDauthor{Paul W. Talbot, Dylan J. McDowell, R. Daniel Garrett, Botros N. Hanna, Abhinav Gairola, Jia Zhou}
+\SANDauthor{Paul W. Talbot, Dylan J. McDowell, R. Daniel Garrett, Botros N. Hanna, Abhinav Gairola, Jia Zhou, Anthoney Griffith}
 \SANDreleaseType{Revision 1}
 \def\component#1{\texttt{#1}}
 % ---------------------------------------------------------------------------- %
@@ -185,7 +185,8 @@
     \input{../src/Howtorun}
     \input{../src/InputStructure}
 %INSERT_SECTIONS_HERE
-	 \input{../src/ExternalCodeIntegration}
+	  \input{../src/ExternalCodeIntegration}
+    \input{../src/WorkflowOptions}
     \providecommand*{\phantomsection}{}
     \phantomsection
     \addcontentsline{toc}{section}{References}

doc/user_manual/src/WorkflowOptions.tex

@@ -0,0 +1,39 @@
+\section{Workflow Options}
+HERON has the capability to run different workflows, which expand the flexibility and capabilities of this plugin. Currently, HERON input files control the workflow selection via the \xmlNode{workflow} node, which is a subnode of the \xmlNode{case} node. Each workflow approaches the Techno-economic Analysis (TEA) with a unique problem formulation and solution technique.
+
+\subsection{Default}
+The default HERON workflow primarily utilizes RAVEN. In this workflow, RAVEN runs RAVEN to solve a two-level representation of the TEA by utilizing both pyomo and RAVEN's gradient descent optimizer. To run this workflow, insert ``standard`` into the \xmlNode{workflow} node, or simply do not define this node.
+
+\subsection{Monolithic Optimizer for Probabilistic Economic Dispatch (MOPED)}
+This workflow formulates the problem as a single-level optimization problem. More specifically, MOPED utilizes TEAL and RAVEN's externalROMloader to generate and solve a pyomo object. To run this workflow, insert ``MOPED`` into the \xmlNode{workflow} node.
+\noindent MOPED provides an alternate approach to solving the TEA provided by the input file. The solutions MOPED and the default workflow provide should be similar in standard cases.
+
+\subsubsection{Motivations}
+The primary motivations and potential benefits of MOPED include:
+\begin{itemize}
+    \item \textbf{Computational time:} In cases where the IES in question is following a cooperative dispatch heuristic (The standard dipatcher for the default workflow applies here), the single level formulation maintains the advantage of utilizing a more deterministic optimization algorithm
+          (`ipopt`') than gradient search. This results from the gradient descent treating the NPV cost function as a black box with capacities as input and NPV as output. In constrast, MOPED's pyomo object has an algebraic expression generated with TEAL, allowing for more direct application of optimization techniques.
+    \item \textbf{Seeding for more complicated scenarios:} In future versions of HERON, FARM will be available as a validation tool for HERON. FARM introduces new constraints that limit aspects of dispatch, such as ramping and setpoints, to ensure physical feasibility of the system's operation.
+          For this use of HERON, MOPED could provide an initial solution input to FARM. This may reduce the number of iterations required to meet the validation criteria of the analysis.
+    \item \textbf{Validation of default workflow/Confirmation of bilevel-monolithic equivalence:} Comparing the results between these two workflows provides a litmus test for the validity of either.
+\end{itemize}
+
+\subsubsection{Limitations}
+MOPED is limited to the TEA's where the dispatch and capacity selection agents are cooperative. In other words, MOPED cannot solve analyses where maximizing dispatch value reduces the total NPV value. Possible scenarios include deregulated markets, direct competition, and agent-based dispatch.
+
+Additionally, MOPED has limitations in terms of acceptable inputs, which currently include:
+\begin{itemize}
+    \item Capacities for VRE's (Wind/Solar)
+    \item Reference prices from Synthetic Histories
+    \item Components that consume one resource to produce another
+    \item Storage components
+    \item Dispatch plotting
+    \item Custom functions for prices, VRE capacities, demand, etc.
+    \item Components that do not start operation at project start
+    \item Components with (component life x rebuild count $<$ project life)
+\end{itemize}
+Development is focussed on reducing the number of items on this list. The end goal of MOPED is to maintain the same capabilities as the default workflow.
+
+\subsection{DISPATCHES}
+The DISPATCHES workflow builds a monolithic pyomo object with cost functions from TEAL, which is similar to MOPED. In constrast, this workflow utilizes IDAES modeling to include physics within the pyomo model.
+

src/Cases.py

@@ -101,6 +101,16 @@ def get_input_specs(cls):
     input_specs.addSub(InputData.parameterInputFactory('verbosity', contentType=verbosity_options,
                                                        strictMode=True, descr=desc_verbosity_options))
 
+    workflow_options = InputTypes.makeEnumType('WorkflowOptions', 'WorkflowOptionsType',
+                                               ['standard', 'MOPED', 'combined'])
+    desc_workflow_options = r"""determines the desired workflow(s) for the HERON analysis. \default{standard}.
+                            If ``standard'' runs HERON as usual (writes outer/inner for RAVEN workflow).
+                            If ``MOPED'' runs monolithic solver MOPED using the information in xml input.
+                            If ``combined'' runs both workflows, setting up RAVEN workflow and solving with MOPED.
+                            See Workflow Options section in user guide for more details"""
+    input_specs.addSub(InputData.parameterInputFactory('workflow', contentType=workflow_options,
+                                                       strictMode=True, descr=desc_workflow_options))
+
     # not yet implemented TODO
     #econ_metrics = InputTypes.makeEnumType('EconMetrics', 'EconMetricsTypes', ['NPV', 'lcoe'])
     #desc_econ_metrics = r"""indicates the economic metric that should be used for the HERON analysis. For most cases, this
@@ -384,6 +394,7 @@ def __init__(self, run_dir, **kwargs):
         'inner_samples': 1,            # how many inner realizations to sample
         'macro_steps': 1,              # how many "years" for inner realizations
         'dispatch_plot': True          # whether to output a plot in debug mode
+
     }
 
     self.data_handling = {             # data handling options
@@ -393,6 +404,7 @@ def __init__(self, run_dir, **kwargs):
     self._time_discretization = None   # (start, end, number) for constructing time discretization, same as argument to np.linspace
     self._Resample_T = None            # user-set increments for resources
     self._optimization_settings = None # optimization settings dictionary for outer optimization loop
+    self._workflow = 'standard' # setting for how to run HERON, default is through raven workflow
     self._result_statistics = {        # desired result statistics (keys) dictionary with attributes (values)
         'sigma': None,                 # user can specify additional result statistics
         'expectedValue': None,
@@ -465,6 +477,8 @@ def read_input(self, xml):
           self.dispatch_vars[var_name] = vp
       elif item.getName() == 'data_handling':
         self.data_handling = self._read_data_handling(item)
+      elif item.getName() == 'workflow':
+        self._workflow = item.value
       elif item.getName() == 'result_statistics':
         new_result_statistics = self._read_result_statistics(item)
         self._result_statistics.update(new_result_statistics)