Define initial saturation of model

[dipak_m]

Dear friends,

How I define initial saturation of the Petrel RE/ Eclipse model by using log Sw, without using SATNUM. I want to use single rel-perm and cap curve for this model.

thanks.

[vinomarky]

Dear friends,

How I define initial saturation of the Petrel RE/ Eclipse model by using log Sw, without using SATNUM. I want to use single rel-perm and cap curve for this model.

thanks.

You are not clear in your question;
Do you wish to use/upscale log derived saturations?

OR

Do you wish to use a rel perm/cap curve to initialize saturations?

They are not the same process......

Ideally, you would derive a cap curve / rel perm relationship that would honour your log derived saturations (as long as you believe them) and then initialize with this. If a simple relationship, you can probably do it all in Eclipse, otherwise you'd have to calculate the Swi's in Petrel and initialize the Eclipse model using these and endpoint scaling.

[temr]

Dipak
The exercise in terms of approach is quite simple
take one well and export to excel 3 curves ( make them as syntactical from model in petrel)
1. SStvd
2. Sw
3. Owc

Calculate 4 curve (PC) by following formula pc=(1-0.6)*0.098*Owc
you will get Capillary pressure as eclipse calculates it

then put all points to plot on y axes put Sw on x axes put Pc values
apply power trend and you will get following formula
y=a*x^b
So that what you are looking for
use this dependency in scal file and you will get the same saturation in your sim model of course if you will get high R2

[dipak_m]

Dear Term,

I will be thankfull to you if you give me some basic and detailed idea regarding initialisation of model. I know in this forum you are ony guy to do needful regarding this matter. I made a model in petrel. I want run simulation in Petrel RE. I know there are two ways to define initial saturation. 1. Using SATNUM as per saturation and using relperm and cap data. 2. Using only log derived saturation, no use of SATNUM. In this I have to give the initial pressure and Rs of the model. If I am wrong, correct me.

Plese give me the detailed procedure to define initial saturation of the model.

How I link cap data to relperm data as per SATNUM.

Plase help me.

Thanks

Dipak

[vinomarky]

There is nothing magical about SATNUM. It is simply an index with which you can assign different parts of your model different saturation characteristics. You may well be able to run your model with a single SATNUM for all your cells.

The process temr has tried to outline is a way to take your log saturations and work out a relationship which can be applied generically through the rest of your model

If you have good perm and/or you are not near the FWL, you may be able to get away without using cap pressures

First stop;
1. open a function window in Petrel
2. assign the log derived saturations as X axis
3. assign the log derived permeabilities as Y axis
4. Set Y axis to log scale

do you see something resembling a straight line?

If not, Create a HAFWL property HAFWL=FWL-Depth()

Use this property to colour code the above plot.... do you see a regular progression in colour or scatter?

What about creating a property = SQRT(K/Poro) and using this for the Y axis?

You are looking for a generic relationship that honors your log data which you can then apply to the rest of the model. Once you have such a relationship, depending upon the complexity you may be able to calculate initial saturation in Eclipse directly using the OPERATE keyword - if too complex, you'd calculate in Petrel then export SWL array and use endpoint scaling to initialize the model

[vinomarky]

Some other answers....

I made a model in petrel. I want run simulation in Petrel RE.

Just to clarify - Petrel RE is a module of Petrel that you can use to create an Eclipse deck. The simulation still runs in Eclipse, Petrel RE creates the deck, launches the Eclipse run, then retrieves the results for viewing

I know there are two ways to define initial saturation. 1. Using SATNUM as per saturation and using relperm and cap data. 2. Using only log derived saturation, no use of SATNUM. In this I have to give the initial pressure and Rs of the model. If I am wrong, correct me.

There are quite a few different ways to define initial saturation. The point 1. above is a valid method, but you don't necessarily have to use more than one SATNUM. Point 2. above is I think a bit mixed up. Again, whether or not you want to use SATNUM is irrelevant. You cannot simply use log saturations alone - you have to figure out a representative way to properly describe saturations through your entire model (not just at the wellbore). One way is as temr and myself have glossed over above in that you fit a relationship of initial saturation tied to any number of properties in your model such as permeability, porosity, HAFWL, facies etc.

In such a case, the simplest method is to simply create an array of SWL in either Petrel or via OPERATE in Eclipse (look up SWL and OPERATE in Eclipse manual) and initialize using endpoint scaling (lookup ENDSCALE keyword). You will probably need to add user keywords manually as Petrel RE does not provide GUI support for these sorts of methods.

In all cases, you will still need to give initial pressure of the model and Rs of fluid(s)

As a final piece of advice - Petrel RE is a nice tool to create calculated property arrays, get your grid, simply create faults etc... it is (IMHO) too cumbersome though for the majority of simulation work. I use it as needed for specific tasks, but the majority of my simulation workflow revolves around a good text editor (like TextPad), a good post processor such as S3 suite and if I want to pull out the 'big guns' an assisted history match tool such as Enable. I would strongly recommend you invest some time to better understand how to use Eclipse through a text editor - when you understand how the beast works, everything becomes much easier.

[dipak_m]

Dear Vinomarky,

I am new in simulation. Just try to understand the process. In my company the procedure adopted is given below
1. Derived the Sw from log
2. Define the SATNUM as per log Sw range( say, 20-30%-SATNUM-1, 30-40%-SATNUM-2 ect.........., not for region). So there are many SATNUM no.
3. Define different rel-perm as per SATNUM (using same relperm but changes Swi and Sor as per SATNUM)
4. This SATNUM is to define the model for initialisation
5. I think here Swi value of particular SATNUM is using to define initial Sw.

Is this correct method or not?

When you write earlier in my case no. 1, I should use one SATNUM. In this case I have to use one relperm and cap data. So in this case log derived Sw is required or not? If not, how model is read the Sw?

Thank you so much for your contribution.

[vinomarky]

That method is certainly valid - depending on your situation (ie ok for blocky sands with uniform saturation), and to what degree of accuracy you need it may well be the best method. I however usually find it a bit coarse in defining saturations and somewhat finicky.

Instead of creating a multitude of SATNUM's, each with their own discrete Swi and Sor, if you can fit a equations of Swi and Sor as a function of (usually) permeability, then you can give Eclipse one set of rel perm curves, and either (a) arrays of Swi and Sor or (b) tell it how to calculate Swi and Sor at run time using the OPERATE feature. You then give it the ENDSCALE keyword, and Eclipse will look at each cell in your model and scale that single rel perm curve to suit its Swi/Sor.... in this way by defining essentially the general shape of the rel perm function, and giving it the saturation endpoints for each cell you are defining (for 100,000 cells) 100,000 rel perm curves.

Here is a simple example of a case where I used the OPERATE keyword to define initial saturations, which it turn Eclipse would use to scale rel perm endpoints (I had one set of rel perm curves) - I used constant Sor

First it calculates SWL = 0.7107 x PERMX^-0.2131 (This is case specific, you'd have to find what relationship works for you)
Then, it ensures that no value of SWL exceeds 0.45
Then, it ensures no value is less than 0.12
Then it calculates SGU as 1 - SWL
Then it copies SWL array into the SWCR array (no initial mobile water)


OPERATE
-- for MULTA: output = a x input + b
-- for MULTP: output = a x input ^ b
-- output I1 I2 J1 J2 K1 K2 operate input a b
SWL 6* 'MULTP' PERMX 0.7107 -0.2131 /
SWL 6* 'MAXLIM' SWL 0.45 /
SWL 6* 'MINLIM' SWL 0.12 /
SGU 6* 'MULTA' SWL -1 1 /
/

COPY
SWL SWCR /
/

I'm not saying one way is ALWAYS better than the other, but it would be good for you to understand both.

[itag]

Folks
The most common form of initialization in Eclipse relies on Capillary-gravity equilibrium using the EQUIL keyword. ( There are other ways/options - but this method is the most common/reliable and generally most advisable is starting a simulation from scratch). The EQUIL option uses the supplied Pc vs Sw ( for Oil-water) to determine Sw in every cell above the OWC by casting it as H vs Sw and solving for Sw. Eclipse uses the relative permeability curves to determine whether the 'transition zone' Sw's are mobile or not and supplies many options to alter behavior if required. What is described here asserts that using the EQIL keyword Eclipse defines Sw implicitly from the Pc ( and rel-perm data). BTW even if Pc=0 everywhere - then initializing to capillary gravity equilibrium stuill takes place - its just becomes very simple.

This means that Sw itself (if using the EQUIL option) should never be exported from Petrel to initialize a simulation ( again emphasizing under the assumption of capillary gravity equilibrium) as the simulator needs to establish this equilibrium itself. ( Eclipses geometry for cell volume etc is slightly different to Petrel so you will never get precisely the same oil volumes but you will be very, very close)

Other replies have mentioned use of RELPERM scaling and J functions - these are all valid - but the first thing to appreciate is that Eclipse needs Pc and endpoints first - and it recalculates Sw itself. The only reason Sw is calculated in Petrel is to enable volumetrics to be done in Petrel - once its done there - the engineer doesn't use/need Petrel Sw's. Most folk find this result/recommendation very confusing at first. Much of the earlier advice was suggesting way of estimating what the Pc function you need should look like.

You mention use of SATNUMs to bin rel-perm by initial Sw's ; while this may be a valid approach - if a single Pc or J function ( or simple relperm scaling) works then history matching with 1 set of rel-perms is so much easier to work with. If you end up with 10-to20 sets of relperms ( I have seen studies do this!) then the model becomes unworkable - and likely not useful. I'm not saying there's a right and wrong way of doing things - other than point out that keeping things simple/clean has advantages later. I have never seen a model with 10-to-20 saturation sets history matched ( but I've seen plenty that use just 1 or 2).

THe simplest Eclipse model just needs 1 set of rel-perms curves ( say for O-W and maybe SL-Gas) - with Pc=0. Eclipse just initializes cells using the endpoints found in the relperm curves. ( It doesn't need to be told saturations). See ?

itag

[vinomarky]

Sounds like you also speak from some experience. Many points you raise I agree with, but we'll have to agree to disagree on a few of them. My logic below;

The most common form of initialization in Eclipse relies on Capillary-gravity equilibrium using the EQUIL keyword. ( There are other ways/options - but this method is the most common/reliable and generally most advisable is starting a simulation from scratch).

Agree - the method I outlined above still uses the EQUIL keyword. It just assumes that you are out of the transition zone and so are simply describing a relationship of SWCR vs Permeability

This means that Sw itself (if using the EQUIL option) should never be exported from Petrel to initialize a simulation ( again emphasizing under the assumption of capillary gravity equilibrium) as the simulator needs to establish this equilibrium itself.

Strongly disagree with the 'never' assertion.

Other replies have mentioned use of RELPERM scaling and J functions - these are all valid - but the first thing to appreciate is that Eclipse needs Pc and endpoints first - and it recalculates Sw itself.

That is one option, but you CAN do the opposite as well (ie endpoint scale a single Pc curve to honour given initial Sw's)

The only reason Sw is calculated in Petrel is to enable volumetrics to be done in Petrel - once its done there - the engineer doesn't use/need Petrel Sw's.

Disagree. While what you say is often correct, for fitted capillary pressure functions that are more complex that a J-function (ie Lambda function etc), Eclipse CANNOT initialize these correctly - you are then faced with either putting in a diiferent capillary pressure curve for each cell OR passing to Eclipse the calculated SWL/SWCR/SWU etc honoring the complex capillary pressure regime and height above FWL of that cell, then asking Eclipse to scale not only the endpoints for the rel perm, but the capillary pressure curves so that at initialization everything is still (a) honouring the measured saturations and (b) in static equilibrium

You mention use of SATNUMs to bin rel-perm by initial Sw's ; while this may be a valid approach - if a single Pc or J function ( or simple relperm scaling) works then history matching with 1 set of rel-perms is so much easier to work with. If you end up with 10-to20 sets of relperms ( I have seen studies do this!) then the model becomes unworkable - and likely not useful.

Strongly agree - I never use more than 3 SATNUM regions, and usually just one. The corrolary though if you do not use endpoint scaling (meaning giving Eclipse initial Saturations) is that if you only use (for example) one SATNUM and capillary curve, your 1mD rock at 10m above free water level (FWL) has exactly the same initial saturation as your 100mD rock at 10m above FWL...... the only way to get around this with one SATNUM is to either use a J-function or (if J-function does not provide a decent fit) calculate the appropriate initial saturations in Petrel (or if possible in Eclipse via OPERATE), pass them to Eclipse and ask it to scale the cap pressure curves in each cell to ensure equlibrium

THe simplest Eclipse model just needs 1 set of rel-perms curves ( say for O-W and maybe SL-Gas) - with Pc=0.

Agree

Eclipse just initializes cells using the endpoints found in the relperm curves. ( It doesn't need to be told saturations).

For simple models agree. For complex saturation models disagree

Again, I don't disagree with many of the points you raise, just with the absolute statements of 'never' etc... as you know there are always exceptions and cases where different techniques should be used. From your comments I would guess that you work in a high perm area where transition zones are small and/or relief is large. When you work with reservoirs in the less than 10mD range and structures in the 10-30m relief range, then using a single cap pressure curve without endpoint scaling to initial saturations will simply be wrong. Hydrocarbons in place will not be honoured, and initial mobile water will be simulated when mostly they are not observed.

[itag]

Vinomarky
I think you may have misunderstood my wording. When I say "never" export Petrel Sw's - I am meaning; never export that as an "SWAT" array into Eclipse when doing EQUIL initialization ( my apologies for not making that 100% clear) . Endpoint values for relperm scaling (SWL, SWU etc are another matter - and would not be the Sw's calculated in Petrel using whatever sat-height functions of choice). In this case of Petrel Sw's=SWAT input into Eclipse using an EQUIL keyword : "never" is applicable. Let me know if you still disagree.
I was also attempting to answer the original posters question: 1 relperm, 1 Pc. Your observations about real reservoirs offering more complicated situations, is valid.

itag

[itag]

BTW - in the case when log Sw displays a largish transition zone; try this if your goal is 1 relperm and 1 Pc curve. What was said earlier about k vs Sw works above the transition ( and needs relperm scaling to implement)

I will assume you have a simple oil-water contact and a reasonable transition zone
1. Calculate HAWFL variable as noted = z_OWC - Z ( Z is depth and depth is +ve)
2. Plot HAWFL vs Sw_av where Sw_av is either point value of Sw or suitable block_averaged Sw (note av Sw=sum(phi.sw_i)/sum(phi_i)
3. This last Plot should/might look like a Pc curve if you zoom into the region around & above the FWL ( you may have to filter out some low perm values to clean the plot up a bit)
4. By hand if necessary draw/make a single H vs Sw curve ( the Sw asymptote will be SWCR in Eclipse speak). You may want to bias your curve to the "pay" facies.
5. Now use your PVT oil and water densities to calculate( Delta) water - oil density ( in lb/ft3 say). convert to psi/ft by dividing by 144 ( # might be around 0.2 psi/ft)
6. Convert H to Pc by Pc = delta*H ( where H measured in ft) & Pc will be in psi

You now have an averaged Pc curve that will initialize Eclipse to the average curve you drew. ( ie Eclipse will calculate the same Sw's at a given HAWFL)
This can be generalized to different perm bins if needed. On the other hand, if you scale H*= Hawfl*sqrt(k/phi) and plot H* vs Sw it may make for a nicer plot - then you may find a single Leverett J function works.
( A J function scales Pc for different k/phi ..... not universal in practice - but it usually helps- and it is still simple to implement with a single relperm set.( J functions ultimately allow calculation of Pc, and HAWFL/H* )
( Anything more accurate that J functions in Eclipse will require rel-perm scaling options and possibly separate lithofacies classes - and this is starting to get complex)

Your water krw curve will now dictate the initial water movement in this Pc/J environment. You have to tell eclipse whether your saturation function input data is Pc or J ( as it goes in the same column)

With 1 relperm and 1 Pc/J you can do a "fair" job at reproducing the Sw trends. More complicated/accurate cases will require scaling options ..... which I wouldn't recommend for a new Eclipse user)

Hope these replies are helpful.
itag