Well Performance and Production Profiles by Carlos E. Ferro

In PetroVR we work strongly with the concept of well performance.

This is a model of the production* that the well would have, if was set in an unconstrained production system. This means no choking, no interventions, just the reservoir drive in action, moving the hydrocarbons upwards. In classical models, this drive is usually the difference in pressure between the bottom of the hole and the well head.

Using this notion, we have very simple curves to express the theoretical decline as the reservoir pressure drops. Since we are extracting fluids, we are lowering the pressure. The simplest form of this model is an exponential curve, with the formula

q(t) = q(0)e^-dt

where d is the decline slope and q(t) is the instantaneous rate at time t. This model allows us to know the production rate at any moment in time and, besides having nice mathematical properties, is simple to understand and shows adequately the effects of pressure decay as a function of time. On the same family, we also have hyperbolic and harmonic curves, commonly used to model declines in the industry.

Having a model like this for the well performance is a great simplification of the reality, of course. That is why people sometimes prefer to use tabular declines, where they can express production amounts per lapses of time directly. This enables greater control over the performance curve, because you can add points at will, to indicate time steps as small or large as you wish, having a greater level of detail when the curve changes and low detail when it follows the same trends.

The usage of tabular performances also creates a big temptation for users. It frequently lures them into introducing production data from other wells (in the same area or with similar characteristics) as if it was a well performance. This comes from a very natural - and usually healthy - human concept, rooted in ancient philosophy and common sense: what has happened before, will happen again. And if I have a well that is very similar or close to another one that I am going to drill, it is natural to think that their production profiles will be similar. Since production data is easily available, why not to grab the production history of my (existing) well and define it as the well performance of my (new) well?

After all, it is a common practice in the industry - you use historical production to predict the future production. Also, many times several production profiles are combined to build a "prototype well", modeling the expected behavior of new wells in the same reservoir.

Well, the central point is that we define the performance as a theoretical behavior that the well would have in an unconstrained production system. And this is because PetroVR models constraints in other places, outside well performance curves. We have, for instance, processing capacity constraints modeled at facility level, which usually result in well choking.

What happens if we take the production history from a well? That it is a real history, not a theoretical curve. It has embedded all the constraints that acted on the production line and so on the well. If the well was choked, the production curve gets flat. If we perform an intervention on the well, we can see a “jump” in the production curve.

In reality, these modifications on the production curve are not related to the reservoir production drive, and will be taken into account by PetroVR in different places. They will eventually impact the well’s production during the simulation run.

Let’s consider an example: a choke imposed by a processing capacity constraint. You could "prepare" the production curve, lowering the rates since the time you know it will be affected. But if you just set the capacity for the facility connection point in PetroVR, the system will automatically apply the constraint, only if and when it is necessary, considering all other wells connected to the facility, other downstream constraints and many other factors. You don't even need to guess when you have to start applying the choke! Even better, when the facility has capacity for this well again, the system will automatically un-choke it. And even more: it will automatically distribute the choke needed among all its connected wells.

If you set a very simple well performance curve for the well (for instance, an exponential curve) you can see the effect of all these rules playing along each other in the simulation world. PetroVR is an excellent tool for discovering the effects of interactions between rules, representing the key constraints and the uncertainties of your project. You don’t need to interfere with this using a ready-made curve crafted according to factors you can foresee.

Let the simulation show you the results - and surprise you, provoking new insights - instead of feeding them into the simulation.

-----

* Production in the case of production wells, but we also have performance for injection wells.

PetroVR Simulation and Simulation Theories (Part II) by Alejandro Murgia

Simulation Concepts: Entities and Logical Statements

Simulation Theory distinguishes the following key concepts: entities, logical relations, clock, executive, distributions, and result collection.

Entities

They are the models of tangible elements found in the real world. Entities may be either temporary (e.g. parts that pass through the model) or permanent (e.g. machines that remain in the model). The concepts of temporary and permanent come from Manufacturing and are useful aids to understand the overall objectives of using a simulation, usually to observe the behavior of the temporary entities passing through the permanent ones.

In PetroVR produced fluids would be temporary entities and assets (wells and facilities) permanent ones.

Logical relations

They link the different entities together. Logical relationships are the key part of the simulation model; they define its overall behavior. Each logical statement (e.g. "start machine if parts are ready") is simple but the quantity and variety and the fact that they are widely dispersed throughout the model give rise to complexity.

In PetroVR logical relations are expressed by a system of rules (condition-action) assigned to entities. Rules are the means by which the user defines the behavior of entities in PetroVR.

Clock

A central clock is used to keep track of the logical time at which the state of a system is updated throughout the simulation.

Executive

It is the mechanism responsible for controlling the advance of time. The executive updates the logical relationships between entities and advances the clock to the new time.

In event-driven simulations, the simulation executive maintains an event queue (a string of chronologically ordered events), and removes the first event from the list to execute the relevant model logic. Any new events that occur as a result are inserted into the list at the appropriate point. The cycle is then repeated.

In PetroVR this concept is internally modelled by an object called the World. PetroVR distinguishes between events, which are instantaneous episodes representing a change of state in some entity at a precise point of time, and jobs, which are the objects queued by the World and containing instructions to change states if a given start condition is met.

Each event in the event list has two key data items. The first item is the time of the event which allows it to be ordered in the event list. The second item is the reference to the model logic that needs to be executed. This allows the executive to carry out the correct logic at the correct time. Note that more than one event may reference the same model logic; this means that the same logic is used many times during the simulation.

As stated above, PetroVR models this concept by means of an object called the job. Jobs have a start rule which in turn has two components: the condition and the action. The condition can be defined either as a date condition (it triggers the job at a certain date), an event condition (it triggers the job when a given event happens), a periodic condition (it triggers the job every n days), an evaluable condition (it triggers the job when a given Boolean expression evaluates to true), or a measure condition (it triggers the job when a given variable reaches a threshold).

The start rule can be modeled as a never stop rule, or as just one time rule. This distinction gives PetroVR the ability to handle cases similar to those described in the literature (many events referring to the same model logic).

Distributions

They are a feature considered vital to any simulation system. Random number generators are used to provide stochastic behavior typical of the real world. Having configurable distributions for the values of variables is considered a key feature of simulation systems.

PetroVR provides strong support in distributions for variables and stochastic analysis.

Result collection

The result collection provides the user with means of using the simulation tool to obtain meaningful analyses of the new or proposed system in the form of tables and graphs.

The PetroVR GUI gives results a prominent place, providing tools to collate them and analyze their meanings.

Discrete-Event Modeling Formalism

A great part of the academic work in the Simulation field is aimed at developing and extending the DEVS and GDEVS formalisms. The DEVS formalism is a theory for the specification of discrete-event systems introduced by Bernard Zeigler [cf. 7]. It is a formal approach to building the models, using a hierarchical and modular architecture. The aim of the formalism is to help validate simulations built according to its specifications. The formalism deals with concepts such as components and model coupling.

The latest efforts in DEVS formalisms include the proposal of extensions to manage real-time systems, logical analysis, dynamic structure models, cellular automata, neural networks, intelligent transmission systems and multi-agent systems.

Simulation and Object-Oriented Languages

Simulation literature insistently states that Object-Oriented Languages and Simulation Theory are mutual sources of inspiration. OOP (Object-Oriented Programming) is seen as the most appropriate programming approach to designing simulation software.

It is widely recognized that simulators are a type of application for which OOP offers unique advantages, because it makes it possible to represent physical entities and their properties by means of objects, in the sense of object programming.

Some principles of OOP, such as the existence of a varying number of instances of similar objects, have been in standard use in simulation environment for a long time. The Simula language is recognized as the first true object-oriented language, and since it is also regarded as a milestone in Simulation history, experts from the Simulation field were well aware of such things as classes, live instances and inheritance long before they were rediscovered by the OOP boom in recent years.

Conclusion

This collation between Simulation Theory concepts and PetroVR shows that the design of the PetroVR simulation can be naturally described in terms and concepts coming from that field. Specially related to PetroVR is the discipline known as Discrete-Event Simulation.

References

[1] Jerry Banks, John Carlson & Barry Nelson, Discrete-Event System Simulation. 1996.

[2] Christos G. Cassandras & Stéphane Lafortune, Introduction to Discrete Event Systems. Kluwer Academic Publishers, Boston 1999.

[3] Leonard Kleinrock, Queueing Systems, Volume I: Theory. Wiley, New York 1975.

[4] A.M. Law & W.D. Kelton, Simulation Modeling and Analysis. 1991.

[5] Pegden et al., Introduction to Simulation. 1995.

[6] Kevin Watkins, Discrete Event Simulation in C. McGraw-Hill, London 1993.

[7] B. Zeigler, Theory of Modelling and Simulation. Wiley, 1976.

[8] Stewart Robinson, Simulation. The Practice of Model Development and Use. 2004.

[9] M. Pidd, Computer Simulation in Management Science. 1992.

[10] Bernard Zeigler, Introduction to DEVS Modeling and Simulation with Java. 2005.

[11] J. Sklenar, Simulation. University of Malta, 2000.

PetroVR Simulation and Simulation Theories (Part I) by Alejandro Murgia

Simulation

Simulation has been defined as the process of designing a model of a real system and conducting experiments with this model either to understand the system's behavior or to evaluate different strategies for operating it [cf. 5]. A system is defined as a collection of entities - usually people and machines - that act and interact toward the accomplishment of some logical end [cf. 4].

If the real system is simple enough it may be possible to use mathematical methods (e.g. algebra, calculus, etc.) to build a precise model which will give exact answers; this is usually referred to as analytical modeling. Many of these models can be readily created using a spreadsheet. However, most systems are far too complex for an analytical model. The only solution then is simulation.

Help Desk Common Issues by Annita Caniglia and Virginia Brassesco

If you are an habitual user of our Help Desk Portal the names Annita and Virginia might ring a bell. If you aren't, it's about time you register and let us know about your questions, issues and ideas on PetroVR.

We have often been asked by our coworkers at Caesar Systems which are the most usual topics discussed between Help Desk requesters and us girls. This question is not as simple as it may seem. So, we came up with a great (and in part stolen) idea.

Gaudí and Software Architecture by Leandro Caniglia

The internet has created the illusion that technology is something that time will constantly bring to us, no matter our temporal or spatial coordinates. But what if I told you that some form of art and technology can only be perceived and understood if we travel in space and back in time?

In September 2010 I had the opportunity to visit the Casa Batlló, a fascinating house built by the Spanish Architect Antonio Gaudí, in Barcelona, between 1904 and 1906.

I was so impressed that I had to take a few notes to put my thoughts in order. Today, about two years after that memorable experience, the emotions that the work of this incredible man awakened in me are still so vivid that I would like to share here a short summary of those notes. They outline some relationships between Traditional Architecture (if I'm allowed to use this term with Gaudí) and Software Architecture.

What does Probability Mean? by Pablo S. Armas

How much information can we get from our ignorance?

Odds are always present in our lives. When we board a plane, we do it because we believe that the probability of an accident is low. But what are the odds? What does it mean that when you toss a coin, the probability of getting heads is 50%?

The Power of PetroVR by Alejandro Murgia

We have just produced a new short video that shows that PetroVR represents the equivalent of more than seven different specialized software packages. The video provides the theoretical background behind the design of our software and mentions the disciplines and techniques of those families.

Speaking of videos...

Working Together or Collaborating? by Victor Koosh

Caesar Systems has always had the objective that PetroVR be used by teams rather than individuals.

Why is this important? Our focus is on Accelerating to Production by enabling insight generation for strategic decision-making. The E&P business is sufficiently complex that no individual understands all of the challenges and opportunities associated with an asset. To deal with this, organizations have created integrated teams. In our experience this has meant that technical or commercial people all work in the same proximity while performing individual tasks and meeting to communicate information. This of course is better than it was when everyone just did their own work and then handed results over the wall.

So, can this be improved?

Smart Arrays for a Happy New Year by Leandro Caniglia

This is a good time for sharing good news, anticipating things to come over the next twelve months and making S.M.A.R.T. resolutions for the New Year. I thought I might share with you a bit of the background of the latest developments in PetroVR.

PetroVR arrays are smart in many ways. For instance, they know how to operate with single quantities, functions, conditional logic, etc. Yet there is always a question our developers ask to themselves:  Can we do it better? In other words, could FML arrays be even smarter?

Recursive Expressions by Leandro Caniglia

In a recent post about Simulated Annealing I made a quick reference to the factorial operation. This quantity, namely n!, is defined as the product of all integer numbers between 1 and n:

n! = 1.2.3. … .(n-1).n

The definition of factorial is intrinsically recursive because:

factorial(n) = factorial(n - 1).n

which defines factorial in terms of itself. The recursion is solved because factorial(0) is declared to be 1.