I have to own up that not only I am not a fan of installing and configuring programs (is anyone?) but I found it extremely boring and I always try to avoid it unless it means just one double click (does that even exist?)

The first thing I did was to see what applications were already installed. It was funny to find that I had somewhere in the past upgraded its firmware to version 3.0. Moreover, I made the famous jailbreak (a process to remove some OS limitations of the iPod, such as installing free stuff). Wow! That was several years ago and all I could remember was the name.

The next thing I tried was to uninstall every unused program – almost every one. Here I ran into the first problem. While loading the application that manages free packages I got an error saying some problem occurred during the decompression of an upgrade. (This application tried to upgrade itself since I hadn’t launched it for several years.)

Of course, I had no idea how to solve this problem so I googled it and came up with several websites, from forums to youtube videos, explaining how to deal with it. One of the common steps involved establishing an SSH connection from my computer to the iPod, so I had to search and download the appropriate software.

Naturally, once I had the new program, I followed the basic steps to start a SSH connection but I couldn’t. An error appeared saying ‘Connection was not accepted’ – just that.

Once again, I googled this new problem and ended up with another set of pages telling me what programs to use, what possible problems I could have and their verifications and solutions.

This went on with more errors, suggestions and thousands of pages describing the magic steps to solve more and more problems.

Suddenly, I felt like I was in front of an aircraft control panel, understanding almost nothing about the “extremely complex” problem at hand. Even worse than that, I felt like a flight control panels developer sitting in front of an aircraft control panel and still understanding almost nothing about it!

My first reaction was to take this personally: If I can’t solve this then I just wasted those years at the university.

A few minutes later I decided to postpone my “deep” research on “upgrading an iPod/solving an iPod application error/connecting my laptop to the iPod/etc./etc./etc.” for some other day. However, I’d like to share some comments and questions about what I felt.

• First of all, I am not in the best position to talk about installation, upgrading and configuration processes because I usually avoid them and I consider them boring and tedious.
• How can dealing with programs be as cryptic to a developer (me) as to, say, my grandmother?
• I deal with complex (and very interesting) problems almost every day, but I can’t upgrade my iPod! I already said that I don’t like dealing with installations but I can claim that there are people – beside my grandma and me – that surely would find the complexity of doing such things just absurd!
• And more importantly, what are we – as software developers – doing with software complexity, if it can become overwhelming even for a (decent) developer?
• Finally, if you are a developer, please take care of complexity, think about my grandma, me, and the rest of the current and future human beings who, from time to time, have to deal with software. Otherwise, we will need many more “jailbreaks”!

These and 20 other PetroVR movies are available in our Knowledge Base.

Temporarily shutting-in production

Probability Distributions on Functions

PetroVR Input Variables

For decades, we have seen disciplines working in isolation, carrying out the combined work only from their own point of view, with the output of one discipline being the input for another. This sequential approach leads to substantial delays, rework covering the same tracks over again, and wasted time. The range of options considered is, usually, reduced and decisions surely suffer.

PetroVR Integration

An inherent capability of PetroVR software is the ability to integrate across the traditional E&P disciplines, and also many value chains in complex unconventional projects, where the value chains encompass professions beyond traditional E&P disciplines, such as power generation, manufacturing, and so on.

This, in turn, makes PetroVR the industry tool of choice for collaboration — and a catalyst for breaking down traditional discipline silos for organizations seeking a competitive advantage.

Integrated modeling covers the full scope of an E&P project, from reservoir to sale point, catalyzing technical and commercial disciplines to work together on a single model with input from all and highlighting the impacts and interdependencies between these various areas and disciplines.

What does an integrated project model look like? Here, a typical model layout is shown visually for all team members from all disciplines to view and audit as model assumptions change.

Production flow management in PetroVR is a typical example of this kind of interdependence between areas and disciplines, where modeled reservoirs feed processing facilities with fluids according to predefined declined curves, which can in turn be affected by parameters defined at the facility level, such as processing capacity or maximum number of connected wells. Where constraints cause wells to be scaled back or deferred, the reservoir production profile is modified.

The integrated graphical representation of a production profile (above) shows capacity constraint, potential and actual production, with a simple layout showing the point of constraint.

We have seen the elimination of many rework cycles that were once accepted as a the normal workflow, which leads to time savings by an order of magnitude, higher quality decision information and more reliable decisions.

Efficient integration during E&P project maturation ensures that the evaluation process is accelerated and unnecessary rework is eliminated. With more time available for the collaborative team to review and consider alternatives, their professional insights add more value to the bottom line of their companies.

Complexity is a permanent state. It can get worse, but once you have it there it will never go away. Therefore, if you appreciate simplicity you have to build it up from scratch.

OK, simplicity is hard. But does simplicity really matter? Well, yes it does indeed. Simplicity will give you freedom. Freedom to conceive better alternatives, to execute agilely, to discard trade-offs, to commit confidently. Simplicity is paramount to making good decisions. Complexity, in opposition, constraints your capacity to react.

In the world of Software Development they have the principle of Personal Mastery. This principle establishes that a system is simple when it is comprehensible to a single individual. In other words, if you cannot understand your system, you are in trouble.

When considered more closely, this principle tells us that there is some sort of singularity at the limits of Personal Mastery. Beyond them you will find yourself immersed in the intricacies of complexity without ever being able to get back to simplicity.

Let me propose you an exercise. Ask yourself whether your PetroVR models enable Personal Mastery. Do you understand your models? Can you explain, audit and QC them? Do you really know how to interpret the outcomes of the simulation? Do you have clarity on your uncertainties? Does your models’ logic generate relevant insights?

Decision Analysts are big fans of simplicity. You will never hear them requiring complex models or supercomputers. Instead, they always insist on using Tornado Diagrams to identify relevant parameters, Spider Plots to visualize traits, Sensitivity Analysis to discover risks and opportunities, Correlations to express influences and Monte Carlo runs to assess uncertainties. Big ideas, simple models, clarity on your decisions.

PetroVR supports all of this. But wait. You first have to understand PetroVR as a thought composition environment. If you approach PetroVR as a “tool”, your expectations will go down to calculation techniques.

I know, we should also agree that PetroVR is quite sophisticated. However, its sophistication doesn’t make it complex. The truth is that PetroVR covers a vast territory: reservoirs, drilling, facilities, routing, schedule, resources, constraints and expenditures. Consequently, it must be prepared to allow greater detail everywhere. But this doesn’t mean that your models also have to go into detail everywhere. On the contrary, your models should be more detailed only in parameters that impact your decisions. For instance, even when PetroVR supports probability distributions at every single input, that doesn’t mean that your model has to use them in abundance. In fact, one of the more valuable studies you can perform using PetroVR consists in detecting key parameters through Comparative Sensitivity Analysis and then removing irrelevant probability distributions to minimize noise.

PetroVR is also rich at the output. You will get single and arrayed results, all sort of plots, timelines, reports, convergence curves, correlation clouds, clusters, etc. Still, this complexity doesn’t invalidate the Personal Mastery principle because it is emergent complexity. And this is a great property of PetroVR: it allows you to see the emergent complexity of fairly simple models. In other words, rich outputs coming from simple, elegant models. With PetroVR you can get a lot of useful information from a few well chosen inputs.

So, yes, my goal is simplicity. Or Personal Mastery, which is the same. Simple models give me more freedom to compose big ideas and get valid insights from rich outcomes. Of course, building and preserving simplicity entails a lot of intellectual work, but the reward you get is sound understanding.

This new tool for defining declines is highly customizable and not only includes all of the previous performance types – Custom, Cum Time, Instant Rate Time, Average Rate Time and the old Table – but also a great variety of declines that were not previously available.

This flexibility is achieved by the possibility of defining the following aspects for the same table:

• domain (time or cum),
• fluid production type (average rates, instant rates or cum),
• dimensionality (or lack thereof),
• secondary fluid and water production (rates, cums, fractions of the primary production – GOR and WC – and either as separated functions or as part of the table),
• primary production as smooth curves (available in future versions).

The implementation of this feature is a clear transition from a specific strategy in which isolated options define different decline types to a more generic approach in which a single location of the software offers the flexibility to customize almost any kind of decline.

Of course there are pros and cons for both strategies.

Picture a Victorinox knife. You could think of it as a generic approach for a series of tools that could otherwise be carried separately.

Of course there are some advantages in carrying isolated tools: for example, you might just need the blade, in which case it would not make sense to buy the whole Victorinox. At the same time, you can learn more specifically how to use each of those tools separately, without having to understand the multitool. Everybody knows how to use a screwdriver, and you don’t need to know how to use every tool in the Victorinox if all you want to do is tighten a screw.

In the case of PetroVR, the more specific approach required users to understand only the decline they needed, and their input options were reduced. The same happens when you are programming: the scope is reduced, and therefore, the logic to handle every specific case is rather limited and easier to understand all at once.

However, if you were to carry around all of the tools separately, they would take a lot more space: not only are you carrying many items, but also all of them have a repeated part – the shaft – that could somehow be shared. In writing code, the exact same problem arises. Lines of code with very similar behaviour will be repeated.

On the other hand, if you are not certain what you are going to need until you are out in the open, a Victorinox will save you the trouble of carrying many different objects.

From the programming point of view, this generic strategy led us to rethink all of those different possibilities for well declines, and we did it all in one go (unlike the previous options which were thought and programmed separately). This allowed the design to be much more consistent and tidy.

More importantly, every time a new requirement involves modifying the declines, this centralized makes it possible to implement changes on a single part of the code, rather than being forced to rethink those modifications for each specific decline type.

From the user’s perspective, there are some cases for which the previous possibilities in PetroVR were not enough. For instance, in unconventional projects there might be periods with no primary production while secondary production remains active. Another example might be CBM wells, which start producing water prior to primary production (gas).

Review your mental image of the Victorinox. Now, imagine you can transform it and rearrange its pieces to get a new tool, while preserving its core configuration. This is what the new Table brings to the table (pun intended!) Not only is the table customizable in the sense that the same table can express any of the different types that existed before; now, you can select which parameters to take into account as inputs, creating your own table types!

So, don’t be afraid of getting creative with this new tool that allows maximum customizability. Let out the MacGyver in you and make of this Table your multi use Victorinox!

What we often find instead is, due to vast amounts of data associated with complex projects, combined with the limitations of spreadsheets, the opposite is true. Most of a Development Planner’s time can be spent on data manipulation and detailed modeling, with little time left for generating valuable insights.

This dilemma is addressed with a robust tool set, featuring PetroVR Scenarios, that helps a development planner get into insight generation early, where value can be added, while minimizing the time spent on crunching data and modeling the minutia. Value can be added both in the form of better strategy insights for decision making, as well as avoiding “wrong-focus risk” and directing resources more efficiently.

The PetroVR Scenarios tool powers a Development Planner with several discrete tools, and takes advantage of the unique change system in PetroVR to track and display all changes made to a scenario, automatically, thereby eliminating the need for hours of manual record keeping.

The PetroVR Scenarios tool:

• Keeps all of your optional Scenarios accessible in a single view, with full deterministic and stochastic results for each scenario.
• Provides a graphical interface for comparing scenario results, including plots of deterministic single-value and array results; stochastic “s-curves” displaying single value results; and “percentile” and “box-plots” that reveal array results after a Monte Carlo simulation has been performed on the scenarios.
• Cross Plots for multiple scenarios help a Development Planner identify the cross-over point where one scenario emerges as the preferred alternative. As shown in the cross plot shown above, a “stand-alone” strategy is superior to a “tie-back” strategy when the reserves exceed 600 MMbbl.

Recently, we received this testimonial from a veteran development planner, using PetroVR for scenario comparisons: “PetroVR Scenarios get us into insight generation more quickly, where value can be added, while minimizing time on routine modeling.”

Read the complete Solution on Scenario Evaluations.

Once the enhancements have been implemented, a feeling of satisfaction is followed by a very interesting thought: How were we able to live without this improvement? Was the system really worse then than now?

Furthermore, there is the feeling that we are approaching an optimal state. Since this happens almost every time an enhancement is developed, the fact that the system was actually imperfect before the introduction of an improvement, is not consistent with that feeling of reaching an ideal state. It is true that, because of the enhancement, something has made the system better than it used to be. But in that case, why didn’t this best solution come to us sooner, and moreover, is it possible that we will come up with an even better solution in the future?

We go through the same sequence of feelings in relation to the actual facts in many other areas – when a new workflow is implemented, or an old one is updated, when a new programming practice is added to our list, and so on.

The evolution of the software and, most importantly, the evolution of the team itself, is a cycle in which improving an aspect and pondering upon the changes made gives us room to improve even more in the future.

Therefore, the process of enhancing the system while growing as a team creates a future in which it is possible to grow and improve even more, although this idea might sound contradictory. The room for improvement can never be filled: it gets larger every time you reflect on what has been previously enriched.

This could be seen almost as an infinite stair that gets longer and higher as you climb up its steps.

These thoughts could lead us to conclude that new requirements motorize this cycle of evolution. But in that case, could we evolve without those requirements, or would we stand still on an apparently ‘unenhanceable’ system? The answer to this question is neither yes or no. Requirements can be a great starting point, but they are not the only source of dynamism. During the process of developing enhancements based on requirements, each new requirement in turn awakes ideas and internal requests that further empower the system and keep it alive and evolving.

At the same time, as the system gets better, users develop further capabilities to model their projects and, moreover, to generate more evolved requirements. So, at this point, the evolving cycle of the development process is being fed by the evolving cycle of the modeling process, and viceversa.

This is once more an example of how using better systems helps you think better as well!

That’s it for now. In the future we might rewrite this article because we are sure it will turn out so much better

Now, let’s assume you want to represent a more elaborate dependency. One thing you may want to do is to make the distribution of the second variable depend on the distribution of the first. The idea would be to impact the uncertainty around the producer’s initial rate with the outcome of the initial rate obtained for the appraisal well.

Let’s say the initial rate of your appraisal well A has a Normal Distribution N(5000 , 500). Now your hypothesis is that the distribution N(mu, sigma) around the producer P will depend on A’s initial rate as follows:

If “A: Initial Rate” <= P10, then “P: Initial Rate” will have N(mu, sigma) = N(4000, 250)

If P10 < “A: Initial Rate” <= P90, then “P: Initial Rate” will have N(mu, sigma) = N(4500, 250)

If “A: Initial Rate” > P90, then “P: Initial Rate” will have N(mu, sigma) = N(5500, 250)

In other words, if the initial rate found at appraisal time is low, the producer will have a low probabilistic profile. If it is high, the producer will have much better chances of a nicer profile. Otherwise, the producer will exhibit a regular behavior. Note also that in my example above I’ve reduced the standard deviation to represent how the appraisal lowers the uncertainty around production.

So, how do you express all of this in PetroVR? Simple! Just define three user variables Lo, Mid, Hi with the following distributions:

Lo ~ N(4000, 250), Mid ~ N(4500, 250) and Hi ~ N(5500, 250),

Then define the Percentile user variable as:

“Percentile” = normal(“A: Initial Rate“, 5000, 500)

And finally use the following expression for the initial rate of P:

“P: Initial Rate” = if(“Percentile” <= 0.1, “Lo”, if(“Percentile” <= 0.9, “Mid”, “Hi”))

That’s it!

Of course, I’ve simplified the notation for the sake of clarity by omitting the first part of the full name of all variables. However, if you give this idea a try you will see how easy and natural it looks.

And be certain that if you explore this approach your productivity will increase (multiple puns intended!)

That is why, from the point of view of programmers, it is important to get as close as possible to your users’ intuition. If a software is highly counter-intuitive, users will be less happy to work with it. It is never comfortable to have to use a program where you don’t even know where to start – for example, How do you create a new file? Therefore, programmers have to become experts in unifying the logical language they work with and the actual logic of the software according to the users’ comfort.

However, it may happen that in some cases it is not that easy to see things as a user would. It is hard to distance yourself from your core of knowledge to stand in someone else’s point of view.

Even though I had vaguely noticed some moments of misalignment between these two lines of thought when reading our users’ questions and ideas in Help Desk, only a few days ago I saw this clearly for the first time in the PetroVR environment. The Development team was working on the Array Probabilistic Differences chart, which shows the differences of results between the Monte Carlo runs of different Scenarios for array variables. Here is an example:

In this list you can change the order of the Scenarios, and these changes will be reflected in the chart.

One day someone from the Development team asked me a question which at that moment sounded a little weird: “Taking into account the order of the Scenarios in the reference list, which color would you expect to see the brightest?”

My answer was that water green, representing the delta scenario, should be more visible since it was placed at the top:

Still a little thrown off by the reason for that question, I asked the programmer what she would expect to see. She said that what most of the people in the Development team would expect to see as the brightest color would be the pink one representing the delta-3 scenario. Because it is third in the list, it will be drawn last, and so, on top of the others:

So, there are two parameters to choose an order for the scenarios in the graph. One is the order defined in the references list, and the other is the actual order in the graph, the z order that determines whether the curve drawn first will be at the back or on the front. The more “logical” view, the one that is coherent with how a programmer would naturally think, says that you will draw firstly the one on top of the list, and the second one will be drawn over the first one, and so on. To me, on the other hand, the one on top of the list would be the one on top of the graph as well, the most visible one.

After this I realized that developers really have to take into account what would be easier to take in and comfortable while wearing the users’ shoes. That is why they value user (or non-programmer) feedback when adjusting their “logical” ideas to make them more intuitive.

Another example has to do with Tornado charts in Sensitivity Analysis capabilities:

The Tornado chart shows how the economic results of a model (NPV 0 in the example) will be affected by the variation of the selected input variables. However, the minimum and maximum values of each input are not shown. Nor are the values of the inputs that produce the maximum and minimum economic result. Furthermore, the relationship between the inputs and the result variations is not necessarily linear. Thus, intuition might lead to wrong conclusions – for instance, that the increment in an input value necessarily causes an increment in the result. The Plot graph was created to expand the information that relates the modification of each input with its effect on the results:

So, in this example, because of what intuition probably makes you miss or misunderstand from the Tornado chart, a second one will clarify the variation of each input variable selected.

In conclusion, remember that feedback from users will always provide a fresh look over the software, making the job of working with it more fluid and easy to intuit.

I think it is worth mentioning that, after a little more research, the Array Probabilistic Differences chart was lastly programmed to show the scenarios in the order I – as a non-programmer – had understood as the more intuitive one.