In the context of reservoir simulation, having a history-matched model is the basic requirement for using the model as a forecasting tool. Without a history-matched model, we essentially have nothing—and the model becomes pretty useless.
However, it’s crucial to recognize that history matching is an inverse problem with many possible solutions—meaning that multiple different reservoir models can reproduce the same historical production data.
This inherent non-uniqueness implies that a history-matched model is not the “true” representation of the reservoir, but rather a plausible representation that fits our data.
But… what if we knew the ‘truth’, i.e., the true reservoir system with all its characteristics and properties?
When I first got a hold of the TNAV suite, I was keen to test the multiple Assisted History Matching (AHM) algorithms that are built in. So this is what I set out to investigate:
I first solved the direct problem—that is, I generated a system response from a known system description and initial state.
I then tested the various AHM algorithms to see whether I could resolve the inverse problem: to back-engineer the system that originated the response.
In this case, I know the ‘truth’ because I created the system myself. So, the question is: can I uncover the ‘truth’?
The reservoir system is not critical for the purposes of this exercise, so I created a simple dummy system with the following parameters:
To generate a range of responses, I set reasonable value ranges for a set of key uncertainty parameters: porosity, transmissibilities, relative permeability endpoints, and exponents.
I then ran a quick Latin Hypercube with 60 combinations (variants). From the outcome range, I picked 6 “similar” ones. These 6 variants provide me with a reference “solution space” so that later, when I try to resolve the inverse problem, I can see where the back-engineered solution lands in relation to this solution space.
Each variant represents a specific combination of values for the 6 uncertainty parameters. To keep it simple, I am plotting a 2D crossplot with only two parameters to make it easier to visualize what we’re trying to convey.
This is what the “solution space” looks like:
Each dot is a combination of the 6 uncertainty parameters, and we already know that all these 6 combinations generated a similar response.
Now, I randomly selected one of these 6—the green dot—to be my “truth.” Later, when resolving the inverse problem, ideally we should land on the green dot. However, landing on any of the other points in the solution space may be acceptable, as we know that they all produce a similar response.
I took the green dot variant and used its forecast vectors to redefine them as history vectors (our pseudo-history). These are now the vectors I want to match against in the AHM exercise.
Then, I modified the uncertainty parameters to create a starting model that would have a mismatch to the “truth,” i.e., its response will differ from the response generated by the green dot variant.
Of course, there is an initial mismatch because I generated that response from a modified model with different parameter values. The question now is: when I feed this into the AHM algorithm, can it back-engineer my system and arrive at my “truth”?
This is what it looks like when starting our AHM process:
If I input the red case into the AHM algorithm, I would expect that over subsequent iterations, the solution tends to converge toward the “truth.” In other words, I would like to see a trajectory on this 2D plot from the red dot towards the green dot (albeit not in a straight line, of course).
Let’s test the various AHM algorithms and see what happens.
At the top left, we see how the objective function (an error function) trends downward over subsequent runs until eventually plateauing near zero.
However, we observe that a group of the latest runs with a near-zero error function value have not quite converged to the solution when looking at the field watercut profile. For example, the oil water contact (OWC) fails to move out of a tight range around 9206 ft, whereas we know that the “truth” is at 9200 ft.
On our 2D solution space plot, the trajectory shows that the latest solutions sit in the vicinity of the right-hand side cluster, rather than moving closer to the green dot:
On closer inspection, BHP has converged to the solution, but the watercut has not. To address this, I added weight to the watercut term in the objective function and reduced the tolerance from 5% to 2.5% to see if the solution would improve.
The results of this second evolutionary strategy are shown here:
We can now note that the watercut has also been matched, with all these second-stage cases remaining in the right-hand side cluster of our solution space. This makes sense because all these dots represent cases that produced similar solutions to the “truth” case. The AHM algorithms compute the mathematically aggregated error between the solution vectors, so among many similar vectors, they cannot really discriminate which one is the “true” one.
When we expand the search (using the global search option), we now see three clusters of converged solutions (top left).
These three clusters are color-coded on the right plot, which shows where these cases land in relation to the solution space.
We can see the cases spreading out, yet the “truth” remains elusive. No solutions are convincingly converging toward the green dot.
There is quick convergence, although both clusters sit on top of each other in the left cluster on the 2D solution space plot. Still, the solutions do not move toward the green dot.
We see a couple of cases right on top of the green dot, so it seems like we finally managed to find an algorithm that moves us toward the “truth.”
However, on closer inspection, we note that the defining parameters of these cases are still a distance away from the values in the “truth” case (see the oil exponent and OWC, for example).
Once more, we see that the converged solutions spread more toward the right cluster, rather than following a trajectory heading toward the green dot.
First:
We tested the suite of TNAV AHM algorithms and could not reverse-engineer the “truth.”
In most algorithms, the solutions converged toward clusters that were a distance away from the “truth” case.
Even in the instance where we seemingly converged to the green dot, parameter inspection revealed that the true values had not been reproduced.
Corollary: There is no need to agonize over achieving a perfect match, because even if you do, there’s no guarantee that the “truth” has been found.
Second:
This was an exercise with perfect “historical” information—no noise, no instrumentation errors, no interpretation uncertainty.
Yet, we could not converge to the mathematical solution, the “truth.”
What hope do we have in the imperfect, real world—where information is scattered and noisy, with plenty of data errors and uncertainties?
Corollary: Don’t be swayed by the allure of precision over accuracy. Despite the rise of machines and the promise of infinite computational power, you cannot rely solely on the algorithm. Judgment still needs to be applied.
Third:
History matching is a diminishing returns exercise—there comes a point beyond which you’re not gaining anything (clusters are set, solutions have already converged to their final destination).
Modeling should not be an academic exercise; it’s a business decision-making tool. Eventually, you must stop and move forward with the decision that needs to be made.
Fourth:
Rather than perfecting a single history match (a never-ending process), your focus should be on managing uncertainty.
Use Assisted History Matching to find MANY possible solutions. Run experimental designs in forecasting to obtain an outcome range from those many acceptable HMed solutions.
---
"If Mother Nature can, she will tell you a direct lie."
— Darwin
Explore a curated collection of valuable resources in our Store, both free and paid, all designed to help you upskill.
Alan is a Consulting Petroleum Reservoir Engineer with 20+ years of international industry experience. Alan is the founder of CrowdField, a marketplace that connects Oil & Gas and Energy businesses with a global network of niche talent for task-based freelance solutions. His mission is to help skilled individuals monetize their knowledge as the Energy transition unfolds, by bringing their expertise to the open market and creating digital products to sell in CrowdField's Digital Store.
Subscribe to O&G AI Wave – your indispensable guide to the evolving world of AI and NoCode and their practical applications for Oil & Gas professionals.
Our newsletter brings you the latest trends and insights in AI and NoCode technologies directly impacting the O&G sector.
Every issue is packed with expert analyses and practical tips to help you navigate and leverage these transformative technologies.
Don’t miss out on the opportunity to stay ahead of the trend and future-proof your career in this incredibly dynamic field.
At CrowdField, our mission is to empower YOU—helping you showcase your skills in the open market and monetize them effectively. Here's how you benefit from being with us:
👉 Make your mark and find freelance opportunities by listing yourself in our freelancer directory to get noticed. Join us for free here.
👉 Turn your skills into digital products that sell. We'll help you polish, launch, and list them in our Store, promote them on our LinkedIn page, to our email subscribers, and feature your success in a case study on our Blog, amplifying both your product and personal brand. Whether you're at the idea stage, midway through implementation, or nearing completion, if you see potential for monetization, we're interested. Take the first step by getting in touch to start a conversation at hello@crowdfield.net.
👉 Discover bargains in our digital store with heavily discounted prices during our market discovery period. Take advantage of these limited-time offers as we expand our network. Dive in now and find your gem! Got to Store
