The goal of the project is to develop a modeling and optimization application,
PARETO, that can help organizations better manage, better treat, and – where possible – beneficially reuse produced water from oil and gas operations.
Specifically, PARETO will help decision-makers with:
buildout of the produced water infrastructure
management of produced water volumes
selection of effective treatment technologies
placement & sizing of treatment facilities
identification of beneficial water reuse options
distribution of treated produced water for reuse
The initiative is committed to viewing produced water management from a “systems” perspective and to building an inclusive framework that will unite stakeholders from across the produced water community. The vision is that PARETO will not only help oil & gas but also allow other industries (e.g., agriculture, mining) explore beneficial reuse opportunities for treated produced water. Figure 1 (below) illustrates the scope of “Project PARETO”.
Project PARETO is a 3-year initiative that has been split into three distinct phases; with each phase taking up exactly one year. In execution year 2021, PARETO will capture produced water management, i.e., capturing options for coordinating water deliveries in a given development area. By execution year 2022, the project will shift its attention towards produced water treatment. Finally, execution year 2023 will be dedicated to produced water beneficial reuse.
In terms of deliverables, PARETO itself will be released as free and open-source software every year of the initiative – with increasing capabilities and functionality becoming available over time. The project team is also committed to conducting case studies with industrial and other partners; and where possible findings from those collaborations will be shared with the produced water community as best practice reports.
It should also be noted that the project will be continuously evaluated by a comprehensive stakeholder board that involves individuals representing upstream operators, midstream organizations, treatment technology providers, beneficial reuse entities, regulatory agencies and others – all of which will guide the project team and provide necessary input.
To install the PARETO framework on Windows operating systems, follow the set of instructions below
that are appropriate for your needs. If you need assistance please contact start a new discussion on
our GitHub Discussion form or send
an email to the support email list.
The installation instructions vary slightly depending on the role you will have with Project Pareto.
Below are the roles we’ve identified:
Users: Use the PARETO platform to develop models, but never contribute to
development of the framework (i.e. never commit changes to the project-pareto
repo). This includes people who only work with protected data.
Core-dev: Work primarily on PARETO platform development and never handle
protected data.
Hybrid: Handle protected data, but also commit changes to the project-pareto
repo (even occasionally) - needs approval from PhD. Markus Drouven
Open the Anaconda Prompt (Start -> “Anaconda Prompt”).
Warning
If you are using Python for other complex projects, you may want to
consider using environments of some sort to avoid conflicting
dependencies. There are several good options including conda
environments if you use Anaconda.
Create a Conda environment, named e.g. pareto-env:
condacreate--yes--namepareto-envpython=3.9
Activate the pareto-env Conda environment. This command must be run every time a new console/terminal window is opened:
condaactivatepareto-env
Install PARETO with pip by one of the following methods
To get the latest release:
pipinstallproject-pareto
To get a specific release, for example 1.6.3:
pipinstallproject-pareto==1.6.3
If you need unreleased cutting-edge development versions of PARETO, you
can install PARETO directly from the GitHub repo either from the main
PARETO repo or a developer’s fork and branch (this installs from GitHub
but does not create a local git clone/workspace):
Activate the pareto-dev Conda environment. This command must be run every time a new console/terminal window is opened:
condaactivatepareto-dev
Navigate into the new project-pareto directory, then run the following command to install
PARETO in editable mode and the development-only dependencies:
pipinstall-rrequirements-dev.txt
After installing PARETO, install the open-source solvers provided by the IDAES project:
idaesget-extensions--verbose
(Recommended) install the pre-commit checks that will run automatically whenever gitcommit is used, preventing the commit from being created if any of the checks fail:
pre-commitinstall
Note
pre-commit can cause commits to fail for reasons unrelated to the pre-commit checks. For more information, check the related GitHub issue(s).
Unlike a local clone of the repository, ZIP archives of the repository are static snapshots that cannot be automatically updated, track changes, or publish (push) through Git, while still allowing to modify the PARETO codebase locally.
Download a ZIP file containing a snapshot of the main branch of the repository by navigating to the following URL: https://github.com/project-pareto/project-pareto/archive/refs/heads/main.zip
Note
The URL can be modified to create a ZIP file for other repositories, branches or commits. e.g. for the fork belonging to the user myuser and the branch mybranch, the URL would be https://github.com/myuser/project-pareto/archive/refs/heads/mybranch.zip.
Unpack zip files (select directory)
Navigate to the directory where the ZIP files were extracted
Install pareto-project (non-git tracked repo):
pipinstall-rrequirements-dev.txt
After installing PARETO, install the open-source solvers provided by the IDAES project:
The Produced Water Application for Beneficial Reuse, Environmental Impact and Treatment Optimization (PARETO) is specifically designed for produced water management and beneficial reuse. The major deliverable of this project will be an open-source, optimization-based, downloadable and executable produced water decision-support application, PARETO, that can be run by upstream operators, midstream companies, technology providers, water end users, research organizations and regulators.
PARETO is designed as an executable optimization-based decision-support application. In return for specifying select input data, users will be provided with specific, actionable recommendations as program outputs. The table below summarizes representative inputs and outputs.
It should be noted that PARETO users will be able to choose from a range of objectives for their optimization runs; these can range from minimizing costs to maximing the ruese of produced water (or combinations thereof).
Given a fixed network of pads (completion and/or production), storage tanks, water forecasts (both consumption and production), and distribution options (trucks and/or pipelines), the operational water management model provides insight into the operational costs associated with water management. The operational model allows the user to explore the tradeoff between minimizing costs (distribution, storage, treatment, disposal, etc.) and maximizing reuse water.
Operational Model Mathematical Program Formulation
The default objective function for this produced water operational model is to minimize costs, which includes operational costs associated with procurement of fresh water, the cost of disposal, trucking and piping produced water between well pads and treatment facilities, and the cost of storing, treating and reusing produced water. A credit for using treated water is also considered, and additional slack variables are included to facilitate the identification of potential issues with input data.
Completions Pad Storage Balance:\(\forall p \in CP, t \in T\)
This constraint sets the storage level at the completions pad. For each completions pad and for each time period, completions pad storage is equal to storage in last time period plus water put in minus water removed. If it is the first time period, the pad storage is the initial pad storage.
This constraint has not actually been implemented yet.
Storage Site Truck Offloading Capacity:\(\forall s \in S, t \in T\)
For each storage site and each time period, the volume of water being trucked into the storage site must be below the trucking offloading capacity for that storage site.
\[\sum_{l \in L | (l, s) \in LLT}\textcolor{red}{F_{l,s,t}^{Trucked}}
\leq \textcolor{green}{\sigma_{s}^{Offloading,Storage}}\]
Storage Site Processing Capacity:\(\forall s \in S, t \in T\)
For each storage site and each time period, the volume of water being trucked into the storage site must be less than the processing capacity for that storage site.
\[\sum_{l \in L | (l, s) \in LLA}\textcolor{red}{F_{l,s,t}^{Piped}}
+ \sum_{l \in L | (l, s) \in LLT}\textcolor{red}{F_{l,s,t}^{Trucked}}
\leq \textcolor{green}{\sigma_{s}^{Processing,Storage}}\]
Production Tank Balance:
If there are individual production tanks, the water level must be tracked at each tank. The water level at a given tank at the end of each period is equal to the water level at the previous period plus the flowback supply forecast at the pad minus the water that is drained. If it is the first period, it is equal to the initial water level.
For individual production tanks: \(\forall (p,a) \in PAL, t \in T\)
If there are individual production tanks, the water drained across all tanks at the completions pad must be equal to the produced water for transport at the pad.
For individual production tanks: \(\forall p \in P, t \in T\)
The constraint proposed above is not necessary but included to facilitate switching between (1) an equalized production tank version and (2) a non-equalized production tank version.
Production Pad Supply Balance:\(\forall p \in PP, t \in T\)
All produced water must be accounted for. For each production pad and for each time period, the volume of outgoing water must be equal to the produced water transported out of the production pad.
Completions Pad Supply Balance (i.e. Flowback Balance):\(\forall p \in CP, t \in T\)
All flowback water must be accounted for. For each completions pad and for each time period, the volume of outgoing water must be equal to the forecasted flowback produced water for the completions pad.
Flow balance constraint (i.e., inputs are equal to outputs). For each pipeline node and for each time period, the volume water into the node is equal to the volume of water out of the node.
\[\sum_{l \in L | (l, n) \in LLA}\textcolor{red}{F_{l,n,t}^{Piped}}
= \sum_{l \in L | (n, l) \in LLA}\textcolor{red}{F_{n,l,t}^{Piped}}\]
Bi-Directional Flow:\(\forall (l,\tilde{l}), \ t \in T\) such that \((l,\tilde{l}) \in LLA\), \((\tilde{l}, l) \in LLA\), \(l \in L-F-O\), and \(\tilde{l} \in L - F\)
There can only be flow in one direction for a given pipeline arc in a given time period.
Flow is only allowed in a given direction if the binary indicator for that direction is “on”.
For each storage site and for each time period, if it is the first time period, the storage level is the initial storage. Otherwise, the storage level is equal to the storage level in the previous time period plus water inputs minus water outputs.
For \(t = 1\):
\[\textcolor{red}{L_{s,t}^{Storage}}
= \textcolor{green}{\lambda_{s,t=1}^{Storage}}
+ \sum_{l \in L | (l, s) \in LLA}\textcolor{red}{F_{l,s,t}^{Piped}}
+ \sum_{l \in L | (l, s) \in LLT}\textcolor{red}{F_{l,s,t}^{Trucked}}
- \sum_{l \in L | (s, l) \in LLA}\textcolor{red}{F_{s,l,t}^{Piped}}
- \sum_{l \in L | (s, l) \in LLT}\textcolor{red}{F_{s,l,t}^{Trucked}}\]
For \(t > 1\):
\[\textcolor{red}{L_{s,t}^{Storage}}
= \textcolor{red}{L_{s,t-1}^{Storage}}
+ \sum_{l \in L | (l, s) \in LLA}\textcolor{red}{F_{l,s,t}^{Piped}}
+ \sum_{l \in L | (l, s) \in LLT}\textcolor{red}{F_{l,s,t}^{Trucked}}
- \sum_{l \in L | (s, l) \in LLA}\textcolor{red}{F_{s,l,t}^{Piped}}
- \sum_{l \in L | (s, l) \in LLT}\textcolor{red}{F_{s,l,t}^{Trucked}}\]
The total stored water in a given time period must be less than the capacity. If the storage capacity limits the feasibility, the slack variable will be nonzero, and the storage capacity will be increased to allow a feasible solution.
The total disposed water in a given time period must be less than the capacity. If the disposal capacity limits the feasibility, the slack variable will be nonzero, and the disposal capacity will be increased to allow a feasible solution.
\[\sum_{l \in L | (l, k) \in LLA}\textcolor{red}{F_{l,k,t}^{Piped}}
+ \sum_{l \in L | (l, k) \in LLT}\textcolor{red}{F_{l,k,t}^{Trucked}} \leq \textcolor{red}{D_{k,[t]}^{Capacity}}\]
\(\forall k \in K, t \in T\)
\[\textcolor{red}{F_{k,t}^{DisposalDestination}}
= \sum_{l \in L | (l, k) \in LLA}\textcolor{red}{F_{l,k,t}^{Piped}}
+ \sum_{l \in L | (l, k) \in LLT}\textcolor{red}{F_{l,k,t}^{Trucked}}\]
Treatment Capacity:
The total treated water in a given time period must be less than the capacity. If the treatment capacity limits the feasibility, the slack variable will be nonzero, and the treatment capacity will be increased to allow a feasible solution.
\(\forall r \in R, t \in T\)
\[\sum_{l \in L | (l, r) \in LLA}\textcolor{red}{F_{l,r,t}^{Piped}}
+ \sum_{l \in L | (l, r) \in LLT}\textcolor{red}{F_{l,r,t}^{Trucked}} \leq \textcolor{green}{\sigma_{r}^{Treatment}}+\textcolor{red}{S_{r}^{TreatmentCapacity}}\]
\(\forall r \in R, t \in T\)
Treatment Destination Deliveries:
The total water delivered to a treatment site is the sum of all piped and trucked flows into the site.
\[\sum_{l \in L | (l, r) \in LLA}\textcolor{red}{F_{l,r,t}^{Piped}}
+ \sum_{l \in L | (l, r) \in LLT}\textcolor{red}{F_{l,r,t}^{Trucked}}=\textcolor{red}{F_{r,t}^{TreatmentDestination}}\]
Beneficial Reuse Capacity:
The total water for beneficial reuse in a given time period must be less than the capacity. If the beneficial reuse capacity limits the feasibility, the slack variable will be nonzero, and the beneficial reuse capacity will be increased to allow a feasible solution.
\(\forall o \in O, t \in T\)
\[\sum_{l \in L | (l, o) \in LLA}\textcolor{red}{F_{l,o,t}^{Piped}}
+ \sum_{l \in L | (l, o) \in LLT}\textcolor{red}{F_{l,o,t}^{Trucked}} \leq \textcolor{green}{\sigma_{o}^{Reuse}}+\textcolor{red}{S_{o}^{ReuseCapacity}}\]
\(\forall o \in O, t \in T\)
\[\sum_{l \in L | (l, o) \in LLA}\textcolor{red}{F_{l,o,t}^{Piped}}
+ \sum_{l \in L | (l, o) \in LLT}\textcolor{red}{F_{l,o,t}^{Trucked}}=\textcolor{red}{F_{o,t}^{BeneficialReuseDestination}}\]
Fresh Sourcing Cost:\(\forall f \in F, p \in CP, t \in T\)
For each freshwater source, for each completions pad, and for each time period, the freshwater sourcing cost is equal to all output from the freshwater source times the freshwater sourcing cost.
For each disposal site, for each time period, the disposal cost is equal to all water moved into the disposal site multiplied by the operational disposal cost. Total disposal cost is the sum of disposal costs over all time periods and all disposal sites.
For each treatment site, for each time period, the treatment cost is equal to all water moved to the treatment site multiplied by the operational treatment cost. The total treatments cost is the sum of treatment costs over all time periods and all treatment sites.
Water input into treatment facility is treated with a level of efficiency, meaning only a given percentage of the water input is outputted to be reused at the completions pads.
\[\textcolor{green}{\varepsilon^{Treatment}} \cdot (\sum_{l \in L | (l, r) \in LLA}\textcolor{red}{F_{l,r,t}^{Piped}}
+ \sum_{l \in L | (l, r) \in LLT}\textcolor{red}{F_{l,r,t}^{Trucked}})= \sum_{l \in L | (l, r) \in LLA}\textcolor{red}{F_{r,l,t}^{Piped}} + \textcolor{red}{F_{r,t}^{UnusedTreatedWater}}\]
where \(\textcolor{green}{\varepsilon^{Treatment}} \leq 1\)
Completions Reuse Cost:\(\forall p \in P, t \in T\)
Completions reuse water is all water that meets completions pad demand, excluding freshwater. Completions reuse cost is the volume of completions reused water multiplied by the cost for reuse.
Trucking cost between two locations for time period is equal to the trucking volume between locations in time t divided by the truck capacity [this gets # of truckloads] multiplied by the lead time between two locations and hourly trucking cost.
The constraints above explicitly consider freshwater trucking via FCT arcs included in LLT.
Slack Costs:
Weighted sum of the slack variables. In the case that the model is infeasible, these slack variables are used to determine where the infeasibility occurs (e.g. pipeline capacity is not sufficient).
An extension to this operational optimization model measures the water quality across all locations over time. As of now, water quality is not a decision variable. It is calculated after optimization of the operational model.
The process for calculating water quality is as follows: the operational model is first solved to optimality, water quality variables and constraints are added, flow rates and storage levels are fixed to the solved values at optimality, and the water quality is calculated.
Note
Fixed variables are denoted in purple in the documentation.
Assumptions:
Water quality at a production pad or completions pad remains the same across all time periods
When blending flows of different water quality, they blend linearly
Treatment does not affect water quality
Water Quality Sets
\(\textcolor{blue}{w \in W}\) Water Quality Components (e.g., TDS)
Water Quality Parameters
\(\textcolor{green}{v_{l,w,[t]}}\) = Water quality at well pad
\(\textcolor{green}{\xi_{l,w}}\) = Initial water quality at storage
Water Quality Variables
\(\textcolor{red}{Q_{l,w,t}}\) = Water quality at location
Disposal Site Water Quality\(\forall k \in K, w \in W, t \in T\)
The water quality of disposed water is dependent on the flow rates into the disposal site and the quality of each of these flows.
Storage Site Water Quality\(\forall s \in S, w \in W, t \in T\)
The water quality at storage sites is dependent on the flow rates into the storage site, the volume of water in storage in the previous time period, and the quality of each of these flows. Even mixing is assumed, so all outgoing flows have the same water quality. If it is the first time period, the initial storage level and initial water quality replaces the water stored and water quality in the previous time period respectively.
Treatment Site Water Quality\(\forall r \in R, w \in W, t \in T\)
The water quality at treatment sites is dependent on the flow rates into the treatment site, the efficiency of treatment, and the water quality of the flows. Even mixing is assumed, so all outgoing flows have the same water quality. The treatment process does not affect water quality
where \(\textcolor{green}{\varepsilon_{r,w}^{Treatment}} \leq 1\)
Network Node Water Quality\(\forall n \in N, w \in W, t \in T\)
The water quality at nodes is dependent on the flow rates into the node and the water quality of the flows. Even mixing is assumed, so all outgoing flows have the same water quality.
Beneficial Reuse Options: This term refers to the reuse of water at mining facilities, farms, etc.
Completions Demand: Demand set by completions pads. This demand can be met by produced water, treated water, or freshwater.
Completions Reuse Water: Water that meets demand at a completions site. This does not include freshwater or water for beneficial reuse.
Network Nodes: These are branch points for pipelines only.
Note
Well pads are not a subset of network nodes.
[t]: This notation indicates that timing of capacity expansion has not yet been implemented.
Terminal Storage Level: These are goal storage levels for the final time period. Without this, the storage levels would likely be depleted in the last time period.
Given a set of existing network components (completion pads, storage pads, production pads, and distribution options like trucks and/or pipelines) and capacity expansion options, the strategic water management model provides an insight into financial opportunities and mid-long term investment decisions to reduce operational costs or maximize reuse or reduce fresh water consumption.
Beneficial reuse options: This term refers to the reuse of water at mining facilities, farms, etc.
Completions demand: Demand set by completions pads. This demand can be met by produced water, treated water, or freshwater.
Completions reuse water: Water that meets demand at a completions site. This does not include freshwater or water for beneficial reuse.
Network Nodes: These are branch points for pipelines only.
Note
Well pads are not a subset of network nodes.
\([\textcolor{blue}{t}]\)or\([\textcolor{blue}{t \in T}]\): This notation indicates that timing of capacity expansion has not yet been implemented.
Terminal storage level: These are goal storage levels for the final time period. Without this, the storage levels would likely be depleted in the last time period.
Water boosting: Moving large volumes of water requires water pumps. Water boosting refers to the infrastructure required to maintain water pressure.
The sets for capacity sizes \(\textcolor{blue}{d \in D}\), \(\textcolor{blue}{c \in C}\), \(\textcolor{blue}{j \in J}\), \(\textcolor{blue}{i \in I}\) should also include the 0th case (e.g., 0 bbl) that indicates the choice to not expand capacity.
Alternatively, if it is desired to only consider sizes to build, the 0th case can be left out.
\(\textcolor{blue}{(l,\tilde{l}) \in LLT}\) All valid trucking arcs
Continuous Variables
\(\textcolor{red}{F_{l,\tilde{l},t}^{Piped}}\) = Produced water piped from one location to another location
\(\textcolor{red}{F_{l,\tilde{l},t}^{Trucked}}\) = Water trucked from one location to another location
\(\textcolor{red}{F_{f,p,t}^{Sourced}}\) = Fresh water sourced from source to completions
\(\textcolor{red}{F_{p,t}^{PadStorageIn}}\) = Water put into completions pad storage
\(\textcolor{red}{F_{p,t}^{PadStorageOut}}\) = Water removed from completions pad storage
\(\textcolor{red}{F_{s,t}^{StorageEvaporationStream}}\) = Water at storage lost to evaporation
\(\textcolor{red}{F_{r,t}^{TreatmentFeed}}\) = Flow of feed to a treatment site
\(\textcolor{red}{F_{r,t}^{ResidualWater}}\) = Flow of residual water out of a treatment site
\(\textcolor{red}{F_{r,t}^{TreatedWater}}\) = Flow of treated water out of a treatment site
\(\textcolor{red}{F_{p,t}^{CompletionsReuseDestination}}\) = Water delivered to completions pad for reuse
\(\textcolor{red}{F_{k,t}^{DisposalDestination}}\) = Water injected at disposal site
\(\textcolor{red}{F_{o,t}^{BeneficialReuseDestination}}\) = Water delivered to beneficial reuse option
\(\textcolor{red}{F_{p,t}^{CompletionsDestination}}\) = All water delivered to completions pad
\(\textcolor{red}{L_{s,t}^{Storage}}\) = Water level at storage site at the end of time period t
\(\textcolor{red}{L_{p,t}^{PadStorage}}\) = Water level in completions pad storage at the end of time period t
\(\textcolor{red}{F^{TotalTrucked}}\) = Total volume of water trucked
\(\textcolor{red}{F^{TotalSourced}}\) = Total volume of freshwater sourced
\(\textcolor{red}{F^{TotalDisposed}}\) = Total volume of produced water disposed
\(\textcolor{red}{F^{TotalCompletionsReuse}}\) = Total volume of produced water reused at completions
\(\textcolor{red}{F^{TotalBeneficialReuse}}\) = Total volume of water beneficially reused
\(\textcolor{red}{C_{l,\tilde{l},t}^{Piped}}\) = Cost of piping produced water from one location to another location
\(\textcolor{red}{C_{l,\tilde{l},t}^{Trucked}}\) = Cost of trucking produced water from one location to another location
\(\textcolor{red}{C_{f,p,t}^{Sourced}}\) = Cost of sourcing fresh water from source to completions pad
\(\textcolor{red}{C_{k,t}^{Disposal}}\) = Cost of injecting produced water at disposal site
\(\textcolor{red}{C_{r,t}^{Treatment}}\) = Cost of treating produced water at treatment site
\(\textcolor{red}{C_{p,t}^{CompletionsReuse}}\) = Cost of reusing produced water at completions site
\(\textcolor{red}{C_{s,t}^{Storage}}\) = Cost of storing produced water at storage site (incl. treatment)
\(\textcolor{red}{R_{s,t}^{Storage}}\) = Credit for retrieving stored produced water from storage site
\(\textcolor{red}{R_{o,t}^{BeneficialReuse}}\) = Credit for sending water to beneficial reuse
\(\textcolor{red}{C^{TotalSourced}}\) = Total cost of sourcing freshwater
\(\textcolor{red}{C^{TotalDisposal}}\) = Total cost of injecting produced water
\(\textcolor{red}{C^{TotalTreatment}}\) = Total cost of treating produced water
\(\textcolor{red}{C^{TotalCompletionsReuse}}\) = Total cost of reusing produced water
\(\textcolor{red}{C^{TotalPiping}}\) = Total cost of piping produced water
\(\textcolor{red}{C^{TotalStorage}}\) = Total cost of storing produced water
\(\textcolor{red}{C^{TotalTrucking}}\) = Total cost of trucking produced water
\(\textcolor{red}{C^{Slack}}\) = Total cost of slack variables
\(\textcolor{red}{R^{TotalStorage}}\) = Total credit for withdrawing produced water
\(\textcolor{red}{R^{TotalBeneficialReuse}}\) = Total credit for sending water to beneficial reuse
\(\textcolor{red}{D_{k,[t]}^{Capacity}}\) = Disposal capacity in a given time period at disposal site
\(\textcolor{red}{X_{s,[t]}^{Capacity}}\) = Storage capacity in a given time period at storage site
\(\textcolor{red}{T_{r,[t]}^{Capacity}}\) = Treatment capacity in a given time period at treatment site
\(\textcolor{red}{F_{l,\tilde{l},[t]}^{Capacity}}\) = Flow capacity in a given time period between two locations
\(\textcolor{red}{C_{[t]}^{DisposalCapEx}}\) = Capital cost of constructing or expanding disposal capacity
\(\textcolor{red}{C_{[t]}^{PipelineCapEx}}\) = Capital cost of constructing or expanding piping capacity
\(\textcolor{red}{C_{[t]}^{StorageCapEx}}\) = Capital cost of constructing or expanding storage capacity
\(\textcolor{red}{C_{[t]}^{TreatmentCapEx}}\) = Capital cost of constructing or expanding treatment capacity
\(\textcolor{red}{S_{p,t}^{FracDemand}}\) = Slack variable to meet the completions water demand
\(\textcolor{red}{S_{p,t}^{Production}}\) = Slack variable to process produced water production
\(\textcolor{red}{S_{p,t}^{Flowback}}\) = Slack variable to process flowback water production
\(\textcolor{red}{S_{l,\tilde{l}}^{Pipeline Capacity}}\) = Slack variable to provide necessary pipeline capacity
\(\textcolor{red}{S_{s}^{StorageCapacity}}\) = Slack variable to provide necessary storage capacity
\(\textcolor{red}{S_{k}^{DisposalCapacity}}\) = Slack variable to provide necessary disposal capacity
\(\textcolor{red}{S_{r}^{TreamentCapacity}}\) = Slack variable to provide necessary treatment capacity
\(\textcolor{red}{S_{o}^{BeneficialResueCapacity}}\) = Slack variable to provide necessary beneficial reuse capacity
Binary Variables
\(\textcolor{red}{y_{l,\tilde{l},d,[t]}^{Pipeline}}\) = New pipeline installed between one location and another location with specific diameter
\(\textcolor{red}{y_{s,c,[t]}^{Storage}}\) = New or additional storage facility installed at storage site with specific storage capacity
\(\textcolor{red}{y_{r,wt,j,[t]}^{Treatment}}\) = New or additional treatment capacity installed at treatment site with specific treatment capacity and treatment technology
\(\textcolor{red}{y_{k,i,[t]}^{Disposal}}\) = New or additional disposal facility installed at disposal site with specific injection capacity
\(\textcolor{red}{y_{l,\tilde{l},t}^{Flow}}\) = Directional flow between two locations
\(\textcolor{green}{\gamma_{p,t}^{Completions}}\) = Completions demand at a completions site in a time period
\(\textcolor{green}{\gamma^{TotalDemand}}\) = Total water demand over the planning horizon
\(\textcolor{green}{\beta_{p,t}^{Production}}\) = Produced water supply forecast for a production pad
\(\textcolor{green}{\beta_{p,t}^{Flowback}}\) = Flowback supply forecast for a completions pad
\(\textcolor{green}{\beta^{TotalProd}}\) = Total water production (production & flowback) over the planning horizon
\(\textcolor{green}{\sigma_{l,\tilde{l}}^{Pipeline}}\) = Initial pipeline capacity between two locations
\(\textcolor{green}{\sigma_{k}^{Disposal}}\) = Initial disposal capacity at disposal site
\(\textcolor{green}{\sigma_{s}^{Storage}}\) = Initial storage capacity at storage site
\(\textcolor{green}{\sigma_{p,t}^{PadStorage}}\) = Storage capacity at completions site
\(\textcolor{green}{\sigma_{r,wt}^{Treatment}}\) = Initial treatment capacity at treatment site
\(\textcolor{green}{\sigma_{o,t}^{BeneficialReuseMinimum}}\) = Minimum flow that must be sent to beneficial reuse option
\(\textcolor{green}{\sigma_{o,t}^{BeneficialReuse}}\) = Capacity of beneficial reuse option
\(\textcolor{green}{\sigma_{f,t}^{Freshwater}}\) = Freshwater sourcing capacity at freshwater source
\(\textcolor{green}{\sigma_{p}^{Offloading,Pad}}\) = Truck offloading sourcing capacity per pad
\(\textcolor{green}{\sigma_{s}^{Offloading,Storage}}\) = Truck offloading sourcing capacity per storage site
\(\textcolor{green}{\sigma_{p}^{Processing,Pad}}\) = Processing (e.g. clarification) capacity per pad
\(\textcolor{green}{\sigma_{s}^{Processing,Storage}}\) = Processing (e.g. clarification) capacity at storage site
\(\textcolor{green}{\sigma_{n}^{Node}}\) = Capacity per network node
\(\textcolor{green}{W_{r}^{TreatmentComponent}}\) = Water quality component treated for at treatment site
\(\textcolor{green}{\epsilon_{r, wt}^{Treatment}}\) = Treatment efficiency for technology \(\textcolor{blue}{wt}\) at treatment site
\(\textcolor{green}{\epsilon_{r, wt, qc}^{TreatmentRemoval}}\) = Removal efficiency for technology \(\textcolor{blue}{wt}\) and quality component \(\textcolor{blue}{qc}\) at treatment site
\(\textcolor{green}{\epsilon_{k,t}^{DisposalOperatingCapacity}}\) = Operating capacity of disposal site [%]
\(\textcolor{green}{\chi_{p}^{OutsideCompletionsPad}}\) = Binary parameter designating the completion pads that are outside the system
\(\textcolor{green}{\chi_{wt}^{DesalinationTechnology}}\) = Binary parameter designating which treatment technologies are for desalination (1) and which are not (0)
\(\textcolor{green}{\chi_{r}^{DesalinationSites}}\) = Binary parameter designating which treatment sites are for desalination (1) and which are not (0)
\(\textcolor{green}{\chi_{k}^{DisposalExpansionAllowed}}\) = Binary parameter indicating if expansion is allowed at site \(k`\)
\(\textcolor{green}{\omega^{EvaporationRate}}\) = Evaporation rate per week
\(\textcolor{green}{\delta_{i}^{Disposal}}\) = Increments for installation/expansion of disposal capacity
\(\textcolor{green}{\delta_{c}^{Storage}}\) = Increments for installation/expansion of storage capacity
\(\textcolor{green}{\delta_{wt, j}^{Treatment}}\) = Increments for installation/expansion of treatment capacity
\(\textcolor{green}{\tau_{k}^{Disposal}}\) = Disposal construction or expansion lead time
\(\textcolor{green}{\tau_{s}^{Storage}}\) = Storage construction or expansion lead time
\(\textcolor{green}{\tau_{l,\tilde{l}}^{Pipeline}}\) = Pipeline construction or expansion lead time
\(\textcolor{green}{\tau_{l,\tilde{l}}^{Trucking}}\) = Drive time between two locations
\(\textcolor{green}{\lambda_{s}^{Storage}}\) = Initial storage level at storage site
\(\textcolor{green}{\lambda_{p}^{PadStorage}}\) = Initial storage level at completions site
\(\textcolor{green}{\theta_{s}^{Storage}}\) = Terminal storage level at storage site
\(\textcolor{green}{\theta_{p}^{PadStorage}}\) = Terminal storage level at completions site
\(\textcolor{green}{\kappa_{k,i}^{Disposal}}\) = Disposal construction or expansion capital cost for selected capacity increment
\(\textcolor{green}{\kappa_{s,c}^{Storage}}\) = Storage construction or expansion capital cost for selected capacity increment
\(\textcolor{green}{\kappa_{r,wt,j}^{Treatment}}\) = Treatment construction or expansion capital cost for selected capacity increment
The cost parameter for expanding or constructing new pipeline capacity is structured differently depending on model configuration settings. If the pipeline cost configuration is distance based:
\(\textcolor{green}{\kappa^{Pipeline}}\) = Pipeline construction or expansion capital cost [currency/(diameter-distance)]
\(\textcolor{green}{\mu_{d}^{Pipeline}}\) = Pipeline diameter installation or expansion increments [diameter]
Otherwise, if the pipeline cost configuration is capacity based:
\(\textcolor{green}{\kappa_{l,\tilde{l},d}^{Pipeline}}\) = Pipeline construction or expansion capital cost for selected diameter capacity [currency/(volume/time)]
\(\textcolor{green}{\delta_{d}^{Pipeline}}\) = Increments for installation/expansion of pipeline capacity [volume/time]
Two objective functions can be considered for the optimization of a produced water system: first, the minimization of costs, which includes operational costs associated with procurement of fresh water, the cost of disposal, trucking and piping produced water between well pads and treatment facilities, and the cost of storing, treating and reusing produced water. Capital costs are also considered due to infrastructure build out such as the installation of pipelines, treatment, and storage facilities. A credit for (re)using treated water is also considered, and additional slack variables are included to facilitate the identification of potential issues with input data. The second objective is the maximization of water reused which is defined as the ratio between the treated produced water that is used in completions operations and the total produced water coming to surface.
The annualization rate is calculated using the formula described at this website: https://www.investopedia.com/terms/e/eac.asp.
The annualization rate takes the discount rate (rate) and the number of years the CAPEX investment is expected to be used (life) as input.
Completions Pad Demand Balance:\(\forall \textcolor{blue}{p \in CP}, \textcolor{blue}{t \in T}\)
If the completions pad lies outside the system, the demand is optional. Otherwise, if the completions pad is within the system, completions demand must be met.
Demand can be met by trucked or piped water moved into the pad in addition to water in completions pad storage.
If \(\textcolor{green}{\chi_{p}^{OutsideCompletionsPad}} = 1\):
Completions Pad Storage Balance:\(\forall \textcolor{blue}{p \in CP}, \textcolor{blue}{t \in T}\)
Sets the storage level at the completions pad. For each completions pad and for each time period, completions pad storage is equal to storage in last time period plus water put in minus water removed. If it is the first time period, the pad storage is the initial pad storage.
For each storage site and each time period, the volume of water being trucked into the storage site must be below the trucking offloading capacity for that storage site.
\[\sum_{l \in L | (l, s) \in LLT}\textcolor{red}{F_{l,s,t}^{Trucked}}
\leq \textcolor{green}{\sigma_{s}^{Offloading,Storage}}\]
Storage Site Processing Capacity:\(\forall \textcolor{blue}{s \in S}, \textcolor{blue}{t \in T}\)
For each storage site and each time period, the volume of water being piped and trucked into the storage site must be less than the processing capacity for that storage site.
\[\sum_{l \in L | (l, s) \in LLA}\textcolor{red}{F_{l,s,t}^{Piped}}
+ \sum_{l \in L | (l, s) \in LLT}\textcolor{red}{F_{l,s,t}^{Trucked}}
\leq \textcolor{green}{\sigma_{s}^{Processing,Storage}}\]
Production Pad Supply Balance:\(\forall \textcolor{blue}{p \in PP}, \textcolor{blue}{t \in T}\)
All produced water must be accounted for. For each production pad and for each time period, the volume of outgoing water must be equal to the forecasted produced water for the production pad.
All flowback water must be accounted for. For each completions pad and for each time period, the volume of outgoing water must be equal to the forecasted flowback produced water for the completions pad.
Flow balance constraint (i.e., inputs are equal to outputs). For each pipeline node and for each time period, the volume water into the node is equal to the volume of water out of the node.
\[\sum_{l \in L | (l, n) \in LLA}\textcolor{red}{F_{l,n,t}^{Piped}}
= \sum_{l \in L | (n, l) \in LLA}\textcolor{red}{F_{n,l,t}^{Piped}}\]
There can only be flow in one direction for a given pipeline arc in a given time period. Flow is only allowed in a given direction if the binary indicator for that direction is “on”.
Technically the above constraint should only be enforced for truly reversible arcs (e.g. NCA and CNA); and even then it only needs to be defined per one reversible arc (e.g. NCA only and not NCA and CNA).
Storage Site Balance:\(\forall \textcolor{blue}{s \in S}, \textcolor{blue}{t \in T}\)
For each storage site and for each time period, if it is the first time period, the storage level is determined by the initial storage and storage inputs and outputs.
Otherwise, the storage level is determined by the storage level in the previous time period and storage inputs and outputs.
Water outputs include other system nodes (i.e., pipeline nodes and completions pads) and an evaporation stream.
Flow capacity constraint. For each pipeline node and for each time period, the volume should not exceed the node capacity.
\[\sum_{l \in L | (l, n) \in LLA}\textcolor{red}{F_{l,n,t}^{Piped}}
\leq \textcolor{green}{\sigma_{n}^{Node}}\]
Pipeline Capacity Construction/Expansion:
Sets the flow capacity in a given pipeline during a given time period. The set \(\textcolor{blue}{D}\) should also include the 0th case (e.g. 0 bbl/day) that indicates the choice to not expand capacity.
Different constraints apply based on whether a pipeline is allowed to reverse flows at any time. Thus, the following constraint applies to all pipelines that allow reversible flows:
While popuplating the input data into the spreadsheet for initial pipeline capacities, users must use the following guidelines.
For uni-directional pipelines, the initial pipeline capacity must be populated only in the direction of flow else, it will be ignored by the model.
For bi-directional pipelines, the initial pipeline capacity should be populated for only one of the allowable flow directions, not both. The pipeline capacities are aggregated for both directions, so the choice of direction for the capacity is irrelevant.
Note
\(\textcolor{green}{\delta_{d}^{Pipeline}}\) can be input by user or calculated. If the user chooses to calculate pipeline capacity, the parameter will be calculated by the equation below where \({\textcolor{green}{\kappa_{l,\tilde{l}}}}\) is Hazen-Williams constant and \(\omega\) is Hazen-Williams exponent as per Cafaro & Grossmann (2021) and d represents the pipeline diameter as per the set \(\textcolor{blue}{d \in D}\).
The following 2 constraints account for the expansion of available storage capacity or installation of storage facilities. If expansion/construction is selected, expand the capacity by the set expansion amount. The water level at the storage site must be less than this capacity. As of now, the model considers that a storage facility is expanded or built at the beginning of the planning horizon.
The set \(\textcolor{blue}{C}\) should also include the 0th case (0 bbl) that indicates the choice to not expand capacity.
The following 2 constraints account for the expansion of available disposal sites or installation of new disposal sites. If expansion/construction is selected, expand the capacity by the set expansion amount. The total disposed water in a given time period must be less than this new capacity.
The set \(\textcolor{blue}{I}\) should also include the 0th case (e.g. 0 bbl/day) that indicates the choice to not expand capacity.
Similarly to disposal and storage capacity construction/expansion constraints, the current treatment capacity can be expanded as required or new facilities may be installed.
The set \(\textcolor{blue}{J}\) should also include the 0th case (e.g. 0 bbl/day) that indicates the choice to not expand capacity.
For all piping or trucking arcs \(\textcolor{blue}{(r, l)}\) immediately downstream of a treatment site \(\textcolor{blue}{r}\), the user must specify whether the arc carries treated water or residual water away from the treatment site. Moreover,
Treated Water Balance: \(\forall \textcolor{blue}{r \in R} \ |\) there exists at least one arc \(\textcolor{blue}{(r,l)}\) carrying treated water away from \(\textcolor{blue}{r}, \ \textcolor{blue}{t \in T}\)
\[\textcolor{red}{F_{r,t}^{TreatedWater}} = \sum_{l \in L | (r, l) \in LLA \text{ and } (r,l) \text{ carries treated water}} \textcolor{red}{F_{r,l,t}^{Piped}}
+ \sum_{l \in L | (r, l) \in LLT \text{ and } (r,l) \text{ carries treated water}} \textcolor{red}{F_{r,l,t}^{Trucked}}\]
Residual Water Balance: \(\forall \textcolor{blue}{r \in R} \ |\) there exists at least one arc \(\textcolor{blue}{(r,l)}\) carrying residual water away from \(\textcolor{blue}{r}, \ \textcolor{blue}{t \in T}\)
\[\textcolor{red}{F_{r,t}^{ResidualWater}} = \sum_{l \in L | (r, l) \in LLA \text{ and } (r,l) \text{ carries residual water}} \textcolor{red}{F_{r,l,t}^{Piped}}
+ \sum_{l \in L | (r, l) \in LLT \text{ and } (r,l) \text{ carries residual water}} \textcolor{red}{F_{r,l,t}^{Trucked}}\]
Note
The user is not required to specify any arcs carrying away treated or residual water immedaitely downstream of a treatment site. In reality, water that enters a treatment site must eventually leave and go somewhere, but for the sake of modeling flexibility, it is not required to include such arcs. If the user chooses to omit downstream treated and/or residual water arcs for a treatment site, then the treatment site acts as a sink within the greater network model for the water which is not propagated downstream.
If a beneficial reuse option is not selected (\(\textcolor{red}{y_{o,t}^{BeneficialReuse}} = 0\)), the flow to it must be zero. Furthermore, the specified capacities of beneficial reuse options must be respected.
It is optional to specify capacities (\(\textcolor{green}{\sigma_{o,t}^{BeneficialReuse}}\)) for reuse options. If a capcity is provided for reuse option \(\textcolor{blue}{o}\):
For each freshwater source, for each completions pad, and for each time period, the freshwater sourcing cost is equal to all output from the freshwater source times the freshwater sourcing cost.
The total fresh sourced volume is the sum of freshwater movements by truck and pipeline over all time periods, completions pads, and freshwater sources.
For each disposal site, for each time period, the disposal cost is equal to all water moved into the disposal site multiplied by the operational disposal cost. Total disposal cost is the sum of disposal costs over all time periods and all disposal sites.
For each treatment site, for each time period, the treatment cost is equal to all water moved to the treatment site multiplied by the operational treatment cost. The total treatments cost is the sum of treatment costs over all time periods and all treatment sites.
Completions reuse water is all water that meets completions pad demand, excluding freshwater. Completions reuse cost is the volume of completions reused water multiplied by the cost for reuse.
The total reuse volume is the total volume of produced water reused, or the total water meeting completions pad demand over all time periods, excluding freshwater.
Trucking cost between two locations for time period is equal to the trucking volume between locations in time \(\textcolor{blue}{t}\) divided by the truck capacity [this gets # of truckloads] multiplied by the lead time between two locations and hourly trucking cost.
Cost related to expanding or constructing new disposal capacity. Takes into consideration capacity increment, cost for selected capacity increment, and if the construction/expansion is selected to occur.
Cost related to expanding or constructing new storage capacity. Takes into consideration capacity increment, cost for selected capacity increment, and if the construction/expansion is selected to occur.
Treatment Construction or Capacity Expansion Cost:
Cost related to expanding or constructing new treatment capacity. Takes into consideration capacity increment, cost for selected capacity increment, and if the construction/expansion is selected to occur.
Cost related to expanding or constructing new pipeline capacity is calculated differently depending on model configuration settings.
If the pipeline cost configuration is capacity based, pipeline expansion cost is calculated using capacity increments, cost for selected capacity increment, and if the construction/expansion is selected to occur.
If the pipeline cost configuration is distance based, pipeline expansion cost is calculated using pipeline distances, pipeline diameters, cost per inch mile, and if the construction/expansion is selected to occur.
Seismic Response Areas (SRAs) can reduce the operating capacity at disposal wells. The operating capacity is set by the full built capacity and the max percentage of
capacity the disposal site is allowed to use.
Weighted sum of the slack variables. In the case that the model is infeasible, these slack variables are used to determine where the infeasibility occurs (e.g. pipeline capacity is not sufficient).
New pipeline or facility capacity constraints: e.g., only one injection capacity can be used for a given site.
The sets for capacity sizes should also include the 0th case (e.g., 0 bbl) that indicates the choice to not expand capacity.
Alternatively, if it is desired to only consider sizes to build, the 0th case can be left out.
Evaporation Flow Constraint
Evaporation flow for a given time period and storage site is 0 if it is the first time period. Otherwise, evaporation
is a constant flow set by the parameter \(\textcolor{green}{\omega^{EvaporationRate}}\).
\[\textcolor{red}{F_{s,t}^{StorageEvaporationStream}} = \textcolor{green}{\omega^{EvaporationRate}} \cdot
\sum_{j \in J, r \in R | (r,s) \in RSA} \textcolor{red}{y_{r,'CB-EV',j}^{Treatment}}\]
Deliveries Destination Constraints:
Completions reuse deliveries at a completions pad in time period \(\textcolor{blue}{t}\) is equal to all piped and trucked water moved into the completions pad, excluding freshwater.
\(\forall \textcolor{blue}{p \in CP}, \textcolor{blue}{t \in T}\)
\[\textcolor{red}{F_{p,t}^{CompletionsReuseDestination}}
= \sum_{l \in L | (l, p) \in LLA, l \notin F}\textcolor{red}{F_{l,p,t}^{Piped}}
+ \sum_{l \in L | (l, p) \in LLT, l \notin F}\textcolor{red}{F_{l,p,t}^{Trucked}}\]
Disposal deliveries for disposal site \(\textcolor{blue}{k}\) at time \(\textcolor{blue}{t}\) is equal to all piped and trucked water moved to the disposal site \(\textcolor{blue}{k}\).
\(\forall \textcolor{blue}{k \in K}, \textcolor{blue}{t \in T}\)
\[\textcolor{red}{F_{k,t}^{DisposalDestination}}
= \sum_{l \in L | (l, k) \in LLA}\textcolor{red}{F_{l,k,t}^{Piped}}
+ \sum_{l \in L | (l, k) \in LLT}\textcolor{red}{F_{l,k,t}^{Trucked}}\]
Beneficial reuse deliveries for beneficial reuse site \(\textcolor{blue}{o}\) at time \(\textcolor{blue}{t}\) is equal to all piped and trucked water moved to the beneficial reuse site \(\textcolor{blue}{o}\).
\(\forall \textcolor{blue}{o \in O}, \textcolor{blue}{t \in T}\)
\[\textcolor{red}{F_{o,t}^{BeneficialReuseDestination}}
= \sum_{l \in L | (l, o) \in LLA}\textcolor{red}{F_{l,o,t}^{Piped}}
+ \sum_{l \in L | (l, o) \in LLT}\textcolor{red}{F_{l,o,t}^{Trucked}}\]
Completions deliveries destination for completions pad \(\textcolor{blue}{p}\) at time \(\textcolor{blue}{t}\) is equal to all piped and trucked water moved to the completions pad.
\(\forall \textcolor{blue}{p \in CP}, \textcolor{blue}{t \in T}\)
An extension to this strategic optimization model measures the water quality across all locations over time. As of now, water quality is not a decision variable. It is calculated after optimization of the strategic model.
The process for calculating water quality is as follows: the strategic model is first solved to optimality, water quality variables and constraints are added, flow rates and storage levels are fixed to the solved values at optimality, and the water quality is calculated.
Note
Fixed variables are colored purple in the documentation.
Assumptions:
Water quality of produced water from production pads and completions pads remains the same across all time periods
When blending flows of different water quality, they blend linearly
Water Quality Sets
\(\textcolor{blue}{qc \in QC}\) Water Quality Components (e.g., TDS)
\(\textcolor{blue}{p^{IntermediateNode} \in CP}\) Intermediate Completions Pad Nodes
\(\textcolor{blue}{p^{PadStorage} \in CP}\) Pad Storage
\(\textcolor{blue}{r^{TreatedWaterNodes} \in R}\) Treated Water Nodes
\(\textcolor{blue}{r^{ResidualWaterNodes} \in R}\) Residual Water Nodes
Water Quality Parameters
\(\textcolor{green}{\nu_{p,qc,[t]}}\) = Water quality at well pad
\(\textcolor{green}{\xi_{s,qc}^{StorageSite}}\) = Initial water quality at storage
\(\textcolor{green}{\xi_{p,qc}^{PadStorage}}\) = Initial water quality at pad storage
Water Quality Variables
\(\textcolor{red}{Q_{l,qc,t}}\) = Water quality at location
Disposal Site Water Quality\(\forall \textcolor{blue}{k \in K}, \textcolor{blue}{qc \in QC}, \textcolor{blue}{t \in T}\)
The water quality of disposed water is dependent on the flow rates into the disposal site and the quality of each of these flows.
Storage Site Water Quality\(\forall \textcolor{blue}{s \in S}, \textcolor{blue}{qc \in QC}, \textcolor{blue}{t \in T}\)
The water quality at storage sites is dependent on the flow rates into the storage site, the volume of water in storage in the previous time period, and the quality of each of these flows. Even mixing is assumed, so all outgoing flows have the same water quality. If it is the first time period, the initial storage level and initial water quality, respectively, replace the water stored and water quality in the previous time period.
The water quality at treatment sites is dependent on the flow rates and qualities of the feed streams into the treatment site. Even mixing is assumed in calculating the quality of the combined feed stream.
All treated water from a single treatment site and single time period will have the same water quality. The following constraints allow us to
easily track the water quality at treated water end points like desalinated water.
The water quality at nodes is dependent on the flow rates into the node and the water quality of the flows. Even mixing is assumed, so all outgoing flows have the same water quality.
Completions Pad Intermediate Node Water Quality\(\forall \textcolor{blue}{p \in P}, \textcolor{blue}{qc \in QC}, \textcolor{blue}{t \in T}\)
Water Quality at Completions Pads
Water that is piped and trucked to a completions pad is mixed and split into two output streams: Stream (1) goes to the completions pad and stream (2) is input to the completions storage.
This mixing happens at an intermediate node. Finally, water that meets completions demand comes from two inputs: The first input is output stream (1) from the intermediate step. The second is outgoing flow from the storage tank.
The water quality at the completions pad intermediate node is dependent on the flow rates of water from outside of the pad to the pad. Even mixing is assumed, so the water to storage and water to completions input have the same water quality.
Completions Pad Input Node Water Quality\(\forall \textcolor{blue}{p \in P}, \textcolor{blue}{qc \in QC}, \textcolor{blue}{t \in T}\)
The water quality at the completions pad input is dependent on the flow rates of water from pad storage and water from the intermediate node. Even mixing is assumed, so all water into the pad is of the same water quality.
Completions Pad Storage Node Water Quality\(\forall \textcolor{blue}{p \in P}, \textcolor{blue}{qc \in QC}, \textcolor{blue}{t \in T}\)
The water quality at pad storage sites is dependent on the flow rates into the pad storage site, the volume of water in pad storage in the previous time period, and the quality of each of these flows. Even mixing is assumed, so the outgoing flow to completions pad and water in storage at the end of the period have the same water quality. If it is the first time period, the initial storage level and initial water quality, respectively, replace the water stored and water quality in the previous time period.
In the previous chapter a model for tracking the water quality was shown. Without fixing the flows this model is non-linear. By discretizing the number of water qualities for all locations over time we can make the model linear again.
The discretization works as follows.
Take for example this term from the Disposal Site Water Quality:
Discrete Max Disposal Destination ∀l in L, t in T, qc in QC, q in Q
For each location in time only for one discrete quality there can be water injected at the disposal site and at most the capacity for that disposal site. For all the others it is equal to zero.
Cafaro, D. C., & Grossmann, I. (2021). Optimal design of water pipeline networks for the development of shale gas resources. AIChE Journal, 67(1), e17058.
The treatment model discussed in this section primarily applies to the strategic model within PARETO. The content presented here is therefore focused on its relevance to the strategic model. Although some concepts might be applicable to PARETO as a whole, it is essential to note that component removal efficiency has not been implemented for the operational model.
Treatment systems play a crucial role for achieving desired water quality for various purposes, such as recycling for hydraulic fracturing, beneficial reuse applications, and critical mineral recovery. Depending on the purpose and degree of treatment, the costs associated with treatment systems can be significant and greatly impact the investment cost in a management option. This makes it necessary to carefully consider the treatment models and their costs when evaluating produced water management strategies. Therefore, it is essential to integrate treatment models into the PARETO decision-making process. This will enable stakeholders to better understand the trade-offs between different management options and their associated costs, ultimately leading to more informed decisions.
The PARETO network identifies treatment plants based on their location (\(r \in R\)), capacity (\(j \in J\)), and technology (\(wt \in WT\)). The streams that are piped or trucked to treatment plants are represented by arcs (\((l,r) \in LRA \cup LRT\)), where \(l\) can be any location or node in PARETO network. The indices \(j\) and \(wt\) are employed in conjunction with a binary variable to install or expand a treatment plant with a specific capacity (for further details, please refer to strategic water management).
The following equation describes the flow balance at location \(r\):
where \(F\) and \(Q\) denotes the flow and quality (concentrations) of streams. The units of concentration are typically reported as mass/volume (mg/L, g/m3, kg/L, etc.) and the units of flow rate are reported in volume/time (e.g. bbl/week).
Water treatment systems are modeled using overall water and constituent balances, treatment and removal efficiencies, and operating cost and capital cost values/equations. The schematic in Figure 1 depicts a treatment unit that processes a treatment feed with specific qualities, yielding two output streams: treated water and residual water. The treated water and residual water streams have distinct qualities, which vary depending on the specific treatment process employed.
The overall water and constituent balance equations for water treatment systems are as follows:
Removal efficiency is a measure of the overall reduction in the concentration or load of a constituent in a treatment plant, expressed as a percentage [1]. The removal efficiency of a certain constituent is commonly calculated based on the influent (feed) concentration and the effluent (treated water) concentration as follows:
For example, if the influent concentration of a constituent is 200 mg/L and the effluent concentration is 20 mg/L, then the removal efficiency can be calculated as:
Another method for calculating removal efficiency is the measure of overall reduction in the load of the contaminant (volumetric flowrate times concentration) instead of reduction in concentration. This approach is specifically useful in situations where there are substantial water losses due to evaporation and evapotranspiration.
it should be noted that the load-based definition of removal efficiency will have a non-zero value even for situations where there is no concentration reduction happening, such as a simple splitter. In such cases, introducing an equality constraint on the quality of the streams in the load-based approach will result in the following equation:
It is worth noting that in cases where there is minimal water loss to the residual stream, such that the treated water flow is approximately equal to the feed flow, the removal efficiency values obtained by the two definitions (concentration based and load based) become the same.
PARETO supports both formulations and gives the user the option to choose between the two methods based on their available data or the technology considered. The two options are expressed as RemovalEfficiencyMethod.Concentration_based and RemovalEfficiencyMethod.Load_based in PARETO configruation argument for removal efficiency.
The total cost of produced water treatment consist of capital costs and annual operating costs. Capital costs include the costs associated with the land purchanse, construction, purchasing process equipment, and installation. Annual operating costs refer to the cost during plant operation such as cost of energy, equimpment replacement, chemicals, labor, and maintenance. The sum of the unit operating costs and the unit annualized capital costs determines the total capital cost per unit volume of produced water.
Treatment costs can be incorporated into PARETO with three methods:
To begin, users can provide their own estimated capital and operating costs for each treatment technology. PARETO provides a treatment technology matrix (shown below) with data collected from available literature on various technologies such as membrane distillation, multi-effect distillation, mechanical vapor compression, and osmotically assisted reverse osmosis (for further detail regarding selected technologies and references please refer to the provided sheet: treatmentmatrix). The technologies considered in this matrix are capable of treating hypersaline produced water up to saturation limits. Users may use these values to evaluate treatment options using PARETO. However, we encourage users to provide their own cost data, obtained from treatment technology vendors, to enable better evaluation of management options.
It is important to note that currently, PARETO incorporates treatment costs for discrete values of treatment capacity expansions. In other words, the treatment cost calculations are limited to specific capacity levels.
An alternative approach to incorporating treatment costs in PARETO is through the use of surrogate models. These models allow for linear or nonlinear approximations of treatment costs as a function of treatment capacity, feed quality, and recovery. This method is currently under development and not yet available in the current version of PARETO, and it is planned for inclusion in future updates.
The third method for incorporating treatment costs into PARETO is through the integration of rigorous technoeconomic optimization treatment models. These models allow for accurate capture of the effect of changes in input parameters on treatment plant performance and costs. Currently, a technoeconomic optimization-based modeling approach for single effect and multi-effect mechanical vapor compression (MVC) desalination systems is being developed for integration with PARETO. The following section will provide a detailed description of the MVC modeling effort.
Single effect evaporation and multi-effect evaporation has been studied for shale water desalination. Mechanical vapor compression, uses a compressor to utilize the heat from the evaporated vapor for further evaporation. As shown in the schematic in Figure (2), for a system with I effects, the produced water is fed into evaporator I. After evaporation, the brine from the ith effect is sent to the (i-1)th effect and the vapor from the (i-1)th effect is sent to the ith effect.
The vapor from the ith evaporator is sent to the compressor for compression. The superheated vapor from the compressor is then sent into the tubes of the 1st evaporator to carry out the evaporation process. The condensate from all the evaporator effects is sent to the preheater where it preheats the feed and thus aids in heat integration.
The multi-effect evaporator model is built to consider multiple evaporator effects. The user can specify the number of effects, feed flow rate, TDS concentration in feed and the minimum TDS specification in the brine. The model then calculates the capital costs, operating costs, compressor work, compressor capacity, evaporator heat exchange area and the preheater area. The user can also obtain the pressures, temperatures and concentrations of the individual streams.
The model is built in Pyomo and is based on equations Onishi et al.’s study [2] on shale gas flowback water desalination.
The goal is to minimize the total annualized cost (TAC) of the treatent unit. CAPEX of the equipments were calculated using empirical relations from IDAES costing. Assuming the evaporator is a U-tube heat exchanger, the CAPEX of the evaporators in kUSD is given by:
Annualization factor: The annualization factor for CAPEX is calculated based on fractional interest rate \(r = 0.1\) per year and amortization period \(y = 10\) years.
\[fac = \frac{r(1+r)^y}{(1+r)^y -1}\]
The annualized CAPEX is calculated by:
\[CAPEX_{ann} = fac \times CAPEX\]
The cost of operating the treatment unit comes from operating the compressor using electricity.
\[OPEX_{ann} = C_{elec} \times W_{compr}\]
The total annualized cost is therefore given by:
\[TAC = CAPEX_{ann} + OPEX_{ann}\]
This is our objective function which we’ll minimize.
To demonstrate the effect of the feed salinity on the TAC, we consider a single effect evaporator without heat integration using a preheater. The feed flow rate is fixed to 10 kg/s and the outlet brine TDS concentration needs to be above 250 g/kg. The salt concentration in the feed is varied from 70 g/kg to 190 g/kg. A plot of feed salinity vs TAC is generated as shown in Figure 3:
Figure 3. TAC vs feed salinity for a single effect evaporator
For the same conditions, the sensitivity analysis for a multi-effect evaporator with two stages and heat integration using a preheater is shown in Figure 4:
Figure 4. TAC vs feed salinity for a two effect evaporator with heat integration
Produced water (PW) network operations are highly affected by the pipeline designs and geographical terrain because of pressure losses due to friction and elevation changes. PARETO hydraulics module is an extension to the strategic model that allows the user to compute pressures at every node in the network enabling the user to add operational constraints such as maximum allowable operating pressures (MAOP) and minimum required pressure at injection facilities or at 3rd party offtake points. For this, the PARETO model explicitly considers pipeline details (i.e., length, diameter, material, etc.) and geographic elevations in the model to compute time varying pressures at each node. The hydraulics module is an extension to the PARETO strategic model and can be accessed through the following options in the config argument:
Hydraulics.false: This option allows the user to skip the hydraulics computations in the PARETO model.
Hydraulics.post_process: In this method, the basic PARETO strategic model is solved as step 1, and then using the optimal flows and network design, the hydraulics block containing constraints for pressure balances and losses is solved as step 2. In this case, as only the hydraulics model block solved for the objective of minimizing cost, the optimal values for variables included in the main strategic model and obtained from step 1 remain unaffected.
Hydraulics.co_optimize: In this method, the hydraulics model block is solved together with the strategic model. However, as the flow and diameter are variables in the strategic model, the addition of hydraulics block makes the model a mixed integer nonlinear programming (MINLP) model. In order to solve this MINLP model, the strategic model without the hydraulics constraints is solved as step 1 to determine a good initial state for all variables and constraints.
Note: The MINLP as currently implemented requires the following MINLP solvers: SCIP and BARON. The model is first solved using BARON (if available) to determine a feasible solution and then using SCIP.
Some subtle differences in model components such as in the definition of variables and parameters have been made to avoid nonlinearities and allow the user to use the same solver for solving the post-process method as used for the strategic model. These differences will be shown in the description of mathematical notation and formulation below.
Similar to the strategic model, following color coding has been implemented in describing the model notation. All input \(\textcolor{green}{parameters}\) are in \(\textcolor{green}{green}\) and all model \(\textcolor{red}{variables}\) are in \(\textcolor{red}{red}\).
Parameters
\(\textcolor{green}{\zeta_{l}}\) = Geographical elevation of a Node
\(\textcolor{green}{\rho.g}\) = Product of water density and accelaration due to gravity
\(\textcolor{green}{\iota^{CHW}}\) = Constant for pipeline material in Hazen-Williams equation
\(\textcolor{green}{\nu^{Pump}}\) = Fixed cost of installing a pump
Hazen-Williams based frictional head loss calculation:\(\forall \textcolor{blue}{l,\tilde{l} \in LLA}, \textcolor{blue}{t \in T}\)
Calculate head loss using Hazen-Williams equation. Note that units for all terms in this equation are in SI units so, appropriate conversion factors must be added.
Hazen-Williams based frictional head loss calculation:\(\forall \textcolor{blue}{l,\tilde{l} \in LLA}, \textcolor{blue}{t \in T}\)
Calculate head loss using Hazen-Williams equation. Note that units for all terms in this equation are in SI units so, appropriate conversion factors must be added.
A representative example of a
Permian system. Nearly identical
to treatment demo, but with
reduced CAPEX options.
A very small, toy-sized network.
Useful for testing and debugging.
Larger network, but “small” in the
sense that disposal and pipeline
expansion are not allowed, so the
model solves quickly.
Larger network, and disposal and
pipeline expansion are allowed.
Takes a bit longer to solve. This
can be seen as the “default” case
study for the strategic model.
Generic case study for the
operational model. Note that this
case study cannot currently be run
in PARETO UI - it can only be run
using the Python command line
interface.
Users interested in utilizing PARETO programmatically by writing Python code can download and run these Jupyter notebooks. Additional Jupyter notebook tutorials and examples are currently under development and will be added to the examples directory of the PARETO repository when they are available. The above list will be updated as well.
New users of PARETO will also benefit from familiarity with Python and Pyomo. PARETO, IDAES, and WaterTAP are all built with Python and Pyomo, so we refer users unfamiliar with Python or Pyomo to the following tutorials:
PARETO project provides a set of user-friendly utility methods to display and analyze results. These methods include debugging tools, plotting utilities, and Python-Excel interfaces.
This method uses Pandas methods to read data for sets and parameters from an
Excel spreadsheet. Sets are assumed to not have neither a header nor an index column.
In addition, the data should be placed in column A, row 2, for example:
Parameters can be in either table or column format. Table format requires a header (usually time periods) and index columns whose elements should be contained in a set. Each index column should be labeled with a header starting in cell A2. Spreadsheet names for sets should be used as headers; however, generic keywords “NODES” and “INDEX” can also be used. Column format requires that each set be placed in one column, starting from cell A3. Spreadsheet names for sets should be used as headers in row 2 for each column “NODES” and “INDEX” can also be used. Data should be provided in the last column, and the keyword “VALUE” should be used as header.
This method outputs a dictionary that contains a list for each set
and a dictionary that contains parameters in the following format:
{‘param1’: {(set1, set2): value}, ‘param1’: {(set1, set2): value}}
This method checks if the elements included in a table or parameter have been defined as part of the
Sets that index such parameter. set_consistency_check() raises a TypeError exception If there are entries in the Parameter that are not
contained in the Sets, and prints out a list with all the entries that require revision.
How to Use:
The method requires one specified parameter (e.g. ProductionRates) AND one OR several sets over which
the aforementioned parameter is declared (e.g.ProductionPads, ProductionTanks, TimePeriods). In general,
the method can be run as follows: set_consistency_check(Parameter, set_1, set_2, etc)
This method allows the user to request drive distances and drive times using Bing maps API and
Open Street Maps API.
The method accept the following input arguments:
- origin:
REQUIRED. Data containing information regarding location name, and coordinates
latitude and longitude. Two formats are acceptable:
{(origin1,”latitude”): value1, (origin1,”longitude”): value2} or
{origin1:{“latitude”:value1, “longitude”:value2}}
The first format allows the user to include a tab with the corresponding data
in a table format as part of the workbook casestudy.
destination:
OPTIONAL. If no data for destination is provided, it is assumed that the
origins are also destinations.
api:
OPTIONAL. Specify the type of API service, two options are supported:
OPTIONAL. Define the parameters that the method will output. The user can select:
‘time’: A list containing the drive times between the locations is returned
‘distance’: A list containing the drive distances between the locations is returned
‘time_distance’: Two lists containing the drive times and drive distances between the locations is returned
If not output is specified, ‘time_distance’ is the default
fpath:
OPTIONAL. od_matrix() will ALWAYS output an Excel workbook with two tabs, one that
contains drive times, and another that contains drive distances. If not path is
specified, the excel file is saved with the name ‘od_output.xlsx’ in the current
directory.
create_report:
OPTIONAL. if True an Excel report with drive distances and drive times is created
This method identifies the type of model: [strategic, operational], creates a printing list based on is_print,
and creates a dictionary that contains headers for all the variables that will be included in an Excel report.
The dictionaries are used to create separate excel sheets which categorize the data by variable name or type.
This same data is put into excel sheets named after each variable as well as an overview sheet which contains totals and Key Performance Indicators (KPI) information.
Warning
If an indexed variable is added or removed from a model, the printing lists and headers should be updated
accordingly.
The output of this method prints out each variable’s information in the terminal as specified by the user, as shown below.
Sankey diagrams are a graphic tool used to easily visualize supply-sink flows across a given infrastructure (source/destination).
The relative width of each “flow” is proportional to the amount of water that is being transported between locations.
Such diagrams are commonly used to visualize the complex nature of money, energy or material flows.
This method receives the final lists for source, destination, value, and labels to be used
in generating the Sankey diagram. It also receives arguments that determine font size and
plot titles. The user can save the Sankey diagram in the following formats: jpg, jpeg, pd, png, svg, and html. Html format is set by default.
How to Use:
# Creating links and nodes based on the passed in lists to be used as the data for generating the Sankey diagramlink=dict(source=source,target=destination,value=value)node=dict(label=label,pad=30,thickness=15,line=dict(color="black",width=0.5))data=go.Sankey(link=link,node=node)# Assigning sankey diagram to fig variablefig=go.Figure(data)fig.write_html("first_figure.html",auto_open=True)
This method receives data in the form of 3 seperate lists (origin, destination, value lists), generate_report dictionary
output format, or get_data dictionary output format. It then places this data into 4 lists of unique elements so that
proper indexes can be assigned for each list so that the elements will correspond with each other based off of the indexes.
These lists are then passed into the outlet_flow method which gives an output which is passed into the method to generate the
sankey diagram.
Figure 3. Example of Sankey Diagram Showing Water Production Flows
How to Use:
This method requires two parameters:
1.) An input data dictionary that includes the time periods requested as well as said data. The data is passed in as ‘pareto_var’ and can be in get_data() format, which requires labels, generate_report() format, or 3 separate lists:
“pareto_var” – This parameter can be variable data returned from the get_data() or generate_report() format
“time_period” – This is used to specify which time periods from the data that the user wants shown in the diagram. If the user passes no time periods in, then all time periods are used in the data.
“labels” – This is only required if the data being passed in is in get_data() format. The labels are used to distinguish between the columns.
2.) A dictionary of arguments that include formatting options like font size, title of the plot and output file:
output_file – This parameter is used for creating the file that contains the Sankey Diagram created by this method
This method generates a bar chart based on the variable data that the user passes in. It automatically creates either an animated bar chart (if the variable is indexed by time) or a static bar chart.
1.) A dictionary including the data and labels that are being used, either in get_data() output format or generate_report() output format. (Labels only required for get_data() format).
“pareto_var”– This parameter contains the data that the user wants to use
“labels”– This is a tuple that contains the labels for each column of the data provided.
2.) A dictionary of arguments that include the title of the plot, a group by parameter, and an output file. Here is an example of the arguments:
“group_by” - This specifies what field will be used as the x axis in the plot
“output_file” - This parameter is used for creating the file that contains the Bar Chart created by this method.
“y_axis” - This specifies if the user wants to take the logarithm of the y axis. If not provided, then the y axis remains the default(linear).
This method creates the scatter plot that is generated from the variable data that the user passes in. It creates either an animated scatter plot(if the variable is indexed by time) or a static scatter plot.
Figure 5. Animated Scatter Chart. Notice the time period slider at the bottom.
How to Use
This method requires two parameters:
1.) An input data dictionary that include the variables for x and y axis, a size parameter, and labels parameters that provides a tuple of labels (only required for get_data() format) for x, y, and size variables.
“pareto_var”– This parameter contains the data that the user wants to use.
“labels”– This is a tuple that contains the labels for each column of the data provided.
“size”- This specifies what will be used for the size of each individual marker on the plot. If the size parameter is not provided, a default size is given to all the markers. There are 3 options for the size parameter:
“x/y” - This specifies that size will be calculated as a ratio of the x variable data over the y variable data
“y/x” - This specifies that size will be calculated as a ratio of the y variable data over the x variable data
A Pareto variable that contains data for the size of the bubbles. The data must match the column used for grouping the data in the option “group_by”.
Figure 6. Options for specifying the bubbles size.
2.) A dictionary of arguments that include the title of the plot, a group by parameter, and an output file. Here is an example of the arguments:
“group_by” - This specifies what field will be used as the x axis in the plot. The column name should be used to indicate how to group the data.
If “group_by” is not specified, then first column is used.
“output_file” - This parameter is used to name a file that the figure will be output to. It can be a file path such as “..\first_figure.html” or just the file name itself “first_figure.html”.
There will always need to be a specified extension to the file. The accepted file extensions are as follows: .html, .png, .jpg, .jpeg, .svg, .pdf
“print_data” - The PARETO methods allow the user to specify if they want the plotted data to be printed in the console (default is False):
True: The dataframe used for creating the figure is printed in the console
Figure 7. Setting print_data to True will print out a dataframe for easy inspection.
“group_by_category” - This specifies how the color of the nodes will be assigned for easy visualization. There are 3 options:
True: This will cause the color of the chart markers to be grouped based on the names of the nodes. For example: PP, CP, N, R, S, K, etc
will be assigned a unique color.
False: The data won’t be categorized by color, therefore one color will be used for the chart markers.
A Pareto variable containing a custom categorization. The method will recognize the variable automatically and the values in this variable
will be used for assigning colors to the categories that are provided. An excel sheet should be created with all Node names, removing all duplicates,
and assigning a numerical value to each specific node with the category the user would like it to be associated with. This approach is best for
the situations where nodes of different types are to be categorized together.
PARETO project provides examples to run the operational produced water management model
and the strategic produced water management model (see pareto/case_studies/).
To run the examples, go to:
For Python 3.8 and maybe others, you can get an error when running Jupyter on Windows 10 about
missing the win32api DLL. There is a relatively easy fix:
PARETO Copyright (c) 2021-2023, by the software owners: The Regents of the University of California,
through Lawrence Berkeley National Laboratory, et al. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted
provided that the following conditions are met:
Redistributions of source code must retain the above copyright notice, this list of conditions
and the following disclaimer.
Redistributions in binary form must reproduce the above copyright notice, this list of conditions
and the following disclaimer in the documentation and/or other materials provided with the
distribution.
Neither the name of the Produced Water Application for Beneficial Reuse Environmental Impact and
Treatment Optimization (PARETO), University of California, Lawrence Berkeley National Laboratory,
U.S. Dept. of Energy, nor the names of its contributors may be used to endorse or promote
products derived from this software without specific prior written permission.
THIS SOFTWARE S PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS” AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES: LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
You are under no obligation whatsoever to provide any bug fixes, patches, or upgrades to the
features, functionality or performance of the source code (“Enhancements”) to anyone; however, if
you choose to make your Enhancements available either publicly, or directly to Lawrence Berkeley
National Laboratory, without imposing a separate written license agreement for such Enhancements,
then you hereby grant Lawrence Berkeley National Laboratory the following license: a non-exclusive,
royalty-free perpetual license to install, use, modify, prepare derivative works, incorporate into
other computer software, distribute, and sublicense such enhancements or derivative works thereof,
in binary and source code form
PARETO was produced under the DOE Produced Water Application for Beneficial Reuse Environmental
Impact and Treatment Optimization (PARETO), and is copyright (c) 2021-2023 by the software owners: The
Regents of the University of California, through Lawrence Berkeley National Laboratory, et al. All
rights reserved.
NOTICE. This Software was developed under funding from the U.S. Department of Energy and the
U.S. Government consequently retains certain rights. As such, the U.S. Government has been granted
for itself and others acting on its behalf a paid-up, nonexclusive, irrevocable, worldwide license
in the Software to reproduce, distribute copies to the public, prepare derivative works, and perform
publicly and display publicly, and to permit other to do so.
